L'intelligence d'affaires (BI)

L’intelligence d’affaires (BI) se réfère à une catégorie de logiciels d’entreprise dédiés à la production de rapports analytiques principalement fondés sur les données transactionnelles collectées à partir des divers systèmes commerciaux que l’entreprise utilise pour fonctionner. BI vise à offrir aux utilisateurs non spécialistes en informatique des capacités de reporting en libre-service. Ces capacités peuvent aller de l’ajustement des paramètres sur des rapports existants à la création de rapports entièrement nouveaux. La plupart des grandes entreprises disposent d’au moins un système BI en opération, en complément 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 20e siècle. Cette première itération s’est révélée extrêmement populaire, recevant l’attention de la presse grand public et une large diffusion. Cette popularité démontrait qu’il existait un intérêt marqué pour des rapports quantitatifs à haute densité d’information. Dans les années 1980, de nombreuses grandes entreprises ont commencé à conserver leurs transactions commerciales sous forme de dossiers électroniques, stockés dans des bases de données transactionnelles, en tirant généralement parti de certaines premières solutions ERP. 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 dossiers et, en 1983, SAP a introduit le langage de programmation ABAP ³, dédié à la génération de rapports fondés sur les données collectées au sein même de l’ERP.

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. D’abord, la conception des rapports devait être réalisée par des spécialistes en informatique hautement qualifiés. Cela rendait le processus lent et coûteux, limitant sévèrement la diversité des rapports pouvant être élaborés. Ensuite, la génération des rapports était très gourmande en ressources pour le matériel informatique. Les rapports pouvaient, en général, être produits uniquement durant la nuit (et par traitement par lots), 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 des limitations logicielles.

Au début des années 1990, les progrès du matériel informatique ont permis l’émergence d’une nouvelle catégorie de solutions logicielles ⁴, des solutions de Business Intelligence. Le coût de la RAM (mémoire à accès aléatoire) avait constamment diminué, tandis que sa capacité de stockage avait régulièrement augmenté. 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 lever les deux principales limitations des systèmes de reporting mis en œuvre une décennie plus tôt : les nouvelles interfaces logicielles front-end étaient bien plus accessibles aux non-spécialistes ; et les nouveaux back-ends – intégrant des technologies OLAP (expliquées ci-dessous) – éliminaient certains des plus grands goulots d’étranglement informatiques. Grâce à ces avancées, à la fin de la décennie, les solutions BI étaient devenues courantes parmi les grandes entreprises.

Au fur et à mesure que le matériel informatique progressait, une nouvelle génération d’outils BI a émergé ⁵ à la fin des années 2000. Les systèmes de bases de données relationnelles des années 1980, incapables de produire aisément des rapports, sont devenus, dans les années 2000, de plus en plus capables de contenir l’intégralité de l’historique transactionnel d’une entreprise en RAM. Par conséquent, des requêtes analytiques complexes pouvaient être exécutées en quelques secondes sans recourir à un back-end OLAP dédié. Ainsi, l’attention des solutions BI s’est déplacée vers le front-end, offrant des interfaces web encore plus accessibles – principalement en mode SaaS (software-as-a-service) – tout en présentant des tableaux de bord de plus en plus interactifs qui exploitaient la polyvalence du back-end relationnel.

OLAP et cubes multidimensionnels

OLAP signifie traitement analytique en ligne. OLAP est associé à la conception du back-end d’une solution BI. Le terme, inventé en 1993 par Edgar Codd, fédère une série d’idées de conception logicielle ⁶, dont la plupart datent d’avant les années 1990, certaines remontant même aux années 1960. Ces idées de conception ont été essentielles à l’émergence de la BI en tant que catégorie distincte de produits logiciels dans les années 1990. OLAP relevait le défi de pouvoir produire de nouveaux rapports analytiques en temps opportun, 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 nouveau rapport analytique consiste à lire les données au moins une fois. Cependant, si l’ensemble de données est si volumineux ⁷ que le lire dans son intégralité prend des heures (voire des jours), alors produire un nouveau rapport nécessitera également des heures, voire des jours. Ainsi, afin de générer un rapport mis à jour en quelques secondes, la technique ne peut pas impliquer de relire l’ensemble complet de données à chaque demande de rafraîchissement du rapport.

OLAP propose de tirer parti de structures de données plus petites et plus compactes – reflétant les rapports d’intérêt. Ces structures spécifiques sont conçues pour être mises à jour de manière incrémentale au fur et à mesure que de nouvelles données deviennent disponibles. Par conséquent, lorsqu’un nouveau rapport est demandé, le système BI n’a pas besoin de relire l’intégralité de l’historique des données, mais seulement la structure compacte contenant toute l’information nécessaire à la génération du rapport. De plus, si la structure est suffisamment petite, elle peut être conservée en mémoire (dans la RAM) et ainsi être accessible plus rapidement que le stockage persistant utilisé pour les données transactionnelles.

Considérez l’exemple suivant : imaginez un réseau de distribution exploitant 100 hypermarchés. Le directeur financier souhaite obtenir un rapport indiquant les ventes totales en euros par magasin et par jour sur les 3 dernières années. Les données brutes historiques des ventes sur ces 3 années représentent plus d’un milliard de lignes (chaque code-barres scanné dans chaque magasin durant cette période), et plus de 50GB sous forme tabulaire brute. Toutefois, une table comportant 100 colonnes (1 par hypermarché) et 1095 lignes (3 ans * 365 jours) totalise moins de 0,5MB (à raison de 4 octets par nombre). De plus, chaque fois qu’une transaction se produit, les cellules correspondantes de la table peuvent être mises à jour en conséquence. La création et la maintenance d’une telle table illustrent le fonctionnement interne d’un système OLAP.

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

Reporting interactif et visualisation de données

Rendre les capacités de reporting accessibles aux utilisateurs finaux non spécialistes en informatique a été un moteur clé dans l’adoption des outils BI. Ainsi, la technologie a adopté une conception WYSIWYG (what-you-see-is-what-you-get), s’appuyant sur des interfaces utilisateur riches. Cette approche diffère de celle couramment utilisée 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, semblable aux tableaux croisés dynamiques d’un tableur, permettant 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 d’ensembles de données particulièrement volumineux, le besoin de cubes OLAP a régressé à la fin des années 2000 parallèlement aux grands progrès réalisés dans le matériel informatique. De nouveaux outils BI « minces » ont alors été introduits, se concentrant exclusivement sur le front-end. Ces outils BI minces étaient principalement conçus pour interagir avec des bases de données relationnelles, contrairement à leurs prédécesseurs « épais » qui utilisaient des back-ends intégrés comportant des cubes OLAP. Cette évolution a été rendue possible parce que la performance des bases de données relationnelles, à l’époque, permettait généralement l’exécution de requêtes complexes sur l’ensemble du jeu de données en quelques secondes – bien entendu, tant que celui-ci restait en dessous d’une certaine taille. Les outils BI minces peuvent être considérés comme des éditeurs WYSIWYG unifiés pour les divers dialectes SQL qu’ils prenaient en charge. (En fait, en coulisses, 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 de données des outils BI relevaient essentiellement de la présentation des données côté client, que ce soit via une application de bureau ou web. Ces capacités de présentation ont progressé régulièrement jusqu’aux années 2000, lorsque le matériel des utilisateurs finaux (par exemple, stations de travail et ordinateurs portables) a commencé à largement dépasser (d’un point de vue computationnel) ce qui était nécessaire pour la visualisation de données. De nos jours, même les visualisations de données les plus élaborées sont des processus peu gourmands, éclipsés par la consommation de ressources informatiques liées à l’extraction et à la transformation des données sous-jacentes.

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 s’avère difficile, ne serait-ce qu’en raison de la grande diversité des données disponibles. De plus, même si l’outil BI est relativement accessible, la logique de reporting que les entreprises mettent en place tend à refléter la complexité de leur activité, et par conséquent, cette logique peut être bien moins accessible que l’outil permettant 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 soutien aux côtés du département informatique. Comme le prédit la loi de Parkinson, le travail s’étend de manière à occuper tout le temps disponible pour son achèvement ; ces équipes ont tendance à s’agrandir au fil du temps avec le nombre de rapports générés, indépendamment des bénéfices 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 existe un compromis entre les vertus des outils BI, c’est-à-dire qu’une plus grande facilité d’accès se fait au détriment de l’expressivité ; en l’occurrence, les transformations appliquées aux données se limitent à un ensemble relativement restreint de filtres et d’agrégations. C’est la première limitation majeure, puisque de nombreuses questions commerciales – sinon la plupart – ne peuvent être résolues 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, cependant de telles fonctionnalités « avancées » contrecarrent ⁸ l’objectif initial de rendre l’outil aisément accessible aux utilisateurs non techniques. Ainsi, concevoir des requêtes de données avancées ne diffère pas de la construction d’un logiciel, une tâche intrinsèquement difficile. À titre anecdotique, la plupart des outils BI offrent la possibilité d’écrire des requêtes « brutes » (généralement en SQL ou dans un dialecte proche du SQL), retombant ainsi sur la voie technique que l’outil était censé éliminer.

La deuxième limitation majeure est la performance. Cette limitation se présente sous deux aspects distincts selon que l’on considère les outils BI minces ou épais. Les outils BI minces intègrent généralement une logique sophistiquée pour optimiser les requêtes de la base de données qu’ils génèrent. Cependant, ces outils sont en fin de compte limités par la performance offerte par la base de données servant de back-end. Une requête apparemment simple peut s’avérer inefficace à exécuter, entraînant de longs temps de réponse. Un ingénieur en bases de données pourra certes modifier et améliorer la base pour remédier à ce problème. Toutefois, encore une fois, cette solution contredit l’objectif initial de maintenir l’outil BI accessible aux utilisateurs non techniques.

Les outils BI épais voient leur performance limitée par la conception même des cubes OLAP. D’abord, la quantité de RAM requise pour maintenir un cube multidimensionnel en mémoire augmente rapidement à mesure que les dimensions du cube s’accroissent. Même un nombre modéré de dimensions (par exemple, 10) peut conduire à 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 de gestion de la mémoire.

De plus, le cube est une représentation approximative des données transactionnelles originales : aucune analyse réalisée avec le cube ne peut récupérer des informations qui ont été perdues dès le départ. Rappelons l’exemple de l’hypermarché. Dans un tel scénario, les paniers ne peuvent être représentés dans un cube. Ainsi, l’information « achetés ensemble » est perdue. La conception globale du cube OLAP limite sévèrement les données pouvant être représentées ; cependant, cette limitation est précisément ce qui rend possible la propriété « en ligne » dès le départ.

Limites commerciales de la BI

L’introduction des outils BI dans une entreprise est moins transformatrice qu’il n’y paraît. Tout simplement, produire des chiffres, en soi, n’a aucune valeur pour l’entreprise si aucune action n’est associée à ces données. La conception même des outils BI met l’accent sur une production « illimitée » de rapports, mais cette conception ne soutient aucune démarche concrète. En réalité, dans la plupart des situations, la faible expressivité des outils BI s’avère trop limitante lorsqu’il s’agit d’automatiser quoi que ce soit à partir des rapports BI.

De plus, l’outil BI tend à exacerber les tendances bureaucratiques des grandes entreprises. Des preuves anecdotiques, des chiffres approximatifs et un bon sens suffisent souvent à établir les priorités d’une entreprise. Cependant, l’existence d’un outil analytique en libre-service – tel que la BI – offre une occasion propice à la procrastination et à la confusion avec un flux incessant de métriques douteuses et non actionnables.

Les outils BI sont vulnérables aux maux du design by committee où les idées de tout le monde se retrouvent intégrées dans le projet. La nature en self-service de l’outil met en avant une approche extrêmement inclusive lors de l’introduction de nouveaux rapports. En conséquence, la complexité du paysage des rapports tend à croître au fil du temps, indépendamment de la complexité de l’entreprise que ces rapports sont censés refléter. Le terme vanity metrics est devenu largement utilisé pour désigner des indicateurs – généralement mis en œuvre via un outil BI – tels que ceux-ci qui ne contribuent pas au résultat final d’une entreprise.

L’avis de Lokad

Compte tenu des 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 méritent d’être lus est difficile. Bien qu’un outil BI utilisé en petites quantités soit bénéfique pour la plupart des entreprises, à doses plus élevées, il devient un poison.

En pratique, il n’existe qu’un nombre limité d’informations que l’on peut tirer du BI. L’introduction de toujours plus de rapports aboutit rapidement à des rendements décroissants en termes de nouvelles informations (ou informations améliorées) obtenues avec chaque rapport supplémentaire. N’oubliez pas que la profondeur de l’analyse de données accessible via un outil BI est limitée par conception, puisque les requêtes doivent demeurer aisément accessibles aux non-spécialistes via l’interface utilisateur.

De plus, même lorsqu’une nouvelle information est acquise à partir des données, cela n’implique pas que l’entreprise puisse en faire quelque chose de concret. Le BI est, par essence, une technologie de reporting : il n’insiste pas sur un appel à l’action pour l’entreprise. Le paradigme BI n’est pas conçu pour automatiser les décisions commerciales (même les plus banales).

La plateforme Lokad et ses fonctionnalités offre des capacités de reporting sur mesure étendues, similaires à celles du BI. Cependant, contrairement au BI, Lokad vise l’optimisation des décisions commerciales, plus précisément de celles concernant la supply chain. En pratique, nous recommandons qu’un Supply Chain Scientist soit en charge de la conception, puis de la maintenance, de la recette numérique qui génère – via Lokad – les supply chain decisions d’intérêt.

Notes