ERP, cyber, fournisseur critique : trois scénarios pour faire décider le COMEX

L’intégrateur confirme le calendrier. Le directeur financier réclame une date ferme. Les métiers signalent pourtant que plusieurs données de reprise ne sont pas fiables. Faut-il maintenir le démarrage du nouvel ERP, réduire son périmètre ou le reporter ? Une présentation des risques ne répond pas à cette question. Le COMEX doit pouvoir comparer des options, leurs conséquences et les preuves qui permettraient de trancher.

Le pilotage par scénarios devient utile précisément à cet endroit : quand une décision engage l’activité et que toutes les conditions de réussite ne sont pas connues. Il ne s’agit pas de raconter quatre futurs spectaculaires. Il s’agit de préparer un arbitrage avant que l’urgence ne le rende confus. Voici une méthode appliquée à un cas fictif, sans l’attribuer à une entreprise cliente.

Un cas de travail : une bascule ERP à huit semaines

Imaginons une entreprise industrielle qui prépare le remplacement de son ERP. Les commandes, les stocks et la facturation sont concernés. La date approche, mais trois incertitudes demeurent : la qualité des données, la disponibilité des équipes métiers et la capacité de l’intégrateur à traiter les anomalies bloquantes. Le scénario nominal suppose que ces trois conditions seront réunies. C’est une hypothèse, pas une preuve.

La première question à poser est métier : quelle activité doit absolument fonctionner le premier matin ? On peut accepter de différer un tableau de bord ; on ne peut pas traiter de la même façon l’impossibilité de préparer une commande. Cette distinction évite de discuter de centaines d’anomalies comme si chacune menaçait également l’entreprise.

Dans Révolution Numérique !, Guy de Lussigny relie les difficultés des programmes ERP aux données, au sponsor, aux processus et à la relation avec l’intégrateur. Cette lecture change l’objet du comité : il ne demande plus seulement si le logiciel est prêt, mais si l’organisation peut réellement travailler avec lui.

Trois options, trois preuves à obtenir

Première option : maintenir la bascule complète. Elle ne devrait être présentée comme crédible qu’avec une répétition des processus critiques, des données contrôlées et une équipe de soutien disponible. Le statut « recette en cours » ne remplace pas un résultat observé. Qui a passé une commande complète, jusqu’à sa facturation, et quels écarts restent ouverts ?

Deuxième option : démarrer sur un périmètre réduit. Cela peut limiter l’exposition, mais crée parfois une coexistence coûteuse entre deux systèmes. Il faut alors documenter les interfaces temporaires, les doubles saisies, les rapprochements comptables et le responsable de chaque exception. Un petit démarrage n’est pas automatiquement un démarrage simple.

Troisième option : reporter. Le coût ne se limite pas aux jours d’intégrateur supplémentaires. Il comprend la prolongation des outils actuels, la remobilisation des utilisateurs, les engagements contractuels et les occasions commerciales perdues. Le report devient une décision défendable lorsqu’il achète une réduction précise du risque, avec une nouvelle condition de passage.

Remplacer le feu tricolore par une fiche d’arbitrage

Pour chaque option, une page suffit si elle contient les bonnes informations. La fiche doit permettre de répondre aux questions suivantes :

• Quelle activité serait affectée, et pendant combien de temps ?
• Quelle preuve manque pour autoriser la décision ?
• Quel coût supplémentaire et quel risque résiduel accepte-t-on ?
• Qui peut décider, et avant quelle date ?
• Quel retour arrière reste réellement possible ?

Le retour arrière mérite une vérification particulière. Revenir à l’ancien logiciel après plusieurs jours de saisie dans le nouveau n’est pas un simple bouton à presser. Il faut savoir où se trouvent les transactions, comment les rapprocher et qui rétablit une situation exploitable. Une option dont personne ne connaît le délai d’activation n’est pas encore une solution.

Définir les seuils avant la dernière réunion

Dans notre exemple, le comité pourrait exiger qu’une chaîne commande-livraison-facturation soit exécutée avec succès sur le périmètre retenu, que les écarts critiques aient un traitement accepté et que l’assistance au démarrage soit nominativement organisée. Ce sont des exemples de conditions à adapter, pas une norme universelle de recette ERP.

Le seuil doit déclencher un arbitrage identifié. Si la condition n’est pas remplie à la date convenue, le directeur de programme présente les options actualisées ; le sponsor métier et l’instance habilitée décident. On évite ainsi le glissement habituel : les réserves restent dans un compte rendu tandis que le calendrier continue comme si elles avaient disparu.

Appliquer le même raisonnement à la cyber et aux fournisseurs

Pour une indisponibilité informatique, la question devient : quels processus faut-il rétablir en premier, avec quelles dépendances et quelle preuve de restauration ? Un serveur redémarré ne démontre pas que l’entreprise sait livrer ou encaisser. Le scénario doit inclure les données, les accès, les personnes et les applications nécessaires au service métier.

Pour un fournisseur critique, on examine plutôt la sortie : dispose-t-on d’un export exploitable, des droits contractuels nécessaires et des compétences pour reprendre l’activité ? Ces dépendances et cette réversibilité font également partie du cadre développé dans Révolution Numérique !. Le principe reste identique : transformer une inquiétude générale en option préparée et en décision attribuée.

Ce qu’une mission doit laisser derrière elle

Le parcours de Guy de Lussigny comprend notamment la direction du programme ERP international de Clarins, des fonctions DSI de transition chez Suzuki France et un programme de risques IT à la Société Générale. Ces références situent les environnements d’intervention ; elles ne sont pas les entreprises du cas fictif présenté ici.

Sur un programme qui hésite entre maintien, réduction de périmètre et report, un cadrage peut viser quatre livrables : une carte des dépendances critiques, des options chiffrées avec les équipes, une fiche de décision COMEX et un suivi des conditions de passage. Le périmètre et les délais se définissent après examen de la situation, sans promettre un redressement standard.

Pour approfondir la gouvernance des SI, des programmes et des dépendances, découvrez Révolution Numérique !. Si une bascule ERP, une DSI fragilisée ou une transformation nécessite un pilotage opérationnel, présentez votre situation à Guy de Lussigny. L’objectif n’est pas un plan de plus : c’est une décision exécutable, avec ses responsables et ses preuves.

#DSI #ERP #ManagementDeTransition #Gouvernance #GuyDeLussigny