.webp)
Dans mon dernier article, j’évoquais l’évolution du marché de l’EPM, porté par des efforts de transformation visant à connecter les différentes fonctions métiers via un outil commun et à optimiser les performances à grande échelle grâce aux technologies OLAP (Online Analytical Processing).
Mais avec le temps, les conditions économiques ont changé. Nous vivons aujourd’hui dans un environnement instable, où la capacité à réagir rapidement aux évolutions du marché devient un véritable avantage concurrentiel. Face à cette nouvelle réalité, les fondateurs de Pigment ont remis en question le statu quo des systèmes EPM.
Les limites des technologies OLAP
L'adoption des technologies OLAP dans les années 1980 a marqué un tournant technologique pour la gestion de la performance. Mais les organisations les plus avancées ont rapidement été confrontées à des contraintes, notamment en matière de gestion de la donnée, de gestion des hiérarchies et des relations et de scalabilité.
Gestion des données (gestion de la sparsité)
Les cubes multidimensionnels OLAP sont conçus pour les ensembles de données denses, où la majorité des combinaisons de dimensions contiennent des données. En réalité, dans la pratique, bon nombre de ces combinaisons peuvent être vides, générant ainsi de la sparsité.
.webp)
Et pourtant, chaque intersection possible entre les dimensions se voit attribuer un espace de stockage, même en l’absence de données pertinentes.
Chaque agrégation ou calcul déclenche un traitement sur toutes ces intersections, qu’elles contiennent ou non des données. C'est pourquoi il est judicieux de maximiser le nombre d'intersections qui stockent les données.
Pour optimiser les performances, les organiation tentent alors de remplir artificiellement un maximum d’intersections — en fusionnant les niveaux des hiérarchies autour du plus petit dénominateur commun à l’échelle de l’organisation. Cela se fait nécessairement au détriment de la granularité des analyses et des rapports.
Prenons l'exemple suivant : imaginons une analyse des revenus produits par région (en violet) et par mois (en bleu). Un produit est vendu uniquement au Canada, en février, dans le cadre d’une promotion pour la Saint-Valentin. Pour capturer cette donnée dans le cube, le Canada devra être ajouté comme région distincte. Cela entraînera la création de stockage pour chaque mois — alors que des données n’existeront que pour février.
Pour minimiser le stockage, on pourrait décider de fusionner le Canada avec les États-Unis sous une dimension unique "Amérique du Nord".
Conséquence : impossible de distinguer les revenus générés au Canada l’année suivante et de capitaliser sur le succès potentiel de la promotion.
Gestion des hiérarchies et des relations
Les cubes OLAP OLAP impose une agrégation préalable des données selon les dimensions définies à l’origine. Toute modification structurelle ultérieure perturbe l’ensemble du cube.
De plus, la création de structures différentes pour répondre à des besoins de reporting spécifiques devient complexe. Si, par exemple, l'équipe finance répartit les dépense liés aux effectifs par région, mais que l’IT budgétise les dépenses de masse salariale par projet couvrant plusieurs zones, il faudra alors créer une correspondance entre collaborateurs, la région et les projets. Si cette répartition évolue (en ajoutant par exemple un pourcentage de temps par projet), toute la hiérarchie doit être revue.
Les organisations s'appuient généralement sur les équipes IT ou sur d'exoerts externes pour maintenir et aligner leurs structures de données. Cela coûte cher, prend du temps et rend les ajustements rarement immédiats, poussant les équipes à planifier avec des données obsolètes.
Évolutivité
Les bases de données OLAP offrent de bonnes performances en matière de récupération des données, car elles fonctionnent en mémoire. Mais cela limié souvent leur déploiement à des serveurs ou des architectures mono-serveur, avec une puissance de traitement limitée.
La puissance des bases de données relationnelles
Pigment s’appuie sur les avancées des bases de données relationnelles pour proposer une nouvelle approche : plus flexible, plus performante à grande échelle.
Les bases relationnelles gèrent nativement la sparsité : seules les combinaisons contenant des données sont stockées. Résultat : des hiérarchies de produits, de régions ou de départements complètes peuvent coexister sans sacrifier la granularité.
La gestion et la maintenance des hiérarchies est également facilitée, car tout enregistrement peut être lié à un autre par n'importe quel attribut ou propriété. On peut ainsi ajouter ou modifier des tables de propriétés, relier des enregistrements complexes et effectuer des analyses multidimensionnelles en toute agilité.
Pigment devient ainsi une réplique digitale de l'organisation, une sorte de jumeau organisationnel numérique.
Mais le défi des bases de données relationnelles a toujours été d'améliorer leurs performances lors de l'exécution de ces manipulations de données. Alors, comment Pigment résout-elle ce problème ?
Le secret de Pigment
Sans dévoiler tous les secrets de notre équipe produit (nous y reviendrons dans le prochain article), le moteur Pigment est conçu pour être flexible et optimisé pour davantage de performance. Pigment est ainsi conçue pour fonctionner à grande échelle. Cela passe par plusieur leviers : une infrastructure adaptée à chaque client, une optimisation du traitement des calculs pour une expérience optimale de l'utilisateur final et une consolidation en amont des représentations des données - avant même leur consultation. Résultat ? Une expérience de navigation et une analyse des données plus fluides que jamais.
Pour réserver votre démonstration de la plateforme Pigment, cliquez ici.
