La question est légitime, car le CRM doit contenir l’ensemble des Clients / Prospects et l’information peut être tenue à jour par les commerciaux qui les rencontrent régulièrement. Mais avant de faire ce choix, quelques interrogations méritent d’être levées.
La gouvernance à mettre en place est-elle compatible avec mon CRM ?
Le CRM n’est pas le seul système à pouvoir créer, compléter ou mettre à jour des données Clients. Les systèmes de gestion, de facturation ou autres frontaux Clients influent également sur la vie de ces données. Appliquer au CRM l’étiquette de référentiel n’est donc pas suffisant. Il faut mettre en place l’ensemble de la gouvernance des données de référence Client (ou plus généralement concernant les Tiers) associées au principe de référentiel :
Définir le cycle de vie des Clients,
Définir un modèle objet exhaustif (qui ne soit pas limité aux seuls besoins du service commercial),
Pour chaque attribut, définir quels utilisateurs seront en capacité de le mettre à jour, à partir de quel outil, le tout en fonction du statut ou de l’état du Client,
Mettre en place une couche pour assurer la qualité de la donnée (formatage, dédoublonnage, contrôle de cohérence, complétion via des bases externes, …),
Prévoir les mécanismes et processus de validation des données,
Construire les interfaces nécessaires afin de consolider et de diffuser la donnée,
Définir les droits/politiques d’accès à la donnée,
Anticiper les impacts sur le pilotage, le reporting, la traçabilité, le versionning des données, la gestion des données à date, …
Quel modèle de donnée client dans le référentiel ?
Il faut également garder en mémoire que les CRM se concentrent par nature sur les éléments ayant trait à la relation commerciale avec les Clients. Or l’ensemble des données du CRM ne sont pas forcément à porter dans un référentiel. Inversement, dans bien des cas un CRM ne contient pas l’ensemble des données référentielles d’un Client (rôles du Client [payeur / commanditaire / bénéficiaire…], données techniques liées à la mise en place d’un service pour le Client…).
Construire le référentiel Client au sein du CRM implique donc de s’assurer que ce dernier contienne bien l’ensemble des données référentielles et de pouvoir aisément distinguer celles-ci des données à caractère opérationnel.
De plus, dans de nombreux cas cela implique également que des acteurs non commerciaux aient accès au CRM afin de maintenir ces données Client. La Direction Commerciale et Marketing souhaitera-t-elle ouvrir son outil à ces acteurs ? Ceux-ci accepteront-ils d’utiliser le CRM, outil qui n’est pas fait pour répondre à leurs propres besoins ?
Quel périmètre de données est concerné ?
Lorsque les clients sont des personnes morales, il peut être intéressant de croiser les données afin de savoir quels sont les clients qui sont également fournisseurs, quel est le chiffre d’affaire généré par un Client/Fournisseur vs la charge que représente ses prestations. Toute consolidation risque d’être complexe si les référentiels Client et Fournisseur sont distincts. Il s’agit pourtant dans les deux cas de personnes morales mais gérer ses Fournisseurs dans un CRM ne fait pas forcement sens. Dans ce cas, un référentiel ad hoc permettrait de pallier le problème. La problématique sera identique pour tout autre tiers d’intérêt comme les apporteurs d’affaire, les sous-traitants, les cautions / garants…).
Et la technique dans tout ça ?
Point inhérent aux précédents, le CRM a-t-il les capacités techniques pour assurer le rôle de référentiel ? Est-il capable de faire de la gestion de la qualité des données ? Ou alors s’intégrer avec un outil de DQM (Data Quality Management) spécifique ? Est-ce que le modèle de données du CRM est compatible ou suffisamment personnalisable afin d’intégrer le modèle de données de l’entreprise ? L’outil aura-t-il les capacités techniques pour diffuser l’information au sein du SI ? Supportera-t-il des dizaines de milliers de requête par jour ? Est-ce que le contrat de service associé à ce CRM est suffisant pour permettre à l’ensemble des applications qui en dépendent de fonctionner correctement ?
Est-ce que je fais un bon investissement ?
Les aspects financiers sont également un élément-clé de la décision. Certes, de prime abord, utiliser le CRM comme référentiel Client permet d’éviter un investissement dans un nouveau système, mais à quel prix ? Combien coûte la mise en place (et l’exploitation) des fonctionnalités de référentiel au sein d’un CRM ? Combien coûtent la haute disponibilité, la qualité de service, les SLA qui n’étaient peut-être pas nécessaires pour le simple usage des commerciaux ? Combien coûtent les licences supplémentaires attribuées aux utilisateurs qui n’étaient pas dans le périmètre initial ? Le modèle de facturation du fournisseur est-il en cohérence avec l’usage que l’on souhaite en faire (un coût à l’usage peut s’avérer rapidement très onéreux) ? Est-ce que l’économie est réelle lorsque l’on compare cette option à la mise en place d’un référentiel dédié ?
Quelles sont les autres solutions possibles ?
Si le CRM n’est pas l’outil le plus adapté à votre cas, quelles sont les autres possibilités ?
Les MDM (Master Data Management) sont a priori plus aptes à traiter les problématiques de référentiel de données puisqu’ils ont été développés dans cette optique. Ils possèdent des fonctionnalités pour traiter la saisie, la consolidation et la diffusion des données et intègrent généralement une couche de DQM permettant d’en assurer la qualité.
Toutefois, la prudence s’impose car tous les outils n’ont pas forcement la même maturité et tous proposent des fonctionnalités qui répondent à des besoins qui ne sont peut-être pas les vôtres. Pourquoi payer les fonctionnalités d’un progiciel si c’est pour ne pas les utiliser ?
Pour répondre à des besoins relativement simples, le développement d’une solution spécifique pourrait être considéré.
Quelle est la meilleure solution pour mon référentiel client ?
CRM, MDM ou développement spécifique, il n’y a pas de réponse générique, mais il peut y avoir des conséquences sur l’ensemble du système d’information.
Bien que tous les éditeurs (de CRM) soutiennent que leur solution peut être utilisée en tant que référentiel Client, ils sont beaucoup plus tempérés une fois les besoins et contraintes à traiter exprimés.
Par ailleurs, et non des moindres, il faut noter que ce n’est pas uniquement le réceptacle qui fait le référentiel. C’est bien la gouvernance qui encadre la donnée qui permet de maintenir le point de vérité. Il est nécessaire de mettre en place une organisation avec des rôles et responsabilités définis ainsi que des outils adaptés respectant l’urbanisation et l’architecture du système d’information.
Mais n’en sommes nous pas à la vision 360° client désormais ?
Encore une fois, malgré des éditeurs de CRM et de MDM qui promettent la Vision 360° Client, il faut replacer ces solutions à leurs « justes » fonctionnalités et regarder vers de nouveaux outils autour du Big Data qui permettent effectivement la mise en place d’une « vraie » Vision 360° Client sans pour autant remplacer le CRM ni le Référentiel Client. Ces visions consolidées et cross-business sont généralement utiles aux clients eux-mêmes mais aussi et surtout aux commerciaux ou gestionnaires pour leur permettre d’être encore plus efficient dans leur travail au quotidien.
Notons surtout que ces nouveaux outils ne font que renforcer l’intérêt d’un Référentiel Client qui soit partagé au sein du SI car construire une vision 360° Client nécessite d’agréger en un point unique des données venant de l’ensemble du SI.
De nouveaux types d’architecture, incluant la mise en place de Data Lake, d’API, de frontaux digitaux permettent la construction et l’utilisation de cette vision 360° mais elle ne restera possible que si les données peuvent être corrélées les unes avec les autres. Cette corrélation est grandement facilitée lorsqu’un référentiel Client a été mis en place au cœur du système d’information. La vision 360° n’a alors plus qu’à relier tous les éléments métier autour du « golden record » Client unique.
Le marché français était en léger retard depuis quelques années sur l’adoption du Cloud. Les entreprises américaines étant les premières à avoir fait le saut dans l’informatique en nuage. Pourtant les derniers chiffres issus du baromètre Markess indiquent une très forte hausse d’adoption depuis 2 ans avec une évolution annuelle tournant autour des 25-30%.
Nous avons pu confirmer ce changement lors de notre dernière visite au Salon Cloud Computing World Expo qui s’est tenu Porte de Versailles à Paris.
La première raison de ce changement est que pour certains domaines professionnels, les nouveaux standards du marché sont parfois uniquement disponibles à la demande (i.e. Office365 ou G-Suite). De nombreuses entreprises ont fait le choix de migrer leur messagerie et outils bureautiques devenus obsolètes vers des outils de collaboration plus adaptés au monde digital. A ce sujet, les collaborateurs en entreprise sont de plus en plus demandeurs de retrouver le même confort qu’ils ont à la maison : avoir accès à leurs applications depuis internet via différents devices (PC, tablette, portable).
Autre exemple, les solutions CRM étaient auparavant dominées par des socles logiciels très lourds à déployer et à maintenir. Beaucoup de sociétés veulent gagner en agilité et souhaitent limiter leurs investissements (CAPEX) en migrant vers des solutions Saas (i. e SalesForce.com). Ceci leur permet de déployer rapidement aux métiers des solutions tout à fait adéquates sans avoir besoin de développer des fonctions spécifiques sur mesure.
Comme l’a exprimé Emmanuel Guichet, directeur de la division IT Factory du groupe Total, lors d’une conférence:
« réaliser un projet de 18-24 mois pour concevoir les 20% de fonctionnalités manquantes n’est plus acceptable par la Direction Générale pour ce type d’application ».
Autre effet, inattendu il y a quelques années, le Cloud est vu maintenant comme un levier de croissance. Avec l’arrivée de nouveaux concurrents issus du monde du web, certaines entreprises ont été forcé à prendre des initiatives en dehors de leur business model habituel. Ceci a souvent nécessité la mise en place de nouvelles plateformes pour faire du Big Data ou s’interfacer avec des objets connectés (IoT) pour certains cas d’usages. Or ces innovations se font souvent en mode incrémental voir expérimental et ne justifient pas toujours les lourds investissements nécessaires au démarrage de ces projets. Il peut être pragmatique, comme l’a fait LeBonCoin.fr, d’externaliser ces briques applicatives afin d’adopter un paiement à l’usage pour mitiger ce risque.
Cette même stratégie permet de concevoir et de construire son architecture en mode Agile à moindre frais d’infrastructure sans avoir peur de tout remettre en cause. En fonction de la taille de votre structure, de vos compétences en interne et de la criticité de vos données, il vous restera ensuite de choisir les briques technologiques et le fournisseur Cloud appropriés.
Ces nouveaux entrants « disruptifs » ont également une particularité commune : ils ont tous des cycles de développements très courts ! Ils peuvent délivrer des nouvelles fonctionnalités en peu de temps à leurs utilisateurs finaux. Les entreprises traditionnelles se voient forcées d’abandonner leurs méthodes de gestion de projet classiques basées sur des cycles en V.
Elles doivent adopter des méthodes Agiles, Lean voire de revoir en profondeur leur organisation pour adopter une culture DevOps. AXA et la Société Générale, ont toutes les deux déclaré publiquement avoir entamé ces transformations importantes dans le but ultime de réduire leur « Time to Market ».
Les deux sociétés ont été contraintes pour des raisons réglementaires de s’appuyer dans un premier temps sur un Cloud Privé mais ont donné des indications de vouloir aussi s’appuyer sur du Cloud Public dans la mesure du possible. La Société Générale a indiqué avoir fait le choix d’utiliser des containers Docker pour faciliter la migration d’un Cloud à un autre et ainsi avoir un véritable Cloud hybride.
S’appuyer sur le Cloud a un effet bénéfique sur le budget opérationnel (OPEX) de ces entreprises. Cela leur a permis de rationaliser leur nombre de datacenters comme indiqué par la société minière et métallurgique Eramet.
Elles profitent de ces migrations pour revoir leur portfolio applicatif et décommissionner celles avec peu de valeur ajoutée comme le rapporte Thierry Favier, responsable informatique chez eSNCF.
Enfin, toutes celles venues témoigner au Salon ont entrepris de piloter la migration de leur SI Legacy vers le Cloud en tenant compte de deux critères majeurs : la réduction de coût et les risques opérationnels.
Le résultat est que pour toutes ces entreprises, s’appuyer sur du Cloud dans leur transformation digitale a été une évidence. Elles ont toutes défini en amont une stratégie de déploiement (Saas, PaaS, IaaS) propre à certains cas d’usages ou besoins fonctionnels. Que ce soit pour couvrir de nouveaux besoins, venir en appui de changement d’organisation et de culture ou pour réduire leur coût tout en se modernisant, elles n’ont pas hésité à franchir le pas !
Le Cloud est donc bien un tremplin vers la transformation digitale.
Le métier de consultant est une véritable aventure ! Chaque mission, chaque client est une occasion de découverte mais aussi une opportunité d’inventer, d’expérimenter, d’utiliser et de développer ses talents. Cette fois-ci parlons de la médiation, c’est-à-dire l’art de résorber ou d’atténuer les conflits.
Les enjeux humains chez os clients mettent parfois en danger nos missions
Consultants, nous constatons toujours dans nos interventions, aussi techniques soient-elles, qu’il y a des enjeux humains qui impactent les problématiques que nous avons à traiter. Être rigoureux, s’en tenir aux faits, développer des convictions, communiquer largement, expliquer nos démarches de réflexions, gérer nos interlocuteurs, etc. nous avons des actes-réflexes pour faire face.
Mais souvent c’est pire ! Les situations relationnelles de nos clients ressemblent à des conflits. Et ce n’est pas étonnant, car des conflits il y en a dans toutes les sociétés ! Pour éviter que nos interventions en subissent directement le poids, nous mettons alors en place des dispositifs palliatifs supplémentaires comme :
Des hypothèses de production et des KPI (pour se protéger des défaillances du client) ;
Des stratégies de travail (pour pouvoir avancer malgré tout) ;
Des stratégies de validation (pour obtenir des quitus).
La résolution des conflits produit de la valeur
Mais dans certains cas, on a tout intérêt à faire un peu plus, ou un peu différemment. En effet, si les stratégies précédentes (actes réflexes et dispositifs palliatifs) permettent de s’en sortir honorablement, elles ne sont pas complètement convaincantes : le conflit rencontré demeure non résolu. Moralité : on a fait le job mais pas plus.
Si on pouvait résoudre le conflit en question, on pourrait prouver notre engagement à notre client et ainsi l’aider à obtenir des résultats inespérés.
La médiation est faites au profit des parties
D’un naturel « communiquant et sensible », j’ai découvert l’art de la médiation pas à pas. Je vais vous exposer mon approche du sujet. Précisons que la médiation se rapproche de la négociation, mais une grande différence les sépare : la négociation est conduite dans l’espoir d’un gain personnel, alors que la médiation est conduite au profit des parties, pas du médiateur.
La démarche de médiation est toujours implicite (seuls ses résultats sont explicites)
Première bonne pratique : le consultant n’étant pas mandaté pour conduire une médiation, devra en constater le besoin et la conduire sans le dire. Si les parties prenantes du conflit avaient conscience d’une telle démarche, elles pourraient modifier leurs comportements au point de la faire échouer. Cela vaut aussi pour le consultant : il doit faire l’effort de ne pas paraître avoir de parti-pris (et il pourrait en avoir compte-tenu des enjeux de la réussite de la médiation sur sa mission). En ce sens la mission initiale et explicite du consultant (conduire un projet, définir une architecture, produire un rapport d’analyse, etc.) est un paravent très commode !
Deuxième bonne pratique : être curieux. Il faut observer, écouter et discuter pour diagnostiquer la situation relationnelle conflictuelle. Le projet technique que l’on conduit étant toujours le cœur de la discussion -jamais ladite médiation- : pourquoi ce projet ? quelles difficultés pressenties ? conditions de réussites ? vécu des parties prenantes ? leurs craintes ? leurs opinions ? etc.
Troisième bonne pratique : faire émerger au sein du projet technique, un sous-projet (ou sujet latéral) sur la base duquel on fera progressivement collaborer les interlocuteurs en conflit. 4 étapes pour cela :
Détourer pour soi-même le périmètre sur lequel les 2 parties peuvent converger (« chacune des 2 parties seraient satisfaites si … »).
Présenter à chacune des 2 parties le périmètre en question et s’assurer qu’elles se l’approprient et sont suffisamment en confiance (« compte-tenu de ce qui vient de vous être présenté et de tout le reste, comment voyez-vous la mise en œuvre ? »).
Proposer une collaboration encadrée, soutenue par le consultant, qui doit déboucher sur un premier résultat encourageant (et la découverte mutuelle qu’il est possible de collaborer, même si cela reste non formulé : on ne pointe du doigt que le résultat obtenu, pas les personnes, car leur implication reste fragile à ce stade).
Solliciter un retour d’expérience, pour ancrer l’idée qu’une démarche commune est possible (« que pensez-vous de la démarche qu’on vient d’accomplir ? », « quelle pourrait être une suite naturelle possible ? »)
Trois illustrations de médiations réussies
Voici 3 contextes différents, où sur la base de notre mandat préalable de consultant et du diagnostic d’un conflit, notre envie d’aller plus loin nous a conduit à produire plus de valeur que les analyses et livrables qui nous étaient initialement demandés.
En 2011, nous assistons le pilotage d’un grand projet de refonte du SI et tout est bloqué. Sous le poids des incertitudes les chefs de chantiers sont mode « défense passive » et se renvoient tous la balle : « les livrables en entrée de mon activité sont incomplets, je ne peux pas travailler ! ».
Sujet latéral et périmètre de convergence. Sous couvert de mettre à plat la méthode projet pour des besoins de gouvernance, nous concevons avec l’ensemble des acteurs la map du déroulement du projet sur 1 an ½ tel que chacun le voit, que nous publions et affichons dans tous les couloirs.
Collaboration encadrée et convergence. Nous organisons tous les jeudis un point d’avancement rassemblant les chefs de chantiers concernés par l’étape en question : le chef de projet s’y fait expliquer la situation, détoure une solution acceptable pour les chefs de chantiers et leur apporte son soutien (moyens, prise en charge des risques, etc.).
En 2014, dans une société de transport, nous intervenons pour revoir l’ensemble des processus opérationnels pour les besoins réglementaires (conformité sécurité). Cela est nécessaire à la bonne marche de l’entreprise, mais le responsable des processus s’est construit une tour d’ivoire et sa chef, à défaut de pouvoir le piloter, envisage de déléguer cette activité à un autre service. Leurs cultures, technique d’un côté et administratif de l’autre, les opposent.
Périmètre de convergence. Sous couvert de redéfinir le livret des processus, 1) nous détaillons les services rendus, la valeur ajoutée de l’activité et le planning des prochaines étapes, 2) nous faisons exprimer à la chef de service les KPI pour piloter l’activité. Nous rapprochons services, valeur ajoutée et planning des KPI attendus.
Sujet latéral, Collaboration encadrée et Convergence. Nous définissons un tableau de bord commun aux 2 parties qui leur permet de communiquer. Nous soutenons les 2 parties lors des premières itérations de tableaux de bord. Les 2 parties au bout de quelques semaines se font part de leur satisfaction.
En 2017, nous devons diagnostiquer l’organisation d’un des Services d’une filiale bancaire et définir un plan de modernisation de l’organisation. Le tout nouveau Directeur ambitieux se confronte au chef de service et à son équipe de « vieux briscards » présents dans la société depuis 25 ans pour certains :
« Je ne sais pas ce qu’ils font », « quand je m’adresse à eux, c’est comme si je parlais à des tombes »
« il ne cherche pas à nous connaître, il ne connaît même pas nos noms », « il ne sait pas toute la valeur qu’on produit »
Comment mettre en mouvement un tel équipage ?!
Périmètre de convergence. Passé le diagnostic initial, nous définissons un plan d’action de changement acceptable pour le Directeur et le Chef de Service.
Sujet latéral.Nous définissons avec le Directeur 10 sujets sur lesquels il voudrait voir des progrès. Nous partageons ces sujets avec les équipes et lançons 10 groupes de travail, où nous n’intervenons qu’en support (planification des ateliers, aide méthodologique). L’objectif est de démontrer la valeur des collaborateurs par leur capacité à traiter les sujets en autonomie.
Collaboration encadrée. Sur la base de l’accord trouvé sur le plan d’action, nous demandons au Directeur et au Chef de Service de soutenir unanimement et de manière univoque les groupes de travail : pour chacun des 10 sujets en cours de traitement, ils définissent l’aide qu’ils pourront l’un et l’autre apporter aux collaborateurs.
Convergence. La revue finale a lieu :
les 10 groupes de travail présentent tour à tour leurs résultats. 8 ont vraiment réussi l’exercice et les 2 autres sont plus en retrait. 2 groupes brillent (celui sur le management du Service notamment !)
le Directeur constate la valeur de ses équipes et leur apporte son soutien, ainsi que le Chef de Service.
le Directeur et le Chef de Service sont « alignés » pour la première fois depuis des mois
Quand la médiation échoue
Il arrive que la médiation échoue : à tout moment une partie ou des deux peuvent sortir du jeu en refusant de collaborer. C’est souvent le fait d’un écart culturel trop prononcé, de divergences trop ancrées, d’une envie d’en découdre ou d’une rupture qui est déjà trop engagée, etc.
Cette approche de la médiation appliquée aux missions de conseil, demande du temps, de l’écoute, de la patience et surtout l’envie d’aider ses congénères. Cependant, par rapport à un médiateur professionnel, le consultant-médiateur avance masqué : on l’a vu faire, on a accepté son approche (on voit bien ce qu’il fait) … on voit la situation s’améliorer, mais son rôle de médiateur n’est pas formellement reconnu. Il pourrait y avoir un risque à vouloir être reconnu comme médiateur : devoir reconnaître formellement qu’il y a un conflit … rare qu’on ait envie d’officialiser les difficultés qu’on ne sait pas résoudre. Comme dans le voyage de Monsieur Perrichon, les témoins de nos faiblesses, sauveteurs patentés soient-ils, deviendraient rapidement gênants et auraient tôt fait d’être délaissés !
L’architecture, tout comme les technologies, évolue constamment. Un architecte doit donc s’adapter et suivre une formation continue pour rester à la pointe de son domaine.
Pour fournir une vision d’ensemble du SI et de sa transformation, l’architecte doit faire émerger les principes du « vivre ensemble » partagés par l’ensemble des parties prenantes du SI.
Un SI construit sans vue d’ensemble c’est ça
Et les connexions entre applications ressemblent à ça
Construire ensemble
La cible du SI et ses paliers de transformations fournis par l’architecte d’entreprise sert à donner à chacun la vision d’ensemble dans laquelle il s’insère.
Lorsqu’une solution n’est pas compatible avec la direction donnée et les bases de la construction, elle peut avoir de grandes répercussions sur les autres, voire mettre l’ensemble de la construction en danger (ici la structure de l’immeuble a failli s’effondrer sous le poids supplémentaire).
Chacun a son point de vue sur la solution, et tout le monde a raison (de son point de vue évidemment)
Chacun imagine des solutions, même si celles-ci peuvent paraître en décalage avec l’idée qu’on s’en fait. Des dérogations peuvent être accordées tant qu’elle ne gêne pas l’ensemble de la construction l’architecte d’entreprise ou le difficile équilibre du vivre ensemble L’architecte d’entreprise ou le difficile équilibre du vivre ensemble discussion
Une fois que la cible est définie et partagée par tous, il faut alors effectivement définit les règles du vivre ensemble
L’architecte d’entreprise est là pour proposer des principes communs qui permettent de faire avancer le SI dans son ensemble. Il a pour but de faire communiquer les différentes composantes de l’entreprise et de trouver les solutions qui conviennent à tous, qui sont les plus pérennes et les plus proches des standards voulus par l’entreprise. Dans notre monde actuel, les connaissances sont fragmentées et la coopération entre toutes les parties est essentielle pour tirer le meilleur des nouvelles situations et des technologies.
L’architecture globale du SI doit permettre de laisser chacun libre d’aménager (ou pas !) son propre espace (l’intérieur de sa solution). Le but est alors que chaque solution puisse vivre selon son propre rythme en harmonie avec les autres et en garantissant un langage minimum commun pour se comprendre.
Peu importe la solution choisie pour le SI, la bonne solution est celle qui répond au problème. Elle doit être partagée par tous, construite suivant les règles de l’art et chacun doit pouvoir y trouver sa place.
Quelques grandes règles et principes suffisent pour construire ensemble un édifice solide. À tout moment, il doit être possible de justifier des principes qui nous ont amené à choisir cette solution. Ces principes peuvent (doivent) évoluer bien sûr. Ils sont là pour nous aider à se poser les (bonnes) questions. La gestion des dérogations à ces mêmes principes est un art subtil à manier avec précaution et à ne pas négliger !
La bonne architecture fournit la solution adaptée à un besoin en prenant en compte les différents paramètres de coûts, délais, qualité, esthétique, technique, évolutivité etc.
Les DSI pâtissent souvent de ne pas avoir une description claire de leur SI. Une description qu’ils puissent montrer aussi bien aux métiers pour déclencher les budgets et l’intérêt, qu’aux différents interlocuteurs (nouveaux entrants, sous-traitants, etc.). Elle permet d’expliquer le fonctionnement global du SI dans sa complexité, dans les différentes composantes majeures, dans les parties prenantes impliquées, etc. Et quand on parle de description, il ne s’agit ni de la liste des lignes budgétaires, ni de la liste des projets, ou autre. Nous parlons de la vraie description du fonctionnement du SI avec ses principales applications / domaines et les flux qui permettent de décrire un fonctionnement dynamique du SI.
Un de nos clients, une filiale d’un grand groupe bancaire nous a demandé récemment d’avoir le « poster » avec les principales applications et les flux, pour qu’il puisse comprendre et présenter le SI. Il était inquiet de ne pas savoir avec qui / quoi le SI était en interaction… Cela lui permet aussi de bien visualiser et de positionner ses enjeux en terme de transformation, d’investissements, etc.
Combien de DSI, malgré toutes leurs demandes et les missions de cartographie ne disposent toujours pas de la cartographie claire de leur SI ? Une cartographie qui leur permette de maîtriser ce qu’est leur patrimoine et leur « terrain de jeu ».
Combien de fois, les architectes sont revenus faire des dessins aux tableaux pour expliquer tel ou tel point, et au final, c’est toujours le même dessin qui est fait, mais personne ne capitalise dessus ? J’ai vu faire un architecte devenu un client, qui expliquait pendant plusieurs séances, le SI et sa transformation avec un dessin au tableau. Il rajoutait, modifiait des explications au fur et à mesure des échanges avec ses interlocuteurs. Le tableau devenait alors trop illisible et il refaisait son dessin sur un paper board, et c’était reparti pour un cycle. Nous lui avons fait le fonds de carte et maintenant, il raconte son histoire à partir de là en mettant régulièrement à jour ce dessin qui est devenu son « fonds de commerce ».
Cette démarche de description macro du SI doit être faite rapidement. Dans un esprit agile, les premières étapes doivent être celles qui apportent le plus de valeur ajoutée.
Ne pas finir une cartographie, ce n’est pas grave, à condition que l’on ait apporté le plus de valeur ajoutée dès le début.
Dans le cadre de nos interventions, notre démarche nous permet de répondre précisément et complètement à ses attentes et de fournir les vues pertinentes à la compréhension du SI. Une vue assez stable pour ne pas devoir être mise à jour à la vitesse des projets (qui se succèdent à un rythme effréné en ce moment) et qui permet de bien comprendre les grands enjeux du SI.
Définissons ensemble les vues qui vous manquent le plus et donc celles qui vous apporteront le plus de valeur. Nous allons commencer par celles-là et y mettre les moyens !
Tout comme le Chief Marketing Officer a pour objectif d’augmenter la valeur « client », le Chief Data Officer doit poursuivre le même objectif avec les « données ».
En effet, chercher à augmenter la valeur des données actionne, in fine, tous les leviers auxquels le Chief Data Officier doit s’attaquer. Ce sont ces leviers que nous allons passer en revue ici pour cadencer la feuille de route du CDO.
Angle d’approche ? Les sources de données !
Pour augmenter la valeur des données, il va falloir être capable de la mesurer.
Quel périmètre doit-on mesurer ? Qu’est-ce qui détermine la valeur des données ?
Afin de disposer à la fois d’un périmètre fini à gérer, et des données présentant les mêmes caractéristiques, nous allons mesurer la valeur d’une « source de donnée » (exemple de sources de données : la donnée client dans le CRM, la donnée produit dans le référentiel produit, les opérations de compte dans le système dédié à la gestion des comptes, etc.).
Cela nous donne une première activité clé du CDO : Constituer et faire vivre le référentiel des sources de données majeures de son organisation. Elles vont constituer l’actif qu’il va devoir gérer et faire prospérer.
« Actif », vous avez dit « Actif » ?
C’est en particulier en considérant les données comme un actif, que l’on va disposer d’un guide pour établir et développer leur valeur.
Tout d’abord, la valeur propre de notre actif, qui caractérise son état actuel et son potentiel, va se traduire, pour une source de données, par :
Son niveau de connaissance : les données sont-elles décrites et leurs caractéristiques partagées au sein de l’organisation ? (exemple : définitions, données personnelles…)
Son niveau de qualité : les données sont-elles fiables ?
Son niveau d’accessibilité : les données sont-elles facilement accessibles ?
Son niveau de fraîcheur : les données sont-elles alignées avec la réalité qu’elles décrivent ?
Son niveau de gouvernance : le cycle de vie des données est-il géré ? Avec des rôles et responsabilités définis ?
Son niveau de conformité : les données répondent-elles à des cadres réglementaires ?
…
Ces différentes caractéristiques constituent un premier guide pour le CDO déterminant les domaines d’action à couvrir ou à dynamiser : C’est le plan d’action « Développer la valeur propre »
Mesurer et améliorer la qualité des données,
Disposer d’un cadre souple et agile de gouvernance des données,
Lancer des initiatives pour faciliter l’accès aux données (internes et externes),
Rapprocher les cadres réglementaires des données qu’ils couvrent … .
…
Une fois cette valeur propre établie, encore faut-il la concrétiser : Ce sont les usages qui vont en être fait qui vont permettre d’arriver à ce résultat.
Définissez vos cas d’usages !
Cette valeur d’usage va se caractériser de plusieurs façons, qu’il faut combiner pour démultiplier la valeur d’une source de données :
Combien de métiers différents utilisent ces données ? Uniquement le marketing ou aussi la conformité, les canaux digitaux, l’écosystème… ?
Quelle diversité y-a-t-il dans l’utilisation de ces données ? Uniquement pour du reporting ou aussi pour des usages en temps-réel, des usages opérationnels, des visions 360°, de la détection de fraude… ?
Quels revenus sont générés (ou économies réalisées) grâce à ces données ?
Quelle valeur est réalisée dans l’écosystème de l’organisation ? Les données sont-elles uniquement utilisées en interne ou bien participent-elles à un écosystème plus large (partenaires, Open Data, image…) ?
…
Ces axes de développement constituent un second guide pour le CDO, déterminant les domaines d’action qu’il doit couvrir ou dynamiser. : C’est son plan d’action : « Développer la valeur d’usage »
Développer une culture Data dans l’organisation afin de favoriser les nouveaux usages et de sensibiliser à la protection des données,
Multiplier les activités avec les métiers pour identifier de nouveaux usages,
Mesurer et maximiser les revenus et les économies permis par l’utilisation des données,
Étendre, jusqu’à l’écosystème de son organisation, ses activités et ses partenariats
…
Mettre en place les plans d’action que nous venons de lister va permettre de concrétiser à la fois la valeur propre et la valeur d’usage des données. Et nous disposons dès lors d’un critère de priorisation des activités centré sur la valeur. Et c’est bien là tout l’objet de cette approche consistant à faire de l’augmentation de la valeur des données l’objectif premier du CDO : Identifier les actions concrètes à mener, jour après jour, pour développer la valeur des données, avec des éléments de mesure objectifs.
Vous voilà parés pour augmenter la valeur de vos données.
