Plaidoyer pour une Business Intelligence de proximité

Un projet de Business intelligence, au sein d’une organisation, quelles que soient son activité et son envergure, donc même au sein des plus petites, recouvre trop de dimensions pour que l’on ne puisse jamais le qualifier de simple ou de facile.

Définir des objectifs, s’inscrire dans une enveloppe financière, analyser les besoins réels des décideurs et anticiper leur évolution, identifier les sources d’informations et en analyser le potentiel, dessiner l’architecture d’une solution, maquetter les attendus, choisir des outils et logiciels pour la réalisation, obtenir les autorisations et les paramètres de connexion pour accéder aux données sensibles et mettre en œuvre les moyens techniques pour y arriver, concevoir, développer pas à pas et finaliser les documents, imaginer leur circulation et inventer de nouveaux véhicules pour leur transmission aux utilisateurs, tester minutieusement et déboguer, inaugurer les premières publications, activer une boucle d’amélioration continue… Le tout dans des délais courts, un environnement changeant et des priorités souvent modifiées. Voilà une longue liste et de quoi décourager les meilleures bonnes volontés.

Et pourtant la demande pour des outils d’aide à la décision pertinents, précis, fonctionnels, rapides, flexibles… est pressante, partout. Parce que le monde des affaires, mais pas seulement lui, demande toujours plus de réactivité, de vitesse de décision, de profondeur d’analyse. Parce que les données à mettre en œuvre recouvrent des volumes toujours croissants puisque la numérisation des activités est maintenant globale.

Certains projets informatiques, pourtant concrètement essentiels au sein de l’organisation, resteront ignorés de presque tous car peu partagés en interne et peu visibles en externe.

Caricaturons un peu : qui se soucie réellement du système de gestion d’entrepôt (Warehouse Management System) en dehors des équipes logistiques dont il pilote et garantit l’efficacité au quotidien ? Et pourtant les enjeux de satisfaction client et de maîtrise des stocks y sont évidemment vitaux pour une entreprise.

En revanche, les documents issus de la Business Intelligence vont circuler au cœur des multiples centres et niveaux de décision, être présents sur les bureaux d’une multitude d’acteurs clés, s’afficher sur des ordinateurs, des panneaux d’information électroniques dans les couloirs ou les ateliers. Les commerciaux les transporteront dans leur poche grâce à leurs téléphones portables et dans leur mallette sur une tablette graphique, pour les consulter le soir à l’hôtel ou même en partager quelques morceaux choisis avec leurs clients ou leurs prospects.

La Business Intelligence véhicule autant l’image de l’organisation qu’elle ne met en forme ses données.

Du coup, le projet d’informatique décisionnelle va devenir un projet phare, focalisant l’attention managériale au motif de ne plus pouvoir décider sans un outil d’aide performant, et finalement susciter la compétition entre les grandes fonctions de l’organisation, et la convoitise de leurs dirigeants, pour en piloter la mise en œuvre sous la pleine lumière des projecteurs directoriaux, et en conserver ensuite le contrôle opérationnel.

Rivalités et tendance naturelle à l’accaparation des objets les plus brillants, vont alors vite transformer le désir initial de mettre à disposition les informations utiles, au bon moment, au bon endroit et sous la forme la plus pertinente, en une solution centralisatrice dont le promoteur interne deviendra le propriétaire et dont les données lui permettront de connaître les secrets cachés de ses collègues. La coopération cède ainsi la place à la compétition. Les données révèlent leur pouvoir d’influence caché. La Business Intelligence peut devenir aussi un instrument de pouvoir.

Une Business Intelligence centralisée

Les systèmes de Business Intelligence implantés dans les organisations échappent rarement à cette tentation, accaparatrice donc centralisatrice. Ils deviennent le jouet utile de la fonction la plus en cour : direction financière très souvent, via l’une de ses vassalités de contrôle, direction informatique assez régulièrement puisque le système implique l’exploitation des systèmes d’information et des réseaux.

L’une comme l’autre direction est fortement marquée par la verticalité. Ne faut-il pas remonter toutes les informations au Siège pour produire les comptes et les analyser ? Ne faut-il pas piloter les systèmes et garantir leur sécurité par un contrôle central des accès ?

Le remplacement des logiciels départementaux par des ERP (Entreprise Resource Planning) témoigne de cet attachement à l’unicité des outils et des procédures : un seul cadre logiciel, une seule base de données regroupant toutes les informations nécessaires aux traitements, un seul pilote (une seule équipe de pilotage) pour gérer son fonctionnement complexe et sa mise à jour. Tout part donc d’en haut puisque les opérationnels se sauraient avoir une vue complète du système d’information mis en œuvre.

Même logique pour l’infrastructure informatique : serveurs centraux internes ou externalisés pour motif de maintenance, ouverture centralisée des droits d’accès pour motif de sécurité, centre d’appel global pour motif d’insuffisance de compétences locales.

L’implantation d’une solution de Business Intelligence se réalise du coup dans ce contexte jacobin et c’est tout naturellement que le projet, souvent initié par la direction générale, se retrouve confié aux acteurs centraux plutôt qu’aux opérationnels pourtant directement concernés par son utilisation.

Les adeptes de la centralisation porteront en avant les avantages attendus d’une unité de commandement et de décision : l’unicité de pilotage du projet et plus tard du système de Business Intelligence permet de garantir la cohérence des référentiels de données et des processus de travail, la performance des bases de données dédiées (le Data Warehouse) et une réelle capitalisation des compétences autour de l’équipe BI centrale. Le besoin de cohérence est d’autant plus prégnant que la structure de l’organisation est complexe, horizontalement et verticalement. La centralisation est donc toujours présentée comme un critère de maturité de l’organisation.

Peut-on contrer ces arguments qui semblent tellement de bon sens ? Sans nul doute, oui, À quoi serviraient alors les structures de coordination s’il n’y a plus rien à coordonner lorsque la gouvernance est complètement centralisée ? Détaillons ces besoins ainsi exprimés.

L’unicité du modèle mis en place, des processus et des définitions de tâches, des référentiels, des définitions de données est réellement indispensable. Imagine-t-on plusieurs définitions du chiffre d’affaires entrant en concurrence pour la présentation des résultats ? À vrai dire, la situation se rencontrent fréquemment dans des organisations qui n’imposent pas un référentiel commun aux différentes branches et services. Une situation proprement intenable, amenant une contestation interne permanente des informations partagées, et la circulation de tableaux de bord parallèles.

Un référentiel unique est nécessaire, mais l’imposer par le haut suffira-t-il à faire disparaître toute définition alternative dans l’organisation ? Une revue décentralisée des approches et une coordination permettent généralement de mieux faire accepter une définition « groupe », éventuellement associée ensuite à des indicateurs métiers complémentaires.

Les entrepôts de données (Data Warehouse) sont des bases de données exigeant une excellente structuration des données qu’elles auront à gérer pour garantir leur efficacité. N’oublions pas qu’elles auront très rapidement à traiter de très gros volumes de données (en particulier pour la gestion des historiques), avec un dessin relationnel multidimensionnel d’une grande densité. Et pourtant elles devront garantir aux utilisateurs des temps de synthétisation et d’accès les plus réduits possibles.

Une vision centrale semble s’imposer pour réussir cette prouesse puisqu’elle permet de mettre en œuvre des capacités techniques de haute intensité : serveurs puissants, hautes compétences en systèmes d’information, large bande passante sur les réseaux… tout en assurant plus aisément de plus hauts degrés de sécurité contre les pannes et les intrusions.

Mais des entrepôts spécialisés et décentralisés proches des lieux de production des données ne répondraient-ils pas à ces mêmes contraintes tout en réduisant la complexité globale du schéma relationnel ? Ce qui n’empêcherait nullement de regrouper dans un entrepôt central le volume réduit de données synthétisées nécessaires à la production des tableaux de bord du Siège. En matière de sécurité le risque serait réparti, ce qui est un des principes de base de l’assurance, un modèle ayant depuis longtemps fait ses preuves.

La capitalisation des savoirs et savoir-faire est elle aussi présentée comme un argument en faveur de la centralisation. Un système de Business Intelligence est complexe, et la maîtrise technique des paramétrages réseaux, des connaissances bases de données et de l’utilisation créative des logiciels de Business Intelligence impose un investissement humain et en formation assez lourd. La centralisation sur une équipe BI centrale pointue semble alors s’imposer pour ne pas multiplier les personnels dédiés ni les disséminer isolés dans les différentes branches de l’organisation.

Ce qui se conçoit aisément mais n’implique pas pour autant l’absence d’alternatives, à l’heure du travail à distance institutionnalisé et systématisé. La capitalisation passe autant, si ce n’est davantage, par les outils de formalisation des connaissances (Knowledge Management), ou par le partage élargi sur plusieurs échelons de maîtrise technique, que par la centralisation sur quelques têtes bien faites et bien pleines regroupées dans un même bureau. Une équipe unique ne traitera qu’un petit nombre de tâches de maintenance simultanément et traitera en priorité les anomalies bloquantes. Les demandes d’amélioration ou de modification locales resteront alors très longtemps en fin de liste.

Ces trois arguments d’unicité du modèle, de structuration de l’entrepôt de données et de capitalisation des savoirs ne suffisent de toute façon pas à créer un système de Business Intelligence efficace, réellement proche des décideurs, ajusté à leurs besoins individuels, suffisamment flexible pour s’adapter au changement permanent, et facile à prendre en main et à s’approprier. Un système de Business Intelligence central a toutes les chances au contraire de se figer rapidement et se transformer en une machine à produire des graphiques utiles… au petit nombre d’utilisateurs proches de sa gouvernance.

Pour une approche alternative de la Business Intelligence

Une organisation, même fortement centralisée, ne pourra fonctionner sans un espace de décision suffisant confié aux collaborateurs de terrain. La centralisation managériale fixera certes les principes, les règles, les marges laissées, mais les décideurs de proximité les appliqueront selon leur compréhension propre, et en exploiteront les failles, au besoin, pour réussir dans leur mission et atteindre leurs objectifs.

Même la plus totalitaire des institutions génère une autonomie locale sans laquelle ses rouages ne sauraient tourner. Le contrôle du respect des règles n’est réalisable qu’a posteriori et doit bien accorder aux acteurs le bénéfice de leurs réussites. Du coup, plus le management est centralisateur, plus les décideurs de proximité auront besoin d’un outil de Business Intelligence rapide, précis et bien ajusté, pour mesurer l’utilisation de leur faible marge d’initiative.

C’est donc bien un système BI déconcentré qui devrait prévaloir pour accompagner la prise de décision locale : un tableau de bord aux indicateurs (Key Performance Indicators, KPI) définis par chaque décideur selon ses propres besoins, mais s’appuyant sur un modèle de données partagé avec le niveau organisationnel supérieur.

Le système peut ainsi se construire brique par brique à grande vitesse par chaque collaborateur en coordination avec son niveau hiérarchique supérieur. La cohérence est aisément assurée par le partage des indicateurs (KPI, mode de calcul et sources de données) à la fois horizontalement entre collègues et par remontée verticale. Pourquoi ne pas laisser aux équipes de terrain le choix de leurs indicateurs puisque de toute façon dans un système BI centralisé elles ne prendront en compte réellement que les indicateurs qui leur conviennent le mieux ? Tel commercial se focalisera sur le nombre de nouveaux clients, générateur de primes, et tel autre sur le chiffre d’affaires total et le panier moyen.

La hiérarchie pourra assurer à chaque niveau le travail de coordination et d’harmonisation ; elle garantit donc la cohérence du modèle de données, avec le support technique (faisabilité informatique) et organisationnel (vision élargie des besoins) du Siège. À chaque niveau, les interlocuteurs sont peu nombreux, les discussions ne risquent donc pas de s’enliser, et le travail de construction d’un tableau complet d’indicateurs sera vite réalisé. La construction du référentiel (processus, données, indicateurs) pourra être réalisée par simple collection et comparaison des remontées locales.

La phase d’analyse ainsi découpée en cellules élémentaires travaillant simultanément ne pourra qu’en être accélérée. Cela ne se réalisera naturellement pas sans un sérieux travail de préparation et de formation de l’encadrement. On pourra également identifier des « champions », volontaires pour participer au projet, et dont la motivation et l’investissement personnel faciliteront le déroulement lors de la phase d’analyse, mais également dans les phases ultérieures de mise en place opérationnelle et d’amélioration continue.

Entrepôts de données : l’analyse des données sources et de l’organisation des systèmes d’information qui les produisent d’une part, et des indicateurs à produire d’autre part, permettra de construire des entrepôts de données sectorisés homogènes, connectés à des sources plus proches et de nombre plus réduit, au volume de données plus faible et utilisés par moins d’utilisateurs. Leur mise à jour sera améliorée par la proximité en utilisant les plages horaires les plus pertinentes pour ne pas pénaliser les performances des systèmes sources et des réseaux. Il sera donc possible d’utiliser des solutions techniques moins sophistiquées. Ce qui n’empêchera ni la remontée des informations nécessaires aux traitements du Siège, mais en volume réduit car synthétisées, ni l’application d’un pilotage central et de protocoles de sécurité homogènes dans toute l’organisation.

La capitalisation des compétences devrait rencontrer moins d’obstacles dans une Business Intelligence déconcentrée par la présence de spécialistes BI de terrain, les « champions », aux compétences de premier échelon, et aptes à intervenir en intermédiaires entre les utilisateurs et décideurs, et l’équipe logiciel ou l’équipe réseau. Les questions posées par les utilisateurs seront ainsi traitées plus rapidement par des intervenants comprenant à la fois les deux langages. Les points plus complexes resteront seuls traités par les équipes centrales ainsi déchargées. La formation de ces champions est rapide car peu pointue et centrée sur l’utilisation, le paramétrage de base, la création de requêtes simples et la création de documents. Les plus motivés d’entre eux approfondiront d’eux-mêmes leurs compétences par curiosité et pour se rendre indispensables à leurs collègues. Ce sont eux qui construiront le cœur de la base de connaissance Business Intelligence de l’organisation.

Sans doute si l’on reste bloqué dans une pensée centralisatrice.

Il existe une large gamme de logiciels ciblant, au choix, des publics de spécialistes, des utilisateurs avertis ou des débutants inexpérimentés. L’accessibilité d’un logiciel est souvent plus liée à la génération du logiciel qu’au cœur des ses fonctionnalités, mais pas toujours. Le choix du logiciel doit donc être réfléchi et basé sur une étude rationnelle, non seulement de son potentiel technique mais également de son ergonomie, en étudiant chacun des modules (extraction et transformation des données pour alimenter l’entrepôt de données, conception des documents de synthèse, et distribution des documents dans l’organisation).

Si le choix du logiciel est laissé, en central, aux spécialistes de la Business Intelligence, le logiciel sera certainement plus complexe et peu accessible aux analystes de terrain. À l’inverse, ces derniers préféreraient des outils simples aux performances peut-être un peu limitées pour les premiers…

Mais l’organisation ne peut-elle pas proposer simultanément à ses utilisateurs un choix d’outils adaptés aux différents besoins et niveaux de compétence BI ? L’important n’est pas tant le logiciel de mise en forme des données utilisé, que le contenu de l’entrepôt. Pourquoi imposer au contrôleur de gestion en charge d’une unité de vente dans une filiale d’utiliser le même logiciel que le service central chargé de réaliser les synthèses pour le comité de direction ?

Le contrôleur de gestion, qui maîtrise Excel dans l’exercice de son activité première, trouvera sans doute avantage à construire le tableau de bord de l’équipe commerciale grâce aux fonctionnalités de gestion de données de son tableur (Modèle de données Excel, Power Query, Power Pivot…), en puisant automatiquement dans l’entrepôt de données les informations nécessaires. Et plutôt que de se voir imposer un format standardisé pour l’ensemble des unités de vente du groupe, il peaufinera un document adapté aux spécificités de son unité, aux centres d’intérêt de ses commerciaux : un document facilement modifiable pour suivre les évolutions de leurs besoins.

Le tableau de bord du comité de direction, aux visualisations de données plus sophistiquées, mais également plus synthétique et plus figé, publié dans l’intranet de l’organisation et distribué via le réseau à différents niveaux d’encadrement avec des contenus personnalisés automatiquement, pourra lui provenir d’un logiciel de Business Intelligence plus orienté communication.

La maturité d’une organisation en Business Intelligence ne la conduit pas obligatoirement à évoluer du tableau de bord bricolé sur tableur à l’exploitation centralisée d’un logiciel lourd et complexe par une équipe BI centrale. Une approche déconcentrée est tout à fait compatible avec les besoins et impératifs d’une organisation, même large et complexe.

Mais il faut d’abord oser changer de point de vue.