Dans un monde où les ruptures stratégiques, technologiques ou sanitaires s’accélèrent, les stratégies sont mises à rude épreuve. Ces stratégies intègrent de plus en plus de composantes digitales dans une logique où les business models ne sont plus « simplement » supportés par l’IT mais où c’est l’IT qui réinvente les business models. Aujourd’hui l’IT devient le business.
Imaginer et concevoir des innovations de valeur à fort contenu digital ne suffit plus car il est nécessaire d’organiser une mise en œuvre de l’IT à même de répondre avec flexibilité et rapidité aux enjeux tout en assurant sécurité et résilience des opérations IT. Dans ce contexte, il devient plus délicat de traduire ces nouvelles exigences du Run en capacités opérationnelles. Et sauf à vouloir se prendre les pieds dans le tapis , je ne recommande absolument pas de se « jeter » sur la construction d’organisations cibles avant d’avoir compris pour qui et comment ces organisations doivent créer et délivrer de la valeur.
Tout le monde a une stratégie avant de se prendre un direct en pleine face.
Mike Tyson
Sur la base de mon expérience de conseil, j’ai ainsi souhaité partager dans ce billet une solution relativement élégante pour adresser cet enjeu. Il s’agit d’adapter le modèle opérationnel du Run en créant un modèle opérationnel cible (TOM) qui intègre les différents changements nécessaires au modèle existant afin de traduire les nouvelles exigences du Run en capacités opérationnelles. Ce billet aborde ainsi 3 points :
Qu’est ce qu’un modèle opérationnel et quels étaient jusqu’à présent les principaux modèles opérationnels pour les activités de Run ?
Quelles sont les principales tendances qui poussent à adapter le modèle opérationnel du Run ?
Quand et comment procéder pour adapter le modèle opérationnel du Run ? Quelles sont les nouvelles tendances en matière de modèles opérationnels du Run ?
1. Le modèle opérationnel du RUN
Un modèle opérationnel fait le pont entre stratégie et exécution et décrit comment l’organisation va créer et délivrer la valeur. On peut définir un modèle opérationnel à l’échelle d’une entreprise toute entière, d’une business unit ou même d’une fonction (ex. la DSI) ou encore une sous-fonction (ex. le Run de la DSI). Comme il n’y a pas de définition vraiment standard, je vous propose 3 illustrations que j’ai adopté et qui permettent chacune d’aborder le modèle opérationnel sous un angle différent.
Illustration n°1 : si vous êtes familier avec le business model canvas de Alex Osterwalder et Yves Pigneur, on peut déjà considérer que le modèle opérationnel se positionne comme le back-end du business model en intégrant les activités clés, les ressources clés ainsi que les partenaires/partenariats clés.
Illustration n°2 : d’autres à l’instar de Andrew Campbell de l’université d’Ashbridge tentent de populariser l’operating model canvas en agençant avec plus de détails le back-end de l’illustration n°1
Ce qui est intéressant dans ce modèle, outre la mention des Locations (lieux géographiques d’exécution) et de Information (structures et flux d’information), c’est l’apparition des Value Delivery Chains censées traduire la logique des chaînes de valeur nécessaires au delivery des propositions de valeur. De mon point de vue, cette notion est fondamentale à tout modèle opérationnel.
Illustration n°3: enfin, j’ai aussi dans mon attirail une autre façon de représenter les modèles opérationnels que j’ai peaufiné au fil du temps et à laquelle je tiens beaucoup.
Ce qui est intéressant dans ce modèle est la prise en compte de l’axe culture (organisation informelle et l’humain) qui rappelle que les opérations s’exécutent souvent sur la base d’habitudes de collaboration, de valeurs et de soft-skills spécifiques et ce indépendamment des structures organisationnelles et des processus. L’autre point fondamental est l’introduction de la gouvernance qui représente le système nerveux du modèle opérationnel et sa clé de voûte.
C’est donc en s’appuyant sur un certain nombre de modélisations que l’on se forge à la fois des convictions et des outils pour adapter les modèles opérationnels et plus spécifiquement dans ma pratique : les modèles opérationnels du Run.
Afin d’être plus spécifique et encore à titre d’illustration, je schématise ci-dessous les 2 modèles opérationnels du Run beaucoup rencontrés ces dernières années.
Le modèle des silos technologiques
L’organisation par silos technologiques n’a plus vraiment cours aujourd’hui car elle présente un certain nombre de challenges et inconvénients commentés dans l’illustration ci-dessus.
Le modèle PLAN-BUILD-RUN avec un RUN orienté par activité
Ce modèle opérationnel de Run intégré dans le modèle Plan-Build-Run de la DSI fait la part belle aux activités. Il organise en effet les opérations IT en usines qui regroupent les activités par niveaux d’interventions (N0 – Hébergement, N1 – Exploitation, N2 – Administration, N3 – Expertise) quelles que soient les technologies et métiers concernés. A l’instar des modèles déployés par les grands prestataires, ce modèle vise le plus souvent à industrialiser les opérations en déployant des processus standards ITIL. L’inconvénient majeur de ce modèle est de reléguer le Run en bout de chaîne, sclérosant ainsi toute la chaîne de delivery et ne favorisant ainsi pas l’agilité.
Certaines déclinaisons récentes de ce modèle tentent de fluidifier davantage la chaîne de Build pour conduire à des modèles un peu différents qui distinguent la gestion des socles techniques de celle des services.
Sur ces bases, on a pu voir se dessiner des modèles d’organisations détaillées ressemblants au schéma ci-dessous.
Alors disons le tout de suite, aucun de ces modèles n’est la panacée mais tous ont un intérêt pour exécuter les activités de Run. Il est donc important de capitaliser sur l’expérience des différents modèles et comprendre valeur et utilisation des briques de bases. C’est ainsi que l’on disposera de bonnes bases pour entamer une phase de réflexion et de conception quand il s’agira d’adapter le modèle opérationnel du Run aux nouveaux enjeux. Et justement comme nous allons le voir dans la prochaine section les raisons de changer sont multiples et souvent impérieuses.
2) Tendances d’évolution et d’adaptation des modèles opérationnels du RUN
Comme je le mentionnais en introduction, l’IT est aujourd’hui au coeur du business et les DSI doivent faire face (quand ce ne sont pas les Chief Digital Officer) à de nombreux impératifs pour rendre possible / faciliter la transformation du business et des métiers.
Au-delà de ces impératifs, s’ajoutent plus classiquement les demandes de réduction de coûts et des risques ainsi que le besoin de transparence accrue. Evidemment, et pour finir, on peut trouver les nombreuses tendances technologiques actuelles et à verniret qui sont autant d’opportunités/leviers de transformation.
Ces impératifs pressurisent les modèles opérationnels en place et les tendances technologiques mettent le plus souvent en évidence l’impréparation et l’inadéquation des capacités d’IT Management. C’est donc sur ces bases que les organisations de type DSI doivent se réinventer en adoptant des modèles opérationnels plus adaptés.
3) Quand et comment adapter le modèle opérationnel du run ? quelles pistes d’évolution ?
Avant de s’engager dans un projet d’adaptation du modèle opérationnel du Run, il est nécessaire de bien cadrer les raisons qui poussent à changer et définir un tant soit peu les modalités du projet d’adaptation de TOM. Généralement cela passe par un cadrage stratégique permettant d’établir les éléments structurants du projet d’adaptation du modèle opérationnel :
Objectifs du projet d’adaptation
Évaluation des bénéfices attendus, impacts et facteurs de risques
Définir les meilleures options organisationnelles pour mener le projet d’adaptation
Éclairer la prise de décision
L’élément le plus important et difficile étant l’évaluation des bénéfices attendus et des impacts à anticiper. Sans révéler de secrets, c’est le plus souvent un timing particulier sous tendu par des forts enjeux / opportunités qui incite à se lancer dans l’adaptation d’un modèle opérationnel et ce principalement dans 4 situations types :
Vous démarrez quelque chose de totalement nouveau
Vous changez de stratégie
Vous avez des problèmes de performance
Vous mettez en oeuvre un changement majeur
Dans le contexte d’une DSI et des implications sur le Run, il peut s’agir de plusieurs structures qui fusionnent / se rapprochent avec chacune une organisation de Run; d’un programme structurant de modernisation IT, d’une globalisation des opérations IT pour delivrer des services IT à l’ensemble des pays d’une entreprise, ou encore d’une transformation agile de l’entreprise et/ou de la DSI.
Ensuite vient le travail à proprement parler sur la définition du TOM. La description détaillée d’une méthodologie ne rentre pas dans le cadre de ce billet mais néanmoins je recommande de toujours démarrer par la définition de la Value Chain Map ou chaîne de valeur permettant de délivrer la proposition de valeur attendue / en ligne avec la stratégie à exécuter. A titre d’illustration, ci-dessous la chaîne de valeur que l’on pourrait trouver dans une DSI classique
Cette étape, n’est pas facile car si – par exemple – on souhaitait redéfinir cette chaîne de valeur, il pourrait être difficile de choisir la meilleure manière de la segmenter l’offre de service et de définir l’enchaînement des différents macro-processus créateur de valeur. En général, il faudra choisir de segmenter les chaînes de valeur par type de clients internes/externes ou par besoin clients ou par pays ou par produits/services ou bien encore par technologies (l’exemple du modèle opérationnel par silos technologiques).
Dans tous les cas, il ne faut absolument pas jouer aux apprentis sorciers et improviser : une bonne dose d’analyse et de pragmatisme est nécessaire mais on peut aussi s’inspirer de tendances très actuelles (quoique peu documentées) dans la définition de modèles opérationnels adaptés aux enjeux décrits dans la section n°2.
Une piste qui me paraît intéressante étant de s’inspirer du standard IT4IT de l’Open Group qui propose un début de modèle opérationnel organisé autour d’une chaîne de valeur et de Value Streams spécifiques à L’IT à l’instar de certains domaines métiers qui ont développé des Value Streams maintenant connues comme : make-to-order, order-to-cash,…)
Ainsi le point de départ IT4IT se compose des Value Streams suivantes qui sont orientées besoins client et remplacent avantageusement la classique segmentation Plan, Build, Deliver, Run et sont de nature à casser un fonctionnement en silos peu propice à l’agilité. Ce découpage est d’ailleurs la clé pour évoluer vers un modèle où le Build est beaucoup moins prépondérant et est remplacé par une logique de Broker/Intégrateur/Orchestrateur.
Ce rôle de Broker/Integrateur/Orchestrateur sera principalement mis en oeuvre au travers des capabilities de la value stream « Request to Fulfill » qui seront en charge de cataloguer, mettre en oeuvre et suivre l’usage des différents services standards.
Les impacts de cette nouvelle « value chain » sur le Run sont structurants. Le Run ne sera plus isolé en bout de chaîne et participera aux autres value streams dans une logique de collaboration avec les autres parties prenantes. C’est cette logique d’agilité qui s’affranchit des frontières organisationnelles qui sera propice à la construction de modèles opérationnels Digital Ready intégrant nativement des mécanismes opérationnels comme DevOps et FinOps par exemple.
Une fois la colonne vertébrale de la value chain définie, on peut s’attaquer – sans dogmatisme – aux autres éléments (partenaires, géographies, modèle d’organisation ou capabilities map, culture,..) en fonction de leur importance dans la stratégie et des enjeux de valeur à délivrer.
En guise de conclusion
Voilà pour ce petit tour d’horizon de l’adaptation des modèles opérationnels DSI pour traduire les nouvelles exigences du Run en capacités opérationnelles. Pour conclure, il faut retenir que le modèle opérationnel n’est que le Blueprint de l’organisation cible et que cette logique s’inscrit dans une démarche plus globale de transformation
En attendant, de démarrer vos projets d’adaptation, vous pouvez toujours évaluer si votre modèle opérationnel (qu’il soit formellement défini ou pas) permet de délivrer la bonne valeur aux bons clients (internes ou externes).
Les activités de production d’un Assisteur (GIE d’un Groupement de Mutuelles), devaient faire face à plusieurs enjeux dans les années à venir : Agilité, Excellence opérationnelle, Maîtrise budgétaire. Ils ont exprimé plusieurs besoins :
Besoin de maîtriser le Legacy tout en construisant le SI cible (ERP) de demain
Besoin de fournir des services aux métiers dans un cadre convenu et non comme un fournisseur de ressources IT exclusivement réactif
Besoin d’accroître la qualité et l’efficience des opérations IT dans un contexte technologique / opérationnel en silos
Solution
Nous avons accompagné la Direction de la Production Informatique sur 3 axes :
Diagnostic de l’existant : faire le point sur l’organisation et le fonctionnement des activités de production informatique, en identifiant les points faibles, les risques et les évolutions nécessaires au regard des enjeux
Bilan des besoins : projeter les évolutions nécessaires en priorisant les besoins selon leurs impacts et avantages
Scénario cible : analyser différents scénarios et identifier une cible préférentielle ainsi que la trajectoire et les projets associés en ligne avec la capacité à faire
Bénéfices
Un scénario cible qui combine des projets d’évolution de la gouvernance et de l’organisation, de l’industrialisation des processus et une approche volontariste sur le sourcing IT
Evolution du modèle opérationnel avec d’un côté l’expertise sur les socles techniques dans la chaîne de Build et de l’autre la polyvalence et l’industrialisation du Run en mode service
Un repositionnement de la production face aux métiers avec la création d’un service dédié à la relation avec les métiers et la gestion des niveaux de service / du catalogue de services
Les autres success stories qui peuvent vous intéresser
Réussir la mise en oeuvre de gestionnaires de relation métiers au sein de la DSI
Réussir la mise en oeuvre de gestionnaires de relation métiers au sein de la DSI
Dans le cadre de missions d’organisation des activités de Run, je m’intéresse souvent – au delà du modèle opérationnel – aux différents domaines de gouvernance à structurer.
Dans ce contexte, la gestion de la relation aux métiers (business relationship management) est un besoin important qui revient régulièrement et peut se définir comme le processus responsable de maintenir une relation positive avec les métiers, en identifiant au préalable leurs besoins et en garantissant la fourniture de service sur la base d’un catalogue de services approprié. Sur ces bases, le processus de gestion de la relation métier s’incarne généralement via le déploiement d’un ou plusieurs gestionnaires de relation métier (GRM). J’ai pu noter un certain nombre de prérequis qui doivent être pris en compte afin de réussir la mise en œuvre d’une telle fonction. J’en partage quelques uns dans ce billet.
Confiance des métiers dans le GRM et dans le dispositif de fourniture de services
Pour réussir la mise en oeuvre d’un GRM avec les métiers, il est impératif que les métiers
acceptent le principe de travailler avec un GRM
aient confiance dans le dispositif de fourniture de services de la DSI.
Ainsi, un GRM efficace établira non seulement de bonnes relations avec les métiers, mais véhiculera aussi l’image du dispositif de fourniture de services. En conséquence, si les métiers font confiance au GRM, ils auront également confiance dans le dispositif de fourniture de services. Les métiers comprennent en effet assez vite que le GRM dépend dans une certaine mesure du dispositif de services, mais doivent être également être convaincus que le GRM a les intérêts du métier à cœur.
Finalement, le GRM souhaitant asseoir sa crédibilité sur la base de la confiance des métiers doit être en mesure de démontrer la valeur ajoutée concrète apportée, et non être vu comme une surcouche du dispositif de fourniture des services.
Collaboration du GRM avec le dispositif de fourniture de services
Le rôle du GRM n’est pas seulement d’être l’interface avec le métier. En effet, le GRM faisant partie intégrante de l’organisation de services de la DSI, doit certes à ce titre regarder vers l’extérieur en direction de ses clients métiers, mais également s’engager auprès de ses collègues du dispositif de fourniture des services afin de s’assurer que les métiers obtiennent le meilleur service possible.
Dans ce rôle essentiel, les compétences et attitudes indispensables au développement de la relation avec les métiers seront également déterminantes pour établir des relations au sein de l’organisation du dispositif de fourniture de services.
Faire partie de l’organisation de services de la DSI ne garantit pas en effet au GRM que ses collègues du dispositif de fourniture de services répondront toujours comme il le souhaiterait. L’une des raisons est que plus le GRM prendra son rôle à cœur et plus il est possible qu’il soit considéré par les collaborateurs du dispositif de services comme faisant partie intégrante de l’organisation métier (et donc potentiellement vu comme « passé à l’ennemi »).
Si cela se produit, le GRM pourra faire face à des tensions continuelles dans ses relations avec les membres du dispositif de fourniture de services.
Clarifier les rôles et responsabilités ainsi que les interfaces
La mise en œuvre d’un nouveau rôle de GRM se créera inévitablement à partir de parties de rôles existants au sein de la DSI. La création du rôle peut signifier que les canaux de communication déjà actifs entre les métiers et les différents acteurs de la DSI soient interceptés par le GRM et que les tâches qui ont déjà été la responsabilité d’autres rôles deviennent la responsabilité du GRM.
Ces changements créent généralement des difficultés : les parties prenantes sont naturellement réticentes à rompre les relations de travail et à perdre des responsabilités importantes pour eux. Ainsi, la capacité du GRM à nouer des relations fructueuses avec les parties prenantes de la DSI peut être tout aussi importante que l’établissement de relations avec les métiers.
Inévitablement, il pourra donc y avoir de nombreuses interfaces et recouvrement avec des rôles couverts par d’autres fonctions et processus. C’est pourquoi une attention toute particulière devra être apportée à la définition des rôles et responsabilités des GRM ainsi qu’aux interactions avec les différentes parties prenantes sous peine de courir un risque de confusion / de manque de clarté et parfois de conflits.
Distinguer activités de Service Management centrées sur l’IT de celles centrées sur les services métiers
La tentation peut être forte de combiner les rôles de GRM avec d’autres rôles de Service Management plus centrés sur des services IT spécifiques (gestion des changements, gestion des problèmes, …). Bien que cela puisse contribuer à optimiser les coûts et simplifier les interfaces, force est de constater que les inconvénients ne sont pas neutres.
En effet, si le GRM s’enlise dans la performance spécifique de certains services IT, il lui sera plus difficile de superviser globalement la relation aux métiers et moins simple de s’engager auprès des métiers au bon niveau pour une gestion pertinente et efficace de la relation.
Pour conclure, et étant donné qu’il est très rare d’avoir des métiers prêts à payer directement pour les services du GRM, il est indispensable d’optimiser le ratio coûts-valeur de ces activités en ne limitant pas la performance attendue à la seule mesure de la satisfaction des métiers.
Pour mémoire, j’avais qualifié la gouvernance contractuelle de la relation comme un frein à l’innovation, au dynamisme et globalement à la valeur ajoutée du partenariat.
In fine, quand on observe ce qui se passe sur une majorité de contrats d’infogérance on s’aperçoit que :
L’efficacité des dispositifs d’infogérance dépend de l’adaptation des équipes de l’infogérant aux différents métiers client,
Dans un contexte client dynamique et exigeant, c’est la collaboration client-fournisseur qui conditionne un haut niveau de qualité et de valeur ajoutée,
Le passage de la coopération à la collaboration est un enjeu organisationnel pour la DSI et ses partenaires,
Rompre avec la rigidité de l’approche contractuelle traditionnelle permet de mieux collaborer.
1. L’efficacité des dispositifs d’infogérance dépend de l’adaptation des équipes de l’infogérant aux différents métiers
Encore trop de dispositifs infogérance ont une organisation calquée sur la structure du contrat.
Les différentes parties prenantes d’un projet d’externalisation informatique, considèrent le plus souvent que l’infogérance doit apporter des réponses standard sur la base d’un modèle d’opération industriel / optimisé. S’engager sur ce terrain, c’est oublier l’autre moitié de l’équation du projet d’infogérance : les métiers. En effet, si les réponses doivent être le plus standard possible, cela n’exclut pas pour autant de considérer la spécificité des besoins client au regard des différents métiers.
Des équipes face aux métiers
Face à une diversité de métiers – studios de design, laboratoires de recherche, usines de fabrication ou d’assemblage, fonctions support au sein des sièges, magasins ou agences commerciales, entrepôts logistiques, … – c’est l’adaptation des collaborateurs et de l’organisation de l’infogérant – équipes par équipes face aux différents métiers – qui fera l’efficacité du dispositif infogérance.
2. Dans un contexte client dynamique et exigeant, c’est la collaboration client-fournisseur qui conditionne un haut niveau de qualité et de valeur ajoutée
Depuis que l’on a mis en place ces processus ITIL à la noix, plus personne ne se parle…
Un DSI du CAC40
Certaines entreprises font le choix de l’infogérance pour confier un périmètre maîtrisé et statique afin qu’un fournisseur spécialisé le gère mieux et pour moins cher. Dans un contexte où la transformation digitale est partout et constitue un réel levier d’adaptation / de conquête business, de nombreuses entreprises sont cependant à l’initiative et les infogérants doivent aujourd’hui faire face à des contextes de plus en plus dynamiques et exigeants.
La collaboration comme levier d’adaptation
Dans des environnements dynamiques, en perpétuel changement, les dispositifs infogérance en silos et/ou basés sur des processus rigides ne peuvent donc absolument plus répondre aux objectifs de qualité et de valeur ajoutée attendus par les DSI et les métiers. D’ailleurs quels seraient les bénéfices des différentes transformations agiles et digitales menées par les entreprises si les infogérants devenaient le maillon faible de la chaîne d’agilité ?
Face à ce challenge, la collaboration client-fournisseur est un levier d’adaptation via le partage d’objectifs mobilisateurs et non plus via la « simple » répartition de tâches décrite dans les modèles d’organisation « RACI » que l’on trouve dans des PAQ (Plan d’assurance qualité) à l’applicabilité discutable dans un contexte où rien n’est plus figé.
Sur la base de mon expérience, et afin d’illustrer mon propos avec quelques exemples, j’ai noté que la collaboration client-fournisseur se produit quand :
les différents groupes de support (ceux des infogérants et ceux des clients), collaborent dans une logique de solidarité, d’apprentissage mutuel et de travail d’équipe,
clients et fournisseurs font évoluer de concert les processus opérationnels clés dans une logique d’amélioration continue, de cadrage et recadrage permanent ainsi que de maintien mutuel de l’outillage de ces processus,
le niveau d’échange et d’interaction entre clients et fournisseurs prend de la hauteur,
l’implication au coté des métiers est permanente dans une logique de gestion des attentes et d’adaptation aux spécificités, de revues régulières de coordination, de capitalisation / de diffusion des bonnes pratiques
3. Le passage de la coopération à la collaboration est un enjeu organisationnel
Pour la DSI et ses partenaires
La coopération implique que les acteurs internes de la DSI interagissent
dans un but commun avec leurs partenaires mais en se partageant les tâches.
La collaboration s’opère sans division fixe des tâches mais selon un partage d’objectifs qui remet parfois en cause les frontières organisationnelles internes à la DSI mais aussi externes vis à vis des fournisseurs.
Les modalités d’une collaboration efficace et structurée :
Faire le mieux possible avec les ressources disponibles : dans un environnement exigeant et contraint, la collaboration client-fournisseur associe capacités de création et d’initiative et doit s’appuyer sur la motivation, la disponibilité et les compétences de chacun quelle que soit son appartenance : DSI ou infogérant.
S’engager dans une logique d’amélioration continue : les nombreux et fréquents échanges entre les acteurs de la DSI et ses partenaires déclencheront des opportunités d’amélioration continue dont il faudra tirer partie dans des environnements où les contraintes ne facilitent pas forcément des logiques d’amélioration en rupture.
Paralléliser le travail des différentes équipes : organiser le travail en séquences de tâches parallèles pour plus de proactivité et des résultats rapides qui concourent à des buts communs.
Les différents acteurs doivent se parler pour se synchroniser : pour être efficaces, les acteurs de chacune des tâches devront partager des informations utiles et facilement exploitables sur les autres tâches parallèles.
4. Rompre avec la rigidité de l’approche contractuelle traditionnelle permet de mieux collaborer
Le mariage est un contrat social souvent incompatible avec le grand amour
Tahar Ben Jelloun
D’une gouvernance infogérance traditionnelle à une gouvernance collaborative
Si passer de la coopération à la collaboration semble séduisant sur le papier, comment se « dégager » d’une approche contractuelle qui installe durablement DSI et infogérants dans une coopération où innovation, dynamisme et valeur ajoutée sont le plus souvent absents ?
Principaux bénéfices d’une gouvernance collaborative pour une DSI :
Sans tomber dans une vision trop idyllique de la gouvernance collaborative, on peut cependant noter les bénéfices suivants :
Flexibilité et rapidité dans la résolution des problèmes et la réponse aux enjeux métiers
Adaptabilité aux changements face à des besoins internes ou liés à l’environnement externe
Capacité pour la DSI de garder le contrôle sur les événements et de les « comprendre »
Enfin, c’est aussi un excellent moyen pour cheminer vers plus d’agilité métier, plus de satisfaction des utilisateurs et une meilleure image de la DSI.
Par où commencer ?
Tout d’abord il ne faudrait surtout pas opposer gouvernance contractuelle et gouvernance collaborative : il faut d’abord obtenir de bons résultats via la gouvernance contractuelle pour progressivement se détacher de la « logique contractuelle » afin d’aller vers plus de « logique relationnelle ». Le juste équilibre entre ces deux logiques étant d’ailleurs un enjeu clé pour le partenariat. Adresser cet enjeu nécessite une bonne dose de pragmatisme en fonction des situations rencontrées.
Ainsi, l’analyse portera tout d’abord sur la maturité du partenariat en fonction des objectifs restants à atteindre : amélioration de la performance, relance d’une dynamique de progrès, développement du partenariat, mise en oeuvre d’innovations. On évaluera ensuite où l’on se situe sur l’axe contractuel : en rupture, sous le coup de pénalités ou dans un mode de pilotage « normal ». Les évaluations porteront enfin sur l’axe relationnel : confit, neutralité ou dialogue équilibré. Chacun des paramètres du partenariat devra alors être finement « réglé » dans le cadre des instances et des mécanismes de pilotage de la relation : revue de la performance quotidienne, comités techniques, comités de pilotage, comités stratégiques, identification et mise en oeuvre des plans de progrès, gestion des litiges et des crises, et enfin contract management.
Pour conclure
La gouvernance contractuelle est indispensable et prépondérante au démarrage d’un contrat d’infogérance afin de s’assurer que les engagements contractuels soient tenus. La gouvernance collaborative doit ensuite progressivement prendre le pas sur la gouvernance contractuelle afin d’engager une dynamique de progrès et développer le partenariat dans le but d’être plus efficace dans la recherche de solutions, de s’engager dans une logique d’amélioration continue et développer l’agilité métier. A chacun d’analyser sa situation spécifique – contrat par contrat – et d’adapter ses plans d’actions en matière de pilotage des services et de gestion de la relation fournisseur.
Le marché de l’externalisation est devenu plus mature et les DSI beaucoup plus expérimentées sur la base des différentes générations de leurs contrats d’externalisation. Les enjeux d’hier : préparer / lancer un appel d’offre et contractualiser les services sont aujourd’hui perçus comme moins sensibles en dépit de nouveaux enjeux tels que le multi-sourcing, les renouvellements de contrats forcément plus fréquents et les nouvelles approches de delivery (Cloud, Devops, Agilité, SDA/RPA,…).
Néanmoins et en dépit de la maturité du marché, les difficultés à capter toute la valeur ajoutée des projets d’externalisation informatique n’ont pas diminué et ce d’autant plus que les durées cumulées des différents contrats s’allongent … Au-delà du RFP et du contrat quels sont donc les écueils que l’on rencontre dans les projets d’externalisation informatique ? Sur la base de mon expérience et des échanges que je peux avoir avec mes clients, j’identifie quatre type d’écueils :
Ecueil n°1 : pas de stratégie de sourcing pertinente
On peut presque tout externaliser mais pas n’importe comment ni avec n’importe qui…
Les motivations à externaliser un périmètre donné devraient théoriquement être toujours déterminées par l’objectif de le faire progresser dans différentes dimensions (coûts, qualité, flexibilité,..). Une fois tranchée la question des grands domaines susceptibles d’être externalisés, se posent des questions de stratégie de sourcing plus opérationnelle et leurs lots d’écueils potentiels :
Les axes de progrès recherchés (organisation, finance, technique,…) ne sont parfois pas formalisés et/ou partagés : difficile dans ces conditions de mesurer la valeur de tels projets et surtout d’empêcher les différentes parties prenantes d’être en situation d’insatisfaction quasi-permanente,
Dans certains cas, les leviers de progrès / d’optimisation indispensables et adaptés sont incompatibles avec la politique de l’entreprise ou bien les transformations organisationnelles à mener ne sont pas traitées dans le cadre du projet d’externalisation. En conséquence des projets souvent pertinents se retrouvent « plantés » en raison d’un modèle de sourcing inadéquat ou d’une gouvernance qui n’a pas été adapté. C’est dans ces situations que l’on voit des appels d’offres qui posent les mauvaises questions au marché,
Pire encore, l’appel d’offre pose les bonnes questions mais aux mauvais acteurs … C’est la meilleure manière d’externaliser un périmètre à un fournisseur qui n’a pas les leviers (industriels, méthodologiques, humains,..) pour faire progresser ce périmètre. C’est un cas que l’on voit relativement souvent quand un donneur d’ordre n’est pas si mature que cela et finit par signer un contrat avec un fournisseur aussi peu mature que lui mais avec qui le niveau d’échange est très bon mais les promesses rarement tangibles …
Ecueil n°2 : un gouvernance contractuelle de la relation
Quand on n’a qu’un marteau comme outil, tous les problèmes ressemblent à des clous…
Ou quand la relation client-fournisseur n’est vue qu’au travers du prisme du contrat signé – on parle alors de gouvernance contractuelle de la relation – tous les aspects de la relation client-fournisseur semblent régis par le contrat avec les écueils suivants :
Sans surprise, les gestionnaires de contrats côté fournisseurs finissent assez rapidement par se prendre pour les gestionnaires de la relation client mais avec un niveau d’échange limité aux enjeux de delivery, des interlocuteurs côté client centrés sur le pilotage du contrat et une tendance à ne pas laisser approcher les commerciaux et autres gestionnaires de comptes de ce qu’ils considèrent être leur périmètre. En conséquence, aucune promesse implicite (non contractualisée) n’est généralement tenue (exemple l’innovation) et le dynamisme dans la gestion du contrat / de la relation n’est souvent pas au rendez-vous.
Dans le contexte d’une gouvernance contractuelle de la relation le niveau des échanges conditionne le niveau des interactions. Ainsi l’on parle plutôt d’une relation de coopération et d’un partage des tâches que d’une relation de collaboration où ce sont les objectifs qui seraient partagés. Les incidences sont concrètes et directes, avec par exemple dans le cas de la coopération, un pilotage via un certain nombre de revues d’évaluation de la performance et pour la collaboration un certain nombre de revues de synchronisation … Ça fait toute la différence et c’est le début de relations client-fournisseur plus équilibrées / plus productives.
Ecueil n°3 : des services non centrés sur les utilisateurs
Les services sont produits au moment où ils sont consommés. On ne peut donc jamais s’affranchir de l’utilisateur…
Si les utilisateurs sont souvent les derniers à découvrir ce qui a été prévu pour eux dans un contrat d’externalisation, ils sont généralement les premiers à être impactés quand les services ne leur conviennent pas. Autant l’équation de services centrés sur les utilisateurs est simple à poser « adéquation aux besoins + attitudes + performance + valeur ajoutée », autant la promesse est difficile à tenir dans le cadre des projets d’externalisation. Je ne connais pas de méthodes scientifiques pour réussir ce challenge mais recommande trois principes d’actions de bon sens :
Impliquer les utilisateurs dans la définition du catalogue de services. C’est simple quand la maîtrise d’ouvrage est structurée, c’est difficile et souvent inefficace quand c’est la maîtrise d’oeuvre qui s’en charge et présume des besoins des utilisateurs,
Ne pas trop stéréotyper les prestations et veiller à garder de la flexibilité dans le modèle de delivery,
Enfin, concevoir des services certes industriels mais sans jamais les déshumaniser.
Ecueil n°4 : modèle d’opération inadapté
Ce n’est pas en faisant les choses de la même façon que l’on obtient des résultats différents…
Pour faire progresser les périmètres externalisés dans différentes dimensions (coûts, qualité, flexibilité,..), le fournisseur doit transformer le ou les modèles d’opération existants à l’aide de leviers de transformation dont son client ne dispose à priori pas.
Mais dans certains cas, le modèle d’opération cible n’est pas adapté aux progrès attendus et ce pour trois raisons principales :
Le projet d’externalisation a prévu une phase de transition des services vers l’infogérant mais n’a tout simplement pas prévu de phase de transformation.
Dans d’autres cas, un projet de transformation a bien été prévu dans le projet d’externalisation mais à l’usage, les leviers de transformation se révèlent inapplicables où bien le projet de transformation ne va pas au bout pour d’autres raisons (souvent des raisons de complexité, de coûts du projet ou de maturité de l’équipe en charge de la transformation).
Parfois c’est le client qui ne collabore pas suffisamment au projet de transformation avec son infogérant…. rarement volontairement mais souvent pour des raisons de gouvernance interne.
Dans les trois cas, le résultat est problématique car l’infogérant n’a tout simplement pas les moyens de tenir ses promesses avec un modèle d’opération inadapté / non transformé.
A titre d’illustration, on peut noter le cas de grands groupes qui externalisent – pour les faire converger – leurs différents Service Desk (filiales / pays) vers un infogérant unique. Dans de nombreux cas la « transformation » s’arrête à la transition des différents périmètres vers le fournisseur choisi. Très peu de rationalisations sont finalement menées et la capture des gains liés à la mutualisation de ressources et à l’utilisation de processus et d’outils communs demeure un vœu pieu.
Et pourtant tout s’annonçait si bien…
Syndrome du Titanic ?
Pour finir, les 4 écueils précédemment évoqués partagent avec l’histoire du Titanic et de son iceberg fatal, les 2 caractéristiques suivantes :
Ces écueils sont potentiellement dans le chemin critique du succès du projet d’externalisation avant le démarrage du projet,
Une fois le projet lancé, ces écueils sont difficiles à éviter / contourner.
En guise de conclusion : quelle que soit votre maturité en matière d’externalisation, il est toujours aussi crucial et difficile d’acheter les bonnes promesses et de faire en sorte qu’elles soient tenues dans la durée.
