Définition CRM : ce qu'il faut absolument définir avant de commencer

Pourquoi la définition des besoins n'est pas une perte de temps

Une bonne définition des besoins réduit la durée de l'implémentation et minimise les changements pendant le développement. Elle crée une base commune pour l'équipe de projet, les départements et la direction — ce qui est construit, pourquoi, et qui en est responsable.

Les livrables essentiels

Un Discovery bien mené produit au minimum les livrables suivants :

• Cartographie des processus As-Is et To-Be avec des décisions claires.
• Modèle de données initial — objets, champs clés, relations.
• Modèle de permissions au niveau conceptuel — profils, rôles, partage.
• Liste des intégrations nécessaires avec la direction du flux.
• Backlog documenté avec hiérarchisation pour la première version par rapport aux phases ultérieures.
• Mesures de succès concrètes pour la période post-Go Live.

Les bonnes questions pour les propriétaires de processus

Un bon Discovery ne demande pas « ce que vous voulez dans le système », mais essaie de comprendre comment les choses fonctionnent réellement :

• Que se passe-t-il lorsqu'une nouvelle demande ou un nouveau lead arrive ? Qui gère, qui approuve, qu'est-ce qui est conservé ?
• Quelles décisions sont prises en dehors du système (e-mail, Excel, WhatsApp) ?
• Quels sont les rapports réellement nécessaires à la direction et aux chefs d'équipe ?
• Quelles règles de qualité des données sont essentielles au travail ?
• Que se passe-t-il lorsqu'un employé quitte ou change de poste ?

Ce qui nuit aux processus de définition des besoins

• Définition des besoins gérée uniquement avec l'IT et non avec les propriétaires de processus réels.
• Un document énorme que personne ne lit ni n'approuve.
• Décisions reportées à la « phase de développement » et créant une dépendance sans fin.
• Éviter de dire « non » aux requêtes qui n'ont pas leur place dans une première version.

28. Questions fréquentes