Vous avez peut-être souvent entendu ces mots « Data is an Asset ». Mais la personne qui les prononce va rarement au bout de l’idée. Et pour cause, l’exercice est plus complexe qu’il n’en a l’air. Cet article a pour ambition d’éclairer le domaine et, pour cela, procédons par étape :
1 – Qu’est-ce qu’un Asset ?
Nous n’allons pas l’inventer, il existe une très bonne définition sur ce site : https://www.investopedia.com/ask/answers/12/what-is-an-asset.asp)
« An asset is anything of value that can be converted into cash. Assets are owned by individuals, businesses and governments »
« Un asset est quelque chose qui peut être converti en monnaie sonnante et trébuchante ».
Avec une maison, cela marche bien en effet. Une expertise suffira à vous donner une bonne idée de la valeur euro de votre maison. Mais pour vos données, ça ne paraît pas si simple.
Le défi aujourd’hui est d’être en mesure de valoriser une donnée, ce qui signifie :
Pouvoir par exemple très formellement comparer deux actifs Data entre eux, deux jeux de données (par exemple sur la base de critères bien définis)
Mettre une valeur « euro » sur un jeu de données (monétisation, prise en compte de l’actif Data sur des opérations d’acquisition / fusion, etc.)
Gérer nos données comme des Actifs, pour maintenir ou développer leur valeur dans le temps
Sur ce dernier point, faisons l’exercice rapide ensemble. Prenons un processus d’asset management standard, appliquons-le à la donnée.
2 – Appliquons un Processus d’Asset management à la Data
Alors allons y ! Appliquons ce processus sur les données pour voir si elle peut être gérée comme un Asset ?
« Inventory » :Inventorier les assets Data. Jusque-là tout va bien.
« Asset Condition Assessment » :Évaluer l’état des biens: Est-ce que la donnée est de qualité, est-ce qu’elle il y a souvent des erreurs qui apparaissent ? Comment les gère-t-on ?
« Determine residual Life / Decay curve » : Il s’agit d’évaluer l’évolution potentielle de différents critères de valeur dans le temps. Par exemple est-ce que la donnée risque de perdre en rareté ? Les usages vont-ils être moins importants ? etc. En général cette notion porte sur le vieillissement d’un bien physique :
« Valuation » : Pour valoriser la donnée, on sent qu’il nous faut poser clairement un cadre de valorisation sur base d’un ensemble de critères. Au même titre que l’expert par exemple en Asset commercial connaît parfaitement les critères qui permettent da valoriser un commerce (surface du commerce, chiffre d’affaire, situation géographique, etc…). Notre conviction est qu’il faut aujourd’hui développer ce cadre pour l’actif « Data ».
« Life Cycle Costing » : C’est le processus qui permet d’identifier tous les coûts impliqués dans le cycle de vie de l’actif (coût d’une erreur, coût de la réparation / correction, coût de la perte de production éventuelle, coût de la maintenance corrective, ….)
« Determine replacements» : Est-ce qu’il faut revoir la manière de gérer certains asset Data ? Faut-il en abandonner/purger certains, non rentables ?
« Set target LOS » : Quel est le niveau de service attendu sur chaque asset Data ? A quels besoins faut-il répondre pour que l’asset ait de la valeur, soit viable ? Quels critères de valorisation veut-on améliorer ? (rareté, qualité, …)
« Assign BRE rating » = Business Risk Evaluation : Et quels sont les risques ? (GDPR, perte de données, …) : « Comment est-ce que des problèmes / incidents peuvent apparaître ? Quelle probabilité d’apparition ? Qu’est cela coûterait si le problème apparaissait ? Quelles en seraient les différentes conséquences ? »
« Determine Appropriate Maintenance » : Si l’on veut maintenir la qualité d’une donnée par exemple, par exemple 3 stratégies de maintenance existent dans le monde physique, elles sont applicables à l’actif Data (Use Base Maintenance : revue à une fréquence donnée, Fail based maintenance : correction sur incident/erreur, Condition Bases Maintenance : Maintenance plus préventive)
« Determine Appropriate CIP » (Capital Investment Program) : Initier (ou mettre à jour) notre programme d’investissement (Projet d’extension du capital d’assets Data, de renouvellement/modification de la gestion de certains Assets, mise en place de nouveaux processus de maintenance = gouvernance…)
« Fund your strategy » : On obtient le financement pour tout cela
« Build the Asset Management Plan » : Enfin on construit, ou on met à jour notre plan de gestion et de valorisation de nos assets Data
La méthode a l’air adaptée. Mais elle soulève des questions clés, auxquelles il va nous falloir répondre, notamment concernant les critères de valorisation. A titre d’exemple, le CIGREF a travaillé sur un cadre d’appréciation de la valeur économique des projets de transformation numérique. Il est intéressant d’avoir une approche comparable pour l’actif « Data ».
3 – Et après ?
Nous venons de voir que la data est effectivement un actif, d’un type bien particulier. Pour aller plus loin, il va falloir identifier des critères objectifs de valorisation des données, et faire des usages de ces données un vecteur clé de sa valorisation.
Dans cet optique, nous pensons qu’un cadre méthodologique de valorisation des données est nécessaire.
Rhapsodies Conseil construit une approche méthodologique pour mesurer la valeur des données, en mettant les usages métiers des données au cœur de la méthodologie, approche que nous vous invitons à découvrir prochainement. En parallèle, nous vous recommandons les travaux initiés sur ces sujets par Doug Laney pour Gartner Inc., en particulier à travers son ouvrage « Infonomics » aux éditions Routledge.
Les nouvelles réformes engagées sous l’appellation « finalisation de Bâle III », que l’industrie financière nomme déjà « Bâle IV », soumettent les méthodes de calcul des RWA, notamment en ce qui concerne le risque de crédit, à d’importantes modifications.
En effet, en matière de ratio de capital, les apports de Bâle III, applicable depuis 2013, ont porté sur son numérateur (renforcement quantitatif et qualitatif des fonds propres), alors que très peu de modifications ont été apportées à son dénominateur (RWA). L’actuelle méthode de calcul de ce dernier est principalement héritée de Bâle II (2004).
Pourquoi la méthode standard ?
Depuis décembre 2017, le Comité affiche une volonté de faire évoluer le traitement des RWA. Pour ce faire, il prévoit, entre autres, une profonde refonte de la méthode standard du risque de crédit.
L’importance de cette mesure tient avant tout à l’importance de la méthode standard elle-même dans l’usage bancaire. En France, en Europe et à l’échelle mondiale[1], cette méthode est la plus utilisée. Par conséquent, la plupart des acteurs bancaires sont concernés par la mise en œuvre de la nouvelle méthode et devraient s’y préparer.
Les nouveautés
Le texte du Comité de Bâle de Décembre 2017 fixe, avec un important niveau de détail, les nouvelles réformes de la méthode standard. Sans vouloir restituer ici toute la complexité du dispositif, nous abordons ses deux apports les plus novateurs, à savoir :
Même si ces deux éléments ont pour motivation commune le renforcement de la sensibilité au risque, la démarche du comité soulève quelques interrogations sur l’atteinte de l’objectif.
1- Plus de granularité pour plus de sensibilité au risque ?
Le manque de sensibilité au risque est l’une des critiques adressées par le Comité de Bâle lui-même au dispositif actuel. L’objectif des nouvelles réformes est justement de surmonter cette faiblesse.
Tenir compte de la sensibilité au risque sans pour autant complexifier la méthode standard, voilà le défi auquel le Comité a fait face. Pour le relever, il a choisi l’option de la granularité. Concrètement, le Comité estime que la méthode actuelle (héritée de Bâle II) n’associe pas un nombre suffisant de pondérations à certaines expositions, ce qui réduit la sensibilité au risque. La nouvelle méthode, quant à elle, augmente le nombre de pondérations pour beaucoup d’expositions (clientèle de détail, immobilier résidentiel, immobilier commercial…).
Si nous prenons le cas de la clientèle de détail (hors immobilier) nous constatons un niveau de granularité nettement plus important dans la nouvelle réforme (figure 1.2) comparée à la méthode actuelle (figure 1.1) :
Figure 1.1 : Méthode actuelle
Expositions sur la clientèle de détail (hors immobilier)
Pondération
75%
Source : BRI, 2006
Figure 1.2 :
Expositions sur la clientèle de détail (hors immobilier)
Clientèle de détail réglementaire (non renouvelable)
Clientèle de détail réglementaire (renouvelable)
Autres expositions sur la clientèle de détail
« Transactors »
« Revolvers »
Pondération
75%
45%
75%
100%
Source : BRI, 2017
Jusque-là, la granularité évolue bien vers un renforcement de la sensibilité au risque. Cependant, le secteur de l’immobilier, fortement mis en avant par le Comité, soulève question : le Comité introduit le ratio LTV[3] comme critère de pondération. Ce choix est questionnable étant donné son caractère procyclique qui va à l’opposé du renforcement de la sensibilité au risque recherché par le Comité.
Il semble que les leçons de la crise de 2007 n’ont pas été entièrement tirées. Il ne faudrait pas oublier que le marché immobilier américain se trouvait au cœur de cette crise et que le financement d’une partie de ce marché reposait davantage sur la valeur des biens acquis que sur la capacité de leurs acquéreurs à rembourser leurs prêts. Le LTV renforce cette même logique. Quelle est alors la cohérence d’introduire un dispositif comme le LTV dans un cadre prudentiel visant le renforcement de la sensibilité au risque ?
2 – SCRA, autorisation explicite à moins de granularité !
Cette approche est prévue pour les juridictions n’autorisant pas le recours aux notations externes à des fins réglementaires (notamment les Etats-Unis jusqu’à présent) et pour les expositions non notées dans les juridictions permettant le recours aux notations externes. A la différence de l’approche ECRA[4], dont la granularité a bien été renforcée, l’approche SCRA est composée de trois tranches de risque seulement : A, B et C. La figure 3 illustre cela dans le cas des expositions sur les banques.
Figure 2 : Pondération des risques afférents aux banques (ECRA vs SCRA)
Figure 2.1 : Approche externe de l’évaluation du risque de crédit (ECRA)
Note externe de la contrepartie
AAA à AA-
A+ à A-
BBB+ à BBB-
BB+ à B6
Inférieur à B-
Coefficient standard
20%
30%
50%
100%
150%
Pondération des risques afférents aux expositions à court terme
20%
20%
20%
50%
150%
Figure 2.2 : Approche standard de l’évaluation du risque de crédit (SCRA)
Evaluation du risque de crédit de la contrepartie
Tranche A
Tranche B
Tranche C
Coefficient standard
40%
75%
150%
Pondération des risques afférents aux expositions à court terme
20%
50%
150%
En attendant Bâle V ?
Dans le cadre de négociations internationales ayant pour but de bâtir un consensus mondial sur la régulation du système bancaire, il est concevable que les parties fassent des concessions. Néanmoins, les concessions faites dans la version actuelle (probablement finale) de Bâle IV limitent la portée de l’objectif même de la réforme, à savoir le renforcement de la cohérence et de la crédibilité de la mesure des RWA, pour au moins deux raisons :
Le renforcement de la sensibilité au risque afin de rétablir la crédibilité du calcul des RWA et l’introduction pour la première fois du LTV susceptible de décrédibiliser le dispositif.
L’introduction de davantage de granularité avec l’approche ECRA et dans le même temps l’admission du recours à l’approche SCRA qui est moins granulaire !
Ces interrogations seront-elles soulevées lors de la transposition des recommandations du Comité dans le droit européen, afin d’éviter un nouvel accord, probablement Bâle V ? Ou seront-elles ajournées aux prochaines négociations ?
[1] Comité de Bâle sur le contrôle bancaire : Note récapitulative sur les réformes de Bâle III, Décembre 2017. [2] Standardised Credit Risk Assessment Approach. [3] Loan to Value. Ce ratio est égal à : montant de l’emprunt/valeur du bien. [4] External Credit Risk Assessment Approach.
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.
25 juin 2025
Pilotage & Performance Opérationnelle et Contractuelle
La réforme initiée du cadre prudentiel de Bâle provoque déjà des tensions, entre régulateurs et institutions financières, sur une question en apparence de forme : comment la nommer ?
Les régulateurs parlent d’une « finalisation de Bâle III », alors que beaucoup d’institutions financières y voient déjà « Bâle IV »…
Derrière cet antagonisme de vocabulaire, quels sont les enjeux ? Quelles positions/intérêts s’affrontent ?
En effet, ce débat révèle la préoccupation quant à la continuité ou la rupture du cadre prudentiel en vigueur (Bâle III). L’enjeu pour les institutions financières étant de savoir si les efforts consentis depuis 2010 ne seront pas réduits à néant par l’instauration d’un nouveau cadre prudentiel radicalement différent. Pour les régulateurs, l’objectif est de rassurer le marché sur le maintien du cap actuel.
Un air de déjà-vu !
Ce débat rappelle la longue hésitation au tournant de l’année 2010 entre « réforme de Bâle II », « Bâle 2.5 » ou « Bâle III ». La suite est connue de tous, finalement Bâle III a été bien différent de Bâle II : composition (aspect qualitatif) et niveau (aspect quantitatif, différents coussins compris) des fonds propres, ratios de liquidité…
L’histoire se répéterait-elle ?
Quelques indices
Il est vrai que les nouvelles réformes ne sont pas encore dans le droit positif. Toutefois, le comité de Bâle a publié, à la suite des consultations menées auprès des parties prenantes, un document[1] fixant les principales orientations de la réforme. Il est fort probable que les instances européennes retiennent l’essentiel de ce document, notamment :
La refonte de l’approche standard du risque de crédit: il s’agit de l’épicentre de la réforme. Celle-ci est motivée par une volonté d’accroissement de la granularité des expositions, en vue du renforcement de la sensibilité au risque.
La révision de l’approche de notation interne: les banques ne pourront plus utiliser l’approche interne avancée pour une part importante de leurs contreparties ; elles devront se limiter à l’approche fondation[2]. Le Comité introduit également des floors concernant la perte en cas de défaut et/ou la probabilité de défaut.
La mise en place d’un nouvel « output floor »: il complète les deux mesures précédentes en limitant les avantages tirés par les banques qui utilisent les modèles internes. Concrètement, les RWA calculés par les modèles internes ne pourront être inférieurs à 72,5% de ceux calculés par les approches standards.
Le ratio de levier : la nouvelle réforme introduit un volant supplémentaire au ratio de levier (constitué des fonds propres Tier 1) applicable aux établissements bancaires systémiques mondiaux. Il est fixé à 50% des exigences supérieures de capacité additionnelle d’absorption des pertes.
La revue de la méthode de calcul de la CVA: l’objectif évoqué par le Comité est le renforcement de la sensibilité, de la solidité et de la cohérence de la part des fonds propres qui protège les banques contre les pertes liées aux prix de marché des instruments dérivés, dans le cas d’une dégradation de la solvabilité des contreparties.
L’unification de la méthode de calcul du risque opérationnel: le Comité vise une rationalisation du traitement de ce risque[3], en remplaçant les quatre approches existantes par une seule approche standard. Celle-ci tient compte de l’historique de pertes internes sur 10 ans et facilite la comparabilité des RWA d’une banque à l’autre, en supprimant la possibilité de recours à des approches multiples.
Ces mesures peuvent engendrer deux types d’impacts :
L’alourdissement des exigences en fonds propres: les nouvelles réformes entraineront une hausse des besoins en fonds propres de beaucoup de banques, essentiellement en Europe. Ceci se traduira par des coûts supplémentaires, ou de manière équivalente une baisse de la rentabilité des institutions concernées. Au-delà, le risque peut s’étendre à des effets macroéconomiques négatifs, à une incitation des institutions financières à revoir leurs business modèles ou aux deux en même temps.
Des pertes sèches sur des investissements précédents: outre les coûts futurs précédemment décrits, les grandes institutions financières subiront des pertes sèches relatives à une partie de leur infrastructure opérationnelle développée et mise en place pendant plusieurs années. Ces pertes sont dues à leur incapacité future à utiliser des systèmes qu’elles ont développés pour la méthode interne (notamment l’approche avancée) et le savoir-faire/capital humain qui lui est associé. Les répercussions de ces changements ne se limitent pas à l’aspect financier mais risquent de produire des effets sur les parts de marché et rapports de force entre les différentes institutions au sein des économies et entre elles (notamment entre Europe et Etats-Unis).
Alors, « finalisation de Bâle III » ou « Bâle IV » ?
Regardons juste le calendrier de mise en application des nouvelles réformes (voir Illustration 1) : il s’étend jusqu’en 2022 et même 2027 pour les dispositifs transitoires ; 4 ans pour un simple recalibrage du modèle ? Pour rappel, le passage de Bâle II à Bâle III avait duré moins longtemps (de juillet 2009 à janvier 2013)…
Dans tous les cas et quelle que soit sa dénomination, cette réforme a été entérinée dans ses principales orientations par les gouverneurs des banques centrales des pays membres de la BRI, les banques doivent se préparer à sa mise en place…
[1] Comité de Bâle sur le contrôle bancaire, Bâle III : finalisation des réformes de l’après-crise, décembre 2017. [2] La méthode interne de notation du risque de crédit se compose d’une approche fondation et d’une approche avancée. [3] Comité de Bâle sur le contrôle bancaire : Finalisation de Bâle III en bref, document non daté.
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é.
Plusieurs questions se posent aujourd’hui, alors que de nombreux environnements Hadoop sont en production depuis quelques mois / années :
Le Data Lake est-il aussi utile/utilisé que prévu ? et ne l’utilise-t-on pas, à défaut d’avoir trouvé un usage pertinent, à des fins qui n’étaient pas prévues au départ ( exemple courant … GPP : Gros Passe Plat ou encore EDDC : Extracteur De Données Centralisé … )
Comment structurer les données dans le Data Lake ? Si c’est pour mettre un Hadoop chez soi et structurer sa donnée dans quelques parquets et des tables hive, mais avec la même logique que nos bonnes vieilles tables SQL normalisés 3NF, à part de dire « Youhou, hadoop on l’a fait, on en a une belle maintenant ! » Quel intérêt ? C’est comme s’acheter une console Switch en ne la décrochant jamais de son socle (pardon pour l’image pour ceux qui ne connaîtraient pas la dernière console de Nintendo…).
Comment on rend la valeur de l’outil palpable par l’utilisateur final ? Que ce soit pour du reporting quasi temps-réel / journalier / mensuel, de la Data Viz ou de l’analyse de données avancée (un super Random Forest, un neural Network au top en production…) qu’est ce qui fera la différence pour l’utilisateur final ? Par rapport à ce qu’on lui donnait déjà avant…
J’essaie de donner des éléments de réponses ci-dessous et ce n’est que mon humble avis. Si vous avez vos expériences à partager n’hésitez pas.
1 – Le data lake est-il aussi utile/utilisé que prévu ?
Les environnements distribués naissent un peu partout au moment ou j’écris ces lignes. 2 cas caractéristiques existent qui peuvent être problématiques :
Cas 1 – Etre gourmand, trop gourmand : De nombreuses entreprises se sont ruées vers la tendance sans même vraiment avoir eu une réflexion de fond sur la valeur que devraient leur apporter ces nouvelles capacités dans leur contexte, elles se retrouvent aujourd’hui avec des téras stockées qui ne leur apportent pas autant qu’elles l’auraient espérées. On a voulu en mettre beaucoup, on n’a pas pris le temps de travailler sur la description de ce qu’on y a mis (meta data), et peu de gens comprennent vraiment ce qu’on peut y trouver et si c’est vraiment fiable.
Leur Data Lake devient petit à petit un passe-plat facilitant préparations et fournitures de certaines données bien spécialisées, même sur des volumes qui ne justifient en rien son usage, opérant quelques croisements ici et là entre sources originales qui n’étaient pas avant dans le même environnement technique. Elles font face à des bi-modes Hadoop VS Entrepôt Oracle/SAS (pour ne donner qu’un exemple). Certaines données sont dans les deux types de système et l’utilisateur Analyste ne sait pas vraiment lequel utiliser. Alors les Data Scientist, statisticiens – vieux de la vieille continuent à bosser dans SAS parce qu’ils n’ont pas le temps d’apprendre Python, et les petits jeunes qui sortent d’écoles pensent pouvoir changer le monde avec leur modèle de churn codé en Python / Spark mais qui a en réalité déjà été implémenté il y a 10 ans par un Data Miner expert SAS avec une méthode et des résultats similaires… Ce n’est qu’un rien caricaturale.
Pour prouver sa valeur et justifier son coût, ce Data Lake là va devoir se recentrer sur des usages clés porteur de valeur (et de gain euros…) pour l’entreprise, qui justifie son existence, ou mourir de désillusion ou rester un gros GPP (gros passe plat…).
Cas 2 – Etre timide, trop timide : D’autres entreprises plus prudentes, fonctionnent en petites itérations, à base de POC Big Data sous Microsoft AZURE, AWS et autres google cloud, en sélectionnant des cas d’usages qui justifient l’utilisation de telles plateformes. Parfois, le risque est d’être dans l’excès inverse du premier cas, en priorisant trop et en ne montrant rien.
Trouver 3 usages coeur de métier pour commencer est une excellente chose, mais les cas d’usages doivent être assez complets pour montrer l’étendue des possibilités que peut apporter un environnement comme hadoop et tous ses petits (la multitude d’outils d’intégrations, d’analyses, de traitements qui se basent sur hadoop).
Toutefois, faire un vrai POC métier est la clé pour les entreprises qui en sont à ce stade, montrer que Hadoop traite très très très vite un très très très gros volume de données, n’apporte rien au métier. Faire une démo d’un outil métier qui illustre un vrai cas métier en mettant en valeur :
La performance ressentie par l’utilisateur (des jolis diagrammes qui s’affiche rapidement quand l’utilisateur clique sur la carte 🙂 « C’est beau, ca va vite, c’est utile ! ouaouh ! »
La valeur/connaissance apportée en plus en allant au bout de l’usage : On sait détecter un problème, une fraude, etc…et ça génère une alerte en temps réel dans l’outil de l’opérateur qui lui recommande l’action à faire ! Ouaouh merci c’est ce qui fallait ! c’était possible alors ? dingue…)
Dans tous les cas, encore une fois allez au bout de l’usage ! On a tendance à s’arrêter juste un peu avant ce qu’il faudrait (par manque de temps, de connaissance métier, de courage). Ne faites pas un POC IT, ayez le courage de faire un vrai POC business pas juste à moitié parce que vous ne connaissez pas assez le métier, allez jusqu’au bout de la démonstration, jusqu’à la jolie petite interface interactive qui fera la différence. Sinon vous n’aurez pas votre Waouh. Faites collaborer les Data Scientist avec les développeurs des appli métiers pour avoir un vrai résultat.
Si vous ne faites pas cela, les gens comprendrons peut être la théorie « D’accord vous faites une grosse boîte où vous mettez toutes les données et puis ça tourne vite comme une machine à laver, c’est ça ? 🙂 ».
Non ! vous voulez un : « Ah, mon opérateur ne va plus devoir scruter toutes les logs à la mano pour essayer de trouver les problèmes, et je vais multiplier par 10 ma productivité donc…En fait…Ai-je toujours besoin d’un opérateur ? » OUI, là on est bon.
2 – Quelques principes pour structurer le data lake
Ne traitez pas votre Data Lake comme une poubelle à données qu’on recyclera peut être un jour en cas de besoin (le fameux « on prend, on sait jamais » du Data Lake, anti GDPR par dessus le marché). Mais traitez le bien comme un lac nourrissant, abreuvant et vital ! Moins de quantité, plus de qualité.
Structurer vos Données intelligemment. Ce n’est pas parce que vous avez beaucoup de place que vous pouvez en mettre de partout et n’importe comment (que dirait votre mère franchement?). Votre Data Lake doit normalement séparer :
Les données sources (Raw Data)à l’image des données du système sources
Les données sources (Raw Data) retraitées uniquement par applications de règles purement techniques (votre format de date standard, types de données, etc…). Pas de règles métiers ! Pas ici, le but est juste de récupérer la donnée brute ! C’est d’ailleurs un sage principe que vous trouvez aussi dans la philosophie DataVault de Dan Linstedt. Vous n’appliquez des règles métier qu’au moment de la construction de vues métiers qui répondent à un usage donné. C’est aussi surtout du bon sens…Cela apportera bien plus d’agilité à l’ensemble du système.
Une Historisation structurée et intelligentedes données du Data Lake. « OH Non ! Il a dit « structuré » et « Data Lake » dans la même phrase le monsieur, c’est pas joli ». Malheureusement, beaucoup d’entreprises oublient cette étape. Mais pourquoi donc ? Suivez par exemple ici (encore désolé…) la modélisation Data Vault 2.0, je parle principalement des concepts de Hubs, Links, Satellites, ou au moins la philosophie pour cette partie. Vous pouvez éventuellement exclure de cette phase certaines données exceptionnelles (par exemple si ce sont des données vraiment peu utilisées très spécialisées, que vous savez ponctuelles comme des données externes one shot (que vous n’achetez pas tous les mois…).
!!! Attention je ne dis pas qu’il faut faire un Data Warehouse d’entreprise dans le Data Lake (je ne rentrerai pas dans ce débat). Le Data Lake doit couvrir un certain nombre de cas d’usage spécifiques, qui nécessitent d’historiser (avec agilité !) un certain périmètre de données, qui tend à grandir au fur à mesure que les nouveaux cas d’usages apparaissent.
Si vous vous arrêtez aux Raw Data et aux business View et que vous ne mettez rien entre les deux, que vous ne faites pas ce travail de structuration fonctionnelle, au bout d’un moment vous aurez un gros sac de données applicatives, et les Data Scientists et autres utilisateurs devront eux même comprendre la logique de recoupement de toutes les sources (notamment le grain, la définition des clés techniques/métiers, etc.). Faites ce travail de structuration de l’historisation (DataVault 2.0 recèle de bonnes idées).
Les données préparées pour être prêtes à l’Usage (Business View), requêtables rapidement pour usages business. C’est dans la consolidation de chacun de ces socles que les règles métiers sont appliquées ! Ici, On ramène les données au plus proche de l’usage et structurées pour l’usage en question. Et n’hésitez pas à dé-normaliser vos Business View! Vous n’êtes pas dans mysql… Plein de lignes et plein de colonnes ? C’est fait pour ! Vous pouvez même aller (dans certains cas) jusqu’à pré-calculer dans une grosse table adaptée tous les indicateurs sur toutes les combinaison de segments (dimensions), de périodes, de dates… (attention, intérêt à mesurer par rapport à votre propre usage de consommation de la donnée), mais ça se fait : « ouahou ! comme les graphiques s’affiche vite… »
Les métadonnées : leur intégration peut se faire de diverses manières, mais faites en sorte que les gens ait confiance aux données qu’ils utilisent (C’est quoi cette donnée ? d’où vient la donnée ? quelle application, quel fichier source ? Qui l’a saisie ? Quand l’a-t-on intégré au Data Lake ? quelle fréquence de mise à jour ? etc.)
3 – Comment on rend la valeur de l’outil palpable par l’utilisateur final ?
Ne croyez pas (et je suis sûr que vous ne le croyez pas) que votre Data Lake se suffit à lui même
S’il est déjà bien structuré (c’est déjà un gros avantage), il a quand même besoin de belles décorations :
je ne vous apprendrai rien : un outil de Data Viz/report qui plaît au métier (parce qu’il a été impliqué dans son choix…). Je ne ferai pas de pubs ici…
Une bonne intégration avec les systèmes opérationnels et dans les deux sens (un savoir faire sur le sujet), pas qu’en collecte. Par exemple : Lancer des simulations directement depuis mon application de gestion qui va lancer un job spark sur la business view associée qui elle va renvoyer des résultats en un rien de temps sur l’application de gestion : L’utilisateur est heureux, il ne connaît pas Hadoop ou Spark, il ne veut rien en savoir, mais vous avez amélioré significativement sa façon de travailler. C’est ce qu’il faut viser. C’est cela aller au bout de l’usage.
Un environnement complet d’analyse pour vos Data Scientist (Data Viz, développement IDE, collaboration/gestion de version, notebooks, les bonnes librairies de dev !) parce qu’ils en ont besoin. Impliquez réellement les principales personnes concernées dans ce choix !
Pour conclure, les idées clés :
Les usages doivent toujours driver la construction itérative de votre Data Lake
Ne cherchez pas à refaire un/des Data Warehouse 2 sans vraiment savoir par qui, pour quoi ce sera utilisé, ne cherchez pas à manger un maximum de données pour devenir le plus vite possible la plus grosse base de données et justifier le nom de votre équipe, BIG Data, j’imagine…
Si on vous pousse un usage auquel on pourrait répondre sur une base mysql, redirigez gentiment le destinateur…A moins que vous soyez force de proposition pour faire évoluer son usage pour justifier l’utilisation d’une telle plateforme.
Si vous êtes assez matures, ne voyez plus votre Data Lake comme un Lab collecteur qui se suffit à lui-même, si vous allez au bout des usages, vous serez obligés de l’intégrer avec des applications métier (vous savez, l’utilisateur qui clique dans son appli et ça lui sort toute sa simulation en 0.5 secondes…).
Inspirez-vous de la philosophie de monsieur Data Vault 2.0 (Dan linstedt) (je ne dis pas qu’il faut tout prendre, mais au moins inspirez vous des concepts de Hub / Links / Satellites qu’un enfant de 4 ans peut comprendre pour une structuration agile de l’historique de vos données). Cela évitera bien des noeuds au cerveau à vos utilisateurs, Data Engineer et Data Scientist, et cela apportera de l’agilité au bout du compte.
Dé-normaliser vos vues métiers ! Dénormalisez vos étoiles, vos 3NF, ça ira bien plus vite !
Le Data Scientist « Stateu » doit ouvrir les yeux au Data Scientist « Informaticien » sur ce qu’il est vraiment en train de faire tourner. Le Data Scientist « informaticien » doit apprendre au Data Scientist trop « stateu » à produire du code industrialisable et réutilisable. Recrutez les deux types de profils (Ecoles de stats, et école d’ingé informatique)
Si vous faites collaborer vos Data Scientist avec les équipes de développements des applications métiers, alors c’est que vous êtes sur les bons usages…
