Qu’est ce qu’un bon use case?
D’après notre expérience, voici une liste non exhaustive, des éléments clés d’un bon use case.
Un use case est mesurable
Sans mesure, impossible de justifier d’identifier les axes d'amélioration.. Cela signifie que pour chacune des actions identifiées dans le cas d’usage il faut définir des indicateurs de mesure.
- D’un point de vue micro : les apports très concrets du déploiement d’une solution de catalogue de méta données par exemple : Les usages utilisant des données sensibles, l’accessibilité aux données, applications contenant des données sensibles, usages de données personnelles... Attention cela peut vite se transformer en course à la complétion, ce qui n’a pas un grand intérêt. Il faut donc absolument introduire deux éléments : des notions temporelles afin d’éviter le soufflé et des éléments plus culturels ( accès à la plateforme par population, retour à la plateforme, utilisation d’une fonctionnalité…)
- D’un point de vue macro : l’évolution selon les axes de la data gouvernance identifiés avec une matrice de maturité. On évalue la maturité Data, on met des actions prioritaires et on mesure l’évolution avant/après apportée par le use case.
Cela permettra également de vérifier que les actions identifiées sont suffisamment pragmatiques. Par exemple, des actions comme “meilleures décisions" ou "meilleure qualité des données" seront difficiles à mesurer
Un use case à un périmètre défini
Les périmètres data sont souvent complexes. Il faut donc absolument limiter le périmètre du use case afin de ne pas se perdre. Ce malgré la puissance des connecteurs qui facilitent la récupération de données. L’objectif n’est pas de créer des centaines de milliers mais bien de rendre compréhensible les plus importants. Au moins dans un premier temps!
Il doit être transverse : Les utilisateurs IT & BI sont souvent déjà convaincus de ces démarches, mais attendent beaucoup des retours métiers. Il faut donc trouver des uses cases qui permettent d’intégrer cette population. Ainsi on pourra multiplier les points de vue et faciliter l’intégration dans le quotidien.
Un use case est marketable
C’est l’un des maillons faibles des démarches de data gouvernance. Il faut être en capacité de susciter un certain attrait, une certaine excitation. Des uses cases pragmatiques (objectif atteignable rapidement, actions concrètes et mesurables…) sont un élément clé de cette excitation.
Les facteurs clés de succès d’un Use case
Choisir son combat
La constitution d’un use case est intéressante en ce qu’elle permet d’identifier les douleurs des équipes de terrain et y associer des actions.
Cela rejoint un sujet qui nous est cher et qui nous est souvent remonté : faut-il mieux une approche Top Down ou Bottom Up ? Bien sûr, l’approche top down permet une certaine légitimité très appréciable sur ce type de démarche. Mais nous avons constaté qu’il s’agit bien souvent d’une démarche hors sol, la justification métier est difficile à identifier. Le soufflé retombe.
L’approche Bottom Up a cet avantage qu’elle permet de s’enraciner dans le quotidien des acteurs en répondant à des douleurs précises. La difficulté est alors de positionner ces actions dans une logique cohérente pour supporter les objectifs métier.
Il faut donc, selon une expression consacrée chez DataGalaxy, “Think big, act small”.
Itérativité et incrémentalité
On l’a vu plus haut, chaque organisation a son propre niveau de maturité et des contraintes qui lui sont propres. Vouloir d’un coût passer de l’anarchie à la data gouvernance 2.0 est illusoire. Il faut donc que les cas d’usages prennent cette réalité en compte et inscrivent la data gouvernance dans une certaine logique de pipeline. Chaque nouveau cas d’usage vient en complément pour renforcer et étendre la data gouvernance : on adresse un domaine différent, on complète le précédent, on touche une autre population etc…
Comment le formaliser?
Voici un exemple de template de description de votre cas d’usage.
Une fois que vous aurez identifié l’objectif de votre use case, ce que vous voulez faire et pour qui, vous pouvez alors le marketer avec une courte phrase d’accroche:
- Je souhaite accomplir une action Contenu
- afin que une population de Bénéficiaires
- obtienne un gain de productivité ou de qualité Objectif
Bien sûr il vous faudra également l’adapter à votre contexte (est ce que la démarche est outillée par exemple) et compléter sa description avec
- Des holders référents fonctionnels de ce projet
- Une core team de déploiement
- Des KPI pour l’objectiver
- Un domaine métier
- Un planning
- …
Nous représentons ces uses cases sous la forme de deux slides : La première est celle qui nous permet de faciliter la présentation du use case
La deuxième est celle qui nous permet de décrire ce à quoi nous souhaitons réellement répondre. Elle peut s’appuyer sur un customer journey d’utilisateur de la data.
A quoi cela peut ressembler?
Voici deux exemples issus de deux sociétés très différentes. Chacune a bien sur pris le temps de décrire, dans d’autres slides :
- Les enjeux / pourquoi il faut gérer ces données, si possible en donnant un contexte métier fort : contribuer à la performance opérationnelle, répondre aux exigences réglementaires, répondre aux nouveaux enjeux…
- Les attendus du projet : en quoi ce use case va répondre aux enjeux
- Où ils souhaitaient afin de donner une cible
- Des éléments pragmatiques sur le projet : équipe, démarche, planning...
Voici un premier cas d’usage tourné vers un projet de type BI
Voici un second cas d’usage tourné vers un projet de type conformité / calcul de churn.
