En bref

Le contrôle des changements dans le cadre du programme ERP offre au commanditaire une vue d'ensemble de la valeur, du coût, des tests et de l'impact sur le lancement avant qu'il n'approuve une demande. Une fois que le programme a validé une demande en tant que changement, le commanditaire dispose de quatre options : accepter, reporter, échanger ou refuser. Le directeur du programme ERP prépare la recommandation dans un document unique. Le commanditaire fixe les limites de délégation et décide des montants, des délais et de la base de référence révisée au-delà de ces limites.

Comment de simples demandes de modification d'un ERP peuvent entraîner un élargissement progressif du périmètre du projet

Une fois la conception validée, les demandes affluent. Elles semblent mineures : un nouveau champ sur un écran, un seuil d’approbation modifié, une mise en page différente pour un rapport. Chacune est présentée au comité de pilotage comme une nécessité, décrite comme nécessitant quelques jours de consultation et présentant un faible risque.

Un programme peut perdre le contrôle sans qu’aucune décision majeure n’ait été prise. Les promoteurs ont de bonnes raisons d’accepter, car les demandeurs connaissent bien leurs activités. Refuser peut donner l’impression de faire obstruction lorsqu’ils préviennent que le débit ou la clôture de fin de mois en pâtiront. Cet instinct est justifié. La difficulté réside dans ce que le promoteur peut percevoir au moment de la décision.

Conséquences opérationnelles et sur les tests en aval des modifications apportées au périmètre du système ERP

Le commanditaire identifie une fonctionnalité logicielle sur la page. Cette fonctionnalité entraîne toute une série de conséquences. Prenons une demande hypothétique. Une modification de la configuration de la logique d’allocation des stocks, qui prend deux jours, peut entraîner dix jours de développement de scripts personnalisés. Elle peut invalider trente scénarios de tests d’intégration de bout en bout déjà réalisés. Elle peut également nécessiter la renégociation d’interfaces avec des tiers et détourner des utilisateurs métier clés des répétitions de basculement critiques.

Ces chiffres illustrent une demande hypothétique et ne constituent en aucun cas un ratio applicable à tout autre changement. Lorsque le périmètre, le coût, les dépendances liées aux tests et le calendrier de lancement figurent dans des rapports distincts, aucune page ne permet à elle seule de rendre compte de l'impact global. La base de référence évolue alors sans que personne n'ait pris la décision de la modifier.

Défis transfrontaliers liés à la gouvernance des demandes de modification dans les progiciels de gestion intégrée (ERP)

Le fait que le siège social soit situé à Paris, Zurich, Munich ou Vienne soulève des préoccupations légitimes. Il faut mettre en place des normes à l'échelle du groupe, assurer une visibilité globale et respecter le budget convenu avec l'intégrateur de systèmes. Il faut également justifier tout écart auprès du conseil d'administration.

L'usine utilise un ensemble différent. Une usine de premier rang située en Pologne, en Tchéquie, en Hongrie ou en Roumanie peut approvisionner des chaînes de montage automobiles allemandes ou des clients du secteur aérospatial. Ces clients fixent des créneaux de livraison séquencés, des audits de traçabilité et des normes d'emballage. Le modèle global peut ne pas inclure la logique de codes-barres ou les manifestes de recyclage des conteneurs exigés par un client. L’usine a alors besoin d’une réponse rapide, car sa date de basculement est liée aux créneaux de livraison des clients et aux calendriers de production. Un contretemps peut signifier le prochain créneau disponible, et non pas simplement quelques jours ouvrés.

Ces deux positions sont raisonnables. Des tensions apparaissent lorsque la communication entre les deux parties est lente. Les équipes des usines cherchent alors des solutions de contournement, comme le fait de s'adresser de manière informelle à un consultant local. Il s'agit là de signaux, et non d'un acte de défiance.

Lors d'une demande transfrontalière, trois confirmations provenant de trois instances différentes sont nécessaires. Ces instances relèvent d'entités et de systèmes juridiques distincts, et aucune ne peut valider à elle seule l'intégralité de la demande. La section « Autorités » indique qui valide quoi.

L'intégrateur répond aux demandes qu'il reçoit, mais la décision concernant le périmètre revient au client. Cela nécessite la présence, du côté du client, d'un responsable disposant d'un pouvoir explicite en matière de modification. En l’absence d’un tel responsable, l’entreprise risque de payer deux fois : d’abord pour une personnalisation non budgétisée, puis pour des défauts d’intégration après la mise en service. La question de savoir si un besoin local justifie une dérogation au modèle global relève d’une décision distincte, prise avant celle-ci.

Indicateurs clés de la dérive du périmètre des projets ERP

Les commanditaires et les comités d'audit n'ont pas besoin de consulter les journaux de configuration pour constater que le périmètre du projet s'écarte de ce qui était prévu. Des signes concrets indiquent qu'un programme a perdu le contrôle du changement.

• Lignes de base non synchronisées : L'intégrateur, le bureau de programme et l'usine disposent chacun de leurs propres calendriers généraux.
• Éléments en attente non documentés : Les responsables des axes de travail tiennent à jour des listes informelles des améliorations apportées à la conception qui ne sont pas soumises au comité de pilotage.
• Tests de régression itératifs : Les tests reprennent car de nouvelles améliorations ont été intégrées après le gel du logiciel.
• Érosion due aux aléas : Les ordres de modification émis par les fournisseurs épuisent la réserve pour imprévus, tandis que les jalons clés restent inachevés.

Un seul signe peut avoir une cause banale. Deux signes ensemble justifient de réexaminer la manière dont les modifications sont intégrées au programme.

Cadre décisionnel des promoteurs pour les demandes de modification du système ERP

La gouvernance des demandes de modification dans un ERP repose sur une base de référence bien établie. Ce cadre part du principe que le programme a déjà confirmé qu’il s’agit bien d’une modification, et non d’un travail convenu mais non achevé. Si le client et le partenaire de mise en œuvre ne s’accordent toujours pas sur la nature de la demande, il convient de clarifier ce point au préalable. Le commanditaire, ou le directeur du programme dans les limites des pouvoirs qui lui ont été délégués, dispose alors de quatre options. Chacune nécessite des justificatifs différents.

Option 1 : Accepter et financer les ajouts au périmètre du progiciel de gestion intégré (ERP)

Le commanditaire approuve cet ajout et le finance à partir de la réserve pour imprévus. Si les dépendances l’exigent, le commanditaire prolonge également par écrit la période de test et la date de basculement. Justificatifs requis : coût écrit, heures de travail des utilisateurs clés internes, tests concernés et date d’impact. Le compromis est clair : la réserve pour imprévus utilisée aujourd’hui ne pourra pas couvrir la prochaine demande.

Option 2 : reporter les demandes ERP aux versions postérieures au lancement

Le responsable du projet valide la valeur ajoutée et transfère la demande vers une version postérieure à la mise en production. L'exemple ci-dessous désigne cette étape sous le nom de « Phase 1.1 » ou « Jour 2 ». La bascule s'effectue selon la base de référence établie. Justificatifs requis : une solution de contournement provisoire clairement identifiée, ainsi que la confirmation que l'activité peut fonctionner sans cette modification le jour du lancement. En contrepartie, le demandeur doit contourner cette lacune pendant un certain temps.

Option 3 : adapter la portée du projet ERP afin de garantir le respect des dates de mise en service

Le promoteur accepte cette modification à une condition : qu'un élément existant équivalent, non critique, soit retiré de la version initiale. Cela permet de préserver la capacité de test et la date de lancement. Justificatifs requis : la preuve que l'élément supprimé est réellement non critique, ainsi que l'accord de son responsable pour le reporter. Le compromis consiste à faire patienter une demande pour qu'une autre puisse être traitée.

Option 4 : Refuser les demandes de modification non essentielles du système ERP

Le promoteur rejette la demande car sa valeur ne justifie pas le coût, la perturbation des essais ou le risque opérationnel. Un refus repose sur une évaluation du moment choisi et des conséquences, et non sur le bien-fondé de l’idée. Justificatif requis : une motivation consignée par écrit, afin que le demandeur puisse revenir après le lancement avec un dossier plus solide. Ce compromis est une fonction qui comporte une lacune et peut entraîner une perte de confiance dans le programme.

Autorité d'approbation dans le cadre du contrôle des modifications du périmètre ERP

Le directeur du programme ERP dispose d'une délégation de pouvoirs en matière de contrôle des changements. Il évalue la faisabilité technique, les interdépendances entre les axes de travail et la disponibilité des ressources, puis formule des recommandations. Il doit également être habilité à suspendre les ajouts informels au périmètre du projet et à soumettre des choix commerciaux clairs au commanditaire.

Au-delà des limites déléguées, c'est le responsable du projet qui prend les décisions relatives aux ressources financières et au calendrier. Ces décisions concernent le budget, le calendrier et la date de mise en service. Il peut s'agir du directeur financier du groupe, du directeur des opérations du groupe ou d'un autre dirigeant responsable du projet.

Déclencheurs de remontée hiérarchique pour les modifications du budget et du calendrier ERP

Le contrôle des modifications budgétaires dans l'ERP fonctionne lorsque le responsable définit dès le départ des limites de délégation. Celles-ci doivent être fixées avant la première demande, et non au cours d'une discussion portant sur une demande ultérieure. Le responsable fixe une limite pour chaque demande ainsi qu'une limite cumulative pour les imprévus. Une demande fractionnée afin de rester en dessous d'une limite compte pour une seule demande. Ces critères de déclenchement envoient directement la demande au responsable.

• Cette demande entraîne le report de la date de mise en service ou d'une autre étape clé déjà fixée.
• Cette demande, ajoutée à celles déjà approuvées, mobilise des fonds de réserve au-delà de la limite fixée par le promoteur.
• La demande modifie un critère de passage d'étape ou une conception validée.
• L'intégrateur et le directeur du programme ne sont pas d'accord sur l'impact.

Tout montant inférieur aux seuils de déclenchement reste sous la responsabilité du directeur du programme, qui l'enregistre et rend compte du solde de réserve à chaque cycle de pilotage.

Rôles en matière d'approbation transfrontalière pour les sites de production et le siège du groupe

Le directeur d'usine ou le directeur général confirme que la demande est nécessaire d'un point de vue opérationnel. Des spécialistes qualifiés dans le pays où se trouve l'usine vérifient que toutes les exigences légales sont respectées. Le siège social valide les normes du groupe et débloque les fonds.

Des limites claires profitent aux deux parties. Le site reçoit une décision, ou une demande de preuves datée, lors de la première réunion du comité de pilotage qui examine la demande. Pour les demandes émanant du client ou imposées par la loi, le promoteur peut définir une procédure hors cycle et en fixer la fréquence. Le siège social consulte chaque décision dans un dossier unique.

Champs obligatoires pour une fiche de décision relative à la migration vers un ERP

Le registre des décisions de modification attribue au promoteur une page pour chaque demande. Il s'agit d'un outil de travail destiné au contrôle des modifications du périmètre de l'ERP. CE Interim le propose comme une aide pratique, et non comme une norme reconnue. Il comporte six champs.

• Description de la demande de modification : ce que demande le demandeur et pourquoi maintenant.
• Valeur commerciale et justification opérationnelle : le processus qu'il protège.
• Coût du prestataire et impact sur les ressources internes : les honoraires externes, les heures de travail internes et le solde de la réserve pour imprévus avant et après.
• Analyse des dépendances et de l'impact du calendrier : les tests concernés et les dates associées.
• Portée déplacée ou modifiée : ce qui est conservé dans la version, le cas échéant.
• Décision approuvée et scénario de référence actualisé : le responsable de l'approbation, l'option retenue et le plan révisé.

Le directeur du programme consigne l'impact avant que le promoteur ne prenne sa décision. Ensuite, le directeur met à jour le plan associé et en informe les sites concernés ainsi que l’intégrateur. L’autorisation de lancement, le contrat et les critères d’acceptation constituent des décisions distinctes, chacune s’appuyant sur ses propres justifications. Celles-ci relèvent de la responsabilité du promoteur, ou du Conseil d’administration lorsque le poste est vacant. Toute modification d’une date fixée par le Conseil d’administration doit également être soumise à ce dernier.

Liste de contrôle pour la vérification par le promoteur avant l'approbation des modifications apportées au périmètre du projet ERP

La fiabilité d'un dossier dépend entièrement de la fiabilité des chiffres qu'il contient. Un commanditaire expérimenté se méfie d'une demande accompagnée d'une seule estimation, car chaque partie ne fixe le prix que de sa propre partie.

Tout d'abord, déterminez ce que chaque estimation ne prend pas en compte : les nouveaux tests, les heures de travail des utilisateurs clés, les responsables d'interface et le temps nécessaire à la répétition de la mise en service. Ensuite, rassemblez dans un même tableau les chiffres fournis par l'intégrateur, l'usine et le service financier central, afin qu'aucune des parties ne surévalue son propre impact. Ce n'est qu'alors que vous pourrez poser la question décisive : l'entreprise peut-elle fonctionner le jour du lancement sans ce changement ?

Une étape manuelle dans un processus non critique peut rester imparfaite. Il en va de même pour un rapport en attente de sa première publication. Il n’en va pas de même pour les lacunes en matière de facturation, de gestion des stocks, d’expédition des commandes ou de conformité réglementaire. Le seul compromis qui reste concerne les imprévus. Chaque validation engendre des coûts qui ne permettent pas de couvrir la demande suivante ; le responsable du projet doit donc évaluer cet équilibre avant de donner son accord.

Exemples concrets : évaluation de l'impact des modifications du périmètre d'un ERP sur les données factuelles

Ce scénario est hypothétique. Il ne s'agit pas d'un client de CE Interim, et les chiffres sont donnés à titre indicatif et ne constituent pas des références. Un équipementier automobile de nationalité autrichienne déploie le modèle ERP de son groupe dans une usine en Pologne. Au cours d'un cycle de pilotage, plusieurs demandes sont reçues, chacune étant qualifiée de « mineure ».

Avant la réunion, le directeur du programme ERP consigne chaque demande dans le registre des décisions de modification. L'intégrateur fournit une estimation écrite de l'impact sur les coûts, les tests et les délais. L'usine et le service financier central communiquent leurs heures de travail internes. Ce registre offre au promoteur un cadre structuré pour examiner, évaluer et statuer sur chaque modification ERP proposée. Il empêche toute modification de périmètre d’être intégrée sans visibilité explicite sur les coûts, les tests et les jalons de livraison.

Exemple d'acceptation : enregistrement automatisé des retours en bord de ligne

L'usine souhaite que les opérateurs cessent de saisir manuellement les retours de ferraille, et cette demande est conforme aux critères de base.

• Demande : prise de rendez-vous automatisée pour les retours en bord de ligne.
• Avantage : élimine la saisie manuelle des retours de rebuts ; permet de gagner 1,5 heure de travail administratif par équipe.
• Coût : 18 500 € de frais de prestataire externe ; 45 heures de travail consacrées à la configuration par les utilisateurs clés en interne.
• Tests et calendrier : nécessite 4 jours de tests de régression au sein du volet « Assembly » ; aucun retard sur le chemin critique.
• Portée modifiée : Aucune modification requise ; imprévu pris en charge.
• Décision et état de référence : Approuvé (Accepter maintenant) : budget de référence mis à jour ; tests terminés au cours du Sprint 4.

Le directeur d’usine confirme ce besoin. L’impact est maîtrisé : les tests s’inscrivent dans un volet du projet disposant d’une marge de capacité, et le chemin critique est respecté. Aucun critère d’escalade n’étant rempli, le directeur de programme approuve la modification dans les limites des pouvoirs qui lui ont été délégués. La décision est consignée à l’intention du maître d’ouvrage. Le directeur met à jour la base de référence et rend compte de la marge de sécurité restante au cours du même cycle de pilotage.

Exemple d'échange de périmètre : tableau de bord personnalisé des indicateurs clés de performance (KPI) pour cadres dirigeants

Les dirigeants du groupe souhaitent disposer d'un tableau de bord pour remplacer les rapports statiques sous forme de feuilles de calcul, et ce besoin est tout à fait légitime.

• Demande : Tableau de bord personnalisé des indicateurs clés de performance (KPI) pour cadres dirigeants.
• Avantage : Remplace les rapports statiques sous forme de feuilles de calcul destinés à l'équipe de direction du groupe.
• Coût : 34 000 € pour le développement du fournisseur ; 30 heures consacrées à l'examen des rapports financiers centraux.
• Tests et calendrier : complexité élevée ; mobilise les architectes principaux chargés du reporting pendant les tests d'acceptation par les utilisateurs.
• Portée modifiée : reporter au deuxième jour les rapports de synthèse non critiques sur les centres de coûts.
• Décision et état de référence : périmètre convenu : approuvé pour la version initiale ; rapports de synthèse reportés à la phase 1.1.

Le siège social a ici un réel besoin : une visibilité fiable sur l'usine. Le coût va au-delà des honoraires du prestataire, car les tests de réception nécessitent les mêmes architectes chargés du reporting. Le report de la validation des rapports de synthèse modifie une conception déjà validée, ce qui déclenche une escalade. Le commanditaire consigne par écrit l'accord du responsable du rapport concernant ce report, puis procède à un échange plutôt qu'à un ajout. Le tableau de bord est intégré à la version initiale.

Exemple de report : traçabilité des palettes spécifiques à chaque client

Un distributeur régional a des besoins logistiques particuliers, et la relation commerciale revêt une grande importance.

• Demande : traçabilité des palettes spécifiques à chaque client.
• Valeur : Réponse à une demande logistique hors norme émanant d'un distributeur régional unique.
• Coût : 26 000 € de frais de fournisseur ; logique personnalisée très complète dans le module de gestion des entrepôts.
• Tests et calendrier : retarde de 12 jours ouvrés la validation de l'intégration de la gestion des entrepôts.
• Portée modifiée : aucune n'a été identifiée par le groupe de travail demandeur.
• Décision et situation de référence : reporté à la phase 1.1 : déployé 60 jours après le lancement ; utilisation initiale d'un journal de packaging manuel.

Ce retard repousse une échéance déjà fixée, ce qui déclenche une procédure d'escalade, et le groupe de travail à l'origine de la demande ne peut en aucun cas renoncer à son objectif. Le directeur de l'usine confirme que le distributeur a besoin d'un processus opérationnel dès le premier jour. Un registre manuel permet d'y répondre. Le responsable du projet reporte la demande, désigne le responsable de l'entrepôt comme responsable du registre et fixe une date de révision.

Exemple de refus : facturation automatisée par auto-facturation des fournisseurs

Le service financier souhaite accélérer le rapprochement des factures au sein de l'ensemble de la chaîne d'approvisionnement, et les avantages que cela présente semblent plausibles.

• Demande: Facturation automatisée par les fournisseurs (auto-facturation).
• Valeur: Accélère le rapprochement des factures fournisseurs au sein de la chaîne d'approvisionnement européenne.
• Coût: 52 000 € consacrés au développement chez le fournisseur ; reconfiguration importante de l'interface EDI.
• Tests et calendrier: Modifie les règles fondamentales de comptabilisation ; compromet la fenêtre de basculement du système financier principal.
• Portée décalée: Aucune ; l'équipe demandeuse n'est pas disposée à modifier le périmètre du projet.
• Décision et situation de référence: Refusé : risque élevé lié au calendrier ; le rapprochement standard des bons de commande est maintenu pour la mise en service.

La décision repose sur le risque lié au calendrier, et non sur le bien-fondé du projet. La demande modifie les règles financières fondamentales, ce qui entraîne une modification d’une conception déjà validée et déclenche une procédure d’escalade. L’équipe à l’origine de la demande ne modifiera pas le périmètre du projet. Le commanditaire maintient l’alignement standard pour la mise en production et consigne la raison de cette décision. L’autofacturation touche également aux règles de facturation, qui varient d’un pays à l’autre. Des spécialistes qualifiés en Pologne vérifient ce que les règles autorisent avant que l’idée ne soit renvoyée.

Principaux enseignements tirés des exemples de modification du périmètre d'un ERP

Un même enregistrement a donné lieu à des réponses différentes pour des demandes apparemment similaires, et aucune n’a abouti à un gel général. Il s’agit là de tendances observées dans ce scénario, et non de règles. La demande acceptée a eu un effet limité, et le chemin critique a été respecté. L'échange a fonctionné car la capacité de test constituait la contrainte et qu'un élément non critique avait un responsable disposé à s'en charger. Le report a fonctionné car l'activité pouvait se poursuivre grâce à une solution de contournement définie. Le refus a fait suite à un risque élevé lié au calendrier, sans aucune marge de manœuvre possible.

L'usine a reçu une réponse motivée à chaque demande, y compris celles qui n'ont pas été retenues. La demande acceptée a puisé dans la réserve pour imprévus ; la demande suivante se heurte donc à une réserve moins importante. Le groupe conserve un niveau de référence qu'il est en mesure d'expliquer.

Remédier aux lacunes en matière de gouvernance dans le contrôle des modifications du périmètre des systèmes ERP

Une autorité interne compétente peut assurer le contrôle des modifications apportées au périmètre de l'ERP, dans le cadre de limites déléguées et d'une procédure de renvoi vers le promoteur. Le promoteur, ou le Conseil d'administration si le poste est vacant, peut vérifier la conformité avec ces conditions figurant dans le dossier du programme.

• Aucun responsable côté client n'est à la fois en charge du budget, du plan de test et du plan de basculement ; ces différents aspects sont donc décidés séparément par des instances distinctes.
• Le directeur du programme ne peut pas suspendre les ajouts informels au périmètre, car personne ne lui a accordé cette autorisation par écrit.
• Le poste de parrain est vacant, ou le parrain dirige l'entreprise, ce qui fait que les demandes restent en attente au-delà d'un cycle de pilotage.
• Les chiffres relatifs à l'impact fournis par l'intégrateur, la centrale et le service financier divergent toujours, et personne n'est habilité à les harmoniser.

Lorsque deux ou plusieurs de ces conditions sont réunies, le programme ne statue plus sur les demandes concernant un même dossier. Le groupe risque alors de payer deux fois ou de voir la date fixée par le Conseil modifiée par défaut. Selon CE Interim, le programme présente alors un risque critique pour l’entreprise et nécessite un responsable côté client doté d’un pouvoir décisionnel. Une échéance à elle seule ne constitue pas une raison suffisante pour nommer un dirigeant intérimaire.

Le rôle d'un directeur de transformation par intérim dans la gouvernance ERP

Un Directeur intérimaire de la transformation et des programmes peut détenir le pouvoir de modification côté client. Ce rôle prend ses décisions dans le cadre d'une délégation écrite. Il rend compte à la personne qui le lui a conféré : le maître d'ouvrage, ou le conseil d'administration si le poste est vacant. Il ne s'agit ni du chef de projet de l'intégrateur, ni d'un conseiller qui se contente de formuler des recommandations.

Le mandat prévoit des limites de délégation, fixées dès que les chiffres sont regroupés dans un seul dossier. Il désigne le cadre par intérim comme seul responsable du plan côté client. Il définit une procédure d'escalade et prévoit le transfert du dossier à un responsable désigné. Le cadre transmet au décideur l'ensemble des documents requis : la confirmation des besoins par l'usine, la confirmation juridique locale et l'autorisation de déblocage des fonds par le siège.

Les partenaires intérimaires de CE vérifient la qualité du dossier de modification et facilitent la remontée des problèmes. Ils fournissent à la personne ayant délégué cette responsabilité une visibilité sur l'avancement des travaux selon une fréquence convenue et supervisent le transfert de responsabilité.

Définition du mandat provisoire en matière de contrôle de la direction

Si le poste de directeur est vacant ou si le titulaire ne dispose pas d'une autorisation écrite, le dirigeant par intérim assure l'intérim pour la durée du mandat. Il en va de même lorsque ce poste relève de l'intégrateur ou du service informatique.

Lorsqu’il existe un administrateur compétent mais que le poste de commanditaire est vacant, le mandat relève de l’autorité supérieure à celle de l’administrateur. Si le poste de commanditaire est vacant, le conseil d’administration désigne, avant l’entrée en vigueur du mandat, la personne habilitée à prendre les décisions réservées. Celles-ci portent sur le capital dépassant les limites fixées, le calendrier et la date de mise en service. Un Directeur financier de transition ou Chef d'exploitation de transition peut les maintenir dans les limites fixées par le Conseil d'administration.

L'ordre des étapes est important. Tout d'abord, le dirigeant regroupe dans un seul dossier les chiffres d'impact fournis par l'intégrateur, l'usine et le service financier. Il y intègre également le carnet de commandes informel, en se réservant le droit de suspendre tout nouvel ajout informel. Ensuite, le promoteur, ou le Conseil d'administration si le poste est vacant, fixe les limites de délégation sur cette base. Ce n’est qu’alors que le dirigeant lance le cycle de pilotage, avec la date de restitution convenue dès le départ.

Cette nomination ne modifie pas le contrat de mise en œuvre, ne déroge pas aux critères d'acceptation et n'autorise pas le lancement. Ces responsabilités incombent au promoteur, ou au Conseil d'administration lorsque le poste est vacant. Toute modification d'une date fixée par le Conseil d'administration doit également être soumise à ce dernier.

Publication de lignes directrices sur la gouvernance du périmètre des systèmes ERP

Deux sources publiées viennent étayer le principe de maîtrise du périmètre. Le guide Dynamics 365 de Microsoft décrit des tableaux de conception qui examiner et approuver conception de solutions. Le document précise que les équipes doivent respecter les critères des étapes de validation, sans les ignorer " sous l'effet de la pression ou de l'optimisme ".

Le prestataire de services ERP Atreus fait état d'un dépassement budgétaire lié au déploiement du système ERP pour le service après-vente qui a permis de stabiliser la situation. L'entreprise a revu le périmètre, le budget et les phases du projet, et a défini les rôles et les responsabilités des différents acteurs : métier, informatique et partenaires. Aucune des deux sources ne décrit cet état des lieux ni n'identifie un changement particulier comme en étant la cause. Le rapport d'Atreus est un rapport de prestataire, et non un audit indépendant.

Foire aux questions sur la gestion des changements dans le cadre d'un projet ERP

Faut-il geler les modifications du périmètre du projet ERP à l'approche de la mise en service ?

Ce n'est pas une règle générale. Un gel peut empêcher l'entreprise de fonctionner. Une modification qui répond à une exigence légale ou qui protège un processus critique justifie pleinement d'être acceptée. Les spécialistes du pays où se trouve l'usine doivent confirmer que cette exigence est bien réelle. Les améliorations non essentielles peuvent attendre une version ultérieure.

Qui approuve les modifications dans le cadre du contrôle des changements du périmètre ERP ?

Le directeur du programme ERP approuve les demandes dans les limites qui lui sont déléguées et les enregistre. Une demande qui répond à un critère de déclenchement est transmise au parrain exécutif, qui décide du budget, du calendrier et de la date de mise en service. Le parrain règle également tout désaccord entre l'intégrateur et le directeur du programme concernant l'impact.

Un cadre intérimaire remplace-t-il le directeur du programme ERP ?

Ce n'est pas le cas par défaut. Un directeur compétent disposant d'une autorisation écrite conserve ce poste. Lorsqu'un dirigeant par intérim occupe ce poste, le mandat définit la hiérarchie et les limites de la délégation de pouvoirs. Il fixe également dès le départ une date de passation de pouvoirs. Les décisions relatives au contrat, à l'acceptation et au lancement restent du ressort du promoteur, ou du conseil d'administration lorsque le poste est vacant.

Qu'advient-il de la date de lancement convenue lorsqu'un changement de système ERP est accepté ?

Le maître d'ouvrage redéfinit par écrit les bases de référence du programme : calendrier général, dates des étapes clés, plans de tests d'intégration et budget. Le directeur du programme en informe ensuite tous les sites et fournisseurs concernés. Lorsque le Conseil d'administration s'est engagé sur la date initiale, le maître d'ouvrage lui soumet d'abord la nouvelle date.

Connaissances connexes et prochaine étape

Le contrôle des modifications du périmètre ERP protège la base de référence lorsque chaque demande entraîne des implications en termes de coût, de test et de date, le tout regroupé en une seule décision. Une demande approuvée sans cette prise en compte peut entraîner une mise en service avant que le comité de pilotage n’ait convenu d’une nouvelle date. Le promoteur, ou le comité de pilotage si le poste est vacant, vérifie d’abord la conformité des conditions ci-dessus par rapport au dossier du programme. L’étape suivante consiste à définir les limites de délégation et à déterminer si l’écart se situe au niveau du programme ou du promoteur.

À lire également :

• Fermeture d'une usine américaine depuis l'Allemagne : le responsable de site par intérim qui a mené à bien cette mission en six mois
• Un fournisseur approvisionne plusieurs usines d'Europe centrale et orientale. Comment répartir les stocks limités ?
• Pourquoi un objectif de coût de production ne revient pas à repenser le modèle opérationnel

CE Interim assure un accompagnement transfrontalier des dirigeants dans le cadre de transformations stratégiques de l'entreprise. Une fois le cahier des charges établi, un cadre supérieur préalablement sélectionné, dont le profil correspond à la mission et qui a signé un accord de confidentialité, est prêt à prendre ses fonctions.

Si deux ou plusieurs des conditions ci-dessus sont remplies, consultez un(e) Associé par intérim chez CE concernant le mandat.