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.
Nous avons résumé dans cette infographie les éléments clés à retenir !
Dans le cadre de missions d’organisation des activités de Run, je m’intéresse souvent – au delà du modèle opérationnel – aux différents domaines de gouvernance à structurer.
Dans ce contexte, la gestion de la relation aux métiers (business relationship management) est un besoin important qui revient régulièrement et peut se définir comme le processus responsable de maintenir une relation positive avec les métiers, en identifiant au préalable leurs besoins et en garantissant la fourniture de service sur la base d’un catalogue de services approprié. Sur ces bases, le processus de gestion de la relation métier s’incarne généralement via le déploiement d’un ou plusieurs gestionnaires de relation métier (GRM). J’ai pu noter un certain nombre de prérequis qui doivent être pris en compte afin de réussir la mise en œuvre d’une telle fonction. J’en partage quelques uns dans ce billet.
Confiance des métiers dans le GRM et dans le dispositif de fourniture de services
Pour réussir la mise en oeuvre d’un GRM avec les métiers, il est impératif que les métiers
acceptent le principe de travailler avec un GRM
aient confiance dans le dispositif de fourniture de services de la DSI.
Ainsi, un GRM efficace établira non seulement de bonnes relations avec les métiers, mais véhiculera aussi l’image du dispositif de fourniture de services. En conséquence, si les métiers font confiance au GRM, ils auront également confiance dans le dispositif de fourniture de services. Les métiers comprennent en effet assez vite que le GRM dépend dans une certaine mesure du dispositif de services, mais doivent être également être convaincus que le GRM a les intérêts du métier à cœur.
Finalement, le GRM souhaitant asseoir sa crédibilité sur la base de la confiance des métiers doit être en mesure de démontrer la valeur ajoutée concrète apportée, et non être vu comme une surcouche du dispositif de fourniture des services.
Collaboration du GRM avec le dispositif de fourniture de services
Le rôle du GRM n’est pas seulement d’être l’interface avec le métier. En effet, le GRM faisant partie intégrante de l’organisation de services de la DSI, doit certes à ce titre regarder vers l’extérieur en direction de ses clients métiers, mais également s’engager auprès de ses collègues du dispositif de fourniture des services afin de s’assurer que les métiers obtiennent le meilleur service possible.
Dans ce rôle essentiel, les compétences et attitudes indispensables au développement de la relation avec les métiers seront également déterminantes pour établir des relations au sein de l’organisation du dispositif de fourniture de services.
Faire partie de l’organisation de services de la DSI ne garantit pas en effet au GRM que ses collègues du dispositif de fourniture de services répondront toujours comme il le souhaiterait. L’une des raisons est que plus le GRM prendra son rôle à cœur et plus il est possible qu’il soit considéré par les collaborateurs du dispositif de services comme faisant partie intégrante de l’organisation métier (et donc potentiellement vu comme « passé à l’ennemi »).
Si cela se produit, le GRM pourra faire face à des tensions continuelles dans ses relations avec les membres du dispositif de fourniture de services.
Clarifier les rôles et responsabilités ainsi que les interfaces
La mise en œuvre d’un nouveau rôle de GRM se créera inévitablement à partir de parties de rôles existants au sein de la DSI. La création du rôle peut signifier que les canaux de communication déjà actifs entre les métiers et les différents acteurs de la DSI soient interceptés par le GRM et que les tâches qui ont déjà été la responsabilité d’autres rôles deviennent la responsabilité du GRM.
Ces changements créent généralement des difficultés : les parties prenantes sont naturellement réticentes à rompre les relations de travail et à perdre des responsabilités importantes pour eux. Ainsi, la capacité du GRM à nouer des relations fructueuses avec les parties prenantes de la DSI peut être tout aussi importante que l’établissement de relations avec les métiers.
Inévitablement, il pourra donc y avoir de nombreuses interfaces et recouvrement avec des rôles couverts par d’autres fonctions et processus. C’est pourquoi une attention toute particulière devra être apportée à la définition des rôles et responsabilités des GRM ainsi qu’aux interactions avec les différentes parties prenantes sous peine de courir un risque de confusion / de manque de clarté et parfois de conflits.
Distinguer activités de Service Management centrées sur l’IT de celles centrées sur les services métiers
La tentation peut être forte de combiner les rôles de GRM avec d’autres rôles de Service Management plus centrés sur des services IT spécifiques (gestion des changements, gestion des problèmes, …). Bien que cela puisse contribuer à optimiser les coûts et simplifier les interfaces, force est de constater que les inconvénients ne sont pas neutres.
En effet, si le GRM s’enlise dans la performance spécifique de certains services IT, il lui sera plus difficile de superviser globalement la relation aux métiers et moins simple de s’engager auprès des métiers au bon niveau pour une gestion pertinente et efficace de la relation.
Pour conclure, et étant donné qu’il est très rare d’avoir des métiers prêts à payer directement pour les services du GRM, il est indispensable d’optimiser le ratio coûts-valeur de ces activités en ne limitant pas la performance attendue à la seule mesure de la satisfaction des métiers.
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.
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é.
