Un client nous a contactés l'an dernier pour un tableau de bord de reporting personnalisé. Il avait une vision précise en tête - des graphiques, des filtres, des tableaux exportables. Il avait même réalisé des maquettes sommaires. Cela ressemblait à un projet simple.
Nous avons passé une semaine à cartographier comment les données circulaient réellement dans son entreprise avant d'ouvrir un éditeur de code. Ce que nous avons découvert a tout changé. Le problème n'était pas l'absence de tableau de bord. Le problème était que les données alimentant tout tableau de bord auraient été erronées, parce que les personnes chargées de la saisie suivaient quatre conventions différentes sans standard partagé. Un beau tableau de bord construit sur des données mauvaises n'aurait été qu'un moyen coûteux d'afficher des chiffres inexacts plus rapidement.
Nous l'avons d'abord aidé à corriger le processus de saisie de données. Le tableau de bord est venu ensuite, plus simple et moins cher que prévu initialement, et réellement utile dès le premier jour.
C'est pourquoi nous commençons toujours par un audit des processus.
Ce qu'est réellement un audit des processus
Le nom évoque un long et coûteux engagement de conseil. Ce n'est pas le cas.
Un audit des processus est un exercice ciblé et limité dans le temps - généralement une à deux semaines - fondé sur des entretiens structurés et une observation directe. L'objectif est de comprendre comment le travail circule réellement dans l'entreprise : qui fait quoi, dans quel ordre, avec quelles informations, et où les choses se grippent.
Nous cartographions les transferts de responsabilités. Nous regardons où les décisions sont prises et de quelles informations elles dépendent. Nous cherchons où le travail se bloque, se duplique ou se perd. Nous examinons les outils déjà utilisés et la façon dont ils sont réellement utilisés, par opposition à la façon dont ils étaient censés l'être.
Pas de longs rapports. Pas de cadres méthodologiques pour le principe. Le résultat est une image claire de l'endroit où se trouve la vraie friction et quelle intervention aurait le plus d'impact.
Ce que nous cherchons
Chaque entreprise a sa propre version des mêmes problèmes. Nous recherchons :
Les goulots d'étranglement - des étapes dans un processus où le travail s'accumule parce qu'elles dépendent d'une seule personne, d'un seul outil ou d'une seule décision qui ne peut pas suivre le volume entrant.
Les étapes manuelles qui existent parce que personne ne les a remises en question - des données copiées manuellement d'un système à un autre, des approbations faites par WhatsApp faute de workflow adapté, des rapports assemblés chaque lundi matin à partir de cinq tableurs différents.
Les données dupliquées - des informations clients dans le CRM, dans le système comptable et dans un tableur personnel, toutes légèrement différentes, aucune n'étant définitivement juste.
Les décisions prises à l'aveugle - des responsables qui fixent les niveaux de stock, les effectifs ou les prix sans données fiables, ou avec des données qui arrivent trop tard pour être utiles.
Ce ne sont pas des problèmes exceptionnels. Ils se retrouvent dans presque toutes les entreprises avec lesquelles nous travaillons. La question n'est pas de savoir s'ils existent - c'est lesquels coûtent le plus et lesquels un logiciel peut réellement résoudre.
Ce que l'audit change
Le résultat d'un bon audit des processus confirme rarement le plan initial. Le plus souvent, il modifie trois choses.
Premièrement, le périmètre. Ce que le client avait demandé est soit trop large, soit trop étroit, soit mal ciblé. Un client qui voulait un système complet de gestion des stocks peut découvrir que 70 % de sa douleur vient d'un goulot d'étranglement spécifique qui pourrait être résolu avec un outil bien plus simple. Ou il découvre que le périmètre doit s'élargir parce que le problème décrit est en aval d'un problème structurel plus important.
Deuxièmement, l'ordre. Même quand la vision initiale est globalement juste, la séquence dans laquelle les choses sont construites a de l'importance. Un audit des processus révèle quelles parties d'un système bloquent tout le reste et doivent être construites en premier. Construire dans le mauvais ordre signifie que les parties ultérieures ne sont jamais utilisées parce que les fondations n'étaient pas bonnes.
Troisièmement, l'approche. Parfois, l'audit révèle que le problème ne nécessite pas de logiciel sur mesure du tout. Un outil existant, correctement configuré et réellement adopté, ferait l'affaire. C'est une conclusion inconfortable quand un client s'attendait à commander un développement - mais c'est la conclusion honnête, et elle permet d'économiser beaucoup d'argent.
Pourquoi la plupart des agences sautent cette étape
La réponse est simple : cela retarde le début du développement facturable.
Une agence qui gagne de l'argent en construisant a une incitation structurelle à commencer à construire le plus vite possible. La phase de découverte - comprendre le problème avant de proposer une solution - est un centre de coûts qui retarde les revenus.
Nous pensons que c'est une fausse économie, pour nous comme pour les clients. Les projets construits sans découverte sérieuse sont plus susceptibles de nécessiter des refontes importantes, des changements de périmètre et des conversations difficiles plus tard. C'est coûteux pour le client et dommageable pour la relation. Nous préférons passer deux semaines à comprendre le problème et construire la bonne chose une seule fois.
Ce que vous perdez si vous sautez cette étape
Le schéma est constant : une entreprise identifie un point de douleur, commande une solution logicielle, la solution est construite, les gens essaient de l'utiliser, et il s'avère que la solution ne correspond pas à la façon dont le travail circule réellement. Le système nécessite des contournements. Les gens reviennent à leurs anciennes habitudes. Le projet est déclaré terminé mais le problème n'est pas résolu.
Vient alors la conversation sur la refonte. Plus d'argent, plus de temps, et maintenant une équipe sceptique parce qu'elle a déjà vécu ça une fois.
Nous avons hérité de suffisamment de ces situations pour savoir comment elles se produisent. Presque toutes auraient pu être évitées avec un audit sérieux des processus au départ. Pas un exercice de case à cocher - un regard réel et honnête sur le fonctionnement de l'entreprise avant de décider quoi construire.
Notre approche
Chaque projet que nous prenons en charge commence par un audit des processus. Ce n'est pas optionnel et ce n'est pas décoratif. C'est la fondation sur laquelle tout le reste est construit.
Nous organisons des entretiens structurés avec les personnes qui font réellement le travail - pas seulement des responsables décrivant comment ils pensent que les processus fonctionnent, mais les personnes sur le terrain qui savent où se trouve la vraie friction. Nous observons les workflows lorsque c'est possible. Nous regardons quelles données existent, où elles se trouvent et dans quelle mesure elles sont fiables.
Le résultat est un brief clair : quel est le vrai problème, ce que nous recommandons de construire, dans quel ordre, et pourquoi. Ce brief guide ensuite tout le reste - le périmètre, le calendrier, l'architecture.
Ce n'est pas la phase la plus excitante d'un projet. Mais c'est celle qui détermine si le projet réussit.
Si vous envisagez un investissement logiciel et souhaitez commencer par bien comprendre le problème, contactez-nous.