Richard Aznar est directeur du contrôle de la performance dans les assurances et les services. Il nous fait part aujourd’hui de son expérience sur le maintien et l’évolution du référentiel dans un outil BI en nous livrant ses bonnes pratiques. N’hésitez pas à retrouver un autre article sur le maintien et l’évolution du référentiel de Richard.
Qu’est-ce que tu peux nous dire sur le maintien et l’évolution du référentiel dans un outil BI ?
Il y a une petite année à peu près, on a mis en place un logiciel extrêmement précis et documenté. Puisque le client a des problématiques de facturation très détaillées, sur des actes avec des règles de gestion un peu complexes. le projet était mené en coopération très étroite avec les équipes clients qui ont documentées qui ont rédigé le cahier des charges. Les règles ont été définies, l’outil lui-même a été implémenté il y a une année maintenant. Et tout fonctionne pour le mieux dans le meilleur des mondes. Les rendus sont plutôt beaux, efficaces donc tout va bien jusqu’à ce que l’organisation du client change. Que les sachants qui avait été pressentis pour maintenir l’outil veuillent donner une autre orientation à leur carrière.
Donc, le client revient vers son intégrateur en disant voilà, j’ai un problème je ne sais plus intégrer mes nouvelles règles de gestion. Donc votre outil ne fonctionne pas, et le client fait reporter à son intégrateur cette problématique d’une complexité trop forte de l’outil. De mon point de vue, compte tenu de ce que j’ai pu y voir les règles de gestion sont complexes et l’outil en lui-même est tout à fait capable de gérer des règles de gestion bien plus bien plus larges que ça. Donc ce n’est pas un sujet d’outil, c’est un sujet d’organisation et de prise en compte de cette dimension là de maintenance, qui pour moi est souvent sous-estimée.
Pourquoi est-ce un point important ?
On considère que dans la partie maintien évolution, on va toujours avoir le logiciel lui-même par son éditeur qui va facturer une redevance. L’outil est maintenu, ça c’est vrai, par contre les règles de gestion… On me dit non mais ça a toujours marché comme ça. Ne t’inquiète pas, si ça ne marchait pas on le saurait, on s’en serait rendu compte. Puis quand on regarde en détail, on se rend compte qu’il y a clairement des trous dans la raquette.
Tout simplement parce que cette maintenance au niveau de l’utilisateur n’est pas forcément d’une grande qualité ou qu’il y a des règles qui ont été oubliées et les systèmes divergent petit à petit. C’est une vraie problématique, parce que le client n’est plus en capacité de maintenir l’outil et envisage clairement de recommencer un nouveau projet pour se doter d’un nouvel outil ou de voir dans quelle mesure son intégrateur va pouvoir le dépanner sur le sujet.
Justement, quelles ont été les solutions retenues pour ce cas ?
Je vois deux choix qui sont structurants. Soit les règles de gestion sont relativement simples et c’est assez facile de les faire maintenir par des contrôleurs de gestion, une petite équipe projet. Soit les règles sont complexes et là, il faut faire appel à de la régie, un prestataire extérieur, à qui on va transférer cette obligation de gérer les règles et de maintenir l’opérabilité de notre outil BI. Ce qui est entrain de se passer, puisqu’aujourd’hui pour maintenir son outil, il fait appel de nouveau à un prestataire qui maintient l’outil, qui est la solution qu’il n’avait pas retenue au départ et qui de mon point de vue, est la bonne solution. Parce qu’on transfère sur le prestataire cette obligation et les règles de gestion avec un certain nombre de SLA, moyennant évidemment des coûts.
Mais un ou deux jours de consultant par mois représentent un coût, qui est somme toute par rapport à la taille de l’outil et l’enjeu du projet pas extrêmement élevé. Et, j’insiste sur ce sujet parce que c’est souvent quelque chose que je vois dans différents endroits où j’interviens. C’est une vraie question et dans ce cas là, la problématique client et le choix que le client avait retenu n’était clairement pas pérenne.