Digitaliser un processus cassé : l'erreur que commettent 80% des projets SI en PME
Un processus dysfonctionnel mis dans un outil ne se répare pas. Il se perpétue plus vite. La majorité des projets SI en PME ne résolvent pas les problèmes d'organisation parce qu'ils les digitalisent avant de les avoir nommés.
Donatien Lefranc
Fondateur & Président, Leando
La phrase qu'on entend avant presque tous les projets SI qui dérivent
« On va mettre ça dans un outil et ça ira mieux. » Cette phrase précède plus de la moitié des projets SI qui se retrouvent à refaire des ateliers dix-huit mois après la mise en production. Pas parce que l'outil était mauvais. Parce que le problème qu'on voulait résoudre n'était pas un problème d'outil.
La digitalisation résout les problèmes de vitesse et de traçabilité.Elle ne résout pas les problèmes de définition, de responsabilité ou d'organisation. Si votre processus de validation des devis est lent parce que personne n'a l'autorité de le signer sans consulter trois personnes, un outil de signature électronique accélérera les échanges et laissera le blocage décisionnel intact.
Le processus n'était pas cassé par manque d'outil. Il était cassé par un manque de clarté sur qui décide quoi. Mettre un outil autour d'un tel processus rend simplement le dysfonctionnement plus visible et plus rapide, ce qui n'est pas la même chose que le corriger.
Ce qui se passe quand on digitalise un processus informel
Un processus informel est un processus dont les règles vivent dans les habitudes des équipes plutôt que dans une documentation ou une décision explicite. Quand vous demandez à deux collègues comment se passe la validation d'une commande, vous obtenez deux descriptions différentes. Aucune n'est fausse : elles reflètent deux adaptations locales d'une règle que personne n'a jamais formalisée.
Quand vous mettez ce processus dans un outil, vous êtes obligé de faire des choix. Quel champ est obligatoire ? Qui peut modifier une ligne après validation ? Quel statut déclenche quelle notification ? Chaque choix d'implémentation est une décision organisationnelle déguisée en paramétrage technique.Ces décisions sont prises par les développeurs ou les intégrateurs, souvent sans que la direction soit consciente qu'une décision organisationnelle vient d'être prise.
« Souvent ce ne sont pas des sujets tech. C'est souvent un sujet organisationnel, systémique, et ensuite en effet technologique. »
Le résultat est un outil dont les règles encodées ne correspondent pas aux pratiques réelles des équipes. Ces équipes contournent l'outil pour faire leur travail correctement. Le taux d'adoption chute. La direction conclut que le problème vient de la résistance au changement, alors que le problème vient d'un outil qui ne correspond pas au métier.
Comment reconnaître un processus prêt à être digitalisé
Les signaux d'un processus non formalisé
Trois indicateurs permettent d'évaluer la maturité d'un processus avant de lancer un projet d'outillage. Le premier : la variabilité inter-opérateurs. Si la façon de faire varie significativement selon qui exécute la tâche, le processus n'est pas formalisé. La digitalisation choisira arbitrairement l'une des variantes et créera de la friction pour tous ceux qui font autrement.
Le deuxième indicateur : la fréquence des exceptions non documentées.Tout processus métier a des cas particuliers. Si ces cas ne sont pas listés et traitables par règle explicite, l'outil ne saura pas quoi faire et les équipes créeront des contournements. Le troisième indicateur : la présence de personnes-clés dont le départ poserait un problème immédiat de fonctionnement. Ces personnes portent des règles métier que personne d'autre ne connaît. Un outil ne peut pas les remplacer sans les avoir d'abord explicités.
Pour aller plus loin sur le diagnostic des signaux qui indiquent un SI qui freine la croissance, notre analyse des 6 signes que votre SI freine votre croissance vous donnera un cadre applicable dès cette semaine.
La séquence qui produit un outil qui s'utilise
La méthode qui fonctionne part du terrain, pas du cahier des charges. La première étape est une observation des processus réels : comment le travail se fait aujourd'hui, pas comment il devrait se faire théoriquement. Cette observation produit une carte des pratiques existantes, avec leurs variations, leurs exceptions, et leurs dépendances informelles.
La deuxième étape est la formalisation : décider, avec les parties prenantes, quelles sont les règles qui s'appliquent, qui a l'autorité de les faire évoluer, et comment les exceptions sont traitées. Cette étape est organisationnelle, pas technique. Elle peut prendre deux à quatre semaines selon la complexité du processus.
C'est seulement une fois ce travail fait qu'un outil peut être conçu utilement.Sur un projet PME avec lequel nous avons travaillé dans le spectacle vivant, trois ateliers de formalisation ont suffi avant deux semaines de développement pour produire un POC fonctionnel, avec un retour sur investissement en six à sept mois. La rapidité d'exécution était directement liée à la clarté des règles métier avant le premier développement.
La méthode qui permet de naviguer entre observation terrain, formalisation et développement progressif est détaillée dans notre article sur l'automatisation de processus métier en PME par l'approche lean.
La prochaine fois qu'un projet SI vous est présenté, posez une question simple avant de valider le budget de développement : est-ce que les règles métier du processus visé ont été formalisées et validées par les équipes terrain ? Si la réponse est non, commencez par là.
Questions fréquentes
Un processus est prêt quand ses règles de fonctionnement sont explicites et stables. Concrètement : si vous pouvez décrire en une page comment une tâche se déroule du début à la fin, avec les exceptions et les cas particuliers, sans avoir à demander à une personne spécifique, le processus est formalisé. Si la description varie selon qui vous interrogez, le processus n'est pas encore prêt.
Votre prochain projet SI mérite un diagnostic avant le premier développement
Un échange d'une heure permet de distinguer ce qui relève d'un problème organisationnel de ce qui relève d'un problème d'outil. C'est souvent les deux, dans cet ordre.
Prendre un premier rendez-vous