Organisation Data Driven : Comment rendre les données accessibles et actionnables ?

Vous faites partie d’une organisation dite Data Driven ? Êtes-vous certain que vos données sont accessibles et actionnables au sein de votre organisation ? De plus en plus d’entreprises collectent et analysent leur data afin d’optimiser leurs actions, process et prises de décisions. Cependant, bon nombre d’entre elles sont mal structurées et peinent à faire de la Data un véritable levier de croissance. Pire, parfois ces problèmes organisationnels peuvent engendrer de défaillances réelles qui nuisent à l’ensemble de l’entreprise.

Dans cet article, nous commençons par vous présenter des types d’organisations défaillantes en explicitant, bien sûr, leurs causes. Puis, nous vous détaillons le fonctionnement d’une organisation en Data Layer qui permet de rendre vos données plus facilement accessibles et actionnables au sein de votre entreprise.

Organisation Data Centric – Retour sur des organisations défaillantes

#1 L’attente interminable

La lenteur de la remontée des informations est un problème courant au sein des organisations fonctionnant en silos. Pour illustrer ce type d’organisation défaillante, prenons l’exemple d’une banque et des exigences réglementaires qui vont avec ce type d’entreprises.

Le Data Analyst : intermédiaire entre le business et l’ingénieur Data

La banque que nous prenons en exemple exploite un ensemble de bases de données RDBMS massives, qu’elle stocke dans un entrepôt de données central.

Dans ce contexte, le travail quotidien d’un analyste consiste à fournir divers rapports de performance à la direction de l’entité commerciale dont il fait partie. En réalité, le Data Analyst ne connaît pas ces bases de données et n’interagit pas directement avec elles mais avec une équipe de « Services IT » qui lui est assignée.

Concrètement, le rôle d’un Data Analyst est donc de fournir à son manager un ensemble de données en se rendant sur la plateforme mise à disposition par le prestataire de Service IT. Pour cela, ce dernier construit donc des sous-ensembles de données au sein de l’entrepôt principal.

Après avoir découpé et redécoupé les données pour extraire les chiffres souhaités, le Data Analyst le fait remonter sous la forme d’un tableur Excel, pour que le manager puisse les analyser à son tour.

Un process douloureux

Cette organisation fonctionne jusqu’à ce que le manager demande des données auxquelles il n’a pas accès, le process suivant se met alors en place :

• #1 Le Data Analyste vérifie qu’il ne dispose pas déjà de ces chiffres au sein d’un sous-ensemble de données déjà extrait.
• #2 Il contacte le service IT en créant un Ticket dans lequel il demande à un Ingénieur Data à ce que les nouvelles données soient ajoutées à un sous-ensemble de données existant ou d’en créer un nouveau. Ce Ticket est ensuite envoyé à un système central de planification des ressources de l’entreprise, le coût associé à la démarche est ensuite imputé au département qui crée la demande.
• #3 Attendre trois semaines.
• #4 Au bout de trois semaines, le Service IT informe le Data Analyst que le Ticket a été traité et que les nouvelles données sont disponibles sur la plateforme.
• #5 Si le Ticket comprend une erreur ou n’est pas clair, le Service IT demande d’éditer le Ticket et nous sommes de retour à l’étape 2.

Holistics : The Analytics Setup Guidebook

Perte de temps et sous-exploitation de la Data

La perte de temps engendrée par un Ticket mal réalisé est très importante (3 semaines supplémentaires) et met le Data Analyst en difficulté vis à vis de son manager qui attend ses chiffres pour la fin de la période donnée.

En outre, le rôle du Data Analyst est très limité et extrêmement dépendant de la flexibilité de l’ingénieur data assigné par le prestataire de services IT en cas d’erreur.

Ces délais et ces difficultés sont encore plus importants lorsque d’autres demandes venant de plus haut sont priorisées par le service IT. Il ne reste alors que très peu de temps à attribuer aux autres demandes et le poids d’une erreur sur un Ticket IT est encore plus important.

#2 La guerre des metrics

Dans des organisations data driven plus modernes et flexibles, on retrouve un autre type de défaillance liée au traitement de la donnée : la guerre des metrics.

Pour illustrer ce second type de défaillance, prenons l’exemple d’une start-up, moins silotée que notre banque de l’exemple précédent.

Un pôle Data indépendant des entités Business

En termes de gestion des données, notre start-up utilise donc un serveur SQL Microsoft comme base de leur magasin de données, construit des cubes dans les services d’analyse du serveur SQL Microsoft (ou SSAS), puis upload ces extraits de données vers Tableau.

Ici, le Data Analyst travaille directement au sein d’un pôle Data, avec pour objectif de donner aux utilisateurs de l’entreprise et aux chefs de projet un accès direct aux données de l’entreprise, dans le meilleur des cas en libre-service.

Quand on repense à la lenteur du process de notre exemple précédent, ça semble effectivement être une bonne idée.

Process : des données en quasi libre-service

Tableau est un outil de BI puissant qui permet aux équipes marketing et de vente de créer des analyses visuelles sur la base des données fournies par l’équipe Data. Plus concrètement, le process associé est donc le suivant :

• #1 Le pôle Data exploite les données issues du CRM ou de l’ERP utilisé et les met à la disposition des équipes marketing et de vente sous la forme de fichiers CSV.
• #2 Les différentes entités uploadent ensuite ces données dans Tableau – qui est très intuitif et ne demande pas ou peu de compétences techniques pour être exploité – et réalisent ensuite leurs analyses.
• #3 Les rapports générés sont ensuite utilisés par la direction pour prendre des décisions stratégiques.

Holistics : The Analytics Setup Guidebook

Des analyses différentes en fonction des entités

Les limites de ce type d’organisation ne viennent pas du process mais du manque de contrôle du pôle Data sur l’exploitation des données fournies par les différentes business units. Que se passe-t-il lorsque deux BU obtiennent des résultats différents en basant leurs analyses sur les mêmes chiffres ? Elles se retournent vers le pôle Data et demandent des comptes ! Les sources de données sont pourtant les mêmes, les chiffres devraient correspondre.

En réalité, sans standardisation des données à l’échelle de l’entreprise, il est possible qu’une entité exploite des données sous un format légèrement différent des autres et se retrouve donc avec des analyses différentes. Les décisions stratégiques prises sur la base de ces données erronées peuvent alors avoir un impact négatif sur la réussite de l’entreprise.

Il s’agit ici d’une limite aux outils de BI qui deviennent de plus en plus intuitifs et donc accessibles aux profils qui ne disposent pas des compétences techniques pour les maîtriser totalement. Pour pallier à cela, les équipes Data ou de BI (équipes compétentes) doivent définir et standardiser les métriques qui peuvent être exploitées et analysées par les équipes commerciales.

Organisation en couche

Nous avons observé les limites des organisations « Data Centric », intéressons-nous maintenant à un autre type d’organisation data driven : les organisations en Data Layer.

Pour illustrer ce troisième type d’organisation, prenons l’exemples d’une autre start-up en phase croissance, plus récente. Cette dernière utilise une solution de stockage des données en cloud d’Amazon, Redshift ainsi que Looker, un outil de BI.

Des modèles de données créés par l’équipe Data

Looker est un outil très intuitif qui adopte une approche de l’analyse de données totalement différente des outils évoqués en première partie.

Connecté à RedShift, Looker exécute des requêtes SQL directement dans la base de données.

Dans ce cadre, le rôle de l’équipe de Data Analysts consiste principalement à créer des modèles de données en LookML, le langage de modélisation de données de Looker. Ces modèles sont ensuite transmis aux membres moins techniques de l’organisation qui le transforment alors en tableaux de bord et en rapports via une interface self-service.

Holistics : The Analytics Setup Guidebook

Des metrics basés sur les mêmes données

Contrairement au paradigme de l’approche précédente qui passait par l’utilisation de Tableau, ici c’est l’équipe Data qui définit et standardise la logique commerciale et les metrics qui en découlent dans la couche de modélisation des données.

Ces modèles ont ensuite été réutilisés par d’autres analystes et par des utilisateurs non techniques pour produire les rapports au service des décisions stratégiques de l’entreprise.

Un écosystème complexe

L’évolution organisationnelle suit l’évolution technologique

Le principal facteur qui a influencé l’évolution vers des organisations en Data Layer est le progrès technologique qui permet aujourd’hui de créer des bases de données analytiques rapides et bon marché (dont beaucoup ont même migré vers le cloud).

Il est facile d’oublier à quel point le hardware était coûteux dans les années 90. En 1993, par exemple, 1 Go de RAM coûtait 32 300 dollars – une somme folle pour ce qui semble être une quantité de mémoire insignifiante aujourd’hui ! Cela explique en grande partie les difficultés rencontrées dans notre premier exemple : les entrepôts de données étaient tout simplement trop chers et trop lents pour être utilisés pour l’analyse quotidienne.

Ces entrepôts de données MPP et ces systèmes SQL-on-Hadoop sont si rapides et si bon marché que vous n’avez plus besoin d’extraire vos données pour les analyser. Vous pouvez faire vos analyses directement dans la base de données.

Les structures et outils laissent de lourds héritages

La logique commerciale et organisationnelle que les outils de BI servent est plus importante que la sélection des outils en elle-même.

Voici les principales conclusions à tirer lorsqu’on prend du recul sur l’évolution organisationnelle des outils de BI au sein de entreprises :

• Les approches en matière d’outils de BI sont limitées par la technologie.
• Les nouvelles approches se créent souvent en réaction à des douleurs dans la génération précédente d’outils.
• Chaque génération d’outils et de structures reste longtemps, très longtemps au sein des organisations.

Le monde de l’intelligence économique constitue aujourd’hui un écosystème complexe pour cette troisième raison : les outils et les approches restent longtemps en place. Cela donne un mélange de terminologies, d’idées, de schémas architecturaux et d’approches parfois difficiles à cerner qui freine les entreprises dans leur capacité à rendre leurs données accessibles et actionnables.

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir