Les systèmes décisionnels présentent certaines caractéristiques spécifi-ques qui induisent des risspécifi-ques particuliers tant dans la mise en œuvre que dans l’exploitation. Ces spécificités sont les suivantes :
Figure 3-8 : Les datamarts
03-Chapitre 3 Page 97 Mercredi, 8. septembre 2004 2:59 14
Partie I – Définition et périmètre du CRM
•Orientés données : les traitements ne sont pas nécessairement parfaite-ment définis lors de la conception d’un entrepôt de données ; dès lors, il est nécessaire de structurer certaines données sans pour autant être sûr qu’elles soient utiles.
•Traitements non déterministes : la manière d’attaquer la base de données dépendra de la créativité des utilisateurs, qui pourront s’appuyer sur des « requêteurs » ouverts. Dès lors, face à des requêtes inconnues par avance, il est très délicat d’optimiser a priori la structure de la base de données.
•Spécifications initiales faibles : dans la continuité du premier point, l’entrepôt de données est avant tout un lieu d’exploration. Ces explora-tions aboutissent à des conclusions qui elles-mêmes justifient l’indus-trialisation de certains traitements. En d’autres termes, les spécifica-tions sont très faibles au départ et évoluent sans cesse.
•Sous-estimation de la non-qualité des données : de nombreuses données ont été entrées dans les systèmes opérationnels sans contrôle. L’absence d’un audit préalable des données ne permet pas d’avoir une vision exhaustive des modalités et conduisent à de l’écriture de scripts de chargement au fur et à mesure de la découverte des problèmes. La phase de recette est sous-estimée, ce qui se traduit par la livraison de données fausses au démarrage. Il est alors très difficile de reconstruire la confiance des utilisateurs.
•Projet récurrent : corollaire des points précédents, un entrepôt de don-nées est un projet récurrent avec des évolutions permanentes. La sur-consommation budgétaire pour le chargement des données se traduit par une réduction des budgets de maintenance. Les erreurs sont iden-tifiées par les utilisateurs, mais les équipes techniques n’ont plus les moyens de faire évoluer, voire de corriger les défauts les plus flagrants.
L’entrepôt passe du statut de huitième merveille du monde à celui de ruine inutile !
•Critères de réactivité : la plupart des systèmes sont jugés sur leur stabilité et leur précision. Dans le cas d’un entrepôt de données, il n’est pas rare de préférer obtenir des informations partiellement justes mais dans un temps record, plutôt que d’attendre trop longtemps l’information par-faite. La limitation des espaces de stockage ou des réseaux se traduit pour les utilisateurs par des procédures répétitives pour calculer des agrégats, des temps d’exécution des traitements et une perte de pro-ductivité évidente. En 2003, nous avons eu l’occasion de rencontrer des utilisateurs de données d’entrepôt avec une place disque de 10 Mo (vous avez bien lu !).
•Qualité dépendant des autres systèmes : une caractéristique essentielle de
03-Chapitre 3 Page 98 Mercredi, 8. septembre 2004 2:59 14
Chapitre 3 – Collecte et traitement des données : le data warehouse
chargements, peut avoir des effets fâcheux : annonce d’une progression du chiffre d’affaires de 5 % à la Direction générale, invalidée quelques jours plus tard, après le constat que les chiffres du dernier week-end ont été chargés deux fois ! Il faut mettre en place des procédures de contrôle et des alertes (sur des données stables) pour identifier ce type de pro-blème au plus tôt.
•Technologies très spécifiques : lorsque l’entrepôt de données attend certains volumes, ou que l’utilisateur recherche une liberté toujours plus grande dans sa navigation dans les données, il est nécessaire de considérer des technologies assez particulières telles que les machines massivement parallèles ou les bases de données multidimensionnelles. Les tâches d’optimisation des entrepôts nécessitent des expertises encore rares.
L’intervention d’un expert en optimisation a permis de faire passer un traitement de 2 heures à 2 minutes !
•Besoin d’un administrateur fonctionnel : la définition même des termes et des concepts manipulés dans l’entrepôt requiert une attention spécifique ; dès lors, il est de plus en plus fréquent de voir apparaître une fonction d’administrateur fonctionnel de l’entrepôt, dont la vocation est de gérer la sémantique des données manipulées. L’administrateur fonctionnel doit être capable de comprendre les procédures de transformation et de chargement pour valider la donnée, mais être suffisamment pédagogue pour concevoir une documentation intelligible par les utilisateurs.
•Risques d’hétérogénéité liés à l’ouverture : le fait de permettre une attaque par des outils de requête rend l’entrepôt de données plus vulnérable qu’une application traditionnelle. En effet, il existera sur l’entrepôt de données différents outils ou procédures, par exemple pour charger des données qui constituent autant de risques sur leur intégrité.
Ces caractéristiques particulières induisent plusieurs risques, certains liés au projet lui-même, d’autres qui peuvent se révéler lors de l’exploitation de la solution, et dont les principaux sont évoqués ci-après.
Le syndrome data warehouse
Certaines entreprises abordent le problème sous un angle radical : « Je ne connais pas les besoins en traitement, donc je stocke tout et je verrai plus tard. » Il s’agit la plupart du temps de projets poussés par les directions techniques et qui prennent la forme d’une prouesse technologique. Ceci risque de se matérialiser ainsi :
• La solution ne sera pas structurée et les données seront difficilement accessibles.
• La quantité de sources de données étant la variable la plus calibrante, le fait d’être exhaustif peut faire exploser les coûts indépendamment de la valeur des sources considérées.
03-Chapitre 3 Page 99 Mercredi, 8. septembre 2004 2:59 14
Partie I – Définition et périmètre du CRM
Pour éviter cela, les mesures essentielles sont :
• différencier les sources par leur contribution ;
• établir une structure de données globale et la remplir progressivement par des lots successifs.
L’inadéquation des moyens face aux objectifs
Les moyens affectés à la base marketing sont réduits pour des objectifs fonctionnels inchangés ou bien, les ressources affectées au-delà de la première version sont insuffisantes pour assurer les évolutions nécessai-res. Dès lors, la solution est limitée en puissance et en évolutivité et ne suit pas l’incontournable évolution des besoins fonctionnels.
La contre-mesure est évidente : s’accorder une marge de manœuvre budgétaire dès le départ, et planifier très en amont les besoins en ressour-ces complémentaires comme les expertises externes, mais aussi les ressources maîtrisant les systèmes source.
L’amalgame entre CRM et marketing automation
Certaines entreprises décident d’amalgamer dans un seul projet global les problématiques de relation client et les problématiques de marketing.
Le projet devient alors gigantesque, lorsqu’on sait que les objectifs entre relation client et marketing peuvent être parfois antinomiques, et néces-siter des arbitrages longs et douloureux.
La confusion entre conception et réalisation
Par nature, les besoins marketing sont difficiles à spécifier ; le risque est Exemple : un opérateur de télécom mobile a voulu stocker de manière exhaustive toutes les données client et notamment les appels sur une très longue période ; à la limite des possibilités technologiques, les processus de chargement quotidien se terminent souvent après midi. Face à cette indisponibilité quasi permanente, les uti-lisateurs se sont créé des bases parallèles.
Exemple : un constructeur d’automobiles a dépassé les budgets prévus initialement ; il a dès lors entamé les budgets d’entretien de son entrepôt, ce qui ne permet pas d’assurer les évolutions demandées par la direction marketing. Des so-lutions artisanales commencent à fleurir localement : dans les pays, dans chaque segment de véhicule, voire pour chaque véhicule.
Exemple : un constructeur d’automobiles a voulu mettre en place un projet global intégrant l’automatisation des ventes (SFA) et la gestion de campagnes (EMA).
Après plusieurs années, il a constaté des dérapages énormes en termes de délais et de coûts et la nécessité de refondre entièrement certains blocs fonctionnels.
03-Chapitre 3 Page 100 Mercredi, 8. septembre 2004 2:59 14
Chapitre 3 – Collecte et traitement des données : le data warehouse
Pour éviter ce genre de situation, plusieurs mesures peuvent être prises :
• trouver un équilibre entre refus global ou laxisme quant à l’ajout de spécifications ;
• planifier un effort permanent au-delà du lancement du projet ;
• planifier certaines tâches, par exemple, les agrégats, l’historique… en time-framed, c’est-à-dire en fixant a priori le temps imparti et en ne réali-sant que ce qu’il est possible de réaliser dans le respect de ce temps.
L’effet tunnel
Le cycle de créativité marketing est beaucoup plus rapide que d’autres fonctions d’une entreprise. Le risque est donc, sur un projet long, de déca-ler la solution par rapport à des attentes en constante évolution.
Pour éviter ces situations gênantes, quelques précautions élémentaires peuvent suffire :
• trouver des lots réalistes sur six à neuf mois ;
• paralléliser la conception de l’étape suivante avec la réalisation de l’étape en cours.
L’hétérogénéité entre pays et l’anarchie
Dans des contextes internationaux ou décentralisés, les utilisateurs ne sont pas satisfaits de la solution et développent leurs propres fichiers/
outils parallèles. Dans ces conditions, les données deviennent hétérocli-tes, par exemple, plusieurs notions de client, de CA… et la solution globale n’est que partiellement remplie et utilisée.
La qualité des données
Le contenu de la base marketing est inexploitable, soit parce qu’il est insuffisamment renseigné, soit parce que les données sont sales. Dans ce cas, il y a tout à parier que la base marketing devienne marginale et que le processus marketing retourne à l’état artisanal.
Exemple : une grande banque prenait deux mois de retard tous les mois sur son pro-jet de base marketing, car le périmètre était si large au départ que les spécifications évoluaient nécessairement pendant la mise en œuvre.
Exemple : une banque a mis quatre ans à sortir sa base marketing. Entre-temps, les centres d’appels étaient devenus des outils de vente à part entière, et la fonction distribution était totalement distinguée de la fonction production, ce que la base marketing n’avait pas prévu.
Exemple : les responsables du canal Internet d’une enseigne de distribution ont déve-loppé leur propre marketing de base de données. Ils se retrouvent aujourd’hui incapa-bles de prendre en considération les achats des clients en magasin dans leurs ciblages.
03-Chapitre 3 Page 101 Mercredi, 8. septembre 2004 2:59 14
Partie I – Définition et périmètre du CRM
Pour éviter ces situations désagréables, il est souhaitable de mener, parallèlement à la conception, une analyse de la qualité des données, et de lancer une sensibilisation des canaux de collecte d’informations sur la nécessité de recueillir des données de qualité.
L’articulation avec les front offices
La base de données marketing doit s’articuler aux canaux de contact avec le client, faute de quoi les superbes résultats obtenus centralement ne peuvent être relayés en local. On aboutit alors à un manque de cohérence entre le marketing et le commercial, voire à une décrédibilisation du marketing.
L’articulation avec les back offices
La base de données diverge progressivement des systèmes de gestion de l’entreprise, les ERP, car la transformation des entités de gestion en entités marketing est complexe et n’est pas maintenue au gré des évolutions des ERP. Les notions d’entreprise deviennent incohérentes, avec une incapacité à réconcilier les données du contrôle de gestion et celles du marketing.
Cette erreur peut être contournée en gardant, dans la base marketing, les indicateurs primaires et les données transformées.
L’implication des acteurs dans la collecte
La collecte des informations ne fait pas l’objet de contreparties suffisan-tes, notamment auprès des forces de vente. Dès lors, le taux de renseigne-ment baisse, ainsi que la fiabilité des données.
Exemple : un club de fidélité voulait lancer des actions de vente croisée et s’est alors aperçu que les âges et les CSP étaient renseignés à moins de 30 %.
Exemple : un laboratoire pharmaceutique organisait son marketing direct sur une segmentation, alors que ses visiteurs médicaux en exploitaient une seconde pour préparer leurs visites. Cette incohérence a mis le marketing en situation délicate.
Exemple : une société de VPC constate un écart de 10 % entre le CA comptable et le CA marketing issu de la base marketing. Une personne est dédiée à plein temps pour récon-cilier les deux notions afin de fournir des rapports cohérents au contrôle de gestion.
Exemple : une société de crédit revolving met en place une solution de centre d’ap-pels très évoluée pour qualifier les apd’ap-pels. La formation est déployée avec force au démarrage, puis abandonnée sans structure de hot line dédiée. Compte tenu du
03-Chapitre 3 Page 102 Mercredi, 8. septembre 2004 2:59 14
Chapitre 3 – Collecte et traitement des données : le data warehouse
Pour éviter cela, il faut trouver des moyens pour former, assister et motiver les acteurs impliqués sur la collecte, dater les données et trouver des moyens d’offrir des contreparties au renseignement des informations de la base de données.
Le manque de perspective
La base de données est conçue dans une optique à court terme sans ouverture sur les évolutions probables. Dès lors, la prise en compte de changements tels que des nouveaux produits, canaux, marchés ne peut pas se faire dans la base marketing sans une refonte profonde.
Ce biais peut être limité en adoptant une conception générale visionnaire et un macromodèle conceptuel de données ambitieux.
Le manque de réactivité
La base de données dans sa première version est figée et les demandes d’évolution ne sont pas ou sont peu prises en compte. Dès lors, se créent des divergences entre la solution et les besoins.
Ce problème peut être anticipé et contré par une allocation budgétaire préalable pour les évolutions probables et par la nomination d’un admi-nistrateur fonctionnel de la base. Enfin, le projet d’entrepôt doit être vu dans une logique d’étapes rapides et rapprochées.
Le sous-dimensionnement technique
Les requêtes étant non déterministes, il est difficile d’estimer a priori le calibrage technique de l’entrepôt de données. Or, le sous-dimensionne-ment impacte les temps de réponse et la satisfaction des utilisateurs, qui peuvent se lasser si ces délais deviennent inacceptables.
Exemple : la vente par téléphone pour une grande banque n’avait pas été prévue initialement dans la base marketing ; dans ces conditions, il a été nécessaire de lan-cer des évolutions lourdes pour intégrer ces nouvelles conditions.
Exemple : une société de VPC entre sur le marché d’Internet et a donc besoin d’une vi-sion internationale de ses clients. Les budgets ne le permettant pas, la divivi-sion Internet développe sa propre base marketing, au détriment de la vision globale du client néces-saire à l’entreprise. Les offres reçues par un même client, notamment en termes de prix, deviennent incohérentes, ce qui dégrade la qualité perçue par le client.
Exemple : une société de VPC ayant des contraintes budgétaires trop serrées impo-se à impo-ses utilisateurs des délais de requête de deux ou trois jours entre chaque comp-tage complexe. Ceux-ci utilisent de moins en moins la solution et élaborent de manière artisanale différents datamarts plus performants.
03-Chapitre 3 Page 103 Mercredi, 8. septembre 2004 2:59 14
Partie I – Définition et périmètre du CRM
Afin d’éviter cette situation pénible, il est nécessaire de prévoir une marge de manœuvre pour améliorer la solution en fonction des besoins, de nommer un administrateur technique en charge de l’optimisation de la solution et de créer, au fur et à mesure de l’utilisation, des vues métier fondées essentiellement sur des agrégats.
L’absence d’indicateurs de performance
La phase de déploiement d’un entrepôt est une tâche complexe. Les équi-pes techniques sont souvent soulagées de livrer le projet aux utilisateurs pour sortir de la pression exercée par la direction. La livraison est devenue au fur et à mesure du temps la priorité.
Afin d’éviter cette catastrophe, il faut se définir un plan de qualité et ne pas chercher à rattraper les retards de développement sur le plan du déploie-ment. La détermination de baromètres de succès du déploiement de l’entre-pôt, par exemple, le nombre de rendez-vous par vendeur, le taux d’efficacité, etc. doit être incontournable. Le projet ne peut démarrer sans une mesure régulière de ces indicateurs. Leur transcription en revenus ou marges est fortement recommandée pour affronter les questions légitimes sur le retour sur investissement. Un projet CRM n’échappe pas à la règle, il se pilote.
Le one man show
Il arrive souvent qu’un projet d’entrepôt de données soit porté par un seul utilisateur. Dans ce cas, la solution est soutenue à bout de bras par un sponsor charismatique sans relais, et le départ ou la mutation de celui-ci sonne le glas de la solution, qui devient alors rapidement obsolète et dénigrée.
Exemple : une société de distribution spécialisée doit faire face à des retards répé-titifs dans la fourniture d’une application de force de vente. La livraison aux utilisa-teurs sans une phase sérieuse de tests et de recettes se traduit par un rejet global des utilisateurs. L’absence d’indicateurs sur le niveau d’utilisation ne permet pas de suivre la prise en main du produit par les commerciaux. Par ailleurs l’absence d’in-dicateurs sur la relation entre les rendez-vous et les ventes ne permet pas d’appré-cier les gains de performance obtenus par les utilisateurs plus impliqués.
L’entreprise continue avec les deux systèmes pour satisfaire les revendications con-tradictoires.
Exemple : une banque régionale se dote d’une base marketing pour près d’un mil-lion d’euros ; le directeur marketing, seul sponsor de la solution, quitte la société ; la solution est immédiatement abandonnée.
03-Chapitre 3 Page 104 Mercredi, 8. septembre 2004 2:59 14
Chapitre 3 – Collecte et traitement des données : le data warehouse
et de communiquer en interne sur les possibilités de la base afin de susci-ter des vocations d’utilisateurs.
Face à ces écueils potentiels, il n’existe pas de solution miracle, mais quelques conseils de bon sens peuvent être donnés :
• Think big and start small.
• Définir les indicateurs de succès et les convertir en euros.
• Intégrer une logique de processus plutôt qu’une logique de projet.
• S’appuyer sur des experts du domaine.
• Affecter les moyens en conséquence des objectifs et des ambitions.
• Déployer en releases rapides par une hiérarchisation des sources.
• Définir un MCD le plus large et pérenne possible, et accepter une logique où les données ne sous-tendent pas forcément des processus, mais des objectifs stratégiques.
• Prévoir une structure commune et internationale indépendamment des choix d’implantation.
• Intégrer la maîtrise d’ouvrage en continu dans toutes les étapes.
• Faire des audits de la qualité des données.
• Prévoir une sensibilisation particulière des forces de vente.
• Former et prévoir un support significatif.
• Démultiplier les utilisateurs centraux.
• Intégrer la résistance naturelle face au changement.
• Assurer une administration technique et fonctionnelle.
• Accompagner les nouveaux métiers dans la reconnaissance de leurs fonctions.