Si la question de la digitalisation ne se pose plus, celle de sa mise en œuvre est quant à elle au cœur des stratégies actuelles des entreprises. (Tout le monde en parle mais le passage à la mise en œuvre n’est pas facile) Le décalage croissant entre l’IT et les attentes des métiers est un DÉFI à la transformation numérique, les efforts des DSI pour moderniser l’outil informatique apparaissent parfois en décalage ou en deçà des attentes des utilisateurs.
La transformation numérique n’est plus un choix mais un impératif, une obligation
On a longtemps délaissé (du moins, ce n’était pas une priorité) l’environnement de travail (workplace) des salariés demain il fera partie des priorités (50% des DSI français ont un projet digital autour de l’environnement de travail utilisateur sur 2019 sources IDC), une évolution qui doit être attribuée aux attentes et à la pression des métiers/utilisateurs en matière d’expérience utilisateur.
Les DSI se déclarent majoritairement insatisfaits des performances des partenaires auxquels ils font appel (support très classique drivé par les coûts et dont la Qos est portée par les individus). Entre 55% et 68%* (Source IDC) des responsables se déclarent déçus et près de la moitié d’entre eux (49%) envisagent de changer de partenaire. Un pourcentage plutôt alarmant.
L’enjeu donc pour l’IT (donc les DSI) consiste à équilibrer innovation et excellence opérationnelle. Voire à les combiner. Les nouvelles générations d’outils numériques sont d’une aide précieuse : big data, réseaux sociaux, cloud, mobilité, Internet des Objets, agents conversationnels, etc. dissimulent un potentiel d’innovation quasiment illimité pour améliorer l’expérience client, mettre à disposition des services hyper-personnalisés et instantanés. Ne pas oublier la génération millenium constituera la moitié de la population active d’ici 2020 donc juste après demain.
Priorité à l’amélioration de l’expérience client
La mise en place d’une « Digital Workplace » représente ainsi la première étape d’une stratégie de Transformation Digitale orientée utilisateur et unifiant les technologies nécessaires à la productivité des utilisateurs.
Une définition simple à retenir de la Digital Workplace : Offrir à l’utilisateur une interface moderne facilitant le travail au quotidien, personnalisée, plus fluide, plus simple, plus rapide, efficace et multi accès.
Repenser le Support IT au sens large en intégrant la dimension digitale liée à des innovations technologiques et des nouvelles pratiques est une réelle opportunité pour la DSI. Elles verraient ainsi leur service support amélioré et leur relation client renforcée.
L’orientation usage, la meilleure façon de faire
Avoir une vision usage et non techno ni innovation pour de l’innovation
Être en adéquation avec les réelles attentes des utilisateurs
Avoir une stratégie d’écoute des métiers/utilisateurs, afin qu’ils puissent se projeter dans les nouvelles solutions qu’on leur apporte
Donner aux utilisateurs le temps d’exprimer leurs frustrations
Avoir une approche par métier par profil par besoin
Réconcilier ROI pour la DSI et Satisfaction pour les utilisateurs
Cibler des services à l’usage
Avoir un accompagnement quasi permanent des métiers est la clé essentielle de la réussite
Segmenter et Profiler l’accès aux services informatiques
Analyser le marché et identifier parmi la richesse du marché IT la les solutions les plus adéquates au contexte métier-
Les entreprises ayant des services IT modernes et orientés métier récoltent rapidement les fruits
Pour y aller, un accompagnement peut sembler nécessaire, pour :
Avoir une vision des usages & des tendances et les acteurs du marché
Accompagner le développement du Digital et la transformation du Service dans votre contexte
Repenser l’environnement de travail de demain
Placer les usages au centre des initiatives ET concrétiser la valeur
Co-Construire les scénarios des trajectoires de transformation
Mise sous contrôle du projet de transformation
Et l’accompagnement au changement avec un plan marketing de la transformation très tôt dans le processus.
Trop souvent, la construction budgétaire s’enlise dans des détails jusqu’à perdre son sens et son efficacité. Or le budget n’est que le début de l’histoire…
« À ce train-là, nous aurons finalisé les projets avant le budget. » « Je ne suis pas voyante, comment je peux donner autant de détails sur mes dépenses à venir ? » « On en est déjà à la version 20 et ce n’est toujours pas fini ». Alors que la période d’élaboration des budgets bat son plein, voilà les petites phrases que nous entendrons tous probablement autour de la machine à café. Et pour cause : le cadrage budgétaire est victime de plusieurs malentendus qui complexifient inutilement l’exercice. Et pourtant, construire un budget ne devrait pas être plus compliqué que faire ses courses au marché. Explications…
Quand vous faites vos courses, vous partez avec, en poche, un porte-monnaie et, en tête, des idées d’achats par grandes familles de produits (fruits et légumes, viande ou poisson, fromage et laitages, pain…). Au moment de quitter votre domicile, vous ne savez pas encore ce que vous allez acheter, mais vous avez une idée de vos besoins et de ce que contient votre porte-monnaie – votre budget donc. Sur place, face aux étals, vous arbitrerez en fonction des produits effectivement disponibles, des prix affichés, etc. Une certitude : avant de partir, vous n’avez pas passé deux heures à estimer les montants à provisionner pour chaque famille de produits et à les répartir dans autant de porte-monnaie…
Mais ce sont bel et bien les dérives que l’on observe trop souvent lors de l’élaboration budgétaire. Pour les éviter, voici 5 principes.
1) Communiquer en amont avec les équipes
Présenter la stratégie de la DSI, les grands projets retenus, le niveau attendu des dépenses… Autant d’informations qui, communiquées en amont de la construction des budgets, aident les équipes à se projeter (éviter la liste au Père Noël) et à s’inscrire dans le cadre souhaité.
2) Maitriser le nombre de lignes budgétaires
Le budget ne peut correspondre à l’allocation réelle. Inutile de demander aux équipes opérationnelles de détailler ce qui va se passer dans un an, voire au-delà. Dans la pratique, plus les lignes budgétaires sont détaillées, plus les écarts s’accroissent entre le budget et le réel, donc plus les prévisions sont fausses. Résultat, un temps considérable est ensuite consacré à réallouer des budgets de ligne en ligne, aux dépens du suivi et de l’analyse…
3) Gardez la trace de vos hypothèses
S’il faut se tenir à distance de la tentation de détailler chaque type de dépense à venir, il est recommandé en revanche de conserver les différentes hypothèses émises lors de la construction des budgets. Ce matériel s’avère souvent précieux pour, plus tard, expliquer les écarts.
4) Distinguer le run du build
Parce que, comme son nom l’indique, le Run est récurrent, il est aussi mieux maîtrisé que le Build. Savoir où sont ses marges de manœuvre en cas de besoin d’arbitrage fait gagner du temps : il est plus facile de ne pas démarrer un projet que de ne pas engager des dépenses de maintenance, par exemple.
5) Considérez votre budget comme un garde-fou
La vocation première du budget est de fixer une enveloppe pour ne pas dépenser en cours d’année plus que défini initialement. Ce n’est donc pas un outil pour nourrir une analyse qui, elle, se base sur la réalité des dépenses.
Appliquez-vous ces principes ? Pour vous en assurer, regardez tout simplement si vous passez plus de temps à construire votre budget qu’à le suivre… Le budget n’est que le début de l’histoire. Ce qui importe ensuite, c’est d’analyser les coûts, de contrôler la trajectoire, d’identifier les dérives et de proposer des solutions pour rester dans le cadre défini. C’est ainsi, et en associant pas à pas les opérationnels, que vous donnerez du sens au pilotage des coûts avec, à la clé, une construction budgétaire bien plus qualitative.
Une société du CAC 40 réalisait récemment un audit de son contrat mondial de TMA & projets applicatifs, dont le back office se trouve en Inde. Au programme, des difficultés opérationnelles et des conséquences financières sérieuses, mettant en doute le bien fondé du modèle Offshore.
Cet exemple en rejoint d’autres…
Les métiers ont à peine remarqué le changement. La qualité n’est donc pas si mauvaise que cela. Pourtant, les « maîtrises d’ouvrage » métiers sont formelles : « les indiens sont nuls ! » Et après des mois de démarrage laborieux, la DSI a tout essayé : task force, plans d’actions, voyages coûteux pour développer la proximité avec les équipes distantes, formations des collaborateurs pour travailler différemment, etc. Sans compter l’équilibre entre Front office et Back office, révisé avec davantage de proximité, au détriment bien sûr des objectifs financiers.
Après plus d’un an d’efforts de la part du client et de son prestataire, les équipes sont amères, voire dépitées. La relation de confiance, pourtant si précieuse pour travailler efficacement à distance, n’existe pas, ou alors, seulement sur des « ilots » spécifiques.
Mais qu’en serait-il si des erreurs majeures n’avaient pas été commises ?
Le prestataire ne dit pas la vérité lors de la phase d’avant-vente
A quand un discours commercial enfin mature ?
Les prestataires connaissent pourtant « TRES BIEN » les difficultés rencontrées. Que de temps pourrait être gagné, de sueur et de larmes évitées, si le prestataire exerçait enfin son devoir de conseil, au-delà de celui de gagner un dossier ! Nous pensons qu’un discours mature sur le sujet est indispensable, alors que ce n’est un « deal breaker » que pour celui qui ne connait pas les vrais points forts de son offre.
Le client doit pouvoir mieux comprendre qu’il a un rôle clé dans la chaîne des services
Nous voyons encore trop souvent des candidats timides sur certains facteurs de succès d’un programme offshore (ou nearshore). Par leur passivité, ils encouragent le raccourci intellectuel de l’expertise = la qualité des livrables. La vérité c’est que l’expertise est rarement suffisante au départ, notamment sur le plan fonctionnel, et que même si elle l’était, les malentendus resteraient innombrables, si le client ne s’assurait pas activement et régulièrement que ses besoins sont compris.
La question est donc posée aux prestataires, qui devraient adapter leur discours, en rapprochant les équipe de vente des managers de tels programmes.
Les commanditaires internes du projet disent rarement la vérité aux collaborateurs
Il ne faut pas sous-estimer les conséquences d’une mauvaise communication : des managers métiers en défiance avec les choix qui ont été faits, des pratiques de « shadow sourcing » sur des contrats parallèles coûteux, des messages négatifs et déformant les faits, qui tendent à miner toute chance de réussite. Parmi les écueils en matière de communication, nous voyons l’angélisme, qui crée d’emblée un malentendu durable, et nous voyons aussi l’absence partielle ou totale d’information, vécues comme une forme de mépris.
Nous préconisons la clarté sur les objectifs d’un tel projet, même douloureux. Nous recommandons de responsabiliser et de préparer les collaborateurs à travailler davantage, au moins sur certaines activités. Autre point d’attention majeur, celui de préparer les collaborateurs à accepter les différences culturelles, sources de nombreux malentendus.
Le plan de communication interne aux différentes parties prenantes est un incontournable du projet, dès le T0.
Ce plan sera porté par la direction informatique, voire, la direction générale.
Les conditions opérationnelles d’éligibilité ne sont pas remplies
Les conditions d’éligibilité à l’Offshore constituent un inventaire à la Prévert, mais c’est la partie la plus facile du sujet. Un simple diagnostic d’éligibilité qualitatif et quantitatif, relativement rapide et peu coûteux, permet de porter un jugement pertinent sur un niveau de maturité. Il permet d’analyser :
Le niveau de documentation du périmètre, qui doit être suffisant,
Les pratiques des collaborateurs, qui doivent être suffisamment formalisées et référencées,
Le niveau de maîtrise de la langue de travail (souvent l’anglais),
La complexité technique,
La qualité de l’existant au regard des bonnes pratiques,
La complexité fonctionnelle, et la part du spécifique,
Les outillages de gestion des demandes (leur stabilité, la maturité de leur paramétrage),
Le niveau d’activité sur le périmètre. Par exemple un périmètre trop stable ne permet pas de monter en compétence grâce aux demandes de changement,
La pérennité relative du besoin,
L’offre alternative, en matière d’optimisation des processus et d’automatisation
Les collaborateurs ne sont pas assez formés, ni assez impliqués
Deux publics devront faire l’objet de toute l’attention de la conduite du changement projet:
– Les functional designers / business analysts, qui souvent ne maitrisent pas assez l’expression de leurs besoins.
– Les managers, qui ne sont pas forcément formés aux besoins spécifiques d’un tel contrat. Nous pensons au capacity planning, qui permet l‘adéquation entre l’offre et la demande, dans la flexibilité, et la maîtrise des coûts de l’équipe de delivery. Autre sujet majeur, les pratiques « à distance » de quality control, qui posent la question du juste équilibre entre une bonne collaboration client-fournisseur et un bon suivi via des indicateurs (KPI/SLA) de service. Dernier sujet essentiel du management, la mise en place d’un véritable management de programme, c’est-à-dire, transverse, permettant de sortir des silos fonctionnels. Ce management doit être à la fois opérationnel ET contractuel. Une question à ce sujet : connaissez-vous le contenu de vos contrats d’infogérance ? Un contrat bien conçu comporte des outils de gestion efficaces ; charge ensuite au client de les mettre en œuvre dans le cadre de son activité de « contract management » quotidienne.
A adresser dès le T0 du projet, par un diagnostic (« Fit gap analysis ») puis, par les actions nécessaires dans le plan de conduite du changement de projet.
Plus c’est critique et complexe, plus cela risque de mal
La « trajectoire de migration » signifie que tout ne devrait pas basculer dès le « go live » du nouveau contrat. Une trajectoire permet de prioriser les sujets, selon des critères de complexité et de volumes. Pour certains périmètres, l’expérience montre que cela risque de ne jamais marcher. Car, l’expertise y est trop critique, les délais trop courts, et de plus, la mutualisation des ressources (inhérente aux centres de services à bas coûts) deviendrait un facteur de risque trop important.
Des objects financiers ambitieux sont rarement compatibles avec une montée en charge progressive et sélective. pourtant c’est un « key success factor » d’un programme offshore.
Et si on arrêtait de faire n’importe quoi ?
Se lancer dans un marathon en ayant produit un faux certificat médical, sans s’être renseigné sur les risques d’un tel effort, et surtout, sans s’être entrainé correctement, voilà qui comporte une bonne dose de bravoure…ou d’inconscience ! C’est un peu ce que font nombre de décideurs avant de démarrer un projet Offshore. Il y a 2 types de contre-vérités sur le sujet du sourcing offshore : (1) c’est mature et cela va marcher ; il suffit pour cela de choisir le bon partenaire et (2) cela ne marche pas, d’ailleurs beaucoup de clients reviennent après l’avoir expérimenté à leurs dépens. Un projet offshore réussi offre des bénéfices opérationnels et financiers à la fois durables et importants. Il n’y a qu’à constater l’importance de l’offre et des contingents recrutés sur place pour le comprendre. Cependant un tel projet doit s’inscrire dans une véritable stratégie d’entreprise, qui aura su évaluer les autres leviers de la productivité (tels que l’optimisation des processus et l’automatisation). Cette stratégie aura confirmé le périmètre éligible, et révisé les objectifs financiers, en intégrant une mise en œuvre complexe et donc coûteuse.
13 janvier 2025
Pilotage & Performance Opérationnelle et Contractuelle
Pour les « habitués » de RPA et/ou des Shared Services, la lecture pourra sauter les deux premiers paragraphes introductifs.
RPA
L’automatisation des processus avec des robots, ou automates, vise à remplacer tout ou partie de tâches répétitives, qu’un employé exécute depuis son poste de travail. Lorsque le processus est entièrement automatisé, sans intervention humaine, on parle de Robotic Process Automation (RPA) et lorsque l’automate assiste l’humain, plutôt en mode « collaboration », on parle de Robotic Desktop Automation (RDA).
RPA ou RDA ne sont pas nouvelles. Simuler, automatiser l’exécution de « scénarios » comprenant des activités manuelles d’un utilisateur d’un poste de travail, se faisait déjà dans les années 90, avec des outils du marché effectuant des tests d’applications. L’opérateur avait le loisir de lancer 100 fois un enchaînement d’un ou plusieurs scénarios de test, et se souciait essentiellement d’analyser et de gérer les exceptions, c’est-à-dire, les cas particuliers qui pouvaient se produire. Le reste, c’est la machine qui le gérait et enregistrait les résultats.
Aujourd’hui les outils se sont certes améliorés, et couvrent avec efficacité des processus métiers. Mais les cas d’usage de la RPA, restent toujours essentiellement dans l’esprit de ce que je viens de raconter :
Pour traiter des activités :
dans un processus bien cadré,
non ambiguës,
et si possible, parfaitement documentées
A relativement moindre valeur ajoutée :
C’est-à-dire avec des ressaisies entre différents outils,
En fort volumes, répétitives
Avec des données numérisées (accessibles via le poste de travail)
Et même si une étape préalable de numérisation des données est nécessaire de nombreux outils RPA incluent aussi des services de capture / numérisation des données dites « non structurées (scan de facture, images, etc.)
…Sans rien modifier des systèmes en place. Comme le dit l’éditeur Contextor, le terrain de jeu du RPA, c’est la surface de l’existant : il clique à votre place. Vous ne modifiez pas les systèmes, vous ne développez pas de gateway d’un système A à un système B, l’outil RPA se charge de « faire la lecture et la recopie des données entre les systèmes ». Vous pouvez donc fonctionner de manière non intrusive, voire temporaire. (Gare au projet de mise en œuvre toutefois, qui peut représenter quelques mois).
Shared Services Centers
Les centres de services partagés, ou Shared Services Centers (SSC) ont été créés pour répondre à des besoins d’une manière mutualisée, en traitant des volumes suffisants pour pouvoir faire des économies d’échelle, et bien souvent, en étant installés dans des pays où la main d’œuvre est bon marché. Parfois aussi, les SSC ont vocation à garantir une expertise pour différents « clients » de l’entreprise – on parle plutôt dans ce cas de centres d’excellence, ou Centres Of Excellence (COE). C’est un cas un peu différent des SSC. Les COE répondent aussi à une problématique de compétence et ne sont pas forcément localisés dans un pays offshore. Sans autre précision, les SSC et les COE sont des entités internes des entreprises. Par opposition aux SSC et COE dits Externalisés, c’est-à-dire délivrés par un prestataire, le plus souvent dans ses propres locaux. La comparaison entre interne et externe présente des différences majeures, qui correspondent à des choix stratégiques différents sur la gestion des connaissances et compétences, les aspects CAPEX/OPEX, etc. Mais outre ces différences, les SSC (plutôt que les COE), qu’ils soient internes ou externes, ont sensiblement la même vocation principale : relocaliser à moindre coût.
RPA vs SSC ?
Nous venons de voir que du point de vue des services concernés, une comparaison des « approches » RPA et SSC peut avoir du sens : lorsque appliquées à des travaux répétitifs, en volumes importants, avec une valeur ajoutée limitée, utilisant le poste de travail. Cette comparaison est donc l’objet de cet article.
Mais ces deux approches peuvent aussi être combinées l’une à l’autre. Et la comparaison doit aller au-delà des gains, car les contraintes et les prérequis ne sont pas toujours les mêmes. Se pose également dans les deux cas la question de l’existant : la performance des processus, la culture, le social (le rôle des IRP, etc.), et la hauteur de la marche à franchir pour mettre en place une solution ou l’autre.
…alors, la RPA et les shared services (ou services externalisés) : concurrents ou complémentaires ?
1. Choisir entre 2 solutions concurrentes
J’ai pu voir chez un client un cas où l’offre disponible en matière d’automatisation a conduit celui-ci à renoncer à un projet « SSC » alors qu’il s’apprêtait pourtant à le présenter en comité d’entreprise. Cette situation vécue m’avait enseigné deux choses : (1) automatiser chez soi est moins douloureux (et moins visible) que de relocaliser/ externaliser, mais (2) les « savings » potentiels ne sont pas forcément meilleurs avec l’automatisation, car le périmètre automatisable est inférieur au périmètre transférable en SSC.
Voici un résumé des avantages et des inconvénients des 2 options :
2. Viser la complémentarité des deux approches
Les SSC existent déjà dans nombre d’entreprises. Les services délivrés en SSC sont bien souvent éligibles pour partie à l’automatisation.
« Ce qui est automatisable le sera tôt ou tard »
L’automatisation ne présente pas en soi un véritable avantage concurrentiel. Mais appliquée aux SSC, elle permet d’améliorer l’efficience, et donc la performance de l’entreprise. Il serait parfois préférable d’automatiser « nativement » c’est-à-dire sans recourir à l’artifice de la RPA, mais cela implique des transformations des process et des systèmes, qui peuvent être finalement trop longues et coûteuses. Pour améliorer des process en partie relocalisés, il est plus simple d’améliorer de part et d’autre de l’interface entre le client et son SSC. Côté SSC il est déjà possible « de faire la même chose » mais mieux, plus vite et moins cher, pour libérer et/ou pour redéployer des ressources : c’est exactement la valeur ajoutée des outils de type RPA.
Automatiser dans les SSC offre deux possibilités :
Soit, faire le même travail dans le SSC, avec moins de personnes
Soit, redéployer des ressources du SSC, en transférant davantage de travail depuis les entités clientes
La deuxième option, lorsque possible, est la plus intéressante économiquement. Car il est plus avantageux de gagner sur une ressource en entité cliente que sur une ressource dans le SSC (simple effet de levier lié aux différences de rémunération).
Mais cette option nécessite de pouvoir faire évoluer les missions des personnels dans les SSC. Par exemple, de transformer le SSC en COE, ce qui implique :
d’avoir des profils évolutifs : une exigence au moment du recrutement qui implique un coût de personnel moins attractif
de manager le centre de service d’une manière adaptée, c’est-à-dire, pas seulement comme une centre industriel. Les managers doivent favoriser la valeur ajoutée, l’amélioration continue et l’initiative, et mettre en place une vraie dynamique de collaboration avec les entités « clientes ». Les outils collaboratifs et certaines méthodes de management (Agile) y contribuent
3. …vers quelle conclusion ?
A court ou à moyen terme, il faut analyser chaque situation séparément avant de pouvoir conclure. Lorsque les Shared Services existent déjà, la complémentarité des deux approches est intéressante. L’automatisation dans un pays à bas coûts peut apporter un gain de productivité très important, sans avoir forcément à gérer la délicate question sociale propre aux pays occidentaux.
Pour l’automatisation comme pour shared services, maîtriser la mise en œuvre
La mise en place des shared services est un projet complexe, mais c’est un sujet plus mature que l’automatisation, sur lequel l’article ne s’attardera pas.
Pour pouvoir bénéficier des améliorations de la productivité d’un SSC grâce à l’automatisation, a fortiori quand il est externalisé, il faut le prévoir dans le cadre « contractuel » et dans la gouvernance.
Aujourd’hui les contingents de ressources offshore sont nombreux chez les leaders du marché. Il faut comprendre qu’un fournisseur ne souhaite pas a priori réduire ses effectifs car cela revient à réduire son revenu et à lui poser des problèmes de sous-emploi. Les critères de choix devraient donc comprendre :
Choisir des fournisseurs qui sont matures vis-à-vis des projets RPA pour leurs clients et qui implémentent déjà l’automatisation dans leurs propres opérations,
avec des outils du marché, comme par ex. Contextor, Automation Anywhere, …
…ou avec leurs propres outils, comme par exemple la suite Assist Edge d’Infosys
Mettre en place des engagements évolutifs dans le temps sur les délais et sur la productivité
Prévoir le coût des projets et de maintenance de la RPA
Définir un modèle de rémunération qui encourage l’automatisation. Par exemple, via un système de partage attractif des gains induits.
Souvent, les entreprises ne disposent pas des compétences requises en interne pour mener des projets d’automatisation. Certains cabinets de conseil présentent une réelle expertise indépendante des éditeurs et des intégrateurs. Cette indépendance nous parait indispensable.
La première étape d’une démarche d’automatisation est constituée de l’audit des processus, nécessaire pour caractériser les meilleures opportunités, c’est-à-dire, les processus métiers et supports à la fois suffisamment simples et non ambigus, et ayant le potentiel d’amélioration le plus effectif et le plus rentable. Cet audit tient également compte du marché des éditeurs. En effet, certaines opportunités, comme par exemple, certains processus comptables, correspondent à des solutions marché éprouvées, alors que dans d’autres cas, une analyse plus fine est nécessaire.
Nous recommandons de faire une étude d’impact pour éclairer les décideurs qui intègreront dans leurs choix, outre les gains induits, les coûts générés, et les conséquences RH et organisationnelles de l’automatisation.
La planification de la mise en œuvre pourra résulter d’une approche projet « classique », comprenant par exemple un appel d’offres pour choisir le meilleur éditeur, ou d’une approche plus agile, commençant par exemple avec un ou plusieurs pilotes dans des régions à moindre impact, avec quelques éditeurs pré sélectionnés. Il peut être tentant de mener un pilote dans un SSC localisé dans un pays à bas coût. L’impact social y est souvent moindre. Mais le niveau de maitrise que vous aurez sur le projet risque de l’être aussi. Le choix du pilote ne sera pas anodin, car vous voulez produire du résultat et convaincre les stakeholders de l’entreprise avant un déploiement plus large. Et en cas d’échec, il faudra pouvoir rebondir (choisir un autre éditeur, un autre processus…).
Enfin, la mise en œuvre est plutôt celle d’un projet d’organisation avec une dimension technique, et non l’inverse. La réussite reposera également sur la maintenance du service sur la durée, c’est-à-dire, intégrant par exemple, la maintenance des automates, et permettant de capitaliser (via un dispositif dédié pérenne) et de monter en maturité.
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.
Sourcing & Architecture : 2 stratégies complémentaires au service de la performance
Nombreux sont les clients qui, à l’occasion de leurs projets d’externalisation, découvrent leur patrimoine applicatif. Celui-ci constitue pourtant un des éléments de calcul des coûts associés aux contrats de prestations négociés avec les fournisseurs. Comment tirer parti des opérations d’externalisation pour rationaliser son patrimoine applicatif ? et réciproquement… Entretien avec Franck Gerbier et Jean-Michel Goubert, directeurs associés de Rhapsodies Conseil.
Qu’est-ce qu’une stratégie de Sourcing efficace ?
Dans un marché fait principalement de renouvellement de contrats, nombre d’entreprises externalisent sans objectifs clairement définis ni partagés et n’ont pas toujours une vision claire de la réalité de leurs coûts.
Au-delà de la problématique unique des coûts, il est nécessaire d’identifier l’ensemble des objectifs poursuivis pour définir une stratégie de sourcing efficace (rationalisation des prestataires, recentrage sur un coeur de métier, accélération de la montée en compétences vers de nouvelles technologies, évolution vers le cloud, etc.) Il est aussi indispensable d’établir un état des lieux de la situation selon différents axes ; qualitatif, technique, financier et organisationnel. C’est la parfaite connaissance de la situation existante et la définition précise de la cible à atteindre qui permettront de définir la stratégie de sourcing gagnante.
Découvrez l’intégralité de l’entretien Sourcing & Architecture paru dans dans le dossier spécial « Conseil & Finance » de la revue de Polytechnique La Jaune et la Rouge.
