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.
Un programme très riche pour la 9ème édition de l’Agile Tour Rennes 2017 qui s’est tenue les 13 et 14 octobre dernier et a réuni plus de 40 conférenciers sur des thématiques clés de l’Agilité.
Retour sur cet événement avec Hervé, Nicolas et Séverin qui, en plus des conférences qu’ils ont animées, en ont profité pour arpenter les couloirs de l’INSA et dénicher des nouveautés sur l’Agilité.
Comment s’est passé l’agile tour de Rennes ?
Nicolas : N’étant présent qu’une seule journée (le Vendredi), tout est passé très très vite ! J’en garde un super souvenir avec un accueil très chaleureux et une équipe d’organisation disponible et passionnée. Nous avons poursuivi les discussions le soir au restaurant et ce fut un beau moment de partage. Les sujets couverts par cette édition étaient larges et convenaient aussi bien aux novices qu’aux experts.
Séverin : Super bien. L’organisation était au top, on sent qu’ils ont de nombreuses années d’entraînement. Le programme était super intéressant, dommage que je n’ai pas pu rester le samedi car Christian Den Hartigh et Alistair Cockburn ont l’air d’avoir eu beaucoup de succès vu les tweets qui sont passés. Hâte de voir leurs conférences en vidéo.
Hervé : Pour compléter ce que dit Séverin, je confirme: les keynotes d’Alistair et Christian étaient très riches d’idées à tester. La deuxième journée était plus familiale: beaucoup d’enfants ont participé à des ateliers qui leurs étaient dédiés (et tout ça sans trahir ni simplifier l’agilité 🙂
Quelle a été pour vous la découverte de l’événement ?
NL : Le dîner du Vendredi était riche en échanges et j’ai fait la connaissance d’un speaker qui m’a surpris par sa créativité. Il tenait une conférence le Samedi matin sur l’agilité vue par les animaux : original et surtout rafraîchissant comme intervention.
SL : J’ai adoré voir un consultant qui me suit depuis longtemps dans ma carrière et qui a fait preuve d’une grande maîtrise pour sa toute première conférence. Mais chut, je ne donnerai pas son nom.
Une conférence coup de cœur à laquelle vous avez assisté ?
NL : La conférence d’Alexandre Gérard (“Libérer l’entreprise de son patron… pour plus de performance”) très maîtrisée dans le discours. C’était (déjà) la troisième fois que je voyais Alexandre Gérard se produire et force est de constater qu’il a fortement gagné en impact dans son niveau de discours et surtout sa gestion des silences.
SL : Forcément, je vais parler de la conférence “Changer le monde une conversation à la fois” de Gery Derbier. Gery que j’ai connu il y a quelques années et qui m’avait fait découvrir à l’époque Solution Focus. Très sympa de le revoir ici.
HT : J’ai adoré la conférence d’Alistair. Pour lui, c’était une grande première: parler une heure en français ! Ses travaux actuels essaient de reformuler le manifeste agile de façon beaucoup plus compacte, et de proposer une approche différente de l’apprentissage de l’état d’esprit “agile” : kokoro (plutôt que Shu Ha Ri)… Je vous laisse chercher ces deux expressions sur votre moteur de recherche préféré.
Une anecdote à partager ?
NL : A l’occasion de cet Agile Tour de Rennes j’ai effectué ma première conférence en tant que speaker (en fin de matinée le Vendredi). J’étais très stressé si bien que je n’ai absolument rien retenu de la première intervention (de Gery Derbier) qui avait l’air très intéressante. Je m’efforçais d’écouter par intermittence … avant de décrocher quelques secondes plus tard. J’étais sans cesse ramené à mon introduction que je bachotais.
Au final, j’ai l’impression d’avoir passé la conférence à copier le comportement de mon voisin, notamment pendant les animations. J’étais là sans l’être !
SL : Comme j’ai fait mes études à Laval (avec quelques soirées à Rennes à l’époque), j’ai gardé quelques connaissances dans la région. 2 amis d’école d’ingénieur se sont arrangés pour venir me voir, et j’ai aussi croisé un ancien collègue de promo que je n’avais pas vu depuis 15 ans dans les couloirs.
Coach Professionnelle, Team Leader Transformation Agile des Organisations
Cela fonctionne par ce que les membres de l’équipe s’entendent, participent et communiquent entre eux.
Interview Timothée L.
Sérénité, collaboration, fluidité, l’équipe de Timothée L (Manager dans une Grande Banque Française), est beaucoup plus enthousiaste depuis qu’elle a adopté la méthode Agile Scrumban. Comment ont-ils réussi cette transformation Agile ? Quelles ont été les étapes de mise en œuvre et quels en sont les premiers résultats ? Timothée, revient sur la transformation Agile de son équipe, composée de 3 Business Analystes, 4 Développeurs et 1 support.
Comment as-tu connu les méthodes agiles ?
Lors de ma précédente expérience dans une autre banque, j’ai travaillé dans une équipe en mode Scrum.
Qu’est-ce que le lean management t’a apporté ?
Le Lean Management pose un cadre ce qui nous a permis de mettre en place une démarche d’amélioration continue.
La gestion de la capacité nous a permis de mieux gérer les priorités et de nous rendre compte du temps passé sur d’autres tâches que la réalisation de nouvelles fonctionnalités.
Egalement, la mise en place de la matrice de compétence a permis de mieux se rendre compte des compétences présentes dans l’équipe et de celles à développer.
Pourquoi avoir décidé d’évoluer vers l’agile ?
L’amélioration de notre efficacité est une de nos préoccupations principales.
La gestion de la capacité introduite par le Lean Management nous a fait prendre conscience des freins qui nuisaient à notre efficacité.
Nous avions besoin d’un mode de fonctionnement nous permettant de mieux estimer les tâches, de livrer plus fréquemment pour éviter le rush de fin de cycle et de mieux gérer les goulets d’étranglement entre nos différentes étapes de réalisation.
Comment as-tu géré la transformation vers l’agile ?
Après plusieurs ateliers de PSS (Problem Solving Sessions), nous avons choisi la méthode Scrumban (une combinaison des méthodes Scrum et Kanban) qui permet d’avoir le côté visualisation et gestion du flux, mais aussi la limitation du travail en cours de Kanban et le côté itératif de Scrum.
Quel est ton nouveau mode de fonctionnement ?
Notre white board est le cœur de l’information de l’équipe. D’un coup d’œil il est possible de visualiser où nous en sommes.
Ce support de management visuel est composé de 2 parties :
une partie concerne les projets en cours. Ceux-ci sont estimés en taille de T-shirt (S : réalisable en une semaine, M : réalisable en 1 ou 2 sprints, L et plus : ne rentre pas dans une release, doit être découpé).
L’autre partie permet le suivi du sprint, avec visualisation des tâches et des User Stories par étape.
Quels sont les rôles dans l’équipe ?
La priorisation est faite par le Product Owner (PO)
Pendant les phases de cadrage et d’analyse, le PO découpe les projets en User Stories. Et lors des Kick Off de Sprint, nous estimons les User Stories par priorité et nous les rentrons dans le Sprint.
Le PO, si besoin avec les Business Analyste (BA) ont donc en charge des étapes de cadrage, d’analyse et également des tests fonctionnels.
Les développeurs découpent les User Stories en tâches techniques et les réalisent.
Quels bénéfices en tires-tu ?
Grâce à l’estimation collective de la charge de travail en Story points (évaluation en fonction de l’effort, de la complexité et des incertitudes), les tâches sont mieux estimées. Toutes les personnes de l’équipe réfléchissent à la façon de réaliser les choses, aux éventuelles difficultés et incertitudes
En ajoutant la limitation du travail en cours (WIP) à chaque étape, nous avons également beaucoup fluidifié le flux de nos réalisations. Nous arrivons dorénavant à terminer plus de tâches qu’auparavant. Nous appliquons le mode « Stop starting, Start finishing ».
D’ailleurs, les résultats sont là : notre productivité a augmenté entre 25% et 30%, ce qui nous permet de traiter d’autant plus de sujets par release.
Avec une couverture de tests unitaires de 90% nous sommes beaucoup plus sereins dans nos réalisations, refactorings et changements.
Nous allouons également dans chaque sprint 10% du temps à l’amélioration technique ou à la réduction de la dette technique.
Il s’agit un cercle vertueux : la pression est bien moindre et surtout diluée entre les sprints. Nous sommes sortis du « mode panique ». Cela fonctionne aussi parce que les membres de l’équipe s’entendent, participent et communiquent entre eux.
Quelles sont les prochaines étapes ?
Nous continuons à nous améliorer chaque jour et nous souhaitons aller vers du Continuous Delivery pour améliorer notre rapidité de livraison (Time to Market).
Il est donc nécessaire d’automatiser plus encore les tests fonctionnels, et de mettre en place l’outillage et les environnements qui nous permettront de livrer en production automatiquement à chaque release dans un premier temps, et ensuite après chaque sprint.
Que conseilles-tu aux équipes qui souhaitent commencer à travailler en agile ?
Suivre une formation d’acculturation Agile en amont est important, car cela permet de bien comprendre ce que l’Agile peut apporter, et échanger sur des retours d’expérience.
En outre, il est essentiel de se faire accompagner par un coach quand l’équipe démarre sans réelle expérience en Agile.
Aussi, il faut avoir conscience que passer en Agile ne résout pas tous les problèmes, d’autant plus si le métier ne souhaite pas s’impliquer. En conséquence, il sera difficile de s’assurer de la valeur de ce qu’on produit.
Grâce à son fonctionnement, l’Agile permet de mettre en lumière et de traiter plus rapidement les points épineux.
Enfin, il est nécessaire pour la cohésion, d’impliquer toute l’équipe pour que ça marche, notamment sur le choix de la méthode (scrum, kanban, scrumban, xp…).
Je suis intervenu le 10 octobre dans une grande banque française à l’occasion de leur « Agile Day » annuel. On m’a demandé d’intervenir sur l’impact de la transformation agile sur le management.
Mon constat est que la transition managériale dans les grands programmes de transformation agile n’est pas efficace. Ce constat commence à être partagé et mes réflexions m’ont amené à identifier une approche différente de celle traditionnellement mise en œuvre.
Pour développer les Hommes, travaillez sur l’environnement en premier
Quand vous souhaitez amener une entreprise vers un leadership plus agile, il ne suffit pas de décréter qu’elles doivent devenir agiles. Il est nécessaire de rénover le système, qui dans la quasi-totalité des cas, n’est pas compatible en l’état.
Supprimer les silos entre les métiers, les équipes de développement et les équipes de production (approche que j’appelle BIZDEVOPS) est une première étape d’une transformation agile. Modifier les mécanismes contre-productifs, comme les systèmes d’objectifs orthogonaux entre DEV et PROD par exemple, devrait être l’étape suivante. On peut même imaginer une gouvernance d’entreprise basée sur une information transparente, fraîche et honnête, générant des prises de décisions décentralisées et efficaces.
Pour travailler sur le système, vous pouvez démarrer par :
identifier clairement et communiquer beaucoup sur la vision de l’entreprise : son but, sa raison d’être. Finalement, le rôle du dirigeant pourrait se résumer à cela : répéter encore et encore la raison d’être de l’entreprise. C’est d’ailleurs une constante dans les organisations « libérées » qui surperforment dans leurs domaines d’activité.
décentraliser les prises de décisions en donnant plus d’autonomie. Cela signifie en corollaire de garantir un accès transparent à l’information, de développer les compétences, de bâtir des interactions basées sur la confiance mutuelle et de donner le droit à l’erreur dans une approche « fail fast, learn fast ».
Former n’est pas assez
Une fois la prise de conscience et les modifications réalisées au niveau de l’organisation, accompagnez vos managers dans le changement nécessaire de posture. Car en modifiant l’organisation et les interactions entre les différentes parties prenantes, l’impact sur le manager est plus important qu’il ne pourrait y paraître. J’ai déjà rencontré des chefs de projets qui venaient se plaindre de l’agilité parce que leurs équipes parlaient désormais directement avec le Product Owner pour la priorisation des sujets, alors que c’était leur prérogative quelques mois plus tôt.
D’une approche où le manager est traditionnellement un sachant promu pour sa compétence technique (et pas forcément sa compétence en leadership !), nous évoluons vers une approche où le manager s’oriente plutôt vers une posture d’hôte (Host Leadership) ou de coach, avec comme objectif de faire émerger de nouveaux leaders dans son équipe.
Plutôt que d’envoyer les managers en formation pour leur apprendre des recettes qu’ils ne pourront/sauront pas appliquer dans la plupart des cas, préférez un accompagnement sur le terrain. La formation peut être envisagée comme un apport complémentaire si nécessaire et dans un second temps. Le coaching des équipes et des individus amène des résultats bien plus probants car les acquis sont ancrés dans le concret, et surtout, l’apport régulier du coach sécurise la montée en compétences opérationnelle. L’expérience du coach va aussi aider à gérer des situations délicates qui ne manqueront pas d’arriver, et également à identifier les ajustements nécessaires aux modifications réalisées sur le système, dans une approche d’amélioration continue.
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.
