Ingénierie de process

Remettre vos process d'aplomb
avant d'acheter un logiciel

Un logiciel installé sur une organisation floue ne la clarifie pas : il la fige. Je pose à plat ce qui se fait réellement, je conçois la cible avec vous, et je la transmets à vos équipes. Le choix de l'outil vient après — s'il vient.

Le point de départ

Le symptôme est toujours le même

Deux personnes détiennent la connaissance réelle de la chaîne, et personne ne l'a écrite. Les commandes passent par un fichier partagé que quelqu'un a créé un jour. Le devis se refait à la main parce que l'outil « ne sait pas faire ». Les mêmes informations sont saisies trois fois, à trois endroits, sous trois orthographes.

La réaction classique consiste à chercher un logiciel. C'est souvent le bon réflexe au mauvais moment : un outil ne fait que rendre exécutable ce qui a été décidé avant lui. Tant que la décision n'est pas prise, l'outil la reporte — et facture le report.

L'ingénierie de process, c'est ce travail-là. Décider avant d'outiller.

Les contournements sont la matière première du diagnostic, pas un défaut à cacher.

Déroulé

Trois temps, puis on décide

01 · Entretiens et pièces réelles

Diagnostic de l'existant

Je parle aux personnes qui font le travail, et je regarde les fichiers qu'elles utilisent vraiment — y compris ceux qui ne sont pas officiels. Les doubles saisies, l'export qu'on refait tous les lundis, le tableur qui ne devrait plus exister : c'est là qu'est le process réel, pas dans la procédure.

02 · Le cœur de la mission

Conception de la cible

Qui fait quoi, dans quel ordre, avec quelle donnée, et qui en répond. Les règles de gestion sont écrites noir sur blanc, exceptions comprises — ce sont elles qui font dérailler les outils, parce qu'elles ne sont jamais dans le cahier des charges.

03 · Jusqu'à l'autonomie

Transmission

Ce que je livre, vos équipes doivent pouvoir le tenir sans moi. La documentation et la transmission font partie de la mission, pas d'une option. Un process que seul le consultant comprend n'existe pas.

Livrables

Ce que vous récupérez,
et qui vous reste

Des documents que vous pouvez montrer à n'importe quel prestataire, et qui gardent leur valeur si vous ne travaillez plus avec moi.

Les flux
La cartographie des flux, de la demande client à l'encaissement, avec les points de rupture classés par coût et par effort. On voit ce qui coûte cher et se répare vite, et ce qui coûte cher et demandera du temps.
Les règles
Les règles de gestion écrites et opposables, exceptions comprises. C'est le document qu'on ressort quand deux services ne sont pas d'accord sur qui valide quoi.
Les référentiels
Ce qu'est un client, un article, un chantier, chez vous. Sans cette définition, tout rapport produit plus tard sera contesté — et il aura raison de l'être.
Les responsabilités
La répartition des rôles, sans zone grise. Une étape sans responsable nommé est une étape qui n'aura pas lieu.
La spécification
Un document d'outillage utilisable pour consulter n'importe quel prestataire, avec le tri entre ce qui doit être outillé, ce qui peut rester manuel, et ce qui doit simplement disparaître. Plus un avis franc quand la réponse est « vous n'avez pas besoin de logiciel ».

Et si l'outillage passe par Odoo

Je le mets en place moi-même : paramétrage fonctionnel, automatisations sans code, administration courante. Voir la page Odoo →

Qualification

À qui ça sert vraiment

C'est pour vous si

  • Vous avez grandi plus vite que votre organisation.
  • Vous envisagez un logiciel de gestion et voulez savoir quoi lui demander.
  • Un précédent projet d'outillage a échoué, et vous ne savez pas exactement pourquoi.
  • Une fonction clé repose sur une seule personne.
  • Une reprise, une cession ou l'arrivée d'un associé approche.

Ce n'est pas pour vous si

  • Vous cherchez la validation d'une décision déjà prise.
  • Vous voulez une certification : ce n'est pas mon métier.
  • Le sujet réel est un désaccord humain qu'un process ne résoudra pas.
  • Vous êtes un particulier. Entreprises et organisations uniquement.

Questions

Ce qu'on me demande sur les process

Non, c'est même l'inverse. Un outil ne fait que rendre exécutable ce qui a été décidé avant lui ; tant que la décision n'est pas prise, il la reporte et facture le report. La spécification que je produis sert justement à consulter plusieurs prestataires sur une base comparable — et parfois à conclure qu'aucun logiciel n'est nécessaire.
Les deux, mais pas au même moment. Le diagnostic se fait avec ceux qui font le travail, parce que le vrai process est dans leurs contournements. Les arbitrages se font avec ceux qui peuvent décider. Confondre les deux temps produit soit un état des lieux complaisant, soit une cible que personne n'appliquera.
Cela dépend du nombre de personnes à écouter et de l'état des pièces existantes. Ce qui est fixe, c'est l'ordre : je ne propose rien avant d'avoir parlé à ceux qui tiennent l'activité et regardé les fichiers qu'ils utilisent vraiment, y compris ceux qui ne sont pas officiels.
Alors un process ne le résoudra pas, et je le dis avant de commencer plutôt qu'à la livraison. Un désaccord entre deux personnes qui ne veulent pas travailler ensemble ne se règle pas par un organigramme de flux. Écrire des règles de gestion peut rendre le désaccord visible ; ça ne le tranche pas.
Non, ce n'est pas mon métier. Je conçois des process pour qu'ils fonctionnent et pour qu'ils soient outillables, pas pour satisfaire un référentiel de certification. Les deux se recoupent souvent, mais viser la conformité comme objectif produit de la documentation que personne n'ouvre.

Décrivez-moi la situation

Quelques lignes suffisent pour savoir s'il y a matière. Je vous réponds sous 48 h avec un premier avis, y compris lorsqu'une intervention ne vous serait pas utile.

Décrire ma situation →