Commencer par un problème dont quelqu'un se plaint déjà
Un premier processus devrait être un processus qu'une personne nommée souhaite déjà voir corrigé. Pas le plus intéressant sur le plan technique, ni celui aux données les plus propres. Si personne n'est actuellement frustré par le processus, personne n'adoptera son remplacement.
Prenons un exemple fictif : une équipe des finances de quatre personnes reçoit environ 600 factures de fournisseurs par mois. Deux d'entre elles passent une partie de chaque journée à rapprocher les factures avec les bons de commande et les reçus, et à relancer les écarts par courriel. L'équipe peut décrire le problème en une phrase, ce qui est bon signe qu'il est bien circonscrit.
Confirmer la propriété avant la conception
Chaque processus a besoin d'un responsable pouvant approuver un changement à la façon dont le travail est fait. Si le processus traverse trois services et que personne ne peut trancher, le projet s'arrêtera précisément au moment où la conception devient concrète.
La propriété détermine aussi la révision. Dans l'exemple des factures, le contrôleur détient le seuil d'exception et les limites d'approbation déléguées. Ce sont des décisions d'affaires, et l'architecture ne fait que les faire respecter.
Mesurer la référence avant de changer quoi que ce soit
Vous ne pouvez pas revendiquer une amélioration sans point de départ. Consacrez une courte période à consigner ce qui se passe réellement : combien de factures concordent du premier coup, combien de temps une exception attend, à quelle fréquence un élément est ressaisi, quelle part du retard de fin de mois provient de cette file.
Une référence est aussi un test de faisabilité. Si les chiffres sont difficiles à collecter, les systèmes sous-jacents pourraient également ne pas exposer suffisamment d'information pour qu'un processus puisse s'y appuyer.
Tester la faisabilité en fonction des sources, pas de la démonstration
La faisabilité réside dans les sources. Le système comptable expose-t-il le bon de commande par une interface approuvée, ou seulement par un export nocturne? Le reçu existe-t-il dans un système, ou dans une photo jointe à un courriel? La fréquence des mises à jour dépend de ce qu'une source fournit réellement.
C'est également là que se décide le choix entre construire et acquérir. Si la plateforme existante effectue déjà un rapprochement à trois voies mais n'est simplement pas configurée pour le faire, la bonne recommandation est la configuration, pas la construction.
Définir la révision avant de définir l'automatisation
Décidez ce que le système peut faire de lui-même et ce qu'il doit remettre à une personne. Dans l'exemple des factures, une concordance à trois voies propre et dans la tolérance peut être acheminée automatiquement pour approbation. Un écart de prix au-delà du seuil ne le peut pas. Le paiement n'est jamais libéré de façon autonome.
Les parcours de révision devraient être consignés dans les critères d'acceptation, aux côtés du comportement d'abstention : ce que le système fait lorsqu'il n'est pas assez confiant pour répondre.
Établir le seuil d'expansion à l'avance
Avant la mise en service du premier processus, convenez du résultat qui justifierait de l'étendre, de celui qui justifierait de le modifier, et de celui qui justifierait de le retirer. Consigner cela à l'avance évite un résultat familier, où un projet pilote est jugé réussi parce qu'il a été coûteux.
Un processus, un responsable, une référence, un seuil. Cette séquence n'a rien de spectaculaire, et c'est ce qui fait la différence entre un système qui s'intègre à l'exploitation et un autre qui devient une démonstration que personne n'ouvre.