Business Intelligence (BI)

La Business Intelligence (BI) fait référence à une classe de logiciels d’entreprise dédiés à la production de rapports analytiques principalement basés sur les données transactionnelles collectées à travers les différents systèmes d’entreprise utilisés par la société. La BI vise à offrir des capacités de reporting en libre-service aux utilisateurs qui ne sont pas des spécialistes de l’informatique. Ces capacités en libre-service peuvent aller de l’ajustement des paramètres sur des rapports existants à la création de nouveaux rapports complets. La plupart des grandes entreprises ont au moins un système BI en fonctionnement en plus de leurs systèmes transactionnels, ce qui inclut fréquemment un ERP.

Origine et motivation

Le rapport analytique moderne est apparu avec les premiers prévisionnistes économiques^{1 2}, principalement aux États-Unis, au début du XXe siècle. Cette première itération s’est révélée extrêmement populaire, attirant l’attention de la presse grand public et une large diffusion. Cette popularité a démontré un intérêt marqué pour les rapports quantitatifs à haute densité d’informations. Au cours des années 1980, de nombreuses grandes entreprises ont commencé à conserver leurs transactions commerciales sous forme d’enregistrements électroniques, stockés dans des bases de données transactionnelles, en utilisant généralement des solutions ERP précoces. Ces solutions ERP étaient principalement destinées à rationaliser les processus existants, améliorant ainsi la productivité et la fiabilité. Cependant, beaucoup ont compris l’énorme potentiel inexploité de ces enregistrements et, en 1983, SAP a introduit le langage de programmation ABAP³, dédié à la génération de rapports basés sur les données collectées au sein de l’ERP lui-même.

Cependant, les systèmes de bases de données relationnelles, tels qu’ils étaient généralement vendus dans les années 1980, présentaient deux limitations majeures en ce qui concerne la production de rapports analytiques. Premièrement, la conception des rapports devait être réalisée par des spécialistes de l’informatique hautement qualifiés. Cela rendait le processus lent et coûteux, limitant considérablement la diversité des rapports pouvant être introduits. Deuxièmement, la génération des rapports était très exigeante pour le matériel informatique. Les rapports ne pouvaient généralement être produits que pendant la nuit (et en mode batch), lorsque les opérations de l’entreprise étaient interrompues. Dans une certaine mesure, cela reflétait les limitations du matériel informatique de l’époque, mais cela reflétait également les limitations logicielles.

Au début des années 1990, les progrès du matériel informatique ont permis l’émergence d’une nouvelle classe de solutions logicielles, les solutions de Business Intelligence ⁴. Le coût de la RAM (mémoire vive) diminuait régulièrement, tandis que sa capacité de stockage augmentait constamment. Par conséquent, stocker une version spécialisée et plus compacte des données commerciales en mémoire (dans la RAM) pour un accès immédiat est devenu une solution viable, tant du point de vue technologique qu’économique. Ces développements ont permis de résoudre les deux principales limitations des systèmes de reporting mis en œuvre une décennie plus tôt : les nouvelles interfaces logicielles étaient beaucoup plus accessibles aux non-spécialistes, et les nouvelles infrastructures logicielles, basées sur les technologies OLAP (discutées ci-dessous), ont éliminé certaines des plus grandes contraintes informatiques. Grâce à ces avancées, les solutions de BI sont devenues courantes parmi les grandes entreprises à la fin de la décennie.

Alors que le matériel informatique continuait à progresser, une nouvelle génération d’outils de BI a émergé à la fin des années 2000 ⁵. Les systèmes de bases de données relationnelles des années 1980, qui étaient incapables de produire facilement des rapports, sont devenus de plus en plus capables de stocker l’historique transactionnel complet d’une entreprise en RAM. Par conséquent, des requêtes analytiques complexes pouvaient être effectuées en quelques secondes sans avoir besoin d’une infrastructure OLAP dédiée. Ainsi, l’accent des solutions de BI s’est déplacé vers le front-end, offrant des interfaces utilisateur web encore plus accessibles - principalement en tant que service (SaaS) - tout en proposant des tableaux de bord de plus en plus interactifs qui exploitaient la polyvalence de l’infrastructure relationnelle.

OLAP et cubes multidimensionnels

OLAP signifie Online Analytical Processing (traitement analytique en ligne). OLAP est associé à la conception de l’infrastructure d’une solution de BI. Le terme, inventé en 1993 par Edgar Codd, fédère une série d’idées de conception logicielle ⁶, dont la plupart remontent aux années 1990, voire aux années 1960. Ces idées de conception ont été déterminantes dans l’émergence de la BI en tant que classe distincte de produits logiciels dans les années 1990. OLAP a permis de relever le défi de produire des rapports analytiques actualisés en temps voulu, même lorsque la quantité de données impliquée dans la production du rapport était trop importante pour être traitée rapidement.

La technique la plus simple pour produire un rapport analytique actualisé consiste à lire les données au moins une fois. Cependant, si l’ensemble de données est si volumineux ⁷ qu’il faut des heures (voire des jours) pour le lire intégralement, la production d’un rapport actualisé prendra également des heures ou des jours. Ainsi, pour produire un rapport actualisé en quelques secondes, la technique ne peut pas consister à relire l’ensemble des données à chaque demande de rafraîchissement du rapport.

OLAP propose d’exploiter des structures de données plus petites et plus compactes - reflétant les rapports d’intérêt. Ces structures de données spécifiques sont conçues pour être mises à jour de manière incrémentielle à mesure que de nouvelles données deviennent disponibles. Ainsi, lorsqu’un rapport actualisé est demandé, le système BI n’a pas besoin de relire l’ensemble de l’ensemble de données historiques, mais seulement la structure de données compacte qui contient toutes les informations nécessaires pour générer le rapport. De plus, si la structure de données est suffisamment petite, elle peut être conservée en mémoire (dans la RAM) et donc être consultée plus rapidement que le stockage persistant utilisé pour les données transactionnelles.

Prenons l’exemple suivant : imaginez un réseau de vente au détail exploitant 100 hypermarchés. Le directeur financier souhaite un rapport avec le total des ventes en euros par magasin et par jour au cours des 3 dernières années. Les données de vente historiques brutes au cours des 3 dernières années représentent plus d’un milliard de lignes de données (chaque code-barres scanné dans chaque magasin pour cette période) et plus de 50 Go sous leur format tabulaire brut. Cependant, une table avec 100 colonnes (1 par hypermarché) et 1095 lignes (3 ans * 365 jours) totalise moins de 0,5 Mo (à raison de 4 octets par nombre). De plus, à chaque transaction, les cellules correspondantes dans la table peuvent être mises à jour en conséquence. La création et la maintenance d’une telle table illustrent à quoi ressemble un système OLAP en interne.

Les structures de données compactes décrites ci-dessus prennent généralement la forme d’un cube OLAP, également appelé cube multidimensionnel. Les cellules existent dans le cube à l’intersection des dimensions discrètes qui définissent la structure globale du cube. Chaque cellule contient une mesure (ou une valeur) extraite des données transactionnelles d’origine, souvent appelée table des faits. Cette structure de données est similaire aux tableaux multidimensionnels que l’on trouve dans la plupart des langages de programmation courants. Le cube OLAP se prête aux opérations de projection ou d’agrégation efficaces le long des dimensions (comme la somme et la moyenne), à condition que le cube reste suffisamment petit pour tenir dans la mémoire de l’ordinateur.

Reporting interactif et visualisation des données

Rendre les capacités de reporting accessibles aux utilisateurs finaux qui ne sont pas des spécialistes de l’informatique a été un facteur clé dans l’adoption des outils BI. Ainsi, la technologie a adopté une conception WYSIWYG (what-you-see-is-what-you-get), reposant sur des interfaces utilisateur riches. Cette approche diffère de l’approche habituelle pour interagir avec une base de données relationnelle, qui consiste à composer des requêtes à l’aide d’un langage spécialisé (comme SQL). L’interface habituelle pour manipuler un cube OLAP est une interface matricielle, comme les tableaux croisés dynamiques dans un programme de tableur, qui permet aux utilisateurs d’appliquer des filtres (appelés slice and dice dans la terminologie BI) et d’effectuer des agrégations (moyenne, min, max, somme, etc.).

Sauf pour le traitement de jeux de données particulièrement volumineux, le besoin de cubes OLAP a diminué à la fin des années 2000, parallèlement aux progrès considérables réalisés dans le matériel informatique. De nouveaux outils BI “légers” ont été introduits avec un accent exclusif sur le front-end. Les outils BI légers ont été principalement conçus pour interagir avec des bases de données relationnelles, contrairement à leurs prédécesseurs “lourds” qui exploitaient des back-ends intégrés comprenant des cubes OLAP. Cette évolution a été possible car les performances des bases de données relationnelles, à cette époque, permettaient généralement d’exécuter des requêtes complexes sur l’ensemble des données en quelques secondes - à condition que le jeu de données reste en dessous d’une certaine taille. Les outils BI légers peuvent être considérés comme des éditeurs WYSIWYG unifiés pour les différents dialectes SQL qu’ils prenaient en charge. (En réalité, sous le capot, ces outils BI génèrent des requêtes SQL.) Le principal défi technique était l’optimisation des requêtes générées, afin de minimiser le temps de réponse de la base de données relationnelle sous-jacente.

Les capacités de visualisation des données des outils BI étaient largement une question de présentation des données côté client, que ce soit via une application de bureau ou web. Les capacités de présentation ont progressé régulièrement jusqu’aux années 2000, lorsque le matériel de l’utilisateur final (par exemple, les stations de travail et les ordinateurs portables) a commencé à dépasser largement (du point de vue du calcul) ce qui était nécessaire à des fins de visualisation des données. De nos jours, même les visualisations de données les plus élaborées sont des processus peu exigeants, éclipsés en termes d’échelle par la consommation de ressources informatiques associée à l’extraction et à la transformation des données sous-jacentes qui sont visualisées.

L’impact organisationnel de la BI

Bien que la facilité d’accès ait été un facteur décisif dans l’adoption de la plupart des outils BI, naviguer dans le paysage des données des grandes entreprises est difficile, ne serait-ce que en raison de la diversité même des données disponibles. De plus, même si l’outil BI est assez accessible, la logique de reporting que les entreprises mettent en œuvre à travers les outils BI tend à refléter la complexité de l’activité, et par conséquent, la logique elle-même peut être beaucoup moins accessible que l’outil qui soutient son exécution.

En conséquence, l’adoption des outils BI a conduit - pour la plupart des grandes entreprises - à la création d’équipes d’analyse dédiées, qui opèrent généralement en tant que fonction de support aux côtés du service informatique. Comme le prévoit la loi de Parkinson, le travail s’étend pour occuper tout le temps disponible pour son achèvement ; ces équipes ont tendance à s’agrandir au fil du temps, parallèlement au nombre de rapports générés, indépendamment des avantages obtenus (perçus ou réels) par l’entreprise grâce à l’accès à ces rapports.

Limites techniques de la BI

Comme c’est souvent le cas, il y a un compromis entre les avantages lorsqu’il s’agit d’outils BI, c’est-à-dire que plus la facilité d’accès est grande, plus cela se fait au détriment de l’expressivité ; dans ce cas, les transformations appliquées aux données sont limitées à une classe relativement restreinte de filtres et d’agrégations. Il s’agit de la première grande limitation, car de nombreuses questions commerciales ne peuvent pas être traitées avec ces opérateurs (par exemple, quel est le risque de désabonnement d’un client ?). Bien sûr, il est possible d’introduire des opérateurs avancés dans l’interface utilisateur de la BI, mais de telles fonctionnalités “avancées” contredisent ⁸ l’objectif initial de rendre l’outil facilement accessible aux utilisateurs non techniques. Ainsi, la conception de requêtes de données avancées n’est pas différente de la construction d’un logiciel, une tâche qui s’avère intrinsèquement difficile. À titre d’exemple anecdotique, la plupart des outils BI offrent la possibilité d’écrire des requêtes “brutes” (généralement en SQL ou dans un dialecte similaire à SQL), revenant ainsi au chemin technique que l’outil était censé éliminer.

La deuxième grande limitation est la performance. Cette limitation se présente sous deux formes distinctes pour les outils BI légers et épais, respectivement. Les outils BI légers incluent généralement une logique sophistiquée pour optimiser les requêtes de base de données qu’ils génèrent. Cependant, ces outils sont finalement limités par les performances offertes par la base de données servant de back-end. Une requête apparemment simple peut s’avérer inefficace à exécuter, ce qui entraîne des temps de réponse longs. Un ingénieur de base de données peut certainement modifier et améliorer la base de données pour résoudre ce problème. Cependant, une fois de plus, cette solution contredit l’objectif initial de rendre l’outil BI accessible aux utilisateurs non techniques.

Les outils BI épais ont leurs performances limitées par la conception des cubes OLAP eux-mêmes. Tout d’abord, la quantité de RAM nécessaire pour conserver un cube multidimensionnel en mémoire augmente rapidement à mesure que les dimensions du cube augmentent. Même un nombre modéré de dimensions (par exemple, 10) peut entraîner de graves problèmes liés à l’empreinte mémoire du cube. Plus généralement, les conceptions en mémoire (les cubes OLAP étant les plus fréquents) souffrent généralement de problèmes liés à la mémoire.

De plus, le cube est une représentation tronquée des données transactionnelles d’origine : aucune analyse effectuée avec le cube ne peut récupérer les informations qui ont été perdues en premier lieu. Prenons l’exemple de l’hypermarché. Dans un tel scénario, les paniers ne peuvent pas être représentés dans un cube. Ainsi, les informations “achetées ensemble” sont perdues. La conception globale du “cube” OLAP limite sévèrement les données qui peuvent même être représentées ; cependant, cette limitation est précisément ce qui rend possible la propriété “en ligne” en premier lieu.

Limites commerciales de la BI

L’introduction d’outils de BI dans une entreprise est moins transformative qu’il n’y paraît. En d’autres termes, produire des chiffres en soi n’a aucune valeur pour l’entreprise s’ils ne sont pas accompagnés d’une action concrète. La conception même des outils de BI met l’accent sur une production “illimitée” de rapports, mais elle ne soutient aucune action réelle. En fait, dans la plupart des situations, la faible expressivité des outils de BI se révèle trop limitante lorsqu’il s’agit d’automatiser quoi que ce soit en se basant sur les rapports de BI.

De plus, l’outil de BI a tendance à exacerber les tendances bureaucratiques des grandes entreprises. Des preuves anecdotiques, des chiffres approximatifs et un jugement éclairé sont souvent suffisants pour établir les priorités d’une entreprise. Cependant, l’existence d’un outil analytique auto-servant - comme la BI - offre de nombreuses opportunités de procrastination et brouille les pistes avec un flot incessant de mesures douteuses et non-actionnables.

Les outils de BI sont vulnérables aux problèmes de conception par comité où les idées de tout le monde sont incluses dans le projet. La nature auto-servante de l’outil met l’accent sur une approche extrêmement inclusive lorsqu’il s’agit d’introduire de nouveaux rapports. Par conséquent, la complexité du paysage des rapports a tendance à augmenter avec le temps, indépendamment de la complexité commerciale que ces rapports sont censés refléter. Le terme “métriques de vanité” est largement utilisé pour désigner des métriques - généralement mises en œuvre grâce à un outil de BI - qui ne contribuent pas au résultat net d’une entreprise.

L’avis de Lokad

Étant donné les capacités du matériel informatique moderne, utiliser un système de reporting pour produire 1 million de chiffres par jour est facile ; produire 10 chiffres par jour qui valent la peine d’être lus est difficile. Bien qu’un outil de BI utilisé à petites doses soit une bonne chose pour la plupart des entreprises, à plus fortes doses, il devient un poison.

En pratique, il y a seulement un nombre limité d’informations qui peuvent être obtenues grâce à la BI. L’introduction de rapports de plus en plus nombreux entraîne rapidement des rendements décroissants en termes de nouvelles (ou améliorées) informations obtenues grâce à chaque rapport supplémentaire. Rappelez-vous, la profondeur de l’analyse des données accessible à partir d’un outil de BI est limitée par conception car les requêtes doivent rester facilement accessibles aux non-spécialistes via l’interface utilisateur.

De plus, même lorsque de nouvelles informations sont acquises grâce aux données, cela n’implique pas que l’entreprise puisse les transformer en quelque chose de concret. La BI est, en essence, une technologie de reporting : elle ne met pas l’accent sur un appel à l’action pour l’entreprise. Le paradigme de la BI n’est pas axé sur l’automatisation des décisions commerciales (même les plus banales).

La plateforme Lokad propose des fonctionnalités de reporting sur mesure, tout comme la BI. Cependant, contrairement à la BI, Lokad vise à optimiser les décisions commerciales, plus précisément celles concernant la chaîne d’approvisionnement. En pratique, nous recommandons de confier la conception, puis la maintenance, de la recette numérique qui génère - grâce à Lokad - les décisions de la chaîne d’approvisionnement d’intérêt à un scientifique de la chaîne d’approvisionnement.

Notes