Décisionnel : vers de nouveaux modèles de construction

 [Publié le 4 mai 2011]

En dix ans, le décisionnel a pris dans l’entreprise une place stratégique mais se trouve aujourd’hui confronté à une difficulté majeure en raison même de sa position au cœur du système d’information : l’impossibilité pour la direction informatique de satisfaire dans des délais acceptables les multiples demandes émanant de toutes les strates de l’organisation (direction générale, directions métiers, équipes opérationnelles, voire clients et fournisseurs).

Ce manque de réactivité a pour conséquence de pousser les utilisateurs à rechercher par eux-mêmes des solutions répondant plus rapidement à leur besoin mais qui, échappant au contrôle de la DSI, fragilisent le système décisionnel en le fragmentant, ce qui le rend d’autant plus difficile et coûteux à maintenir et à faire évoluer. In fine, c’est la capacité de l’entreprise à piloter ses activités et à assurer sa conformité réglementaire qui est affectée et, partant, sa compétitivité dans un environnement économique où il faut avant tout savoir aller vite et anticiper.

La réaffirmation de quelques principes architecturaux permet de briser ce cercle vicieux et de mettre en place un modèle de construction et de gouvernance donnant aux utilisateurs plus de liberté et d’autonomie tout en garantissant l’intégrité du système décisionnel et son aptitude à satisfaire rapidement les nouveaux besoins.

Quatre principes à respecter

Pour atteindre ce double objectif de réactivité et de maîtrise, le premier principe est de réaffirmer l’unicité et la transversalité du système décisionnel. Il faut pour cela assurer son  étanchéité vis-à-vis des autres systèmes de l’entreprise, de façon à ce que l’environnement décisionnel ne soit ni affecté, ni remis en cause par les évolutions inévitables que connaissent les systèmes opérants qui l’alimentent : non seulement les montées de version, ajouts, retraits et consolidations d’applications mais aussi les réorganisations internes et les cessions, acquisitions et fusions d’activités ou d’unités opérationnelles.

Le deuxième principe est de décomposer le système décisionnel lui-même en sous-systèmes urbanisés, remplissant chacun de manière autonome une mission bien déterminée. Ce découplage des fonctions permet à chaque sous-système d’être indépendant des autres et d’évoluer plus rapidement en fonction des demandes de service des autres sous-systèmes.

Le troisième principe, indissociable du précédent, est de normaliser les échanges et les communications entre les différentes composantes du système décisionnel et entre celui-ci et les autres éléments du système d’information.

Enfin, moins souvent appliqué, le quatrième principe consiste à dénaturer les données qui entrent dans le système décisionnel le plus en aval possible, c’est-à-dire au plus près des métiers, de manière à ce qu’elles conservent leur intégrité fonctionnelle et restent exploitables par le plus grand nombre d’applications décisionnelles sans nécessiter de re-transformation.

Une architecture urbanisée

Le respect de ces principes permet de mettre en place une architecture décisionnelle industrialisée mais au sein de laquelle les utilisateurs (directions métiers, filiales ou autres) disposent d’espaces de liberté pour mener des initiatives répondant à leurs besoins propres sans mettre en péril la cohérence globale du système.

Cette architecture repose sur des briques ou sous-systèmes urbanisés, encadrés par un système d’administration garantissant la conformité fonctionnelle et technique de l’ensemble et, grâce à un métadictionnaire central, la normalisation de la sémantique. Le premier de ces sous-systèmes assure la collecte des données. Seul point d’entrée dans le système décisionnel, c’est lui qui spécifie aux systèmes sources le format dans lequel les données doivent lui être envoyées. Son rôle se limite à un traitement de contrôle avant d’envoyer les données dans le deuxième sous-système : le data warehouse, qui stocke et historicise les données selon un format non dénaturé et une sémantique unifiée, rendant les données utilisables par tous les sous-systèmes avals.

Le data warehouse est en effet le principal point d’alimentation de sous-systèmes spécialisés où les données sont transformées, modélisées et enrichies pour répondre aux besoins spécifiques de reporting, d’analyse et de consultation des différents métiers de l’entreprise. En dessous de ces sous-systèmes métiers, un sous-système partagé regroupe les outils de présentation et de diffusion de l’information décisionnelle et gère les habilitations d’accès aux données ainsi que les rôles des différentes catégories d’utilisateurs. 

Des espaces de « liberté encadrée » pour les métiers

L’originalité de ce modèle est de subdiviser chaque sous-système spécialisé en deux parties. La première est un espace industrialisé, géré par la DSI, qui prend en charge la collecte, l’intégration et le stockage des données selon les règles requises par les applications décisionnelles propres au métier. Le second est un espace où, sans intervention de la DSI, les utilisateurs peuvent charger et organiser librement des données et développer, selon leur niveau de compétence et les droits qui leur sont octroyés, des bases et des traitements spécifiques, des requêtes, des exports, des tableaux de bord simples, des rapports dynamiques, des analyses ou des simulations.

Dans cet espace de liberté, les directions métiers font ce qu’elles ont toujours fait et font de plus en plus depuis l’apparition d’outils de BI (Business Intelligence) particulièrement faciles à maîtriser comme Microsoft, QlikView ou Tableau Software ou certaines nouvelles lignes de produits des grands éditeurs : construire elles-mêmes des applications répondant à des besoins spécifiques, urgents, récurrents ou ponctuels. Mais, inscrites dans un cadre contrôlé, monitoré et borné, ces initiatives ne portent pas atteinte aux autres applications. Elles contribuent au contraire à enrichir le système décisionnel et accélèrent la réalisation des projets.

En effet, si une application créée dans cet espace apporte de la valeur et correspond à un besoin pérenne, la direction métier peut demander son industrialisation. Les demandes sont gérées par la DSI qui, une fois leur pertinence validée, les exécute dans le respect des normes de qualité de données, de documentation et de production. Ce processus allège le travail de la DSI, notamment les phases de spécifications et de recette. Il élimine « l’effet tunnel » qui plombe tant de projets décisionnels puisque, en attendant la livraison de la version industrielle de l’application, la direction métier peut, sans dommage, continuer à utiliser « sa » version.

Une gouvernance spécifique indispensable

L’expérience montre que ce mode de construction et de gestion peut être mis en place quelque soit l’existant décisionnel de l’entreprise. De grandes entreprises l’ont adopté pour lutter contre la prolifération d’applications fragiles mais coûteuses à maintenir basées sur Excel et Access ; d’autres pour maximiser la valeur des applications analytiques développées dans certaines filiales en rendant ces applications accessibles à toutes les filiales sous forme de services ; d’autres encore pour limiter les risques en attendant la finalisation de leur data warehouse. Il n’est donc pas nécessaire de « partir de zéro » pour tirer avantage de cette approche.

Si ce modèle couvre les couches fonctionnelles, applicatives et techniques, son bon fonctionnement est en revanche indissociable de la mise en place d’une gouvernance spécifique, rapprochant les directions métiers et la direction informatique et précisant leurs domaines de responsabilités. Le schéma de gouvernance exige en particulier une maîtrise d’œuvre transversale, dédiée au décisionnel ; une maîtrise d’ouvrage capable de faire des arbitrages dans les demandes d’industrialisation émises par les métiers ; une cellule de gouvernance propre à chaque espace métier, dont les responsables gagnent à être formés aux exigences et contraintes de l’informatique ; enfin, entre ces instances, des workflows fluidifiant les collaborations et les décisions, ainsi que des procédures pour remonter les anomalies et les corriger.
 

par Denis Skalski, Directeur Conseil Business Intelligence chez Keyrus