Les étapes d’un projet Customer Data Platform (CDP)

Pourquoi est-ce que l’organisation souhaite sélectionner, déployer et exploiter une Customer Data Platform ? Quels sont les objectifs poursuivis ? Nous avons eu l’occasion tout au long de cette série de pages consacrées à la Customer Data Platform de mettre en avant les finalités d’une CDP. Des finalités qui, pour l’essentiel, sont de deux ordres :

• Organisationnelles. La CDP facilite et améliore l’exploitation des données clients de l’entreprise. Elle permet de mieux faire circuler la donnée dans le SI Client, de la désiloter, en l’unifiant dans un « Référentiel Client Unique » facilement utilisable par les équipes métiers.
• Marketing. Les cas d’usage data de la CDP sont, pour la plupart, au service de cas d’usage marketing. L’entreprise cherche à unifier sa donnée clients pour améliorer son dialogue client, mieux cibler ses programmes et ses campagnes, enrichir ses scénarios relationnels omnicanaux.

Il est important, en phase de démarrage du projet, de prendre le temps de formuler les objectifs finaux de la Customer Data Platform. Pourquoi votre entreprise envisage d’unifier ses données clients ? Parce que ces objectifs sont potentiellement nombreux, il importe de les hiérarchiser et de les organiser en distinguant les objectifs premiers et les objectifs secondaires. Dans nos accompagnements, nous proposons en général de commencer par une séance de travail « Objectifs » pour formuler et formaliser les objectifs de la démarche. Cette séance de travail prend parfois la forme d’un atelier. C’est une étape qui consomme peu de temps tout en étant très efficace pour structurer le projet et le mettre sur de bons rails.

Formalisation des objectifs CRM / CDP / RCU

La définition et priorisation des objectifs est la première étape de l’expression du besoin. La deuxième consiste à déduire les besoins métiers des objectifs fixés. Quelles sont les choses que les utilisateurs métiers souhaiteraient pouvoir faire avec la Customer Data Platform ? Quels sont les process et les traitements qu’ils voudraient faire évoluer ou mettre en place ?

Ces besoins métiers sont ensuite traduits en exigences fonctionnelles, c’est-à-dire en cas d’usage data et métier de la CDP. Quels sont les cas d’usage data que la Customer Data Platform devra permettre de réaliser, que ce soit en matière de connexion des données, d’enregistrement des données, de modèles de données, de transformation…bref, en matière de préparation des données qui serviront à mettre en place les cas d’usage métier : création de segments dynamiques, campagnes ultra-ciblées, scénarios omnicanaux, marketing en temps réel, automatisation…

Qualification des besoins métiers & transformation en cas d’usage.

Un projet Customer Data Platform cache la plupart du temps un projet d’unification des données clients. C’est d’ailleurs un point sur lequel nous aimerions donner quelques précisions. Parler de « projet Customer Data Platform » présuppose déjà un choix technologique. Or selon nous, le choix technologique est la fin de l’histoire. C’est la raison pour laquelle nous préférons parler de projets « Référentiel Client Unique » ou de projets « Données Clients ». L’entreprise ne souhaite pas déployer une CDP, elle souhaite unifier ses données pour répondre à des cas d’usage plus ou moins définis et pense que la Customer Data Platform est la solution qu’il faut. C’est parfois le cas, mais pas toujours.

Dans nos accompagnements, nous intégrons souvent une étape de définition de l’organisation cible. Cette étape fait le pont entre l’expression du besoin (les deux premières étapes décrites) et la sélection de l’outillage. Elle consiste en deux gestes :

• Définir l’architecture IT qui répond le mieux aux cas d’usage data et métier définis précédemment, tout en prenant en compte les contraintes de l’entreprise : organisation de la donnée, outils existants, budget…Il existe en effet plusieurs solutions possibles pour construire ce que l’on appelle un « Référentiel Client Unique ». La CDP en est une, parmi d’autres. Cette étape est l’occasion de valider le choix de la famille d’outils. Pour en savoir plus sur les principales options d’architecture envisageables, découvrez notre article « Les clés pour réussir la sélection de votre Référentiel Client Unique (RCU)».
• Définir l’architecture du projet, dans ses deux principaux jalons : le déploiement et l’exploitation. Qui est ou sera impliqué dans le projet ? Quelles sont les équipes internes qui interviennent dans la réalisation et la réussite du projet ? Quelles compétences externes mobiliser (éditeurs, intégrateurs, consultants…) ? Quelle méthode de gestion de projet utiliser (agile vs traditionnelle, ou les deux) ? Quel planning, quel lotissement, quel budget ? Quel pilotage du projet ? Etc. Etc.

Options d’architecture IT – Framework.

Les étapes qui précédent ont permis de construire une expression structurée du besoin. Maintenant que l’on sait ce que l’on cherche, il faut s’intéresser à ce que propose le marché. Si l’option « Customer Data Platform » a été retenue pour construire le Référentiel Client Unique de l’entreprise, il va falloir sélectionner l’éditeur proposant la solution CDP la mieux adaptée aux cas d’usage de l’entreprise, à son planning de déploiement, à son budget…

La sélection doit s’organiser. On ne choisit pas une CDP comme on choisit une paire de chaussettes. C’est une décision impactante pour toute l’entreprise comme nous l’avons rappelé au début de cette page. Il y a deux manières d’organiser la sélection d’une solution logicielle :

• La manière « light » : le Request for Information, ou RFI. Comme son nom l’indique, cette démarche consiste à interroger de manière informelle quelques acteurs (éditeurs, intégrateurs…) présélectionnés, sur la base d’une expression du besoin générique et/ou en cours de construction. Le RFI est très utile pour mûrir la réflexion et cerner les différentes familles de CDP. Il permet de nourrir l’expression du besoin par le contact avec les acteurs du marché.
• La manière « hard » : le Request for Proposal, ou RFP. Cette méthode est en fait incontournable. Le RFP est la démarche formalisée qui consiste à sélectionner une solution sur la base d’une expression du besoin exhaustive. Pour résumer, elle consiste à envoyer un cahier des charges fonctionnel à quelques éditeurs/intégrateurs sélectionnés (3-4), éventuellement présélectionnés en RFI, à échanger avec ces derniers (questions-réponses), à organiser les soutenances et démonstrations scénarisées de la solution avant d’évaluer et de sélectionner la solution répondant le mieux au besoin.

L’entreprise a désormais sélectionné sa Customer Data Platform. Les contours et modalités de la phase de déploiement dépendent de plusieurs paramètres :

• L’architecture IT de l’entreprise et son écosystème data, autrement dit le système d’information dans lequel la Customer Data Platform va venir s’insérer.
• La Customer Data Platform elle-même. Les modalités d’implémentation varie d’une famille de CDP à l’autre, mais aussi d’une solution à l’autre.
• Les acteurs du projet, tels qu’ils ont été sélectionnés lors de la définition de l’organisation cible. Le déploiement ne sera pas organisé de la même manière suivant que vous le réalisiez « en direct » avec l’éditeur ou que vous passiez par l’intermédiaire d’un intégrateur.
• Le planning et de le budget cibles.

Les étapes classiques du déploiement d’une Customer Data Platform

Si les modalités de déploiement peuvent être très différentes d’un projet à l’autre, les étapes du déploiement sont relativement stables :

• Le premier enjeu est de réaliser la migration (récupération) des données historiques : inventaire, dessins d’enregistrement actuels et cibles, nettoyages, transformations. Il faut organiser les flux de données entre la Customer Data Platform et les autres outils et bases du SI Client.
• Vient ensuite le paramétrage général de la solution Customer Data Platform : la définition des droits, des process et mesures de sécurité…Cette étape est maîtrisée par les éditeurs, les intégrateurs. Elle fait en général l’objet d’ateliers dédiés.
• La mise en place des cas d’usage principaux. Nous recommandons de séquencer le déploiement des cas d’usage, de procéder par lots de déploiement, en se concentrant pour commencer sur les cas d’usage définis comme importants ou urgents. Cette méthode progressive laisse le temps aux utilisateurs de se familiariser avec la solution, de la maîtriser et de monter en compétences. Elle permet par ailleurs de tester la validité (PoC) des cas d’usage, quitte à les faire évoluer ou les remplacer le cas échéant. En phase de déploiement, nous sommes volontiers promoteurs des méthodes agiles basées sur l’itération et le test & learn.
• La construction d’un dispositif de reporting. On n’améliore que ce que l’on peut mesurer. Il est donc essentiel de mettre en place un dispositif de reporting. Ce dispositif doit être conçu en vue de l’action. On ne reporte pas pour raconter le passé, mais pour agir de manière plus éclairée. A ce titre, votre dispositif de reporting doit avant tout être pensé comme un dispositif de pilotage. Cette manière de concevoir le reporting doit déterminer votre réflexion sur les usages cibles, les utilisateurs cibles, le choix des dimensions, des agrégats/indicateurs, le maquettage des reportings…

Inlassablement, nous rappelons que le projet Customer Data Platform est un projet d’entreprise plus qu’un projet Tech. Le déploiement d’une CDP implique des changements organisationnels qu’il faut gérer et organiser. C’est pour cette raison que nous recommandons à nos clients d’investir ne serait-ce que quelques jours dans la formation des utilisateurs. Allons même plus loin : les utilisateurs finaux de la Customer Data Platform doivent être associés au déploiement. L’entreprise peut par exemple choisir et activer des utilisateurs ambassadeurs qui auront pour fonction de participer au projet, d’apporter la voix de leur service/équipe dans les ateliers, d’aider à la prise de décision (arbitrages, priorisations…). C’est une condition de succès de l’exploitation de la Customer Data Platform.

Nous avons balayé les principaux jalons qui structurent un projet Customer Data Platform. La méthodologie que nous avons présentée est celle que nous mettons régulièrement en œuvre auprès de nos clients.  Vous avez un projet CDP ? N’hésitez pas à entrer en contact pour que l’on en discute !