La seconde question, quant à la nature du Programme de transformation, résulte de l’histoire de l’entreprise. Celle-ci s’est le plus souvent construite à partir de fusions & acquisition d’une part, de schémas directeurs informatiques successifs plus ou moins complets et cohérents d’autre part. Il en résulte que les entités de l’entreprise concernées par la transformation digitale – Business Units et / ou Géographies ainsi que les Fonctions Centrales ou Support métier et bien sûr la / les DSI– mettent en œuvre jusqu’ici les éléments de la chaîne de valeur d’une manière plus ou moins hétérogène. A titre d’exemple projeté sur l’élément « solution logicielle », le nombre de solutions ERP ou la diversité des paramétrage d’une même solution, le paysage des solutions CRM, CMS ou e-commerce peuvent être élevés.

Cette question peut s’énoncer comme suit : quel est le degré de convergence attendu entre les éléments de la chaîne de valeur de l’entreprise impactés, entre les différentes entités de l’entreprise concernes ? Quels degrés d’éloignement maintenu ou rapprochement à créer souhaite t’on en cible pour ces éléments de la chaîne. Pour en rendre la mesure tangible, on peut d’expérience distinguer deux axes de convergence :

• La standardisation ou action d’uniformiser, par opposition à conserver une diversité
• La mutualisation ou action de mettre en commun des moyens organisationnels et humains,outils et infrastructures informatiques, données, …

Il n’y a pas de règle générale pour définir le bon ou mauvais niveau de convergence à atteindre par un Programme. Par contre et dans un but de rationalisation des éléments de la chaîne de valeur, il convient de s’interroger sur la pertinence à standardiser et mutualiser ces éléments. Est-il par exemple utile pour un Programme de CRM SaaS de faire converger les Processus Métier (Vente, MKT, Service), l’organisation et les rôles, les solutions informatiques et d’exploitation des données ? La question concrète induite ici est : « quels paramètres entraînent, pour de bonnes raisons, l’utilité partielle ou totale de standardiser et / ou mutualiser toute ou partie des 6 éléments de la chaîne de valeur ? ». D’expérience, plusieurs paramètres de variabilité sont à considérer :

• Le(s) business model(s) : vendre des produits, vendre des projets, vendre des services, vendre une performance (‘outcome based’) peuvent reposer sur un processus de gestion de la qualité et satisfaction client commun, mais vraisemblablement sur des processus de vente différents.
• Les nouvelles normes structurantes applicables aux activités et entités de l’entreprise.
• Le degrés d’obsolescence des solutions logicielles et / ou de l’architecture d’entreprise (EA)
• Les contraintes induites par le schéma directeur informatique en vigueur
• Les entités opérationnelles : BUs, régions ou pays. Ce paramètre est en réalité souvent le résultat des 4 précédents.
• Le coût au sens TCO (Total Cost Ownership) supporté sur la période de mesure du ROI du programme par le degrés de convergence choisi.

Un point à noter souvent ardu à traiter concerne la convergence de l’élément « solution logicielle ». Il existe, notamment pour une solution SaaS et en simplifiant, trois niveau de convergence possible : une instance de plate-forme centrale, une instance fédérée ou métainstance (au sens méta données) centrales mère de plusieurs instances de plateforme
régionales hébergeant les données réelle, enfin des instances autonomes par région voire pays.

Ce thème de convergence doit être traité avec finesse : comment on peut s’en douter et la réalité
vécue le confirme, il convient de trouver le bon équilibre entre la vitesse et agilité de mise en œuvre initiale, puis d’évolution de la plateforme en mode Run. Le coût prévisionnel dépend fortement dépendant de la capacité des équipes successives à piloter dans la durée une instance
globale ou fédérée.