Aujourd’hui j’ai le goût de vous parler de deux problématiques que je rencontre régulièrement et qui, dans la majorité des projets, ont un impact direct sur un projet: la confirmation de l’existence d’une donnée et l’identification de son propriétaire.

Déroulement standard d’un projet informatique

Que ce soit dans le cadre du développement d’un système informatique, dans le cadre de la mise en place d’un site internet ou lors de l’intégration d’un logiciel, l’équipe de projet en viendra à identifier les informations entrantes qui seront requises. Parmi ces informations, certaines seront existantes et d’autres devront être ajoutées aux systèmes sources. Et, face à chacune des données, l’équipe se positionnera : la donnée existe déjà ou la donnée n’existe pas encore.

Mais avant d’aller plus loin, prenons un exemple concret. Prenons l’exemple de la donnée ‘Nom du produit’. Donnée qui serait nécessaire par exemple, dans le cadre de la mise en place d’un catalogue de produits sur internet.

Houra, la donnée existe !

Une erreur trop fréquente est de conclure sur différentes bases que la donnée existe et de ne pas pousser plus loin le questionnement.

Les impressions sont parfois trompeuses

En effet, trop souvent les gens vont supposer que parce qu’une donnée porte un nom semblable dans le système source et bien qu’on doit parler de la même chose. Ou pire, ils ont vu la donnée sur un rapport quelconque utilisé dans l’entreprise et ils en concluent que la donnée existe quelque part. Oh que de surprises lorsque vient le moment d’importer la donnée dans le nouveau système.

Surprise, la donnée ne correspond pas du tout à ce que l’on a besoin ou tout simplement, elle n’existe pas du tout autre que dans des fichiers Excel servant de rapport!

Confirmer que la donnée existe

Mais il est possible de diminuer la probabilité que ce risque se produise en s’assurant que les tâches suivantes seront effectuées:
1. Valider que la donnée qui semble être existante serve bel et bien le même objectif que ce que l’on recherche. On comprend vite que ce que le projet appelle ‘Nom du Produit’ et ce qui s’appelle dans le système source ‘Nom du Produit’ peut représenter deux informations différentes (ex : dans un cas on parle du nom du produit chez le fournisseur alors que ce qui est nécessaire pour le projet est le nom Marketing, le nom connu des clients).

2. Valider la qualité de la donnée. Et là lorsque l’on parle de qualité, il y a de multiples angles. En voici quelques-uns:

- Est-ce que la donnée est actuellement complète (e.x. est-ce que tous les produits ont un nom marketing de produit?)

- Est-ce que la donnée est consistante? (e.x. certains écrivent le nom de produit en majuscule, d’autres en un mélange des deux, certains noms comportent des abréviations)
- Est-ce que la donnée est Disponible à temps? (ex : est-ce que le nom de produit marketing est entré dans le système que quelques semaines après la disponibilité de l’item sur le marché?)
- Est-ce que la donnée est Modifiable par n’importe qui? (ex : est-ce que n’importe qui peut inscrire n’importe quoi le champ?)
- Est-ce que la donnée est reconnue comme étant fiable dans l’entreprise?
- Etc

En résumé, une fois les données entrantes requises identifiées assurez-vous d’avoir une tâche de prévue afin de confirmer que la donnée soi-disant existante conviendra réellement.

La donnée n’existe pas : pas de problème, on va l’ajouter!

Dans le feu d’un projet informatique, lorsque l’on voit qu’une donnée d’information n’existe pas, la réponse est simple : on va l’ajouter! Soyez honnête, à quel moment vous demandez-vous réellement :

- Mais qui va saisir cette nouvelle information?
- Cette saisie va s’intégrer dans quel processus de travail?
- Qui va lui fournir l’information?
- etc

Malheureusement, vous serez d’accord, c’est trop souvent au moment de passer le système en test ou en production que la question se pose. C’est du moins malheureusement ce que je constate de projet en projet.

Et pourquoi les équipes de projet ont tendance à faire cela : c’est qu’en tant qu’équipe de projet on sous-estime les efforts en lien avec l’assignation d’un propriétaire à une donnée. Mais pourquoi est-ce si compliqué d’avoir un propriétaire de données?

N’en jetez plus la court est pleine!

Combien d’entreprises ont vécues des coupures? On oublie trop souvent que l’ajout de données augmente souvent la tâche de travail des ressources. Et rare de nos jours sont les ressources qui n’ont pas déjà une charge de travail très importante. Quand on se met à la place des patrons de ces ressources, on peut comprendre qu’il veuille faire du ‘pas dans ma court’ et éviter d’ajouter une autre tâche supplémentaire à leurs ressources.

What’s in it for me

Parfois, il sera plus logique de demander à un groupe bien précis de saisir la donnée alors qu’il est claire qu’ils ne vont en rien en bénéficier. Il faut alors amener le groupe à comprendre que pour eux seuls, le bénéfice de gérer cette donnée est inexistant. Par contre, pour l’entreprise,cette donnée est nécessaire.

Ok mais qui va me dire quoi inscrire?

Les informations ne tombent pas du ciel. C’est une chose d’identifier la personne qui va saisir l’information, mais faut-il encore qu’elle sache quoi inscrire. Parfois, c’est à cet endroit que le bas blesse.

Il est possible de diminuer les probabilités qu’une telle situation se produise simplement en s’assurant de:

- Définir clairement la donnée;
- Trouver immédiatement le propriétaire de la donnée et obtenir la confirmation;
- S’assurer que cette personne comprend la définition de la donnée, qu’elle l’endosse et qu’elle donne son opinion sur la donnée (vous pourriez être surpris par ce que vous allez apprendre);
- Identifier le processus à haut niveau qui supportera la mise à jour de cette donnée (qui va participer? Est-ce que quelqu’un doit fournir une info préalablement au travail? Est-ce que la donnée est critique et doit arriver à un moment bien précis? Etc) et s’assurer que tous endossent leur rôle.

Que vous ayez planifié ces tâches ou non, si de nouvelles données doivent être créées, vous devrez passer par ces étapes.

Conclusion

En se questionnant tôt dans le projet sur ces aspects et en planifiant ces tâches, vous éviterez des maux de tête certains. La dernière chose que vous voulez c’est qu’aucun propriétaire ne soit identifié et que des ressources de votre département informatique deviennent responsables de gérer ces données. Vous l’admettrez, ce serait une très mauvaise utilisation du personnel informatique de votre entreprise.

Ce billet a été publié par NancyClermont  | créé le 06-05-2011 | classé sous Bonne pratique.