Industrialiser les processus et automatiser les actions de tous les acteurs du back-office
Apporter de la visibilité sur le suivi des demandes et des incidents ; Piloter vos prestataires infogérants.
Anticiper les incidents et les changements grâce à une CMDB efficace
Gérer et maîtriser son parc informatique matériel et logiciel (ITAM et SAM) et réduire ses dépenses
Proposer la meilleure expérience utilisateur possible tout en renforçant l’attractivité de votre portail de services et en augmentant l’autonomie de vos collaborateurs (Self-Care)
Optimiser les coûts CAPEX & OPEX et le ROI sur vos outils ITSM/ESM
Augmenter la valeur perçue par vos utilisateurs de la chaîne de support et de delivery des DSI
Nos offres
Définir la stratégie ESM
Audit et mesure de la maturité
Co-construction de la stratégie digitale ESM*
Etude et préconisation d’une trajectoire cible
*ESM = Enterprise Service Management (ITSM/ ITAM/ ITOM/ PPM…)
Optimiser les processus
Audit et analyse de l’existants
Optimisation ou refonte des processus selon les référentiels ITIL
Définition de l’organisation cible alignée avec les nouveaux processus
Rationaliser l’usage des outils
Cartographie et analyse des outils existants
Sourcing et accompagnement à la contractualisation de l’outillage et/ou de prestations d’intégration
Préconisation et alignement des outils par rapport aux besoins fonctionnels et aux bonnes pratiques
Accompagnement pour la mise en place du plan d’actions
Pilotage de la mise en oeuvre
Gouvernance dédiée autour des projets ESM
Suivi de la performance des services : éditeur / prestataires intégrateurs
Mise en place d’un plan de conduite du changement
Des bénéfices clés pour votre organisation
Amélioration des niveaux de services
Standardisation des processus à hauteur de 80%
Amélioration de l’expérience utilisateur (accès aux services en 3 clics, augmentation de l’autonomie et du self-care)
Atteinte des objectifs de conformité des actifs IT
Je vous propose une analogie sur l’évolution de l’Homme préhistorique et la métamorphose du métier de contrôleur de gestion depuis son origine à aujourd’hui.
Au cours de mes 20 ans d’expériences professionnelles en Finance, j’ai vu le métier de contrôleur de gestion progresser dans le chemin de la création de valeur et de l’accompagnement des métiers et des opérations sur des enjeux financiers et de performance.
Alors parfois le contrôleur de gestion suscite une certaine suspicion de la part de ses interlocuteurs : Vient-il nous couper les budgets ? Sa vision financière ne va-t-elle pas s’opposer à la vision opérationnelle ? Qui mieux que les opérationnels sont susceptibles de fiabiliser des forecasts ?
Ma conviction est qu’à deux on est plus forts et que c’est la combinaison des 2 mondes Finance & Opérations qui fait et fera la force du Contrôleur de gestion de demain. Alors oui, le contrôle de gestion est une fonction dite « support » dans les organisations et il n’est pas au coeur du réacteur mais c’est un allié incontournable pour sécuriser la stratégie de l’entreprise.
L’âge de pierre & la production taylorienne : le contrôleur budgétaire
Le Contrôleur de gestion homo habilis
Le Contrôleur de gestion Homo habilis (homme adroit) est considéré comme le premier représentant de l’espèce des Contrôleurs de gestion.
Il est apparu il y a environ 100 ans, d’abord aux Etats-Unis puis ensuite en Europe en fonction des besoins des entreprises et de l’évolution du monde technique et économique avec les analyses de Taylor (1905) sur le contrôle de productivité, les recherches de Gantt (1915) sur les charges de structure et les choix de General Motors (1923) et de Saint-Gobain (1935) pour des structures par division.
A l’époque, il ne s’appelait pas encore Contrôleur de gestion, mais il apprenait déjà à s’occuper des activités de production, et à contrôler un certain nombre de tâches déléguées à la tribu.
Jusqu’au début des années 60, il vivait dans des abris parfois rudimentaires inspirés du modèle des premières firmes industrielles américaines. Afin de protéger la production contre d’éventuels prédateurs, il avait adopté les règles de vie et de gestion taylorienne fondée sur 4 principes :
stabilité dans le temps ;
information parfaite des dirigeants ;
recherche d’une minimisation des coûts ;
coût de production dominant dans le coût total.
Il fut le premier à se servir d’outils simples (monofaces) qu’il taillait autour du système de pilotage pour pouvoir mesurer et contrôler la productivité industrielle et en particulier la productivité du travail direct.
Nomade et premier bipède, il se déplaçait sur ses deux jambes Objectifs-Moyens pour aller chercher sa nourriture en réalisant de courtes distances, mais en mettant à disposition tout au long du chemin des informations et des éléments permettant de mesurer le chemin parcouru et les résultats.
Il vivait en petit groupe dans une structure hiérarchique découpée verticalement en centres de responsabilités.
Il se nourrissait essentiellement de gestion de la production et du processus de planification, dans un objectif de productivité et de rationalisation.
Le contrôleur de gestion Homo habilis est donc un contemporain des industries dites de « l’âge de pierre et de la production taylorienne ». Il pratiquait alors le contrôle budgétaire.
L’âge du feu et de l’expertise financière : le contrôleur de gestion
Le Contrôleur de gestion Homo erectus
Le contrôleur de gestion Homo erectus (homme debout) est un grand voyageur.
Il se déplace et est confronté dans le temps, à l’augmentation de la concurrence et à la globalisation de l’économie.
Il apparaît dans les années 60 et commence sa longue mutation en apprenant à vivre aux côtés d’autres tribus émergentes avec lesquelles il s’installe à proximité des lacs et des rivières :
Dans la décennie 60 : la tribu Commerce née de l’augmentation de la concurrence et de la globalisation de l’économie. Il y apprend que tailler la pierre et produire ne sont plus les seuls maîtres mots : il faut, pour lui, adopter une démarche mercatique (l’inverse de celle du producteur de l’âge de pierre de production) pour connaître et répondre aux exigences de son marché avant de produire les biens. Ses outils ne sont plus monofaces mais deviennent bifaces ; lui imposant alors la nécessité d’être flexible dans les choix de production et de diversifier ses produits.
Dans la décennie 70, la tribu Ressources humaines née de la prise en compte de l’individu et de son rôle clef dans la tribu. Durant cette période, le bien être des bipèdes de la production sont mis au cœur des organisations et du système de production. Les abris rudimentaires ne suffisent plus : ils font place à des huttes faites de branches ou d’ossements d’animaux recouvertes de peaux de sorte à ce que chacun s’y sente bien.
Dans la décennie 80, la tribu Finance, à laquelle le Contrôleur de gestion Homo erectus va tout naturellement venir se rattacher. Il apprend à maîtriser le feu et assure ainsi la performance financière de la tribu qui apparaît alors comme prioritaire. La performance va permettre aux premiers hommes : d’éloigner les prédateurs, d’être rentable, de fiabiliser et challenger les forecasts et de pérenniser ainsi la survie de l’espèce.
Dans les années 90, une ère avec une approche systémique apparaît : mettant en évidence les influences réciproques, multiples et permanentes des 4 tribus (Production – Commerce – Finance – Ressources Humaines). La découverte des interdépendances entre tribus et la nécessité de mettre la stratégie au cœur de ses réflexions lui permettent de chasser des animaux plus gros et de se positionner naturellement comme un fédérateur capable d’intégrer toutes les variables de gestion opérationnelles et de faire le lien entre toutes les tribus.
Doté d’une capacité crânienne de 850 à plus de 1000 cm3 et d’une tête osseuse caractéristique : une mâchoire puissante, un prognathisme marqué, des os épais, un front assez bas, pas de menton, un bourrelet sus-orbitaire et une carène sagittale plus ou moins marquée, il a amélioré les techniques de taille en réalisant ses premiers bifaces. Ses outils révèlent l’existence de comportements nouveaux dans la lignée des contrôleurs de gestion : l’élaboration d’outils, une forte adaptation des outils aux conditions locales et aux besoins humains, le développement de modèles parmi lesquels nous retiendrons :
Le développement de la méthode ABC (Activity-Based Costing)
Le développement de l’ABM (Activity-Based Management)
Le développement de l’EVA (Economic Value Added)
Les tableaux de bord & le BSC (Balanced Scorecard)
La maîtrise du feu et des outils informatiques vont favoriser et conforter le Contrôleur de gestion Homo erectus dans son positionnement transverse, faire de lui un acteur privilégié et central dans l’organisation, lui donner sa légitimité d’expert du pilotage de la performance économique.
L’âge de la pierre polie et de la création de valeur : le Business partner
Le Contrôleur de gestion Homo sapiens
Il y un peu plus de 20 ans les premiers Contrôleurs de gestion Homo Sapiens (homme savant) font leur apparition dans un environnement turbulent dans lequel le rythme du changement s’accélère, le cycle de vie des produits se réduit et les transactions se complexifient.
Ils sont les précurseurs directs du contrôleur de gestion moderne de demain.
Ils commencent à cultiver la mise en place de KPI adaptés aux nouveaux objectifs stratégiques de leur communauté ; à savoir la recherche de flexibilité, de réactivité et d’innovation.
C’est surtout dans le domaine de l’art de s’adapter à l’innovation et à l’augmentation exponentielle des données qu’il se distingue de ses ancêtres :
Traitement de l’information : place centrale et prépondérante dans le processus décisionnel. Dans un environnement devenu de plus en plus instable et complexe, les chamans des tribus doivent disposer en permanence d’informations précises et fiables pour mettre au point et déployer leur stratégie.
Maîtrise de l’informatique décisionnelle et des solution informatisées destinée à améliorer la prise de décision des bipèdes leaders dans l’organisation.
Ouverture de ses compétences à la Business Intelligence (BI) et notamment la connaissance et la maîtrise d’applications, d’infrastructures, d’outils et des meilleures pratiques qui permettent l’accès à l’information en vue de son analyse pour améliorer et optimiser les décisions. Cette ouverture permet aux tribus de transformer leurs données en informations exploitables et donc d’accélérer et d’améliorer la prise de décision.
Les contrôleurs de gestion Homo sapiens font parfois face aux réticences de certains membres de la tribu qui ne croient pas en leur valeur ajoutée. Pour contourner ces obstacles, un rattachement à une nouvelle tribu se développe parfois. Le contrôle de gestion n’est plus intégralement rattaché à la tribu Direction financière, mais chaque tribu métier possède son propre contrôleur de gestion : on a ainsi un contrôle de gestion commercial, un contrôle de gestion industriel, un contrôle de gestion du système d’information…
Ils s’y sédentarisent et habitent dans les villages avec les métiers où ils ne sont plus considérés comme l’œil de Moscou et ont accès aux informations opérationnelles. Dans certaines tribus, ce sont des ingénieurs qui sont formés à la gestion qui occupent ces postes. Ils sont parfois jugés plus pertinents et dotés d’une plus grande légitimité car ils ont la maîtrise technique du métier. Ce changement de positionnement a contribué à améliorer leur crédibilité
C’est alors le début du néolithique (âge de la pierre polie), dans laquelle le contrôleur de gestion Homo sapiens doit mettre à profit son rôle de conseil, au-delà du contrôle et du pilotage de la performance économique qu’il exerçait jusqu’à présent. Son savoir-faire repose de plus en plus sur des compétences hybrides qui contribuent à réconcilier les deux tribus de la Finance et des Opérations.
On distingue alors deux profils de bipèdes Contrôleurs de gestion :
Les contrôleurs de gestion dits centraux, au camp, plus éloignés de l’activité opérationnelle d’élevage et d’agriculture. Leur client principal est le Chaman de la tribu et leur activité relève pour l’essentiel du reporting.
les contrôleurs de gestion dits opérationnels, souvent décentralisés et totalement immergés dans l’activité. Ils travaillent en étroite collaboration avec les artisans opérationnels et sont chargés de remonter leurs éléments au contrôle de gestion central à des fins de consolidation.
Le contrôleur de gestion Homo sapiens devient progressivement un artisan clé d’aide à la décision et force de proposition pour orienter des choix souvent stratégiques.
Passé maître dans la façon de tisser et cultiver des liens au contact des tribus métiers afin de leur faire prendre en compte la dimension et les enjeux financiers, il se positionne comme Business partner.
Le contrôleur de gestion expert de l’âge du feu, « gardien du temple » ou « garde-fou » au sens de Lambert et Sponem, évolue vers un métier de Business Partner avec pour principales missions de :
Savoir apprécier les décisions prises et mesurer les risques associés
Savoir conduire les opérationnels vers des objectifs ambitieux
Apporter des idées et suggestions pour améliorer la performance globale
La maîtrise des outils informatiques, la montée en compétences sur des sujets opérationnels et métiers, la recherche de valeur ajoutée constituent les fondamentaux du développement des premières grandes civilisations de Finance Business Partner et permettent au Contrôleur de gestion d’être et de rester un allié incontournable et essentiel à la tribu, notamment dans tout l’Occident.
Ainsi s’achève la Préhistoire du Contrôleur de gestion et….. c’est maintenant que l’Histoire commence…
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).
Réussir le renouvellement de ses contrats d’infogérance nécessite anticipation et préparation dans le cadre de bons choix stratégiques et tactiques plus ou moins collaboratifs vis-à-vis du marché. Ces choix sont systématiquement fonctions de l’analyse de la relation client-fournisseur et des besoins non couverts.
Les DSI sont systématiquement confrontés, à l’approche de l’échéance de leurs contrats d’infogérance et/ou dans le cadre de situations exceptionnelles à la question des modalités de renouvellement / prolongation de leurs contrats et ce si possible bien avant l’arrivée à échéance.
Sur la base de l’expérience de ces situations et de nombreuses missions de conseil, je recommande (1) de bien prendre conscience des différents niveaux d’attente qu’une DSI peut avoir face à aux infogérants, (2) conduire des revues d’évaluation et de dynamisation à mi-contrat, (3) choisir et s’impliquer – le cas échéant – dans les stratégies de remédiation, renégociation ou remise en compétition.
Qu’attendre de vos infogérants ?
Je pense qu’il est important que les deux parties soient attentives à un certain nombre d’attributs de la relation et ce dans un ensemble de dimensions qui se consolident dans la durée. Ce n’est qu’à ce prix que les conditions d’un partenariat peuvent se développer et se maintenir, saisons de renouvellements après saisons.
Conduire des revues d’évaluation et de dynamisation à mi-contrat
Il s’agit d’impliquer des équipes externes au contrat (mais pas forcément des consultants extérieurs) afin d’évaluer l’état des réalisations, le niveau de performance, la perception utilisateurs ainsi que l’évolution des besoins depuis le démarrage ainsi que les moyens qui ont concrètement été mis en œuvre pour y répondre.
Bien que ces revues puisse être mal accueillies par les infogérants et/ou perçues comme « hostiles », dérangeantes ou voire même inutiles, ce type d’analyse de la situation à mi-parcours apporte cependant les bénéfices suivants :
l’œil neuf et le changement de perspective d’une équipe externe permet d’identifier les points oubliés, insuffisamment challengés ou implicitement admis par l’équipe en charge du contrat
l’opportunité d’exprimer son opinion – bonne ou mauvaise – sur le contrat en communiquant à l’infogérant ses besoins de changement pour la suite
donner à l’équipe en charge du contrat (coté client comme coté infogérant) l’opportunité de changer de direction si besoin ou au moins d’adresser suffisamment tôt les problématiques identifiées pour que les changements puissent être menés à bien avant une potentielle remise en compétition.
Opter pour les bonnes stratégies de fins de contrats
Les décisions de « renouvellement » qu’une DSI doit prendre dans le cadre de ses contrats existants ne sont pas si simples car elles nécessitent une évaluation précise des situations selon que ces contrats donnent ou pas satisfaction ou bien qu’ils arrivent prochainement à échéance.
Cas n°1 : une DSI dont le contrat ne répond plus aux attentes ou dont l’exécution ne donne pas satisfaction se posera les questions suivantes : comment en est-on arrivé là ? Que devons nous faire pour adresser les causes profondes de cette situation ? Est-ce le moment de renégocier le contrat ? Est-ce le moment de remettre ce contrat en compétition ? Devrions-nous collaborer avec notre fournisseur pour améliorer la performance rendue et la relation de travail ?
Cas n°2 : une DSI dont le contrat arrive prochainement à échéance se posera les questions suivantes : devrions-nous renouveler ce contrat ou bien le renégocier avec notre fournisseur actuel ? Devrions-nous ouvrir ce contrat à d’autres fournisseurs potentiels dans le cadre d’une remise en compétition ?
Quelle que soit la situation, l’objectif stratégique de la DSI sera de maximiser la valeur ajoutée de son contrat. Trois stratégies, de la plus collaborative à la plus compétitive, sont possibles afin de remettre sur la bonne voie, un contrat qui en aurait dévié et/ou pour bénéficier d’innovations techniques ou organisationnelles non disponibles (ou envisagées) à la signature du contrat initial :
Stratégie de remédiation : il s’agit ici de se focaliser sur la relation avec le fournisseur et les services obtenus plutôt que sur le contrat. Cette stratégie s’attache à améliorer la situation pour les deux parties. La remédiation pouvant faire intervenir ou pas des changements contractuels mais impliquant dans les cas un plan d’amélioration
Stratégie de renégociation : il s’agit dans ce cas de modifier le contrat initialement signé. Ces changements pouvant être aussi mineurs que des ajustements de prix ou de la baseline ressources, ou bien plus significatifs comme la révision en profondeur des termes, des conditions ou du périmètre du contrat. L’origine de ces changements peut simplement être la conséquence d’un contrat initial qui ne fonctionne plus correctement en raison d’un état de l’art qui a évolué depuis sa signature ou bien de besoins client qui ont changé et ne sont pas pris en compte dans le contrat actuel
Stratégie de remise en compétition : il s’agit d’ouvrir à la concurrence, dans le cadre d’un appel d’offre, tout ou partie des services contractualisés . Le tenant actuel du contrat étant inclus ou pas dans la liste des fournisseurs consultés.
Ces stratégies pourront, selon les cas, s’enchaîner et se combiner tout au long du cycle de vie du contrat.
Au sein des DSI, la fonction de Contract Manager a fait ses preuves au cours de ces dernières années.
Suite à la période particulière que nous avons traversé et les conséquences sans précédents observées durant ce printemps 2020, son importance s’est vue décuplée. Ce besoin croissant au sein des DSI peut s’expliquer notamment par certains des questionnements soulevés par Lahcen Elouahi, Senior Manager de Rhapsodies Conseil, lorsqu’il aborde l’impact du télétravail sur les contrats de Soucing IT.
Entre autres :
Comment modifier ses contrats de sourcing pour tenir compte du mode de travail à distance ?
Comment optimiser les coûts de support dans un contexte de travail mixte : sur site et à distance ?
Quels indicateurs de performance, modèle de gouvernance et outillages faut-il mettre en place ?
Comment auditer et faire évoluer ses Contrats IT ?
Partant de la pertinence de ces interrogations, et de la nécessité d’y apporter une réponse adéquate, il est légitime de se demander qui serait le mieux placé au sein de son organisation pour mener à bien les actions attendues ?
Au vu du sujet de cet article, la question est évidemment rhétorique. Cependant, apporter la réponse n’est pas si évident, et de nombreuses entreprises ne parviennent pas à tirer profit du Contract Management. Cette difficulté réside dans la transversalité des sujets concernés, impliquant de fait de nombreux métiers et acteurs de l’entreprise.
Dès lors, il me semble intéressant de comprendre l’origine de la complexité attachée au positionnement du Contract Manager, pour chercher ensuite comment l’intégrer intelligemment au sein d’une organisation.
Comprendre l’origine
Le rôle de la nomenclature des métiers du CIGREF est de rationaliser les métiers de l’IT. La version 2018 de ladite nomenclature a fait ressortir une nouvelle famille de métier, dénommée « Relations Fournisseurs », au sein de laquelle la fonction de Contract Manager (ou « Manager de Contrat » en français) a été déplacée aux côtés de celles de l’Acheteur IT, du Software Asset Manager et du Vendor Manager.
Toutefois, la réalité démontre qu’il est très compliqué de standardiser le rôle et les responsabilités du Contract Manager. Ceci étant dû tant à l’histoire de la fonction, qu’à sa terminologie et/ou à son positionnement. Initialement étranger au secteur informatique, le métier de Contract Manager trouve ses origines dans l’univers du BTP durant les années 1990. Il fait alors partie de ces postes « reflexes » créés en réaction à une action, une inaction ou un besoin inattendu. Dans ce cas précis, le Contract Manager devait répondre à l’émergence de Claims Managers. Ces derniers avaient pour objectifs de maximiser les gains financiers potentiels des contrats dont ils avaient la charge en usant de tous les leviers contractuels disponibles, et ce au détriment de la relation commerciale.
La mission du Contract Manager consista dès lors à s’approprier la gestion du contrat, en privilégiant l’équilibre contractuel et le dialogue nécessaire à une relation commerciale saine. Les Contract Managers sont parvenus à s’approprier le Cycle de Vie Contractuel en liant la théorie juridique, la pratique opérationnelle, l’aspect commercial et les impératifs du contrôleur de gestion.
La combinaison de l’ensemble de ces compétences en fit une fonction transverse. La gestion des risques contractuels fut ainsi simplifiée et entraina une maîtrise efficace et collaborative des cocontractants. Néanmoins, ce métier resté discret en France au cours des années 2000, souffre encore aujourd’hui de sa dénomination anglaise mal perçue par les sociétés et directions françaises. C’est ainsi que l’on retrouve couramment des « Gestionnaires de Contrats » (ou de bases de données contractuelles) dénommés « Contract Manager », chargés de la duplication de documents contractuels, ou de la référenciation massive des contrats. En réalité, leur rôle se rapproche davantage d’un poste de Paralégal ou d’Assistant Administratif. Dans la mesure du possible, cette situation doit être évitée au risque de ne pas rattacher le niveau de compétences adéquat à des missions essentielles.
Au-delà de la terminologie, le Contract Manager souffre également de son positionnement au sein des DSI françaises. Comme cela a été évoqué précédemment, le Contract Manager constitue la pierre angulaire entre quatre métiers essentiels : les juristes (Direction Juridique), les acheteurs (Direction des Achats), les opérationnels (Direction des Opérations) et les contrôleurs de gestion (Direction Financière). Les entreprises fonctionnant majoritairement en silo, la fonction transverse que représente le Contract Manager se voit régulièrement rattachée hiérarchiquement à l’une des quatre directions susmentionnées. Les conséquences ne sont pas anodines, et le profil des Contract Managers se retrouve forcément impacté.
Ainsi, certaines organisations vont faire valoir au Contract Managament une prédominance du métier d’Acheteur, tandis que d’autres organisations pourront décider de recourir majoritairement aux compétences juridiques, et d’autres encore préférer y rattacher les missions d’un Service Delivery Manager.
L’intégration d’une cellule de contract management
Lors de la construction d’une cellule de Contract Management au sein de votre DSI, c’est une réalité qu’il est impératif de prendre en compte. Il est pertinent de se demander en autre :
Quels sont les objectifs recherchés ?
Quelles sont les performances supplémentaires attendues ?
Quelle typologie de risques m’affecte le plus ?
Quels outils et processus peuvent-être adaptés, modifiés, optimisés ?
La réponse à ces questions stratégiques permet la création d’un RACI pertinent et adéquat dont il ressort généralement une typologie de « profil de Contract Manager ». Cette information est clef dans la construction, le rattachement et donc le positionnement du Contract Management. Chaque situation étant spécifique, il n’y a pas de mauvaise solution. En revanche, une cellule de Contract Management correctement positionnée, bénéficiant d’un maximum de rôles et responsabilités transverses, permettra non seulement d’éviter de nombreux travers et points de blocages, mais aussi d’assurer une gestion des risques et des fournisseurs performants.
L’infogérance est un levier externe de transformation du run. Chaque contrat d’infogérance charrie son lot de passion du début de la relation (la lune de miel) jusqu’au développement de la relation et parfois jusqu’au divorce.
Mais au fond, peut-on vraiment parler de partenariat dans le cadre d’une prestation de service régie par un contrat d’infogérance ? Certains pensent que « Oui » et d’autres que « Non »….
De mon côté, et sur la base de l’expérience, je pense que les deux parties doivent être attentives à un certain nombre d’attributs de la relation et ce dans un ensemble de dimensions qui se consolident dans la durée. Ce n’est qu’à ce prix que les conditions d’un partenariat peuvent se développer.
Mais mieux qu’un long discours, je vous livre dans le schéma ci-dessous la synthèse de mes constats :
Décryptage
Un infogérant qui démarre un contrat avec un nouveau client sera souvent choisi (et attendu) pour ce qu’il vous apporte (ce que vous obtenez). Ce sont les promesses explicites qui sont ici en jeu.
Un infogérant en place sera principalement quitté (globalement) pour un problème de relation (comment vous travaillez ensemble). Ce sont les promesses implicites qui sont ici en jeu.
Un « partenariat » se construit et se maintient dans la durée sur la base de la contribution de valeur (la valeur qu’ils vous apportent). C’est l’intimité de la relation qui permet ici de mieux comprendre son client et d’avancer dans cette direction.
La relation et le partenariat se développent quand l’infogérant tient non seulement ses promesses explicites et implicites mais va au-delà des attentes en s’appuyant sur son intimité client et ses compétences cœur de métier.
Voilà, pour ce court billet, j’attends vos commentaires et surtout le récit de vos expériences
