Business case du Process Mining : quatre chiffres pour la direction financière

Un business case de Process Mining présente à la direction financière quatre chiffres à examiner : l’ampleur du problème, le coût de sa résolution, celui du projet pilote et le délai avant d’obtenir les premières preuves. Trois de ces chiffres peuvent être calculés à partir d’un seul export de vos données de processus. Si l’un d’eux reste une estimation, indiquez-le et précisez quand vous le mesurerez.

Une demande visant à « introduire le Process Mining » est difficile à évaluer, car elle ne précise ni problème, ni décision, ni date à laquelle des éléments de preuve seront disponibles. La plupart des business cases qui échouent reposent sur ce que quelqu’un espère que l’outil produira, plutôt que sur le fonctionnement réel du processus. C’est pourquoi cette page se concentre sur un seul processus : ce que vous allez mesurer, le coût du changement et la date à laquelle vous aurez des résultats.

Quels sont les quatre chiffres nécessaires à un business case pour le Process Mining ?

Présentez les quatre chiffres avant de défendre votre demande et indiquez, pour chacun, sur quoi il repose.

1. Ampleur du problème : coût actuel du processus, exprimé dans une unité déjà suivie par votre entreprise, par exemple en jours de temps de cycle, en pénalités de retard, en délai moyen de paiement client ou en heures de travail équivalent temps plein. Fondez ce chiffre sur vos propres volumes et délais.
2. Coût de la solution : coût de la modification du processus, et non de son analyse. Un changement de politique accompagné d’une nouvelle formation représente un travail d’une autre ampleur qu’une modification du système. L’estimation doit venir de la personne responsable du changement.
3. Coût du projet pilote : coût de la licence, du travail sur les données et du temps consacré en interne à l’établissement des faits.
4. Délai avant les premiers éléments de preuve : date prévue pour examiner un résultat et mesure à laquelle vous le comparerez.

En général, trois des quatre chiffres proviennent de la même source. Un export des données de processus vous indique l’ampleur du problème, l’effort nécessaire à la préparation des données et la durée de l’analyse. Le coût de la solution dépend d’une décision qui n’a pas encore été prise. Il faut donc désigner une personne responsable et fixer une date, plutôt que d’inventer un chiffre.

Précisez pour chaque chiffre du business case s’il s’agit d’une mesure ou d’une estimation. La direction financière vous demandera de faire la distinction. Un business case qui y répond sera plus difficile à écarter que quatre chiffres présentés avec assurance, mais sans justification apparente.

Pourquoi les business cases du Process Mining perdent-ils en crédibilité ?

Les business cases échouent rarement parce qu’un chiffre est faux. Un business case pour le Process Mining échoue lorsqu’il ne contient rien qui puisse être vérifié.

Ils demandent une capacité au lieu de proposer une décision. « Nous gagnerons en visibilité sur le cycle commande-encaissement » ne précise pas ce que la direction financière finance ni comment vous évaluerez le résultat. « Nous vérifierons si la deuxième étape d’approbation ajoute une semaine au délai d’un tiers des commandes, et nous présenterons les résultats d’ici au 15 novembre » est beaucoup plus précis.

Ils s’appuient sur des pourcentages de référence. Affirmer que le Process Mining réduit généralement le temps de cycle d’un certain pourcentage ne dit rien sur votre processus. Votre propre référence est plus utile, même si elle est moins impressionnante.

Ils omettent le travail sur les données. L’extraction des données, l’identification des cas, le classement des horodatages et la configuration des actualisations prennent du temps. Si votre business case ne mentionne que la licence, le coût du projet pilote est sous-estimé. Consultez d’abord le détail des coûts pour examiner les différents postes.

Ils s’appuient sur une moyenne qui masque le problème. Une durée moyenne de traitement répartit uniformément cinq jours d’attente entre tous les cas. Le chiffre paraît alors faible, tout comme l’amélioration possible. Indiquez plutôt où se concentre le temps : quelle étape, combien de cas et quelle durée. « Environ 12 000 commandes par trimestre ; près d’un tiers n’arrivent pas à la date promise, et la cause n’est pas claire » donne au lecteur un élément à vérifier. « Inefficacité importante dans la gestion des commandes » ne lui en donne aucun.

Quels sont les résultats habituels d’un projet de Process Mining ?

Savoir quels éléments de preuve vous pouvez obtenir facilite la rédaction du business case. Une première analyse des données d’événements d’un processus répond généralement à des questions telles que :

• Où le temps est consacré : le temps d’attente par activité, comparé au temps de travail correspondant, pour faire apparaître l’écart entre les deux.
• À quelle fréquence le processus se répète : nombre de boucles et de reprises, y compris les étapes absentes du modèle documenté.
• Combien de personnes interviennent dans un cas : nombre de transferts entre équipes et systèmes.
• Dans quelle mesure le processus varie : nombre de parcours distincts et part des cas qui suivent le plus fréquent.
• Où le processus s’écarte des règles : écarts de conformité par rapport au processus prévu.
• Quelles étapes pourraient être automatisées : étapes fréquentes, régies par des règles et peu variables, pour lesquelles une référence mesurée est disponible.
• Quel effort représente chaque étape : temps par étape et par cas, afin de chiffrer un changement envisagé.

Les résultats dépendent de votre processus et de vos données. Un journal contenant un identifiant de cas, une activité et un horodatage permet de répondre aux quatre premières questions. Les autres nécessitent davantage de détails, et certaines exigent un modèle de référence. Découvrez comment le Process Mining analyse vos données de processus. Si vos données ne sont pas encore exploitables, la démarche de préparation des données présente les prérequis.

Il faut le dire clairement : l’outil ne vous donne pas la réponse. Il fournit des éléments de preuve, que vous pouvez ensuite intégrer à votre business case. Aucun des résultats de cette liste ne vous indique la valeur d’un changement, si une étape est nécessaire ou quelle capacité votre équipe peut réellement récupérer. Ces questions relèvent de décisions métier, plus faciles à prendre une fois les mesures disponibles. Les bénéfices du Process Mining dépendent de l’ampleur des changements que ces décisions permettent.

Si le journal ne couvre qu’une partie du processus ou de la période, précisez-le lorsque vous présentez les chiffres. Une mesure partielle reste un élément de preuve, à condition d’indiquer clairement ce qu’elle couvre et ce qu’elle exclut.

Comment évaluer les bénéfices à partir de vos propres mesures ?

La taille du problème ne devient un avantage que si vous précisez ce qui va changer. La valeur du Process Mining tient à la décision que les éléments observés permettent de prendre. Votre analyse de rentabilité doit donc porter sur une décision que votre organisation doit prendre. Pour justifier un investissement dans le Process Mining, deux modèles couvrent la plupart des premiers cas :

Trésorerie ou fonds de roulement :

jours gagnés × nombre de cas concernés × valeur par jour et par cas × coût du capital

Capacité :

heures gagnées par période × coût horaire complet

Gardez à l’esprit trois distinctions :

• Choisissez une unité déjà utilisée dans votre activité. Exprimez le bénéfice en jours de temps de cycle, en pénalités de retard évitées, en réduction du DSO ou en heures récupérées. Le terme « efficacité » ne suffit pas à vérifier le résultat.
• Distinguez la trésorerie de la capacité. Libérer de la capacité ne génère pas de trésorerie à lui seul. Précisez si la valeur vient du traitement d’un volume supérieur avec la même équipe ou d’une décision de recrutement, et indiquez qui prendra cette décision.
• Nommez l’hypothèse dont vous êtes le moins sûr. Indiquez quelle partie de l’estimation est la moins fiable et comment vous allez la vérifier.

Une situation de référence mesurée rend le reste du calcul plus facile à défendre. Si les heures sont calculées à partir de vos propres données d’événements, seule reste à estimer l’ampleur de la réduction, un chiffre qu’un évaluateur peut discuter. Un bénéfice fondé à la fois sur une situation de référence supposée et sur une réduction supposée résiste rarement à la discussion. Si vous ne pouvez pas défendre un pourcentage de réduction, indiquez la fourchette étudiée et précisez la valeur retenue.

Vous pouvez saisir ces données dans le calculateur de ROI de ProcessMind : volume annuel de cas, temps moyen de traitement, coût horaire complet, réduction attendue, incidents et coût moyen associé, ainsi que les données du forfait pour la licence. Le calculateur indique les bénéfices annuels totaux, le bénéfice net, le retour sur investissement et le délai d’amortissement.

Il s’agit d’un modèle général, et c’est précisément son intérêt : il montre comment les différentes données se combinent. Il ne devient votre analyse de rentabilité qu’une fois les valeurs par défaut remplacées par vos propres volumes, durées et coûts. Le calculateur n’inclut pas non plus les efforts de mise en œuvre ni la préparation des données dans les coûts : ajoutez-les séparément. Un modèle que vous ne pouvez pas adapter à votre situation ne constitue pas encore une analyse de rentabilité.

À quoi ressemble concrètement une analyse de rentabilité fondée sur quatre chiffres ?

Les chiffres ci-dessous sont donnés à titre d’exemple. Retenez la méthode, pas les valeurs.

Situation : un processus traite 12 000 commandes par trimestre. Le temps de cycle médian est de 18 jours, et le P90 de 41 jours. Environ un tiers des commandes attendent plus de cinq jours à une étape d’approbation qui nécessite environ quatre minutes de travail effectif.

1. Ampleur du problème : l’attente concerne environ 4 000 commandes par trimestre. Si l’attente moyenne à cette étape est de six jours, cela représente 24 000 jours de temps de cycle par trimestre. Le travail réellement nécessaire à cette étape représente environ 270 heures sur la même période. Le chiffre à retenir dépend de l’impact du retard sur vos coûts, vos niveaux de service, ou les deux. Dans tous les cas, vérifiez-le à partir de vos propres données avant de l’utiliser. Précisez également l’unité : les jours de commande ne sont pas des euros. Si votre analyse doit aboutir à un montant, la conversion constitue une hypothèse supplémentaire à expliciter et à vérifier.

2. Coût de la mesure corrective : une solution pourrait consister à relever le seuil afin que l’étape d’approbation concerne 8 % des commandes au lieu de 33 %, et à désigner un remplaçant en l’absence de l’approbateur. Avant de considérer cette mesure comme peu coûteuse, vérifiez les coûts liés à la politique, au contrôle et à la mise en œuvre auprès des personnes responsables.

3. Coût du pilote : limitez le pilote à un processus et à une période définie. Incluez la licence, le temps consacré par l’analyste à la préparation des données et celui du responsable du processus. Si vous n’avez pas confirmé le temps nécessaire à la préparation des données, indiquez qu’il s’agit d’une estimation. Une analyse de rentabilité du Process Mining qui ne mentionne que la licence sous-estime le travail requis.

4. Délai avant les premiers éléments probants : fixez une date pour examiner le temps de cycle du segment concerné. Si l’attente ne diminue pas, vous disposerez tout de même d’une situation de référence pour éclairer la décision suivante.

Qu’est-ce qui pourrait changer la conclusion ? Si l’étape d’approbation sert à détecter une défaillance de contrôle, relever le seuil pourrait affaiblir ce contrôle. Faites figurer ce risque dans l’analyse et consultez le responsable du contrôle avant de recommander une modification.

Présentez les quatre chiffres et les questions financières sur une seule page :

Chaque ligne de ce tableau doit renvoyer à une mesure ou à une estimation attribuée à une personne nommément désignée. Le calcul du ROI du Process Mining ne fait pas exception : ne présentez pas une estimation comme une économie tant que vos données et la modification proposée ne la confirment pas.

Pour repérer les étapes qu’il pourrait être utile de modifier, lisez comment repérer les possibilités d’automatisation grâce au Process Mining.

Pourquoi commencer par un pilote pour votre première analyse de rentabilité ?

La première analyse de rentabilité doit porter sur un pilote, pas sur une plateforme. Les quatre chiffres sont conçus pour cela : un processus, une décision et une période assez courte pour examiner le résultat avant de vous engager dans un projet plus vaste. Considérez-le comme une preuve de valeur du Process Mining : un exercice de mesure, et non un déploiement à petite échelle.

Commencez à petite échelle et gardez des critères réalistes : l’analyse de rentabilité doit être évidente. Si ce n’est pas le cas, c’est que vous voyez trop grand. Laissez d’abord parler les données, puis élargissez le périmètre là où cela compte. Un pilote qui coûte quelques licences et quelques semaines de travail d’analyste doit répondre à des exigences bien moins élevées qu’un programme de déploiement de plateforme. Il apporte aussi un élément qu’un tel programme ne peut pas fournir : votre propre situation de référence.

Commencer modestement est aussi un choix logiciel. Si un outil n’a de sens que dans le cadre d’un déploiement à l’échelle de l’entreprise, il faut bâtir une analyse de rentabilité ambitieuse avant même de pouvoir le tester. ProcessMind facture par licence utilisateur et propose une offre gratuite après la période d’essai, ainsi qu’un essai gratuit de 14 jours sans carte bancaire. Vous pouvez donc réaliser une première analyse sans contrat destiné à toute l’entreprise. Découvrez le coût de chaque forfait.

Avant de lancer un pilote de Process Mining, définissez quatre éléments :

• Un processus : choisissez un périmètre assez restreint pour qu’une seule question le détermine.
• Une décision : précisez la décision que les résultats doivent éclairer.
• Des critères de sortie : convenez à l’avance des résultats qui justifieraient de poursuivre ou d’arrêter.
• Une date d’examen : fixez le moment où vous évaluerez les éléments recueillis et déciderez de la suite.

Si le pilote justifie la poursuite du travail, appuyez-vous sur ses résultats pour défendre l’étude du processus suivant. Dans le cas contraire, vous aurez tout de même une situation de référence et une raison plus claire de changer de direction. Dans les deux cas, définissez les trois issues possibles avant de commencer : les éléments recueillis justifient cette modification, ils en justifient une autre, ou ils justifient l’arrêt du projet. Une analyse qui ne peut aboutir qu’à une seule conclusion n’est pas un exercice de mesure.

Et si les chiffres ne sont pas encore disponibles ?

L’investissement n’est peut-être pas encore justifié. Le constater est un résultat, pas un échec. Trois raisons l’expliquent généralement : le volume du processus est trop faible pour que le travail ait un impact, les données ne sont pas disponibles dans un format utilisable, ou personne n’attend de décision.

Si les données existent et que le processus est de petite taille, mesurez manuellement une situation de référence. Si les données ne sont pas utilisables, évaluez le travail nécessaire pour les préparer au lieu de demander une licence, et précisez ce qui devrait changer avant de réexaminer l’analyse.