Définir un processus avant de l'automatiser ne nécessite pas un projet de conseil de six mois. Deux semaines, quatre séances de travail et cinq livrables concrets suffisent. Il est inutile de recourir à la pratique courante consistant à demander à quelqu'un de rédiger la procédure, car on aboutit alors à une version idéale du processus, et non à la version réelle.
Cet article décrit la méthode que nous avons appliquée, ainsi que ses composantes, afin qu'elle puisse être exécutée avec ou sans assistance extérieure.
Lorsqu'on leur demande de décrire leur démarche, certains décrivent le chemin principal dans sa version correcte. Ils omettent les exceptions, car elles semblent anecdotiques ; ils omettent les raccourcis, car ils ne sont pas sûrs de leur acceptabilité ; et ils omettent les règles non écrites, car elles vont de soi.
Ces trois omissions sont précisément ce qui fait échouer l'automatisation en production.
La question qui fonctionne est différente : « Parlez-moi de la dernière affaire qui vous a posé problème. ». Elle produit un récit concret plutôt qu'une description abstraite, et dans ce récit, les exceptions, les raccourcis et les règles tacites apparaissent sans qu'il soit nécessaire de les demander.
Livrable | Ce qu'il contient | À quoi ça sert ? |
|---|---|---|
Carte de décision | Qu’est-ce qui est décidé, par qui et sur la base de quelles informations ? | Fondements de toute automatisation |
Inventaire des données | Quelles données, dans quel système, et à qui appartiennent-elles ? | Révéler les contradictions avant le codage |
Catalogue des exceptions | Les cas atypiques et leur résolution aujourd'hui | Définir ce qui est automatisé et ce qui est évolutif |
Règles non écrites | Des critères qui n'existaient que dans l'imagination de quelqu'un. | Cela réduit la dépendance envers les gens |
Ligne de base | Temps de cycle, main-d'œuvre, corrections, coût par cas | Cela permet de démontrer une amélioration après |
Tous les cinq possèdent un bien précieux : Ils créent de la valeur même si le projet d'automatisation n'est pas réalisé.. Le quatrième, en particulier, est généralement celui qui a l'impact le plus immédiat, car il transforme le savoir tacite d'une personne en un atout pour l'organisation.
Jours 1-2 : la situation de référence. Avant de parler à qui que ce soit, prenez des mesures. Combien de dossiers arrivent, combien de temps chacun prend du début à la fin (temps d'attente inclus, pas seulement le temps de traitement effectif), et combien nécessitent une correction ultérieure ? Sans ces données, toute amélioration future sera incertaine.
Jours 3 à 5 : les discussions. Trois ou quatre personnes mènent le processus séparément, chacune interrogeant les utilisateurs sur les cas problématiques. Il est important de travailler individuellement : au sein d’un groupe, la version officielle prévaut. Ce processus permet d’établir la carte décisionnelle et la majeure partie du catalogue d’exceptions.
Jours 6-7 : les données. Pour chaque décision cartographique, quelles informations sont nécessaires, où sont-elles stockées et qui en est responsable ? C’est là que les contradictions entre les systèmes apparaissent, et il est important de les documenter, même si elles sont délicates : chacune représente une décision en suspens que quelqu’un devra prendre.
Jours 8 et 9 : les règles. Consignez par écrit les critères qui ont émergé des conversations et soumettez-les à leurs auteurs pour confirmation ou correction. C'est l'étape qui suscite le plus de résistance, mais aussi celle qui apporte le plus de valeur.
Jour 10 : les qualifications. En tenant compte de tout ce qui précède, déterminez quelle partie du processus peut être automatisée, laquelle doit être laissée à la décision humaine et laquelle doit rester inchangée. Ce n'est qu'ensuite que vous pourrez évaluer la technologie.
Entretiens de groupe. La personne la plus haut placée décrit la procédure officielle, et les autres acquiescent. L'information même qu'ils recherchaient est perdue.
Adressez-vous aux responsables plutôt qu'à la personne qui effectue la tâche. Le responsable connaît le plan ; celui qui l’exécute connaît la réalité. Les deux sont nécessaires, et dans cet ordre inverse à l’ordre habituel.
Documentez le processus idéal. La tentation de corriger les choses pendant la documentation est forte et nuit au travail. On commence par consigner les événements ; la refonte intervient plus tard et constitue une phase distincte.
Avec ces cinq éléments livrables sur la table, les décisions ultérieures cessent d'être de simples discussions fondées sur des opinions :
C’est pourquoi, dans TCG-SAF™, les deux premières étapes – Vision et Domaines – précèdent systématiquement toute décision de construction. Il ne s’agit pas d’une simple formalité méthodologique : sans ces cinq documents, des décisions sont prises, certes, mais sans information et par la personne incompétente.
Il existe un moyen simple de savoir si le travail est bien fait : Confiez la documentation à une personne extérieure au processus et demandez-lui de résoudre cinq cas réels..
Si vous réussissez, le processus est défini et peut être automatisé. Si vous devez poser la question, c'est que ce qui manque à votre interrogation est précisément ce qui manquait à la documentation – et ce qui aurait entraîné un échec en production trois mois plus tard.
Ce travail comprend cinq livrables : une cartographie des décisions, un inventaire des données incluant le système et son propriétaire, un catalogue des exceptions, les règles métier non écrites et une analyse de performance de référence. Ces éléments sont obtenus en une dizaine de jours de travail, répartis en quatre sessions, et ne nécessitent pas un projet de conseil de longue durée.
Parce que l'on décrit le processus principal dans sa version idéale : on omet les exceptions, jugées anecdotiques, les raccourcis, par prudence, et les règles non écrites, qu'on considère comme évidentes. Or, ce sont précisément ces trois omissions qui font échouer l'automatisation en production.
« Parlez-moi du dernier cas qui vous a posé problème. » Cela produit un récit concret plutôt qu'une description abstraite, et dans ce récit, les exceptions, les raccourcis et les critères tacites apparaissent sans qu'il soit nécessaire de les interroger.
Le processus est mené par trois ou quatre personnes, individuellement et non en groupe, car au sein d'un groupe, la version officielle prévaut. Les responsables connaissent le plan, et ceux qui l'exécutent connaissent la réalité ; les deux sont nécessaires, à commencer par la seconde.
Troisièmement : menez des entretiens de groupe, interrogez uniquement les responsables et non les exécutants, et documentez le processus idéal plutôt que le processus réel. La tentation de corriger les choses lors de la documentation est forte et nuit à la valeur du travail : commencez par consigner ce qui se passe ; la refonte viendra plus tard.
Confiez le processus à une personne extérieure et demandez-lui de résoudre cinq cas concrets. Si elle y parvient, le processus est défini ; si elle doit poser des questions, ce qui manque à sa question correspond précisément à ce qui aurait échoué en production.
Souhaitez-vous avoir une vision claire de votre processus avant d'investir dans la technologie ? En deux semaines, nous vous fournissons les décisions, les données, les exceptions, les règles tacites et le référentiel. Cela fonctionne, que vous automatisiez le processus ou non. Parlons-en → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
