La question avant la conclusion.
- Angle
- governance
- Parcours
- 10 points de décision
- Lecture
- 8 min
La réunion se tient au siège. Autour de la table, les directeurs de trois filiales. À l'ordre du jour: « harmoniser nos systèmes ».
Chacun arrive avec une position implicite. Le siège veut un socle unique, pour piloter. Les filiales veulent garder ce qui marche chez elles, parce qu'elles ont mis trois ans à le faire marcher. Personne n'a tort. Et la réunion, si elle se tient sans grille d'analyse, se terminera sur un compromis mou: « un socle commun, avec des adaptations locales » — formule qui ne décide rien.
La question n'est pas si on harmonise. C'est quoi.
Trois choses qu'on confond en permanence
Avant tout arbitrage, il faut séparer trois notions que le langage courant mélange.
Plusieurs sites n'est pas un sujet de gouvernance. Une entreprise avec quatre entrepôts et une seule direction des opérations a un sujet de dimensionnement, pas de gouvernance. Elle décide une fois, elle applique partout.
Plusieurs activités est un sujet d'architecture. Une entreprise qui fait de l'industrie, de la distribution et du transport a besoin de systèmes différents qui se parlent. C'est une question d'interfaces, pas d'autorité.
Plusieurs entités avec une autonomie réelle est le seul vrai sujet de gouvernance. Il y a des directions distinctes, des budgets distincts, parfois des pays distincts — et donc des décisions qui peuvent légitimement diverger.
La grille: décider domaine par domaine, jamais en bloc
L'erreur structurante consiste à poser la question en une seule fois — « centralisé ou décentralisé? » — alors qu'elle appelle une réponse différente selon les domaines.
Notre grille de travail distingue quatre niveaux, et chaque domaine doit être placé dans l'un d'eux:
Commun obligatoire. Ce qui doit être identique partout, sans dérogation possible. Typiquement: la codification des articles, la définition des indicateurs, les règles de sécurité et d'accès. Ce niveau doit rester petit — chaque élément qu'on y met coûte de la coordination à perpétuité.
Commun par défaut, dérogation motivée. Le standard groupe s'applique, une filiale peut y déroger si elle documente pourquoi et si quelqu'un valide. C'est le niveau le plus utile, et le plus rarement formalisé.
Cadre commun, mise en œuvre locale. Le groupe fixe l'objectif et le vocabulaire; chaque entité choisit ses moyens. Exemple: « chaque entité doit pouvoir tracer un lot de bout en bout » — comment, c'est son affaire.
Purement local. Ce qui n'a aucun impact hors de l'entité. Il y en a plus qu'on ne croit, et le reconnaître explicitement fait gagner un temps considérable.
Passer les quinze ou vingt domaines d'un système d'information dans cette grille prend une demi-journée. C'est la demi-journée la plus rentable du projet.
Le référentiel: le seul sujet vraiment non négociable
Si un seul domaine doit être en « commun obligatoire », c'est celui-là.
Tant que le même produit porte trois codes différents dans trois filiales, aucune consolidation n'est possible. On peut construire les plus beaux tableaux de bord: ils additionneront des choses qui ne sont pas comparables. Et les corrections se feront à la main, dans un tableur, par quelqu'un dont c'est devenu le métier à plein temps.
Ce chantier n'est pas informatique. Il est politique et organisationnel:
qui a le droit de créer une référence?
selon quelles règles de nommage et de codification?
qui valide, dans quel délai?
que fait-on de l'existant divergent — on migre, on met en correspondance, on gèle?
Une remarque d'expérience: la mise en correspondance (garder les codes locaux et maintenir une table de traduction) semble être le compromis élégant. C'est presque toujours une dette. La table de correspondance devient un objet critique que personne ne maintient, et les erreurs s'y accumulent silencieusement.
Les flux entre entités: le point aveugle
Quand deux entités du même groupe se vendent des marchandises, se transfèrent du stock ou se rendent des services, on entre dans un domaine que presque aucun cahier des charges ne traite correctement.
Les questions à poser:
un transfert de stock entre entités est-il une vente, ou un mouvement interne? La réponse change tout, comptablement et opérationnellement;
qui porte le stock pendant le transport?
comment les deux mouvements — la sortie d'un côté, l'entrée de l'autre — se répondent-ils? Que fait-on quand ils ne se répondent pas?
les prestations rendues entre entités sont-elles facturées, et sur quelle base?
Ces flux sont souvent gérés par habitude, entre personnes qui se connaissent. Ils fonctionnent — jusqu'à ce qu'une des deux personnes change de poste.
Consolider ne veut pas dire temps réel
Il faut la désamorcer, poliment mais clairement. Une vision consolidée en temps réel suppose que tous les systèmes sources soient accessibles en permanence, que leurs données soient définies pareil, et que la fréquence d'échange le permette. Dans un groupe où les filiales ont des systèmes différents, cela demande un investissement considérable — pour une utilité souvent faible.
La bonne question est: quelle décision voulez-vous prendre avec cette information, et à quelle fréquence la prenez-vous?
Si la décision est hebdomadaire, une consolidation quotidienne suffit largement. Si elle est mensuelle, une consolidation hebdomadaire est confortable. Le temps réel ne se justifie que là où l'on agit en temps réel — ce qui est rare au niveau groupe, et fréquent au niveau d'un site.
Et surtout: harmoniser les définitions avant de consolider. Consolider des chiffres qui ne veulent pas dire la même chose produit un résultat faux avec une précision décimale. C'est pire que pas de chiffre du tout, parce que ça inspire confiance.
Déployer: la question du rythme
Un groupe qui décide d'harmoniser a trois stratégies possibles.
Le big bang — tout le monde bascule ensemble. Séduisant sur le papier, très risqué: un problème sur une entité bloque tout le monde, et personne n'a d'expérience à transmettre.
Le site pilote représentatif — une entité démarre, on apprend, on corrige, puis on déploie. C'est la stratégie que nous recommandons dans la majorité des cas. À une condition: que le pilote soit représentatif et non facile. Choisir la filiale la plus simple donne un pilote qui réussit et n'apprend rien.
Les vagues par famille — on regroupe les entités qui se ressemblent (même activité, même maturité, même pays) et on déploie famille par famille. Pertinent quand les entités sont vraiment hétérogènes.
Le choix dépend d'une seule chose: à quel point vos entités se ressemblent. Si elles ont les mêmes processus, le pilote suffit. Si elles divergent profondément, les vagues évitent de rejouer le même échec plusieurs fois.
Une dernière chose, sur les acquisitions
Un groupe qui grandit par rachat hérite régulièrement de systèmes qu'il n'a pas choisis.
La tentation est de tout remplacer immédiatement, « pour uniformiser ». C'est souvent une erreur de séquence: une entité fraîchement acquise traverse déjà une période de changement, et lui imposer un changement de système la même année ajoute un risque là où il y en a déjà beaucoup.
Le modèle qui fonctionne: définir dès le départ ce que toute nouvelle entité doit fournir au groupe — quelles données, à quel format, à quelle fréquence — et lui laisser du temps sur le comment. L'harmonisation des outils vient ensuite, quand l'intégration humaine est faite.
