Il existe une version de cette histoire dans presque toutes les fonctions finance où nous sommes entrés. Ce n’est jamais un échec technologique. C’est un échec de traduction, et il se produit à un endroit prévisible.
La contrôleuse financière connaît la règle. Demandez-lui pourquoi la tolérance sur le prix d’achat est de 2 % et elle vous dira que le fournisseur d’acier facture à la tonne alors que le chantier commande au kilo : il y a toujours un écart d’arrondi, et 5 % laissait passer de vraies erreurs. Elle le sait depuis quatre ans. Ce n’est écrit nulle part.
Le développeur sait tout construire. Donnez-lui un cahier des charges et il livrera à temps. Ce qu’il ne peut pas savoir, c’est qu’une écriture sur le mauvais compte collectif fausse l’élimination intragroupe de mars, parce que personne ne lui a jamais expliqué ce qu’est une élimination et qu’il ne viendrait à l’idée de personne de le mentionner.
Alors le projet est cadré. La finance rédige ses besoins en langage comptable. L’informatique les lit comme des flux de données. Les deux côtés croient s’être mis d’accord. Six semaines plus tard vient la démo, et la contrôleuse prononce les mots qui mettent fin à la plupart des projets d’automatisation :
« Ce n’est pas tout à fait ce que je voulais dire. »
Le cahier des charges n’est pas le problème
La réponse habituelle consiste à écrire un meilleur cahier des charges. Plus de détails, plus de validations, plus d’ateliers. Cela marche rarement, car la connaissance manquante n’est pas de celles qui survivent quand la personne qui la détient l’écrit pour celle qui ne l’a pas.
Essayez vous-même. Écrivez la règle qui dit quelles factures fournisseurs exigent un bon de commande et lesquelles non. Vous produirez trois lignes. Puis quelqu’un vous interrogera sur les fluides, l’assurance annuelle, l’avocat qui facture par numéro de dossier plutôt que par bon de commande, et le fournisseur qui envoie un relevé au lieu d’une facture parce qu’il le fait depuis 2011. Vos trois lignes deviennent deux pages, et elles restent incomplètes, car la vraie règle réside dans un jugement que la contrôleuse exerce sans même s’en rendre compte.
Ce jugement est la partie précieuse. C’est aussi la partie qu’un cahier des charges ne peut pas transporter.
Ce qui se transmet vraiment
Trois choses transmettent cette connaissance de façon fiable, et aucune n’est un document.
Observer le travail. Asseyez-vous une matinée à côté de la personne qui le fait. Pas un atelier — le vrai travail, avec les vraies exceptions. Chaque fois qu’elle hésite, demandez pourquoi. Les hésitations sont les règles.
Partir de l’historique plutôt que de l’intention. Ne demandez pas comment les factures devraient être imputées. Regardez comment les douze dernières de ce fournisseur l’ont été. Le grand livre est un témoin bien plus honnête de la règle que la description qu’en fait quiconque, y compris la contrôleuse.
Fonctionner en parallèle avant de donner la moindre autorité. Laissez l’automatisation faire le travail aux côtés de l’équipe, sur des données réelles, sans rien comptabiliser. Chaque écart entre ses résultats et les leurs est une règle que vous avez mal comprise, révélée tant qu’elle coûte encore peu. C’est de loin ce que vous pouvez faire de plus utile, et la plupart des projets le sautent parce que cela ressemble à faire le travail deux fois. C’est faire le travail deux fois. C’est tout l’intérêt.
La solution structurelle
Ces trois choses sont plus faciles quand la personne qui écrit l’automatisation sait lire une balance générale. Non que les Chartered Accountants fassent de meilleurs développeurs — en général, non — mais parce que l’étape de traduction disparaît. Il n’y a pas de document de passation, parce qu’il n’y a pas de passation.
Ce n’est pas affirmer que toute équipe d’automatisation a besoin d’un Chartered Accountant. C’est une affirmation sur l’endroit où placer la jointure. S’il faut deux personnes, placez la jointure là où une erreur coûte peu — à la couche d’intégration, par exemple, pas entre « à quoi sert le contrôle » et « ce que fait le code ».
Placez la jointure au mauvais endroit, et vous obtenez la démo, la phrase et les six semaines.