Trois clefs pour réussir sa base de données

15-11-2005 • La réussite d’une base de données repose sur trois facteurs qui sont des clefs de succès indissociables.

 Constat > 

Un grand nombre de projets de bases de données engendrent insatisfaction ou même abandon pur et simple du projet. Il en résulte pour les commanditaires une perte de temps et d’argent qui peut prendre des proportions considérables. On compte nombre de projets GRC (Gestion de la Relation Client, ou CRM) qui ont été des gouffres financiers sans apporter une pleine satisfaction à leurs commanditaires.

Pour Microsoft, le succès ou l'échec de la plupart des initiatives GRC se résument en trois points : l'adoption par l'utilisateur, l'adéquation commerciale et le coût total de possession. Voyons les causes les plus fréquentes de ces revers, qu’il s’agisse d’une base de clients ou de tout autres applications sous forme de fichier.

Les blocages

Le frein le plus fréquent est celui d’un blocage technique. Bien souvent, l’outil ne fonctionne pas à 100% car il n’a pas été débogué ou que petit à petit sa performance décroît. Dans d’autres cas, il peut s’agir d’un problème de rapidité d’accès aux données (serveur indisponible, accès internet ralenti, volumes de données trop importants, etc). L’autre frein qui peut être rencontré est celui de la conception même de l’outil dont la structure ne correspond pas réellement aux besoins rencontrés. Soit parce qu’il manque des paramètres ou des champs importants pour l’exploitation de l’outil, soit parce que l’évolution des besoins a rendu l’application inopérante. L’acquisition d’un outil « clef en main » est souvent la cause de ces abondons : l’outil conçu pour une clientèle en masse ne répond pas à vos besoins précis.

numéro de TVA Intracommunautaire conversion depuis le SIREN à partir de 159€

La complexité

L’adage « trop d’informations, tue l’information » serait-il applicable aux bases de données ? Oui, dans certains cas. Sur des projets complexes ou avec des intervenants différents un outil de gestion des informations peut dès sa naissance être surdimensionné. Il peut arriver qu’à l’origine du projet les usagers consultés aient des attentes personnelles différentes. Or, si le rôle du chef de projet est bien d’écouter tous les avis, il doit en définitive arbitrer entre les besoins réels et les envies trop personnelles ou irréalistes. On constate souvent que sur un projet mal dimensionné, le nombre de champs présents dans la base est important. C’est-à-dire que tout à été prévu pour tous les cas de figure, même les plus hypothétiques. On confond souvent les champs nécessaires avec les champs dit « de confort ». Les conséquences sont immédiates : le nombre d’informations à renseigner est tel qu’il fait fuir les utilisateurs, ou qu’ils n’en remplissent qu’une partie. Dans des cas extrêmes (par exemple sur les formulaires par internet), l’utilisateur préfère mettre des données fausses plutôt que de passer trop de temps à renseigner l’outil ! Nous écarterons de cet exemple le cas d’une base de données prévue pour des sujets à risques où tous les paramètres doivent être pris en compte. Mais en pratique, simplicité rime souvent avec praticité.

Les intérêts personnels

Le manque de motivation est une conséquence fréquente des mauvais résultats des bases de données. Souvent, l’utilisateur ne voit pas quel intérêt il peut avoir à utiliser un nouvel outil ou à remplir un formulaire dont il n’a pas l’usage. Comme le dit le proverbe : « on ne fait pas boire un âne qui n’a pas soif » ! Dans d’autres cas, la contrainte de l’outil est liée à une perte de liberté. C’est souvent le cas d’approches commerciales (outils SFA, Sales Forces Automation). Dans une organisation, l’intérêt du demandeur d’une base de données n’est pas forcément compatible avec les motivations des usagers. Les équipes de vente se méfient d’un outil qui, pensent-elles, pourraient permettre une « surveillance » de leur travail. Dans certains cas, les commerciaux ne souhaitent tout simplement pas partager leurs données avec les autres de peur de se faire subtiliser une opportunité par un collaborateur.

La saturation

Beaucoup de bases de données bien conçues à l’origine perdent de leur qualité au fil des mois. L’information intéressante à un moment T est devenue obsolète et se confond avec les données récemment ajoutées. C’est souvent le cas des contacts physiques. Dans d’autres cas, la base de données est renseignée par des imports massifs de données achetées à l’extérieur (par exemple, un fichier de contacts). Le volume important de données ralentit la consultation et rend moins performante la segmentation et l’analyse des contenus.

 Objectif > 

 Méthode > 

La réussite d’une base de données repose sur trois points indissociables : la prise en compte des utilisateurs, la connaissance des contenus et enfin la performance technologique.

Première clef : la prise en compte des utilisateurs

Il s’agit de prendre l’utilisateur dans toutes ses dimensions. C’est-à-dire les personnes physiques et l’organisation dans laquelle elles évoluent. Dans bien des cas, il faudra distinguer et prendre en compte différentes typologies d’utilisateurs :

• Les utilisateurs qui alimentent l’outil au quotidien : qu’ils soient en interne ou qu’il s’agisse de clients. Et ce, quel que soit le canal. Directement, comme sur internet ou par la saisie directe sur un outil. Ou indirectement, via un media intermédiaire comme l’est le courrier papier (est-ce que le rédactionnel et la forme du courrier invite le destinataire à répondre de façon satisfaisante ?)
  
  
• Les utilisateurs qui manipulent les données récoltées : il faut consulter ceux qui doivent sélectionner, trier, segmenter les données pour analyse.
  
  
• Les techniciens : leur consultation en amont du projet permet de délimiter les fonctionnalités technologiques de l’outil.
  
  
• Le management : il souhaite des résultats quantifiables, l’outil doit pouvoir leur apporter cela, en précisant à quel terme.

S’intéresser aux utilisateurs, c’est aussi comprendre et formaliser l’organisation de la collecte de l’information. Le meilleur outil ne sera jamais performant si en amont, les hommes et femmes qui travaillent sur l’alimentation n’ont pas des méthodes communes, opérationnelles et reconnues. L’assentiment de tous est aussi important que l’adhésion à une organisation du travail.

Enfin, toujours dans cette démarche tournée vers l’usager, le chef de projet doit pouvoir se mettre à la place des utilisateurs et se poser les bonnes questions. Les attentes ne sont pas toutes précises, directes et pragmatiques… Ainsi, en tant qu’utilisateur :

• Comment vais-je tirer un intérêt personnel de ce nouvel outil ?
  
  
• Est-ce que le résultat de mon travail s’en ressentira positivement ?
  
  
• Est-ce un instrument qui valorisera mon poste ?
  
  
• Pourrais-je gagner du temps pour me consacrer à tes tâches plus valorisantes ?
  
  
• Est-ce que cet outil est compatible avec mon organisation ?
  
  
• Est-on dans la réalité des besoins ou dans un objectif un peu trop idéaliste ?
  
  
• Peut-on vraiment affirmer que ce projet me fera prendre de meilleures décisions ou augmenter mes marges ?
  
  
• Est-ce un passage obligé ? Comment les différents utilisateurs peuvent trouver leur intérêt à ces outils ?

En somme, l’attitude générale sera de trouver la meilleure solution pour chacun, malgré des attentes singulièrement différentes. C’est l’attitude « gagnant-gagnant » qui permet de transformer un projet de base de données en succès.

Structuration Mises à jour groupées de données Mettez de l'ordre dans vos données à partir de 79€

Deuxième clef : comprendre les contenus

Il arrive que des projets de bases de données soient entièrement portés par un service informatique qui ne maîtrise pas forcément tous les tenants et aboutissants des contenus. Comprendre, c’est appréhender les données sous toutes les formes :

• Quelles sont les échelles de valeurs : certaines données doivent être exhaustives ou facultatives, fermées ou ouvertes… ?
  
  
• Dans certains cas, faut-il imaginer un contrôle d’unicité afin de prévenir la génération de doublons ?
  
  
• Structure de la base de données et intégrité référentielle : quelles sont les données liées à d’autres ? Par exemple, si les contacts dépendent de sociétés, faut-il supprimer automatiquement les contacts d’une société dont les données sont effacées ?
  
  
• Certaines données peuvent-elle être contrôlées afin d’assurer une meilleure qualité de l’outil ? Par exemple, le numéro de TVA intracommunautaire peut-être vérifié automatiquement.
  
  
• Quels sont les paramètres de normalisation des données : par exemple, l’adresse postale ou l’email doivent-ils être normalisés ?
  
  
• Comment mettre en place des procédures de surveillance sur des données à risque ?
  
  
• Quels sont les critères qui rendent obsolètes les informations saisies ? Et comment assurer une pérennité ou une mise au ban des données périmées.
  
  
• Compte tenu de la difficulté à assurer une bonne mise à jour de certaines informations, quel choix faut-il faire : rendre cette donnée facultative ou ne pas la saisir ?

Troisième clef : maîtriser la technologie

On distingue plusieurs dimensions pour la réussite technique du projet.

• La scalabilité : ce terme d’origine anglo-saxonne désigne la faculté qu’a une base de données de résister à l’augmentation du volume des données. Un outil bien conçu doit dépasser le volume maximum prévu en terme de nombre d’enregistrements dans la base.
  
  
• La rapidité : l’accès aux données doit être facilité par un temps de réaction réduit à son minimum ou à défaut acceptable par les utilisateurs.
  
  
• L’ergonomie : des tests de « usability » pourront être menés auprès d’utilisateurs afin d’améliorer le rendement des formulaires de saisie et de l’agencement des différentes données les unes par rapport aux autres. Il faut savoir qu’un tel travail auprès des utilisateurs permet parfois de développer considérablement le rendement d’une opération. Cela donne par exemple des résultats tangibles dans le domaine du commerce électronique.
  
  
• L’accessibilité : la majeure partie des bases de données sont accessibles par un ordinateur connecté au réseau, soit sur le réseau interne d’une organisation, soit par internet ou maintenant par téléphone. Les connexions à distance doivent dans tous les cas être testées. Dans d’autres cas, l’accès peut être asynchrone. Cela signifie qu’il existe des versions déportées de la base de données qui doivent être régulièrement synchronisées avec la base centrale (on parle aussi de réplication). Ce genre de paramètres doit être géré avec rigueur sinon il engendre rapidement une altération rapide des données.
  
  
• La confidentialité : naturellement, on devra mettre en place un système qui assure une sécurité des données. Certaines parties d'une même application peuvent avoir différents niveaux de confidentialité, ce qui dans bien des cas permet de résoudre les problèmes de partage de l'information.

 Solutions 
 Datalgo > 

• Abonnez-vous pour recevoir régulièrement les flashs conseils Datalgo.

• Consultez les anciens flashs Datalgo.

• Insérez les flashs Datalgo sur votre site au format .

Tous droits réservés
Le contenu de cette lettre d'information
ne saurait engager la responsabilité de Datalgo.