On se met souvent à chercher un consultant en automatisation des processus quand on réalise que le problème n'est peut-être pas l'outil acheté, mais ce qui se passe entre les outils et les personnes qui les utilisent. C'est aussi pour cela que nous nous méfions d'une mission qui s'ouvre sur une recommandation de produit.
Voici la forme que prend généralement ce travail, pour que vous puissiez juger si la proposition devant vous relève d'une vraie phase de découverte, ou si la solution était déjà décidée avant l'audit.
La première phase, on écoute, on ne conçoit pas
Le consultant doit s'asseoir avec les personnes qui font le travail et écrire le processus tel qu'il se déroule réellement, dans l'ordre, y compris les étapes qui ne figurent dans aucune documentation. Ce qui est vérifié deux fois. Qui on va voir quand quelque chose n'est pas clair. Quel tableur reste ouvert sur un second écran toute la journée.
Attendez-vous à ce qu'il demande explicitement les exceptions, parce que le chemin nominal documenté est rarement là où passent les heures. Les exceptions doivent être comprises avant de considérer la cartographie comme terminée, sinon la conception s'appuiera sur le processus documenté plutôt que sur la façon dont le travail se déroule réellement.
Ensuite, le processus devient de l'argent
Pour les étapes manuelles qui semblent mériter un examen, notez la fréquence, la durée approximative et le nombre de personnes concernées, idéalement à partir d'une semaine de comptage plutôt que de la mémoire. Ces heures peuvent ensuite être converties à un coût horaire chargé réaliste, pour obtenir une liste d'étapes avec un montant mensuel en face de chacune. Le coût des erreurs, les délais et les goulets d'étranglement restent visibles à part, plutôt que fondus dans le calcul horaire.
C'est la partie qui rend la suite discutable, au bon sens du terme. Une fois les chiffres posés, vous et le consultant pouvez être en désaccord sur un nombre plutôt que sur une impression, et ce désaccord-là est productif.
Une recommandation qui peut être « ne rien faire »
La recommandation devrait au minimum distinguer ce que vous pouvez corriger sans logiciel, ce qui mérite d'être construit, et ce qu'il vaut mieux laisser tranquille. Si chaque constat finit par devenir une recommandation de développement, demandez-vous si l'audit sépare vraiment vos priorités des intérêts du prestataire.
Un audit qui se termine par un réglage, un modèle de document et un rapport planifié est un audit réussi. Un audit qui se termine par la recommandation claire de ne rien automatiser cette année parce que le processus va changer l'est tout autant.
Construire par tranches, puis remesurer
Quand le flux le permet, commencez par la plus petite tranche qui supprime une étape réelle. Pour tout ce qui porte un risque opérationnel, faire tourner le nouveau chemin à côté de l'ancien pendant une période définie fait apparaître les cas qui n'étaient pas sortis pendant la découverte, et laisse à l'équipe le temps de voir comment il encaisse une semaine normale, cas pénibles compris, avant d'arrêter l'ancien processus.
Ensuite, remesurez la même étape avec la même méthode de comptage. Utiliser la même méthode donne la comparaison la plus propre avec l'estimation initiale, et c'est le chiffre que vous voudrez avoir la prochaine fois qu'on vous demandera de justifier ce type de projet.
Ce que vous devez posséder à la fin
- La cartographie du processus, dans un format que vous pouvez modifier sans le consultant.
- Les mesures, avec les hypothèses écrites, pour qu'un successeur puisse vérifier les calculs au lieu de les croire.
- La recommandation, y compris les étapes jugées non rentables à automatiser, et pourquoi.
- Le plan de construction, assez précis pour qu'un autre prestataire puisse l'exécuter. Sinon, vous avez acheté une dépendance et non un audit.
- Les comptes de production, les dépôts de code et les accès appartenant à votre entreprise, ou placés sous des comptes qu'elle contrôle, plutôt que transférés seulement au moment de la passation.
Comment ces missions dérapent
- Une plateforme est choisie avant d'avoir compris le processus, et le reste du projet devient une négociation pour y faire entrer le travail.
- L'automatisation est construite autour d'une étape défaillante au lieu de la supprimer, ce qui rend l'erreur plus rapide et plus difficile à voir.
- Rien n'est documenté, et l'automatisation devient une deuxième chose qu'une seule personne comprend, c'est-à-dire exactement le problème pour lequel vous aviez recruté.
- Personne ne mesure après coup, la valeur est donc affirmée plutôt que connue, et le projet suivant doit reprendre la discussion à zéro.