Comment migrer son SI Décisionnel et lui donner un nouvel horizon

Premièrement, il est nécessaire de faire un audit de l’existant sur le niveau d’utilisation de la solution et de le mettre en relief en fonction de la complexité de l’architecture. En effet, un SID a tendance à se complexifier tout au long de la phase de RUN pour répondre à de nouveaux besoins fonctionnels tout en tenant compte des choix initiaux de conception. La particularité d’un SID est liée à sa structure puisque c’est un outil qui répond à un besoin évolutif alors qu’il reste assez rigide en terme de modélisation. Il y a donc différentes « strates » de développement qu’il faut comprendre et structurer afin de mener à bien ce chantier. Au regard de ce constat, il faut accepter la possibilité d’une refonte globale, ou a minima une réflexion d’ensemble sur la simplification des indicateurs et attributs, mais aussi sur l’optimisation de la modélisation et des flux. Bien sûr les impacts sont plus importants dans le cadre d’un SI décisionnel Multi-sources.

Un changement d’outil s’accompagne toujours d’un chantier de recueil des besoins auprès des utilisateurs. En effet, ceux-ci étant très autonomes sur la production de reporting, ils ne communiquent pas systématiquement leurs attentes auprès des équipes support. La compréhension des enjeux et du contexte est donc très importante pour pouvoir proposer aux utilisateurs un gain opérationnel. Cette démarche s’accompagne aussi d’une analyse de la qualité des données présentes dans la base. Cette analyse permettant d’identifier la charge de travail à prévoir au niveau de l’ETL*.

Enfin le choix de l’outil et des droit se faire en fonction de paramètres techniques et opérationnels : Gestion des habilitations, sécurité des données, pérennité de la solution, autonomie des utilisateurs, et impact(s) d’un changement d’IHM. L’outil décisionnel pouvant laisser beaucoup d’autonomie à l’utilisateur, il faut anticiper le degré de liberté à prévoir pour chaque profil cible. Les fonctionnalités étant multiples, il faut trouver un bon équilibre entre la possibilité de créer de nouveaux rapports et la « sacralisation » de reporting/dashboarding standard.

En résumé, il faut pouvoir organiser la migration en plusieurs temps afin d’avoir une démarche cohérente et aider à l’acceptation de l’outil cible pour les utilisateurs finaux :
1. Audit de modélisation
2. Recueil des besoins
3. Définition des flux d’alimentation
4. Redéfinition des fonctionnalités cibles par profil
5. Choix de l’outil
6. Chantier d’homogénéisation du reporting existant
7. Accompagnement au changement


*Extract, Transform, Load = Outil permettant d'effectuer des transferts massifs d'information d'une source de données vers une autre