Ceci n'est pas un nouveau format de démonstration. Il s'agit de notre processus existant de validation sur cas public. Les données de ce cas proviennent de la description officielle du cas public de CohnReznick. Nous isolons d'abord les réponses ultérieures, puis nous reconstituons ce qui était connaissable au moment de la décision sous la forme d'un ensemble de données pédagogiques. Il s'agit d'une simulation pédagogique indépendante fondée sur une source publique officielle, et non d'une correspondance réelle ni de résultats clients réels ; cela ne signifie pas que CohnReznick a utilisé, examiné, approuvé, parrainé, certifié ou commandé Minerva Advisor.

Le cas débute avec une entreprise chimique soutenue par un fonds de private equity, qui s'est développée par acquisitions successives et a formé quatre segments d'activité : la fabrication et la revente de produits chimiques, les services de santé animale, le traitement des chaudières et des eaux de refroidissement, ainsi que la logistique de transport. Chaque acquisition a apporté ses propres équipes, processus et technologies, créant des systèmes déconnectés, des rapprochements manuels sous tableurs, une double saisie des données et des silos d'information qui retardaient les décisions de la direction. La décision à prendre : le Chief Transformation Officer doit-il s'engager immédiatement dans le déploiement d'une plateforme ERP à l'échelle de l'entreprise, ou doit-il d'abord opter pour une validation de périmètre partagé, limitée dans le temps et interruptible, afin de guider l'intégration, avec des preuves claires indiquant quand étendre, réduire ou inverser la décision ?

Cette session en direct a produit un reçu de travail en cinq points. Un document source a été utilisé. Quatre rôles ont été identifiés. Six faits, deux inférences et trois points non résolus ont été distingués séparément. Deux voies d'intégration ont été comparées côte à côte. Enfin, trois interprétations alternatives, ainsi qu'une condition de réversibilité, ont été conservées plutôt qu'écartées. Les dirigeants peuvent vérifier la source, les rôles, les preuves, les options et les contre-preuves, point par point.

Voici ce qui était connu et inconnu au moment de la décision. Connu : les quatre segments d'activité présentent des systèmes fragmentés, des rapprochements manuels, une double saisie, des retards de décision et des rapports cloisonnés. Inconnu : les véritables frontières communes de processus et de données entre les unités, si le problème de fond est principalement systémique ou procédural, ainsi que le coût réel de l'intégration et le risque d'adoption. Minerva n'a pas attribué chaque problème directement aux insuffisances de l'ERP.

La contestation interne la plus vigoureuse est venue de la conseillère Evelyn, qui a soutenu que l'entreprise subissait déjà des rapprochements manuels et des retards de décision, et qu'une approche de validation par étapes pourrait sous-estimer le coût réel de la poursuite de ces retards. Le système a conservé ce point comme condition de réversibilité active : si les coûts de fragmentation en cours se révèlent supérieurs au risque de retard lié à la validation, et si la scalabilité des futures acquisitions exige une unification plus rapide que ce que permet une validation par étapes, la recommandation devrait basculer vers un déploiement à l'échelle de l'entreprise plus rapide.

La réponse divulguée ultérieurement par CohnReznick a été délibérément exclue des données fournies à Minerva. Son processus en deux phases, couvrant une découverte approfondie, des ateliers, des entretiens avec les parties prenantes, la cartographie des processus, le choix de NetSuite, le périmètre de mise en œuvre couvrant la finance, la fabrication et la distribution, ainsi que les résultats obtenus, ont été retenus. Minerva ne connaissait pas à l'avance la réponse finale concernant la plateforme, et n'a pas traité les résultats ultérieurs du cas public comme ses propres résultats.

Trois conseillers ont ensuite croisé leurs analyses sur un même jugement. Marcus a défini la véritable frontière d'intégration à trancher. Sofia a modélisé les conséquences pour la finance, la technologie, les unités opérationnelles et la direction. Evelyn a interrogé si une trajectoire de validation par étapes sous-estimait le coût du retard. Leur orientation commune : d'abord trier les causes profondes, puis mener une validation de périmètre avec un responsable désigné, des frontières communes, des conditions d'arrêt et des seuils d'extension.

Cette étape montre si l'apport du dirigeant modifie le jugement. Le dirigeant a ajouté une condition : distinguer d'abord les causes profondes entre système, processus, qualité des données et responsabilité, puis valider le périmètre à l'aide de frontières communes, de conditions d'arrêt et de seuils d'extension. Le système a enregistré un reçu de réponse confirmant le maintien du jugement initial. L'ajout du dirigeant a renforcé les exigences de gouvernance existantes plutôt que de les remettre en cause.

Deux options ont été comparées directement. Verrouiller un ERP à l'échelle de l'entreprise en une seule fois permettrait, en cas de réussite, d'unifier systèmes et rapports le plus rapidement, mais avec des différences entre segments non encore vérifiées, cela risquerait de perturber les opérations et serait difficile à inverser en cours de route. Une validation de périmètre partagé commun permettrait de vérifier d'abord les frontières de processus et de données, préservant la possibilité d'étendre ou de restreindre le périmètre, au prix d'un calendrier global potentiellement plus long. Le dirigeant a choisi la seconde voie, celle qui peut être interrompue.

L'action engagée : une équipe conjointe d'intégration finance et technologie vérifiera, dans un délai de trois semaines, les points communs de processus et de données entre les quatre segments d'activité, et classera les problèmes de rapprochement manuel et de retard en quatre catégories — système, processus, qualité des données et responsabilité — en tant qu'apport direct à la validation de périmètre. Minerva n'affirme pas qu'une plateforme ERP a été choisie, ni que des résultats de transformation se sont déjà produits.

Ce cas CohnReznick a réussi dix vérifications de qualité de décision sur dix. La session a utilisé quatre appels de modèle, livré la première décision en 19.459 secondes et s'est achevée en 27.169 secondes, respectant ainsi le seuil de 30 secondes pour la première décision et celui de 45 secondes pour le résultat complet. La qualité de décision, l'expérience dirigeante et le statut de performance ont tous été validés. Il s'agit toujours d'un test sur un cas unique, qui ne représente ni des standards de service en production ni des résultats clients réels.