Conception : Analyse des indicateurs

1.1.1.1      Indicateurs du Rapport 4 : Tableau de bord par agence 

Il s’agit ici d’analyser le parcours complet du prospect de son arrivée dans le système d’information jusqu’à la signature éventuelle du contrat de réservation. Ce tableau devra permettre une analyse précise des rendez-vous. Combien de rendez-vous positionnés par le « service contacts » ? combien de rendez-vous positionnés par le vendeur ? quels sont les taux de transformation ? quel est le pourcentage de rendez-vous réellement faits ? combien de réservations signées ? etc… Tout ceci regroupé par agence, avec une distinction entre les appels entrants et les appels sortants et un détail par origine.

Il ne semble pas pertinent de revenir ici sur les notions de nombre de contacts, de nombre de réservations, de mode de contact, d’origine ou bien d’agence, elles ont été présentées ci-dessus. En revanche il est indispensable d’approfondir la notion de rendez-vous car cet indicateur produira des effets de bord sur l’ensemble du SI.

En effet, afin de suivre et d’analyser les rendez-vous il faut que ceux-là soient saisis dans le CRM. Nous voilà face à une situation où le besoin en termes de restitution entraînera des conséquences lourdes sur la saisie des données. En effet les rendez-vous ne sont que très exceptionnellement saisis dans le CRM au moment où la mise en œuvre de ces indicateurs voit le jour. Comment faire ?

Demander aux différents services concernés de les renseigner dans l’application semble être la réponse évidente. D’autant plus que le CRM prévoit un module (Communications) rendant cela possible. Mais les salariés ne souhaitent pas saisir de manière régulière ces informations. Le module « communication » du CRM est jugé par les salariés concernés beaucoup trop « compliqué », trop « lourd ». Les accès VPN au CRM sont dits trop lents, ce qui rend les saisies en situation de déplacement « fastidieuses ». Face à cette situation il est décidé de modifier le CRM en ajoutant de nouveaux champs directement sur la fiche prospect. Tous les champs préfixés par « mig » correspondront ainsi aux ajouts internes. 

comp_mig_R1 :  Il s’agit de la date du premier rendez vous

comp_mig_r1_crea : Il s’agit du créateur du premier rendez-vous (identifiant de l’utilisateur qui crée l’enregistrement).

comp_mig_r1_etat : Ce champ nous permettra de savoir si le rendez-vous a été effectivement fait.

comp_mig_R2 : Il s’agit de la date du deuxième rendez-vous.

La première résistance a ainsi pu être levée mais nous verrons plus tard qu’il sera nécessaire d’aller bien plus loin pour faire définitivement accepter la saisie régulière de ces informations dans le SI et disposer ainsi de données « rendez-vous » exhaustives. Informations indispensables pour bâtir un rapport faible qui analyse les taux de transformation des rendez-vous.

1.1.1.2      Indicateurs du Rapport 5 : Tableau de bord par vendeur

Nous retrouvons ici une structure identique au Rapport 4 mais le découpage de celui-ci ne se fait plus par agence mais par vendeur. Le vendeur est renseigné directement sur la fiche prospect du CRM et stocké dans la table COMPANY. Un relation de type (1,N) fait le lien entre la table COMPANY et la table USERS qui liste l’ensemble des utilisateurs du CRM. (Un même resposable du compte peut avoir plusieurs milliers de contacts.)

Vendeur : Responsable du compte. Soit l’utilisateur du CRM auquel a été affecté le contact au moment de son arrivée dans le CRM

Nous venons de voir à travers ces quelques exemples le travail de « fouille » nécessaire dans la base de données pour comprendre l’architecture globale des données. Sans rentrer dans tous les détails de cette phase disons simplement que certaines données sont très facilement exploitables, c’est le cas, par exemple, de la donnée « vendeur » qui est directement liée à la fiche prospect, d’autres nécessitent un travail supplémentaire car le modèle relationnel n’est, par exemple, pas pleinement satisfait, c’est le cas de l’origine, du mode de contact ou de la demande de programmes. En effet pour ces 3 dernières informations le lien se fait toujours avec la table Custom_Captions (ou la vue Vcustom_Captions) et ce lien ne respecte pas le modèle relationnel, c’est le champ Capt_Family de la table Custom_Captions qui permet de savoir à quel type d’information correspond l’enregistrement dans la table Custom_Caption. Ainsi un même Capt_Code peut correspondre à 2 informations différentes et dans le CRM c’est le « Capt_Code » (soit le code du libellé de l’information stockée) qui est enregistré sur la « fiche Prospect » et non l’identifiant du libellé (ce qui me semble-t-il serait plus cohérent). Ceci impose, à chaque fois que qu’un lien entre la table Company et la table Custom_Captions est établmi, de préciser quelle est la « famille » de la donnée à laquelle nous nous intéressons (ex : where Capt_Family = ‘comp_Ucara_demprog’)   

L’ensemble de ce travail préparatoire d’analyse des indicateurs et des données, présenté très succinctement dans les précédents paragraphes, permet de produire un tableau des champs nécessaires à la production des rapports que nous pourrions assimiler à un dictionnaire de données (voir Tableau 4). Il convient de préciser que ce document évolue tout au long du projet et à plus forte raison tout au long d’un projet conduit dans un état d’esprit « Agile ».

Tableau 4: Liste des champs nécessaires à la construction des rapports

Nous pouvons constater que l’essentiel des données nécessaires à la création des rapports figurent dans la table company (ou la vue vcompany). Par ailleurs nous n’observons pas, à ce stade, de difficultés particulières pour obtenir le nombre de contacts, ceci quel que soit l’axe d’analyse.

Le sujet du nombre de réservations semble, en revanche, plus complexe. La complexité est avant tout fonctionnelle. En effet, en regardant la structure de la base de données nous pourrions être tentés de considérer que la comptabilisation d’enregistrement dans la table « réservations » suffirait pour obtenir l’indicateur voulu. Comme je l’ai déjà évoqué il n’en est rien. En effet l’entité « RESERVATIONS » représente les « dossiers de réservation » or ce que les salariés appellent, par abus de langage, nombre de réservations correspond en réalité au « nombre de lots principaux réservés ». Pour obtenir cet indicateur il ne suffira donc pas d’un simple comptage, il conviendra de cibler et filtrer les données qu’il sera nécessaire d’extraire.

Comme nous le verrons plus loin ces filtres vont beaucoup évoluer tout au long de cette phase d’analyse et même lors des différents sprints de la phase de développement.

Néanmoins à ce stade du projet nous savons que les données sont bien présentes dans le système. Il convient désormais de vérifier pour chacune d’elles leur « qualité », une phase incontournable pour des rapports fiables.