To change dataviz tool, 4 options : from “ As Is” to “ Self BI”

 

To change dataviz tool,

4 options  :

from “ As Is”  to “ Self BI”

Migrating from one data visualization solution to another is an ambitious challenge for a company.

But how do you make it successful when the source platform has considerable precedence with all the inherent complexity?

 

We have identified four main approaches, each with its advantages and limitations, depending on the business needs, technical constraints and long-term vision of the company concerned.


(We have made a parallel which seems relevant to us, with the challenges of a "real" move in "real life"  😊).

 

Option #1:

The Big Bang" ,

the radical transformation carried out by the entire team. 

A "Big Bang" migration is like moving into an ultra-modern house that has been completely redesigned. There is no question of keeping grandma's old furniture or outdated decor: everything is redesigned, from the furniture to the living spaces.
The professions are the residents who define their needs in the destination house: "we want a bright space, such and such number of rooms, etc.".  Data analysts play the role of architects and design functional (and elegant) spaces. Data engineers are the electricians or plumbers who ensure that everything (data flows) works well. Finally, the business decision-makers validate or invalidate the choices.

Advantage : 

A complete overhaul to immediately align business needs with modern tools. 

Inconvenience : 

The objectives are sometimes contradictory between the stakeholders with a significant risk of getting bogged down: many "Big Bang" type migrations fail.

 

 

Option #2:

An “As Is” migration,

a Copy Paste from the platform into the target 

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 : 

 

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.  
  • We will provide the possibility to pilot this new semantic layer, to reach an optimum at high speed.  

Advantage : 

A fast approach for essential reports, while offering creative freedom to business teams to design "from scratch" the platform of tomorrow. A deep modernization. 

Inconvenience : 

Some answers may be missing initially. 

See also: 

 

CONCLUSION 

The choice of a migration approach depends on the priorities of the company: speed, radical transformation, or creative freedom, etc.
The "As Is" option offers a quick solution and business buy-in, while the "Big Bang" option implies a complete but risky overhaul.
A gradual migration with a smooth transformation can be an effective compromise. Finally, the Self-BI approach offers a more autonomous model.

{openAudit}  is a solution offered by Ellipsys that allows As Is migrations for certain BI tools, but also Self BI migrations.

{openAudit}  will also allow you to monitor the platform at the end to ensure that it becomes/remains optimal. It's up to you to choose the migration mode that matches your needs with {openAudit}
automationas a catalyst! 

 

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

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

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque