Sans baseline, pas de business case : pourquoi mesurer avant de transformer
« Ce processus est trop lent. »
« Nous consacrons trop de temps aux rapprochements. »
« Les erreurs sont trop nombreuses. »
« Cette opération immobilise inutilement des ressources. »
Ces affirmations peuvent être exactes.
Mais elles ne constituent pas encore un business case.
Avant de décider d’une transformation, une organisation doit pouvoir répondre à une question plus exigeante :
quelle est précisément la situation aujourd’hui ?
C’est le rôle de la baseline.
Elle établit le point de départ à partir duquel les coûts, délais, risques et performances pourront être comparés.
Sans baseline, une amélioration peut être ressentie.
Elle ne peut pas être démontrée.
Une baseline transforme une perception en mesure
Une friction opérationnelle commence souvent par une perception.
Les équipes savent qu’un processus est compliqué.
Les utilisateurs se plaignent de ressaisies.
La finance constate des délais.
Le contrôle rencontre régulièrement les mêmes exceptions.
Le management considère que le processus devrait pouvoir fonctionner plus efficacement.
Ces signaux sont précieux.
Mais ils doivent ensuite être objectivés.
La baseline consiste à mesurer le fonctionnement réel du processus avant sa transformation.
Elle peut notamment établir :
- le délai moyen de traitement ;
- le coût par opération ;
- le nombre d’interventions manuelles ;
- le nombre de contrôles ;
- le taux d’erreur ;
- le volume d’exceptions ;
- le nombre de litiges ;
- le temps consacré aux réconciliations ;
- le niveau de service ;
- les ressources immobilisées ;
- le BFR ou le cash affecté lorsque le processus le justifie ;
- les incidents ou risques observés.
L’objectif n’est pas d’accumuler des indicateurs.
Il est d’identifier les quelques métriques qui permettront ensuite de savoir si la transformation crée réellement de la valeur.
Pourquoi le business case dépend de la baseline
Un business case compare essentiellement deux situations :
la situation actuelle
et
une situation future plausible.
Si la première n’est pas mesurée, la seconde repose sur une hypothèse impossible à vérifier.
Prenons une affirmation :
« La nouvelle solution réduira de 30 % le temps de traitement. »
30 % de quoi ?
Si le temps actuel n’est pas mesuré, le pourcentage n’a presque aucune valeur décisionnelle.
Même problème pour :
« Nous allons réduire les coûts de réconciliation. »
Combien coûtent-ils aujourd’hui ?
Ou :
« La traçabilité sera améliorée. »
Comment mesure-t-on aujourd’hui le temps nécessaire pour retrouver une preuve ou reconstituer une opération ?
Ou encore :
« L’automatisation libérera des ressources. »
Combien d’heures sont réellement consacrées au processus actuel ?
La baseline donne un dénominateur à la promesse.
Sans elle, le ROI devient rapidement un récit plutôt qu’un instrument de décision.
La baseline doit mesurer le processus réel
Une erreur fréquente consiste à mesurer le processus tel qu’il est conçu plutôt que tel qu’il fonctionne.
Un workflow peut officiellement comporter quatre étapes.
Dans la réalité, il peut également comprendre :
- un fichier Excel intermédiaire ;
- une validation par e-mail ;
- une ressaisie dans un deuxième système ;
- un appel lorsqu’une donnée manque ;
- un contrôle supplémentaire en cas d’exception ;
- un rapprochement manuel en fin de période.
C’est cette réalité opérationnelle qu’il faut mesurer.
Une baseline fiable se construit donc sur le As-Is :
ce que les équipes font réellement, et non ce que la procédure suppose qu’elles font.
Cette distinction peut modifier profondément le business case.
Parce qu’une partie importante du coût d’un processus se situe parfois dans des opérations informelles que les systèmes de reporting ne capturent pas correctement.
Il n’existe pas une baseline universelle
Les indicateurs dépendent de la friction étudiée.
Pour un processus de réconciliation, les métriques pertinentes peuvent être :
- volume d’opérations ;
- taux d’écarts ;
- temps de rapprochement ;
- nombre d’interventions manuelles ;
- coût de traitement d’une exception ;
- délai de résolution.
Pour un parcours documentaire :
- nombre de documents ;
- délais de collecte ;
- validations ;
- taux de dossiers incomplets ;
- ressaisies ;
- temps de recherche ;
- coût d’audit.
Pour le cycle de vie d’un équipement :
- temps de localisation ;
- écarts de statut ;
- taux de récupération ;
- pertes ;
- incidents ;
- délai de reconstitution de l’historique.
Pour un processus ayant un impact financier :
- délai de facturation ;
- délai de paiement ;
- montants immobilisés ;
- coût administratif ;
- BFR ;
- cash-flow.
La bonne baseline est donc spécifique à la décision que l’organisation devra prendre.
Cinq familles d’indicateurs sont particulièrement utiles
La Méthode F5 distingue plusieurs familles de mesures afin d’éviter de réduire la transformation à un seul KPI.
1. Performance
Par exemple :
- temps de cycle ;
- délai de règlement ;
- disponibilité ;
- taux d’automatisation ;
- nombre d’incidents.
2. Finance
Selon le cas :
- coût administratif ;
- coût de réconciliation ;
- pertes évitables ;
- BFR ;
- cash-flow ;
- TCO.
3. Qualité et confiance
Par exemple :
- taux d’erreur ;
- litiges ;
- délai d’audit ;
- traçabilité ;
- part des données effectivement réconciliées.
4. Risque et conformité
Par exemple :
- exceptions ;
- alertes ;
- incidents ;
- contrôles échoués ;
- remédiations nécessaires.
5. Adoption et opérations
Lorsqu’une transformation est expérimentée, il faudra également suivre :
- utilisateurs actifs ;
- tâches réellement accomplies ;
- partenaires onboardés ;
- satisfaction ;
- capacité à exploiter la nouvelle solution.
L’erreur serait donc de considérer qu’un indicateur technique — par exemple le nombre de transactions exécutées — démontre à lui seul la réussite d’une transformation.
Il démontre une activité technique.
Pas nécessairement une valeur métier.
Une baseline doit être gouvernable
Un indicateur n’est réellement exploitable que si l’on sait d’où il vient.
Pour chaque métrique critique, il faut pouvoir répondre à plusieurs questions :
Quelle est sa définition ?
Par exemple, quand commence exactement le « délai de traitement » et quand se termine-t-il ?
Quelle est sa source ?
ERP, CRM, système métier, tickets, comptabilité, contrôle manuel ?
Qui en est propriétaire ?
Quelle fonction peut confirmer la donnée et accepter qu’elle soit utilisée pour mesurer le résultat ?
Sur quelle période est-elle calculée ?
Une semaine atypique ne constitue pas nécessairement une référence valable.
Quel est son niveau de fiabilité ?
La mesure provient-elle directement d’un système ou d’une reconstruction manuelle ?
Cette discipline paraît administrative.
Elle est en réalité essentielle.
Car lorsque les résultats du pilote arriveront, la comparaison avec la baseline devra être acceptée par les métiers, la finance et les fonctions de contrôle.
La baseline ne doit pas devenir un projet dans le projet
L’exigence de mesure ne signifie pas qu’il faut attendre plusieurs mois avant de décider.
Une baseline doit être suffisamment robuste pour éclairer la décision, pas parfaite dans l’absolu.
Certaines données seront exactes.
D’autres seront estimées.
Certaines nécessiteront un échantillon.
D’autres devront être présentées sous forme de fourchettes.
L’important est de distinguer clairement :
les faits disponibles ;
les estimations ;
les hypothèses ;
les inconnues.
Une hypothèse explicitée peut être intégrée à un scénario.
Une estimation présentée comme un fait fragilise tout le business case.
Du point de départ aux scénarios
Une fois la baseline établie, l’organisation peut construire plusieurs scénarios.
Par exemple :
Scénario prudent
Une partie limitée de la friction est supprimée.
Scénario central
L’amélioration attendue est obtenue sur le périmètre cible.
Scénario ambitieux
Les gains sont maximisés sous certaines conditions d’adoption ou d’extension.
Ces scénarios permettent de tester la sensibilité du business case.
Que se passe-t-il si :
- le taux d’adoption est inférieur aux prévisions ?
- les coûts d’intégration sont supérieurs ?
- seule une partie des exceptions disparaît ?
- le volume traité évolue ?
- un partenaire essentiel ne rejoint pas le dispositif ?
Le business case devient alors un instrument d’arbitrage, et non une promesse commerciale.
Le TCO compte autant que les bénéfices
Une transformation peut réduire une friction tout en étant économiquement injustifiable.
C’est pourquoi la baseline et les bénéfices doivent être confrontés au Total Cost of Ownership.
Selon la solution, celui-ci peut intégrer :
- conception ;
- développement ;
- intégration ;
- licences ;
- infrastructure ;
- cybersécurité ;
- exploitation ;
- support ;
- gouvernance ;
- maintenance ;
- formation ;
- fournisseurs ;
- réversibilité.
Cette comparaison est particulièrement importante lorsqu’une DLT ou une Blockchain est envisagée.
La question n’est pas uniquement :
« Peut-elle réduire cette friction ? »
mais :
« Le gain obtenu justifie-t-il le coût et la complexité supplémentaires par rapport aux alternatives ? »
C’est précisément pourquoi F2 compare processus, ERP/API, automatisation centralisée et architectures distribuées avant d’autoriser la conception.
Le pilote doit revenir à la baseline
La baseline n’est pas utilisée uniquement au début.
Elle devient la référence du Proof of Business.
Une fois le pilote exécuté, la question n’est donc pas :
« Est-ce que la solution fonctionne ? »
mais :
« Les indicateurs se sont-ils améliorés par rapport à la situation initiale ? »
La Méthode F5 exige justement que le Proof of Business mesure les KPI et actualise le business case avant toute décision de passage à l’échelle.
On peut alors obtenir quatre résultats professionnels :
Stop — la valeur ne justifie plus le coût ou le risque.
Pivot — l’hypothèse reste intéressante mais doit être modifiée.
Extend — davantage de preuves sont nécessaires.
Scale — les résultats justifient une industrialisation.
Cette décision serait impossible à défendre sérieusement sans point de comparaison initial.
Une baseline protège également contre les faux succès
C’est probablement son rôle le plus important.
Un pilote peut être :
- techniquement stable ;
- bien présenté ;
- apprécié des utilisateurs ;
- innovant ;
- conforme à son cahier des charges ;
et malgré tout ne pas créer suffisamment de valeur pour justifier son industrialisation.
Inversement, une solution technologiquement modeste peut produire une amélioration économique très significative.
La baseline empêche donc de confondre :
réussite technologique
et
réussite de transformation.
La question à poser avant d’autoriser le business case
Avant toute discussion sur le ROI d’une transformation, une direction peut demander :
« Quelle est notre situation actuelle, comment l’avons-nous mesurée et qui en valide les chiffres ? »
Si la réponse n’est pas claire, il est trop tôt pour annoncer un gain.
La séquence est simple :
Observer → Mesurer → Construire la baseline → Quantifier → Comparer → Décider.
C’est pourquoi, dans la Méthode F5, F1 observe et construit la baseline avant que F2 ne chiffre et arbitre.
Sans baseline, nous avons une intuition.
Avec une baseline, nous pouvons commencer à construire une décision d’investissement.
Vous souhaitez objectiver la valeur d’une transformation ?
Maymana Consulting accompagne les entreprises et institutions dans la construction de la baseline, la quantification des frictions, le business case comparatif et l’arbitrage entre solutions conventionnelles et architectures distribuées.