Pour changer d’outil de dataviz,

4 options :

du "As Is" à la "Self BI"

Migrer d’une solution de data visualisation à une autre est un challenge ambitieux pour une entreprise.

Mais comment s’y prendre pour que ce soit un succès quand la plateforme source a une antériorité considérable avec toute la complexité inhérente ?

Nous avons identifié quatre grandes approches, chacune avec ses avantages et ses limites, selon les besoins métiers, les contraintes techniques et la vision à long terme de l’entreprise concernée.

(Nous avons fait un parallèle qui nous semble pertinent, avec les enjeux d’un "vrai" déménagement dans la "vraie vie" ).

Option #1 :

Le "Big Bang",

la transformation radicale portée par toute l'équipe.

Une migration "Big Bang", c’est comme emménager dans une maison ultra-moderne entièrement redessinée. Pas question de garder les vieux meubles de mamie ou la déco passée de mode : tout est repensé, du mobilier aux espaces de vie.
Les métiers sont les habitants qui définissent leurs besoins dans la maison de destination : "on veut un espace lumineux, tel nombre de pièces, etc.". Les data analysts jouent les architectes et conçoivent des espaces fonctionnels (et élégants). Les data engineers sont les électriciens ou plombiers qui assurent que tout (les flux de données) fonctionne bien. Enfin, les décideurs métiers valident ou invalident les choix.

Avantage :

Une refonte complète pour aligner d'emblée les besoins métiers sur des outils modernes.

Inconvénient :

Les objectifs sont parfois contradictoires entre les parties prenantes avec un risque important d’enlisement : beaucoup de migrations type "Big Bang" échouent.

Option #2 :

Une migration "As Is",

un Copié Collé de la plateforme dans la cible

Une migration "As Is", c’est un peu comme déménager d'une maison à une autre sans changer un seul meuble, tableau ou rideau. Vous emmenez tout : votre canapé et ses coussins, vos cadres et même cette pile de magazines sur la table basse .
Dans votre nouveau "chez vous", tout est recréé à l’identique : pas de nouveaux meubles, pas de peinture fraîche, aucun changement dans l’agencement. En revanche, les sous-jacents techniques (toiture, plomberie, électricité…) ne sont plus les mêmes.
Côté dataviz, cela signifie que l’ensemble des rapports sont migrés tels quels, sans refonte ni optimisation. Les données sont inchangées et la couche sémantique est adaptée en fonction de la technologie cible. Le design et la structure des dashboards sont fidèlement reproduits, "As Is".

Avantage :

Migration rapide et indolore pour les métiers, avec un haut niveau d’adoption de la solution cible.

Inconvénient :

On garde tout, même les doublons ou dashboards inutiles, on garde aussi les mêmes "pathologies" : des lenteurs, des erreurs… C’est une "demi" modernisation.

Voir aussi :

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

Option #3 :

Une migration "As Is"

& une Transformation à l’issue,

pour atteindre l'Optimum dans le temps.

Ici, on déménage rapidement en mode "As Is" pour ne pas perturber les habitants (les métiers), mais une fois installés, on réorganise, on améliore : "Et si on transformait cette pièce en open-space ? Si on remplaçait les vieux meubles ou ajoutait des rangements ?".

Cette approche permet de rationaliser et optimiser la plateforme cible progressivement : supprimer les doublons, fusionner des dashboards similaires et simplifier le système.

Avantage :

Le métier se retrouve dans la technologie cible et il peut participer dans le temps à la rationalisation de la plateforme cible.

Inconvénient :

La réelle transformation de la plateforme cible, si elle doit avoir lieu, sera graduelle.

Option #4 :

Une migration "As Is"

& "Self BI",

pour une véritable Modernisation !

Pour continuer à filer la métaphore, la "self BI", ce serait comme déménager en ne gardant que les meubles essentiels (les rapports stratégiques) et en laissant les habitants (le métier) s’occuper eux-mêmes du reste.

Pour cela, on va mettre en œuvre 3 principes :

Migration "As Is" des rapports stratégiques dans la plateforme cible, pour constituer une "ossature" décisionnelle.
Migration automatisée de la couche sémantique source vers la base de données cible via des modèles en étoiles. On ne migrera que ce qui a un usage réel, de la source vers la cible, pour un modèle le plus simple possible. Les libellés et les logiques de la source seront implémentés dans la cible, pour une transition en douceur.
On donnera la possibilité de piloter cette nouvelle couche sémantique, pour atteindre un optimum à grande vitesse.

Avantage :

Une approche rapide pour les rapports essentiels, tout en offrant une liberté créative aux équipes métier pour concevoir "from scratch" la plateforme de demain. Une modernisation en profondeur.

Inconvénient :

Certaines réponses peuvent manquer à l’appel au départ.

Voir aussi :

Migrer SAP BO vers Looker avec une vraie couche sémantique

CONCLUSION

Le choix d’une approche de migration dépend des priorités de l’entreprise : rapidité, transformation radicale, ou liberté créative, etc.
L’option "As Is" offre une solution rapide et l’adhésion du métier, tandis que le "Big Bang" implique une refonte complète mais hasardeuse.
Une migration progressive avec transformation en douceur peut être un compromis efficace. Enfin, l’approche Self-BI propose un modèle plus autonome.

{openAudit} est une solution que propose Ellipsys et qui permet les migrations As Is pour certains outils de BI, mais aussi les migrations Self BI.

{openAudit} permettra aussi de monitorer la plateforme à l’issue pour faire en sorte qu’elle devienne/reste optimale.
À vous de choisir le mode de migration qui correspond à votre besoin avec l’automatisation d’{openAudit} comme catalyseur !