Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo

 


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


Rédigé par Par Denis SKALSKI, Keyrus le 10 Novembre 2010

Le principal défi du décisionnel est aujourd’hui de répondre aux besoins croissants des utilisateurs dans des délais compatibles avec le rythme de vie de l’entreprise. Quel que soit l’existant décisionnel, il est possible de mettre en place une architecture et une gouvernance décisionnels conciliant le besoin de réactivité des directions métiers et l’exigence de maîtrise des directions informatiques.



Denis SKALSKI – Directeur Conseil Business Intelligence - Keyrus
Denis SKALSKI – Directeur Conseil Business Intelligence - Keyrus
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

Le principe d’étanchéité permet au décisionnel de rester réactif et intègre en minimisant l’impact de l’évolution des systèmes sources sur les processus de collecte, de stockage et de gestion de l’information décisionnelle.

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

Pour servir l’ensemble des directions métiers, les données du data warehouse ne doivent pas être dénaturées par l’application de règles métiers spécifiques. Ces transformations sont faites en aval, dans un espace propre à chaque métier.

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 aval.

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

Couplé à l’espace métier industrialisé, un espace dédié permet aux utilisateurs de développer les applications décisionnelles qu’ils jugent nécessaires et, le cas échéant, demander à la DSI d’industrialiser ces applications.

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 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 est indispensable

L’expérience montre que ce mode de construction et de gestion peut être mis en place quel que 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.

Denis SKALSKI est Directeur Conseil à la Direction du Consulting de Keyrus. Riche d’une expérience d’une vingtaine d’années dans le domaine du décisionnel bancaire, il a travaillé sous l’égide de grands Cabinets de Conseil pour de nombreuses organisations françaises et étrangères. Il est à l’origine du concept d’Espace de Liberté déposé par Keyrus.




Commentaires

1.Posté par Sébastien MONCEL le 16/11/2010 11:04
Bonjour,

Qu'entendez-vous par "décomposer le système décisionnel lui-même en sous-systèmes urbanisés" ?
S'agit-il de datamarts spécifiques issus de l'entrepôt de données ? de différents projets ou ensembles de restitutions (rapports, graphs...) au niveau des outils de restitution ?
Dans les deux cas, celà aura pour conséquence d'accroitre le risque d'incohérences (entre les sous-systèmes), et mécaniquement les coûts de développements et de maintenance à venir.
Donc effectivement, on y gagne en réactivité (vision court terme), mais on y perd sur les autres aspects (vision moyen et long terme).

2.Posté par Jean-Marc Dupont le 16/11/2010 15:26
Twitter
Tout à fait d'accord avec tous ces principes
Comme vous le dites, le risque des nouveaux outils tels que Qlikview est de passer outre cette nécessaire étanchéité entre décisionnel et système de production.
La facilité de construction d'un modèle, basé directement sur le modèle de production, sur lequel vont s'appuyer les tableaux de bord peut avoir pour conséquence une rupture de service du système décisionnel lors d'une migration de l'ERP de l'entreprise, avec pour impact immédiat une perte des indicateurs de décision pour la direction.
Sans remettre en cause la plus-value de ce type d'outils, il faut en effet encadrer sa mise en oeuvre et conserver le modèle décisionnel qui garantit son étanchéité.
La solution proposée par 6IT respecte ces principes et fournit aux entreprises liées aux métiers de la supply chain un package complet, issu de l'expérience du terrain : http://www.6it.fr/pack-performance.htm

3.Posté par Sébastien MONCEL le 16/11/2010 15:52
@Jean-Marc Dupont
Je suis tout à fait de votre avis au sujet des outils qui restituent les données directement depuis le système de production : il faut bien encadrer leur mise en oeuvre.
En particulier, au niveau des performances en restitution dans les contextes à fortes volumétries de données : les modèles de données des systèmes de production ne sont généralement pas adaptés (très normalisés, jointures avec un coût algorithmique trop coûteux). Si ils l'étaient, nous n'aurions pas besoin de faire d'entrepôts de données reposant sur des modèles en étoile, en flocon et dénormalisés...

4.Posté par Laurent-Xavier GUSSE le 16/11/2010 21:45
On ne peut qu'être d'accord avec les principes évoqués par Denis SKALSKI. Toutefois vos remarques notamment sur QlikView ne sont pas fondées et mettent en évidence un manque de connaissance du produit QlikView. QlikView repose sur les mêmes principes que tout système décisionnel et nécessite l'extraction des données sources et le stockage dans un environnement décisionnel (celui de QlikView). Il n'y a donc pas d'accès direct à l'ERP mais une phase classique d'extraction de données et de stockage dans une structure décisionnelle QlikView.
Au contraire, comme le dit Denis SKALSKI, ces outils tels que QlikView offrent une nouvelle vision du pilotage plus intuitive, plus simple à maîtrise, à mettre en oeuvre mais leur intégration nécessite toutefois d'être encadrée en respectant les principes même d'un système décisionnel.

5.Posté par S.Maouche le 17/11/2010 17:47
Je rejoins Mr GUSSE. QlikView est une solution BI 3G qui ne s'affranchit nullement d'une couche de données décisionnelle bien modélisée. Le gain sur une telle solution de Dashboarding est sa facilité à mettre en application très rapidement des interfaces dynamiques de restitution... là où des solutions BI 2G comme SAP BO ou encore Cognos implique du temps et une connaissance relativement pointue pour une production conforme.
De plus en terme de performance et temps de rafraichissement, QlikView se fonde sur une base de données vectorielle compressée et stockée en local, ce qui induit une réactivité assez impressionnante.


Remarque : article très intéressant qui mériterait encore d'être approfondi :-)

6.Posté par Sébastien MONCEL le 18/11/2010 10:17
@S. Maouche et Laurent Xavier Gusse
Etant donné que Qlikview travaille en mode "In-memory" (me semble-t'il), que donnent les performances en restitution si la volumétrie des données contenues dans la base vectorielle compressée dépasse la mémoire disponible sur le serveur ?

7.Posté par Denis SKALSKI le 19/11/2010 19:07
Bonjour,

merci à tous pour vos remarques fondés auquelles je vais essayer d'apporter un éclairage. sur la question "Qu'entendez-vous par "décomposer le système décisionnel lui-même en sous-systèmes urbanisés" ?" de Monsieur MONCEL

Il s'agit bien de sous-systèmes indépendants : un système de collecte et de stockage temporaire (intégrant la fonction ODS), un système de stockage de la connaissance de l'entreprise (intégrant la fonction DWH), plusieurs systèmes de préparation "métier" (sur lequel je fais un zoom plus bas), un Système d'administration et de référence (intégrant les fonctions de maîtrise et notamment le méta-dictionnaire transversal), le système d'échanges normalisés (intégrant la fonction de préparation de valeurs pour alimenter d'autres systèmes ex. CRM) et enfin le Système de Présentation et de Diffusion de l'information (portant toutes les fonctions d'accès, de restitutions décisionnelles ou de manipulation de l'information)
S'agissant des systèmes de présentation "métier" (SPM), autant de SPM que de métier. Le SPM intègre des blocs standards tels que "collecte", "transformation", "datamart détaillé et agrégé", "application métier" et "espace de liberté". Ces systèmes ont pour vocation de préparer l'information du métier en fonction de ces usages et de la mettre à disposition des fonctions de restitution (SDP). Il est clair que le modèle présenté peut engendrer des problèmes de cohérence et notamment "sémantique". Cependant, dans la démarche et la gouvernance décisionnelle, le SAR et notamment le méta-modèle est le garant de l'unicité des indicateurs. Si un métier souhaite mettre en place un inidcateur de type "PNB" par exemple, le responsable fonctionnel décisionnel se devra de vérifier que cet indicateur n'existe pas déjà dans le système. Si c'est le cas, soit un protocole de consensus aura lieu pour s'assurer de la non redondance de l'indicateur. Si le consensus n'est pas possible, un autre indicateur sera créé.
Le Système d'Administration et de Référence trace l'ensemble du "contenu", les échanges inter-systèmes et la sémantique. C'est le liant indispensable pour assurer la cohérence d'un tel modèle. par contre, le modèle urbanisé va jusqu'au niveau de la fonction (fonctions -> blocs -> sous-systèmes). Ces fonctions sont déclinées sous différentes technologies. Une capitalisation forte existe sur l'ETL qui permet de générer une boite à outils (template) en accord avec les fonctions applicatives
D'autre part, le fait de bénéficier de sous-système, blocs étanches basés sur des échanges "normalisés" permet d'envisager un découplage des développements d'une part mais aussi d'organiser les équipes sur la base de "centres de service" orientés "système" -> ex. equipe dédiée à la collecte, équipe dédidée au DWH (...).
Nous avons clairement identifiés des gains en termes de développement et de maintenabilité dans ce sens (environ 30% en développement, 40% en maintenance et surtout 50% sur les délais)
L'investissement de départ sur le design "urbanisé" est rapidement rentabilisé tant sur le plan qualitatif que sur le plan quantitattif

8.Posté par Denis SKALSKI le 19/11/2010 19:10
Sur la remarque de Monsieur DUPONT.

En effet, ce type d'outil nécessite d'être vigilant et de mettre en place une Gouvernance adaptée autorisant, certe, de la liberté mais pas sans contraintes. "Pas de liberté, sans maîtrise". J'ai un cas client où les Espaces de Liberté ou Espaces Privatifs ont "explosé" / système industrialisé du fait de l'absence de fonction de maîtrise, de bridage, de surveillance et de partage.

9.Posté par Denis SKALSKI le 19/11/2010 19:19
Sur les outils : l'article est clairement fondé sur des principes et concepts d'urbanisation. Pour autant, certaines solutions techniques sont plus adaptées pour couvrir les fonctions du SPM et notamment de l'Espace de Liberté. En effet, il convient d'offrir des fonctionnalités aux utilisateurs leur permettant de s'affranchir de l'IT et notamment des phases de modélisation IT. QlickView, TableauSoftware et Microsoft BI sont des solutions, entre autre, adaptées à cette contrainte. Maintenant, pour des métiers tels que le Marketing, SAS est totalement adapté pour un bloc de type "datalab qualité" ou "datalab marketing".
Nous ne pouvons nous affranchir de ce type d'outils. Si la Gouvernance Décisionnelle et notamment les DSI souhaitent s'en affranchir, il est clair que les métiers prendront eux même le pas sur ces technologies sans consultation des DSI. Il vaut mieux anticiper leurs utilisations pour mieux les maîtriser

Denis.skalski@keyrus.com

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store