N'automatisez pas un processus désordonné

Une direction signe pour un nouveau système parce que le traitement des commandes est trop lent. Six mois plus tard, ce même traitement des commandes se bloque encore, mais désormais sur une plateforme plus coûteuse. Les étapes qui le ralentissaient sont toujours là, soigneusement intégrées. Ce qui a été accéléré, c'est l'erreur.

Un logiciel accélère un processus. Il ne l'améliore pas. Cette distinction paraît mince et pourtant elle détermine si un investissement rapporte ou brûle de l'argent. Qui automatise un processus désordonné rachète le même travail : la même double saisie, le même temps d'attente, les mêmes exceptions, désormais coulés dans le béton et facturés par utilisateur.

La règle que Bill Gates écrivait déjà en 1999

Il existe une phrase sur l'automatisation plus ancienne que la plupart des logiciels que vous utilisez aujourd'hui, et qui reste vraie.

Automatiser un processus efficace augmente l'efficacité. Automatiser un processus inefficace augmente l'inefficacité.

Bill Gates l'a écrit dans Business @ the Speed of Thought (1999), et ce n'est pas un jeu de mots mais un avertissement. Un logiciel prend un processus tel qu'il est et l'exécute plus vite, plus souvent, à un coût plus bas par opération. Si ce processus est bon, vous gagnez sur chaque opération. S'il est désordonné, vous mettez le désordre à l'échelle et vous payez désormais plus vite pour la même erreur.

Faites le calcul. Une opération que vous faites aujourd'hui trois fois par jour de travers, un système la fera bientôt trente fois par jour de travers, car une machine ne connaît ni doute ni pause. L'erreur ne devient pas plus visible, elle devient moins chère à l'unité et plus grande au total. C'est précisément pourquoi certaines entreprises perdent, après une implémentation coûteuse, plus de temps en exceptions qu'auparavant : elles ont mis un mauvais processus à l'échelle au lieu de le résoudre.

À quoi ressemble le désordre avant que vous ne l'automatisiez

Le désordre est rarement spectaculaire. C'est une étape introduite un jour et que plus personne n'ose supprimer. Une commande immobilisée trois jours sur une approbation dont plus personne ne se souvient. Deux services qui ressaisissent les mêmes données dans deux écrans, parce que le lien entre les deux n'a jamais été établi.

Souvent, le gaspillage ne se trouve pas dans l'action elle-même, mais dans la recherche qui l'entoure. Le McKinsey Global Institute a chiffré dans The Social Economy (2012) que les travailleurs du savoir consacrent près de 20 % de leur semaine de travail, environ une journée, à chercher et rassembler de l'information interne, et que les travailleurs d'interaction consacrent environ 28 % au courrier électronique. Si vous coulez ce processus dans un logiciel sans le nettoyer d'abord, vous y intégrez soigneusement cette recherche et ce trafic de messages.

D'abord le processus, le logiciel ensuite

C'est pourquoi, chez nous, le travail ne commence pas par un outil, mais par le processus. Un audit de processus consigne comment le travail se déroule réellement aujourd'hui, étape par étape, avec les temps d'attente et le travail en double. Non pas comment il devrait se dérouler selon le manuel, mais comment il se déroule un mardi ordinaire, avec les exceptions que tout le monde connaît et que personne ne note.

Ensuite, vous supprimez. Une étape qui n'apporte rien s'en va. Deux personnes qui saisissent la même chose, cela devient une seule saisie. Une approbation immobilisée pendant des jours reçoit une limite ou disparaît. Ce n'est qu'une fois le processus en place que vous savez ce que vous devez réellement faire construire, et c'est le plus souvent moins que prévu.

Cette suppression n'est pas la partie agréable et c'est pourtant celle qui rapporte le plus. Retirer une étape ne coûte ni licence ni implémentation. Cela coûte une conversation et une décision. Chaque étape qui disparaît ainsi, vous n'avez ensuite plus à la construire, ni à l'entretenir, ni à la payer, année après année. Le logiciel le moins cher est celui que vous n'avez pas à créer parce que le travail en dessous fonctionne déjà.

Le prix de ce nettoyage se rembourse de lui-même, car sur un processus propre, le gain de l'automatisation devient soudain bien réel.

Ce qui reste après le nettoyage, YK le construit sous forme de modules sur une seule plateforme open source dont vous êtes propriétaire. Ainsi le gain atterrit chez vous, dans un délai plus court et moins de travail manuel, et non dans une licence qui continue de grimper par utilisateur.

Et vous ne construisez pas tout d'un coup. Chaque partie avance par vagues, avec un feu vert ou un feu rouge à chaque étape. Si le processus nettoyé fonctionne en conditions réelles, vous construisez le suivant. S'il ne fonctionne pas, vous vous arrêtez avant de couler un deuxième processus désordonné dans un logiciel.

Le logiciel suit le processus, et non l'inverse. Qui inverse cet ordre achète de la vitesse sur une erreur et la paie pendant des années. Qui le respecte se retrouve au bout avec moins d'étapes, moins de temps d'attente, et un système qui fait ce que le travail exige vraiment. Ne commencez donc pas par la question de savoir quel logiciel vous achetez, mais par celle de savoir comment le travail se déroule aujourd'hui, et ce qui peut en disparaître avant qu'une seule ligne de code ne s'ajoute.