traduire-exigences-du-run-en-capacites-operationnelles

DSI : Comment traduire les exigences du run en capacités opérationnelles ?

DSI : Comment traduire les exigences du run en capacités opérationnelles ?

11 février 2021

– 8 min de lecture

Eric Nizard

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 :

  1. 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 ?
  2. Quelles sont les principales tendances qui poussent à adapter le modèle opérationnel du Run ?
  3. 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.

business model canvas

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.

tendances technologiques

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 à vernir et 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 :

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 :

  1. Vous démarrez quelque chose de totalement nouveau
  2. Vous changez de stratégie
  3. Vous avez des problèmes de performance
  4. 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

elements declencheurs du changement

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).

DSI : réussir le renouvellement de vos contrats d’infogérance

DSI : réussir le renouvellement de vos contrats d'infogérance

21 janvier 2021

– 3 minutes de lecture

Eric Nizard

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 :

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 :

Ces stratégies pourront, selon les cas, s’enchaîner et se combiner tout au long du cycle de vie du contrat.

contract-manager-transverse

Le contract manager, entre silo et transversalité

Le contract manager, entre silo et transversalité

9 décembre 2020

– 4 min de lecture

Louis Rondot

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 :

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 : 

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.

Infogérant / Partenaire: un oxymore ?

Infogérant / Partenaire : un oxymore ?

15 novembre 2020

– 1 minute de lecture

Thierry Sauthier

Senior Manager Transition & Transformation

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

Eric Nizard

La Scorecard, l’outil indispensable pour manager ses fournisseurs

La Scorecard, l’outil indispensable pour manager ses fournisseurs

10 novembre 2020

– 3 minutes de lecture

Ikram Mansour

Consultante Contract Management

Dans un environnement de plus en plus concurrentiel, la recherche de la performance et de l’efficience sont les leitmotivs d’une entreprise tournée vers l’avenir. La mise en place d’indicateurs de performance a pour but de permettre à ses dirigeants des prises de décisions ou de les conforter dans leur stratégie.Toutefois, une entreprise n’agit pas seule, c’est tout un écosystème de parties prenantes qui l’englobe et impacte sa compétitivité, notamment ses prestataires qui l’accompagneront dans l’atteinte de ses objectifs. Si elle souhaite être la meilleure, elle doit donc s’entourer des meilleurs.

Comment s’assurer de la performance de ses Prestataires ? De quels prestataires parle-t-on ?

Le meilleur moyen de s’assurer de la performance de ses fournisseurs est de mettre en place des outils de notation sur des critères précis et compréhensibles, que nous détaillerons, la scorecard fournisseur.

Elle permet ainsi de déterminer la note d’un fournisseur sur chacun de ces critères, ses axes d’améliorations et son positionnement vis-à-vis des autres fournisseurs.

Pour quel fournisseur doit-on mettre en place une scorecard ? 

Les fournisseurs dits « Stratégiques » sont ceux pour lesquels la mise en place d’une scorecard est primordiale : ils impactent directement l’activité de l’entreprise ou d’un service. Un service informatique n’aura pas les mêmes fournisseurs stratégiques que celui des moyens généraux par exemple. Chaque service doit identifier ses fournisseurs stratégiques. 

Généralement l’analyse des dépenses par fournisseur est un bon indicateur des fournisseurs stratégiques. Plus le montant de la dépense est important avec un fournisseur plus le fournisseur a un poids stratégique pour l’entreprise.

Comment mettre en place une scorecard fournisseur ? 

Une scorecard doit traduire les objectifs stratégiques en objectifs opérationnels. Il s’agit donc d’établir une liste de critères sur lesquels nous souhaitons mesurer la performance du fournisseur. Six critères essentiels ressortent :

Le dernier critère n’est pas systématiquement mesuré mais de plus en plus d’entreprises le prennent en compte pour les  enjeux d’image de marque que cela peut entraîner,  comme récemment le scandale Griezman/Huawei. L’affaire sur les camps d’internement de la communauté Ouighours en Chine a touché plusieurs entreprises. Certaines égéries (Antoine Griezmann) ont souhaité arrêter leur partenariat avec les entreprises qui ont employé des Ouighours. Il y a une perte du partenaire d’image mondialement connu, et également une image ternie de l’entreprise auprès du public international. Des appels au boycott ont également été lancés, ce qui peut générer des conséquences importantes sur le chiffre d’affaires de l’entreprise.

Une déclinaison de sous-critères sur chaque item permettra d’affiner la notation. Ainsi, sur l’axe financier, le positionnement du fournisseur sur ses prix par rapport au marché sera à dissocier des propositions d’optimisation permettant une réduction de coût.

Sur l’axe qualité, les sous critères pourraient se décomposer de la manière suivante :

Une enquête est donc réalisée auprès des personnes qui travaillent quotidiennement au contact des fournisseurs afin de récolter leurs appréciations : opérationnels, acheteurs, contract manager… La consolidation des résultats de l’enquête donne une note du fournisseur sur chacun des critères. 

Parfois un sponsor est nécessaire afin de récolter les appréciations de toutes les personnes sollicitées. Le sponsor a pour but de rappeler les enjeux et l’objectif de la démarche. 

La restitution de l’enquête est présentée en interne lors des comités afin de déterminer la stratégie de sourcing (avec quel fournisseur devons-nous renforcer notre partenariat ou au contraire la diminuer lorsque le fournisseur ne parvient pas à améliorer son score dans la durée)

Parallèlement, la scorecard est également présentée au fournisseur afin de présenter les points positifs de leur offre de service et aussi les axes d’amélioration leur permettant d’ajuster leur offre aux attentes du client. Les prestataires sont d’ailleurs généralement demandeurs d’un feedback. 

La scorecard permet donc de mieux manager ses fournisseurs, elle nous donne des indicateurs sur les points forts, les axes d’amélioration et permet de connaître le positionnement vis-à-vis des autres fournisseurs évalués.

Récemment chez l’un de mes clients, un grand projet de transformation et de massification des fournisseurs stratégiques a été mis en place, les résultats de l’enquête scorecard ont été regardés avec grand intérêt afin de déterminer les candidats à l’appel d’offres. 

Toutes ces informations clefs permettent de définir la stratégie de sourcing d’une entreprise et organiser ses sollicitations  en fonction des résultats de la scorecard : un fournisseur à une note moyenne sur l’axe innovation, l’entreprise ne le sollicitera probablement pas pour mener un projet de transformation.

Et vous quel outil de mesure de la performance utilisateur utilisez-vous ?

transformer tma modèle offshore

Transformer une TMA internationale dans un modèle offshore

Transformer une TMA internationale dans un modèle offshore

7 novembre 2020

– 2 min de lecture

Pierre Moulin

Contexte

La maintenance et les développements applicatifs d’une entreprise du CAC 40 sont assurés par différents prestataires, sur plusieurs continents. Les contrats ont été signés par différentes entités, parfois pour des besoins identiques. Les services concernés sont basés sur différentes technologies dont certaines peu répandues (Documentum…). L’ensemble correspond à des ressources dédiées, avec un engagement de résultat faible. Certaines expertises sont difficiles à trouver sur le marché et à stabiliser. Le Client souhaite aussi réduire fortement ses coûts.

Solution

Notre intervention, entièrement en anglais, permet de définir des objectifs forts et partagés, puis de mettre en forme l’ensemble du « package RFP ».  Notre accompagnement définit et structure la démarche et anime les intervenants sur 3 continents (Amérique du sud, Europe et Asie). Nous faisons monter les équipes en compétence sur les meilleures pratiques (pricing model de TMA, SLA, pénalités, delivery model, gouvernance). L’accompagnement se poursuit jusqu’à la contractualisation, la livraison des annexes du Contrat et le cadrage de la transition.

Bénéfices

Le client a pu constater :

Les autres success stories qui peuvent vous intéresser