En bref

La gestion des exigences locales au sein d’un modèle ERP global commence par la classification. Chaque demande correspond à une obligation légale, à un contrat client, à une contrainte opérationnelle physique ou à une préférence. Les trois premières ne justifient une dérogation que sur la base de deux éléments de preuve : un validateur désigné confirme le besoin, et la conception standard testée ne permet pas d’y répondre. Une préférence donne lieu à une formation et à un accompagnement au changement. Des règles précisent qui en assume la responsabilité : l’autorité de conception pour le modèle commun, le directeur d’usine pour la configuration spécifique à l’usine, et le promoteur pour les cas anciens et les désaccords non résolus.

Alignement du modèle global de l'ERP sur les exigences locales de l'usine tchèque

Le comité de pilotage a approuvé le modèle global, ainsi que la conception commune des processus et des systèmes que plusieurs entités du groupe utiliseront. Ce modèle définit le modèle de données commun, le plan comptable et les flux de processus standard.

C'est alors que la première usine tchèque d'un groupe dont le siège social est situé en Allemagne soumet une longue liste de modifications demandées. L'autorité chargée de la conception se trouve au siège social, tandis que l'usine est une entité juridique distincte disposant de ses propres contrats clients.

Le responsable du projet nourrit deux craintes légitimes. Refuser toutes les demandes risque d’empêcher l’usine d’expédier une commande ou de déposer un rapport réglementaire. Accepter toutes les demandes transforme chaque modification en un coût permanent en termes de données, d’assistance et de mises à jour. Dans le cadre du déploiement d’un ERP multinational, la première usine définit le modèle pour tous les sites suivants, et les échéances réglementaires et celles des clients ne peuvent pas être repoussées. Des demandes non validées lors des tests d’acceptation entraînent un report de la mise en service ou un lancement non documenté. Le grand livre consolidé cesse alors de refléter le fonctionnement réel de l’usine.

Concilier la normalisation au sein du groupe et les besoins opérationnels des usines

Le siège social a conçu le modèle de reporting consolidé et la vue d'ensemble de la trésorerie ; le groupe a donc raison de le protéger. Le fonctionnement de l'usine repose sur la disponibilité des lignes de production. Une étape de confirmation qui ajoute 20 secondes à chaque cycle machine réduit la production, et c'est le directeur de l'usine qui en porte la responsabilité.

Les problèmes commencent lorsque chaque partie interprète les préoccupations de l'autre comme une forme de résistance et que personne ne se sent responsable de la réconciliation. Il s'agit là d'une lacune dans la gouvernance de la localisation des progiciels de gestion intégrée (ERP), et non d'un choc des cultures.

Indicateurs clés d'un affaiblissement de la gouvernance des modèles ERP

Un comité de pilotage peut dégager quatre éléments à partir des données issues des propres registres du programme :

• Demandes non classifiées. Les obligations légales et les préférences figurent sur une même liste.
• Réunions binaires. Les avis font office de référence collective face aux réalités locales.
• Solutions de contournement pour les ombres. Les principaux utilisateurs conservent des feuilles de calcul hors ligne pour éviter les écritures comptables standard.
• Examen de conception non effectué. Les équipes locales font procéder à des modifications sans examen architectural.

N'importe lequel de ces éléments laisse penser que le groupe ne dispose pas d'informations fiables sur cette plante.

Classification des exigences locales relatives aux modèles globaux ERP en quatre groupes

Classer chaque demande dans l'un des quatre groupes avant que quiconque n'en discute. Ce premier classement est provisoire ; les éléments fournis par le validateur permettent de le confirmer ou de le modifier.

• Obligation légale. Une obligation légale, telle que la déclaration fiscale. Elle est validée par des spécialistes locaux du droit, de la fiscalité ou de la paie.
• Obligation contractuelle ou vis-à-vis du client. Un format de message, une étiquette ou une règle d'emballage. Le contrat ou le manuel client en assure la conformité.
• Limite physique de fonctionnement. Une contrainte liée au bâtiment, aux équipements ou au temps de cycle. Les ingénieurs d'usine la valident à l'aide des données de production.
• Préférence. La familiarité avec un écran ou une habitude héritée. La formation des utilisateurs clés et l'accompagnement au changement y répondent.

Une obligation légale impose à l'usine de s'y conformer, mais pas nécessairement au groupe de l'adapter. Une localisation standard ou une couche de reporting peut suffire à y répondre.

Informations essentielles concernant les demandes d'exception relatives aux modèles globaux ERP

Une affirmation devient vérifiable lorsqu'elle énonce cinq faits :

• L'opération ou le processus concerné, par exemple une entrée de marchandises.
• La preuve du besoin et le nom du propriétaire qui en est titulaire.
• L'option standard testée par l'équipe du projet, et le résultat.
• Conséquences pour l'usine si la conception standard est maintenue.
• L'impact prévu sur les données, les interfaces, l'assistance et les sites ultérieurs.

Une requête qui ne permet pas d'énoncer le troisième fait ne repose sur aucun résultat de test, quelle que soit sa catégorie.

Hiérarchisation des demandes d'exception ERP en fonction du calendrier et de l'impact

Un responsable expérimenté passe en revue la liste des demandes pour identifier les éléments manquants. Trois lacunes appellent à la prudence : une mention réglementaire sans nom de spécialiste, une exigence client citée de mémoire et une contrainte physique sans données chiffrées. Chacune de ces lacunes n’est pas prouvée, mais n’est pas non plus erronée ; la demande reste donc en attente.

La séquence suit l'ordre chronologique des dates. Fixez la date limite de classification en remontant à partir de la date des tests d'acceptation, en prévoyant un cycle complet de retests et le délai d'intervention des spécialistes. Une demande datée mais non encore confirmée est alors transmise au promoteur. Une demande non datée et ne comportant pas les cinq éléments requis est renvoyée à son auteur. Les préférences sont mises en production sur la conception standard avec une date de révision enregistrée.

Rôles et responsabilités en matière de validation des demandes des usines locales

Les spécialistes locaux de l'usine détiennent les pièces justificatives, souvent en tchèque : l'avis fiscal, la clause client. Les architectes du groupe gèrent la consolidation, les données de référence et la feuille de route de mise à niveau, et ne peuvent pas tester ce qu'ils ne peuvent pas lire. Un validateur désigné, basé localement là où se trouvent les pièces justificatives, confirme d'abord chaque élément.

Le responsable du programme coordonne l'examen et consigne chaque avis sans en certifier aucun. Guide de mise en œuvre de Microsoft Il convient de noter qu'un client et son partenaire de mise en œuvre peuvent chacun supposer que c'est à l'autre qu'incombe une activité. Désignez par écrit un validateur pour chaque demande avant le début de la révision.

Cadre des droits de décision dans la gouvernance des progiciels de gestion intégrés (ERP) au sein des multinationales

L'autorité de conception gère quatre éléments protégés : la consolidation et le plan comptable, les normes relatives aux données de référence, la feuille de route de mise à niveau et la charge de support. Les normes relatives aux données de référence et la feuille de route de mise à niveau peuvent faire l'objet de dérogations pendant une période limitée, à condition que l'exception reste isolée et soit assortie d'une date de réexamen. Ce n'est que rarement le cas pour le plan comptable et les règles de consolidation.

Le directeur d'usine est responsable au niveau local de la production et de la conformité. Dans les limites fixées par la charte, il prend toutes les décisions qui ne remettent pas en cause les autres éléments protégés, comme la mise en page des étiquettes. La charte du programme définit quatre paramètres fixés par le commanditaire :

• Une limite relative à la configuration locale de l'installation, vérifiable par les architectes, telle que la charge admissible.
• Une limite concernant les solutions de contournement enregistrées, telles que les efforts nécessaires pour apporter des modifications et procéder à de nouveaux tests.
• Une seule fenêtre de réponse pour les concours et les recommandations.
• La proportion de classements préférentiels contestés ou d'exceptions légales confirmées qui déclenche un réexamen du modèle avant le site suivant.

Le directeur d'usine cosigne toute demande rejetée parmi les trois premières catégories et peut contester un classement par ordre de préférence avant la date limite de classification. Le promoteur statue dans le délai imparti pour la réponse ; il prend également en charge une demande datée à laquelle l'examen ne peut répondre à temps, ainsi qu'un désaccord qui subsiste malgré l'examen complet des éléments de preuve. Dans ce cas, la meilleure option est généralement celle qui est la plus facile à annuler.

Quand faire appel à un directeur de programme ERP par intérim ?

Lorsque le responsable du programme, le responsable du processus et l’autorité de conception disposent du temps nécessaire et d’une procédure d’escalade, ils peuvent résoudre le problème, et un désaccord local ne justifie à lui seul pas la nomination d’un responsable par intérim. Une décision dont personne n’assume la responsabilité ne peut toutefois attendre le prochain cycle de pilotage. Personne n’en assume la responsabilité lorsque l’une des trois conditions suivantes est remplie :

• Ces signes persistent au-delà de la prochaine réunion de pilotage.
• Une date juridique ou client n'est associée à aucun validateur.
• Ce désaccord est renvoyé au promoteur une fois l'examen des éléments de preuve terminé.

Dans ce cas, un Directeur de programme ERP par intérim prend la tête du programme. CE Interim définit le mandat avant de proposer des candidats : les pouvoirs de décision, la hiérarchie et la procédure d'escalade. Le responsable rend compte au commanditaire, tandis que le directeur d'usine et l'autorité de conception conservent leurs propres responsabilités. CE Interim évalue ensuite chaque responsable à l'aune de ce contexte, par exemple dans le cadre d'une mise en service sur un premier site couvrant deux pays.

Portée de la décision déléguée relative à la gestion provisoire du système ERP

Le promoteur délègue les droits dont ne dispose pas le responsable du programme. Le dirigeant prend la décision finale :

• La date limite de classification, le tri provisoire et un validateur désigné par demande.
• Le groupe confirmé pour chaque demande, une fois que le validateur a fourni la preuve.
• Les demandes non datées qui ne comportent pas les cinq éléments requis sont renvoyées à leur auteur.
• Enregistrement des solutions de contournement relatives à des obligations échues, dans la limite prévue par la charte.

En ce qui concerne les éléments protégés et les dossiers des promoteurs, le dirigeant émet un avis dans un délai imparti, mais ne prend pas de décision. Il ne déroge pas aux critères d'acceptation, ne certifie pas la conformité aux exigences légales et n'autorise pas le lancement.

Le responsable est chargé du processus, et non du verdict : chaque demande fait l'objet d'une décision avant la date prévue. Un associé par intérim de CE examine le journal des décisions avec le maître d'ouvrage, à la recherche de recommandations ignorées, de réponses tardives du maître d'ouvrage et de solutions de contournement dont la date d'examen est dépassée. Lors du transfert de responsabilité, le registre des exceptions et la procédure d'examen sont transmis à une autorité de conception permanente.

Exemple d'enregistrement d'exception dans un ERP d'usine et étude de cas

Étude de cas : gestion des divergences au niveau de l'ERP d'usine

Le scénario ci-dessous est hypothétique. Il ne s'inspire d'aucune mission réalisée pour un client.

Un client a besoin d’une mise en page d’étiquette spécifique avant une date butoir fixée au cours de la période de test. Le responsable global du processus souhaite utiliser l’étiquette standard, afin de conserver une mise en page unique sur tous les sites. Le manuel du client, dont l’actualité a été confirmée par son propre interlocuteur, ainsi que le rejet par le scanner, constituent des preuves suffisantes. La charge de travail du support technique se limitant à une seule configuration d’impression, le directeur d’usine prend la décision dans le cadre des limites fixées par la charte. Si la mise en page avait eu une incidence sur les données de référence, c’est l’autorité de conception qui aurait tranché.

Exemple de registre des exceptions ERP vérifiable

Les exceptions aux modèles généraux s'interprètent au mieux comme des décisions pouvant faire l'objet d'un audit. Voici quatre exemples à titre d'illustration.

Ce différend juridique illustre un processus de validation. Toute exigence tchèque effective doit s'appuyer sur sa propre source en vigueur et faire l'objet d'un avis local qualifié.

Intégration des exceptions ERP approuvées dans le contrôle des modifications

Une exception acceptée ne modifie pas le modèle. Elle est soumise au contrôle des modifications, qui détermine si la version de référence approuvée doit être mise à jour et assume la responsabilité des répercussions sur les coûts et le calendrier. Les demandes rejetées sont conservées dans le dossier avec les motifs correspondants, afin que le site suivant n'ait pas à relancer le débat.

Foire aux questions : déploiements mondiaux d'ERP et exigences locales

Tous les sites de production ont-ils besoin de processus ERP identiques ?

Non. Le modèle de données, le plan comptable et les règles de consolidation restent communs. Les flux opérationnels peuvent varier lorsque des éléments probants démontrent l’existence d’un besoin réglementaire, contractuel ou physique auquel le processus standard ne peut répondre. Chaque divergence est attribuée à un responsable désigné et, lorsqu’elle s’écarte des normes relatives aux données de référence ou du plan de mise à niveau, elle est assortie d’une date de révision. Un même flux peut générer un résultat local différent, tel qu’une étiquette, tandis que les données restent communes.

Quels éléments permettent de valider une exception ERP locale crédible ?

Une preuve vérifiable par un tiers, détenue par un propriétaire identifié. Il s'agit d'une source légale confirmée par un spécialiste qualifié, d'une clause contractuelle ou, dans le cas d'une limite physique, de données de levé topographique et d'une démonstration. Une déclaration fondée sur l'expérience peut ouvrir la procédure d'examen, mais ne peut pas la clore. L'équipe de projet doit également avoir testé l'option standard et consigné le résultat.

Qui est chargé de vérifier la conformité des systèmes ERP aux exigences légales ?

Un spécialiste local qualifié dans le domaine concerné : un conseiller fiscal pour les déclarations fiscales, un spécialiste de la paie pour la gestion des salaires. Certaines tâches évoluent en fonction de la législation, c'est pourquoi l'avis porte une date. Le même spécialiste le reconfirme avant le nouveau test final. Si l'avis arrive après la date limite de classification, le responsable prend en charge la demande. Une tâche datée peut être traitée selon une solution de contournement enregistrée jusqu'à ce qu'un avis tardif soit reçu.

Comment les exceptions ERP acceptées sont-elles gérées dans le cadre du contrôle des modifications ?

L'autorité de conception l'enregistre et soumet une demande de modification portant sur la conception, la configuration, les coûts, les tests et le support. Chaque impact est attribué à un responsable désigné. Le comité de contrôle des modifications examine l’ensemble des coûts avant de décider si la base de référence doit être modifiée. Jusqu’à ce moment-là, le modèle et son code ne sont pas modifiés localement. La seule exception concerne une solution de contournement assortie d’une date de fin, enregistrée en lien avec un engagement daté.

Connaissances connexes et prochaine étape

Les exigences locales non prises en compte dans le modèle global de l'ERP donnent lieu à des solutions de contournement locales, et le groupe se retrouve privé de données fiables sur ses sites. La mise en place d'un processus d'évaluation structuré permet de répondre aux besoins locaux légitimes tout en préservant l'intégrité et la cohérence du modèle global de base.

Lectures complémentaires:

• Le siège allemand a approuvé la restructuration d'une usine tchèque. Quel sera le coût de ces économies ?
• Lorsque plusieurs usines de CEE modifient leurs capacités de production simultanément, qui définit l'ordre dans lequel ces changements doivent être mis en œuvre ?
• Le siège allemand estime que l'usine tchèque respecte ses objectifs. Le nombre d'heures de retouche indique que la capacité est déjà épuisée.

CE Interim met à votre disposition un cadre supérieur dont les qualifications ont déjà été vérifiées, dont le profil correspond à la mission et qui est lié par un accord de confidentialité, prêt à prendre ses fonctions dès que le cahier des charges de la mission aura été finalisé. Lorsque personne n'est en mesure de trancher entre la conception du groupe et l'usine, adressez-vous à un Associé par intérim chez CE.