Quels sites ont reçu le lot suspect, et quels clients l’ont aujourd’hui ? La réponse existe, dispersée entre l’ERP, le MES, le registre qualité et le CRM, sous quatre références différentes. Quelqu’un ouvre un ticket. Trois semaines plus tard arrive un tableur réconcilié à la main, et le lot est déjà parti. Au comité de pilotage suivant, quelqu’un propose un entrepôt de données.
Un entrepôt est un pilote en plus grand
Un pilote copie une partie du métier une fois et interroge la copie. Un entrepôt copie le métier en continu, pour dix fois le coût. Les deux reposent sur la même base : une copie.[1]
Le programme se déroule toujours de la même manière. Un an de pipelines. Un schéma figé au troisième mois par une équipe qui n’a jamais manipulé la pièce. Une couche de réconciliation, puis une équipe dédiée à sa maintenance. À la fin, la question de départ est toujours ouverte, parce que l’entrepôt contient ce qui a été chargé, dans une forme choisie avant que la question ne soit posée.
IBM décrit bien le problème : des données dispersées entre systèmes, applications, clouds et documents, sans source unique de vérité, et périmées au moment où on les utilise. Parmi les remèdes, IBM cite la consolidation dans un entrepôt ou un lac par des pipelines ETL.[2] Le diagnostic est juste. Le remède ajoute un système de plus, un format de plus et une version de plus de la référence.
Chaque format est une frontière
Au sein d’une même organisation, chaque format propriétaire ajoute de la friction, du délai et du travail de réconciliation.[3] La donnée ne circule pas. Elle est extraite, transformée, dégradée, réconciliée en fin de trimestre, et au bout du compte personne ne s’y fie.
Un entrepôt ne supprime pas ces frontières. Il en construit une centrale et fait tout passer par elle. Les quatre systèmes sont toujours en désaccord sur la pièce. Le désaccord s’est simplement déplacé dans un traitement de nuit, où il échoue en silence.
Le ticket entre la question et la réponse
Ceux qui comprennent le métier ne savent pas construire le pipeline, et ceux qui le construisent ne comprennent pas le métier. Entre eux, une file de tickets.[4] L’ingénieure qualité sait ce que « lot » veut dire en atelier. Elle rédige une demande. La demande devient une spécification, puis un pipeline, validé par des gens qui n’ont jamais eu la connaissance d’origine. Le sens se perd à chaque étape, et personne ne voit la chaîne entière.
Le vrai coût est le temps : des jours pour établir quel système a raison sur une seule référence, puis une semaine de plus pour faire accepter la réponse par la direction.[5] L’organisation qui réduit cet intervalle l’emporte.[6] Vos concurrents font appel aux mêmes cabinets. L’avantage revient à l’organisation qui répond à une question sur elle-même aussi vite qu’elle la pose.
Interroger la donnée là où elle est
L’alternative existe depuis longtemps. La virtualisation des données permet à une application d’interroger les sources en place : les données ne bougent pas, et l’accès se fait au système source plutôt qu’à une copie.[7] Rien n’est extrait, donc rien ne se périme. Les limites sont connues : chaque source doit être joignable, et l’approche ne conserve pas d’historique.[7:1]
Mais une requête fédérée sur quatre systèmes qui nomment la même pièce de quatre façons renvoie simplement quatre réponses plus vite. Elle ne réconcilie rien, parce que la réconciliation est un problème de vocabulaire, pas de données. Une organisation sans modèle explicite d’elle-même ne voit pas ce qu’elle n’a pas de concept pour nommer.[8] Ce modèle doit être défini d’abord, dans les mots de ceux qui font le travail, et non rédigé comme documentation après le chargement.[8:1]
Au-delà de la requête, il faut trois choses : un modèle explicite de ce qu’est la pièce dans les quatre systèmes, un chemin de chaque chiffre jusqu’à sa ligne source, et une personne nommée responsable de la décision qui découle de la réponse.
Notre position
Galahad ne migre pas vos données et ne construit pas de copie de votre métier à interroger. Monarch tourne dans votre infrastructure, sous vos comptes et votre juridiction, et lit à travers les systèmes que vous exploitez déjà.[9] Une copie est périmée par nature, elle devient un cinquième système avec une cinquième version de la vérité, et si elle quitte votre réseau, elle quitte votre juridiction.
Les questions à poser à un éditeur
- Votre produit exige-t-il que mes données soient déplacées, copiées ou indexées avant de répondre ? Où vit la copie, et de quand date-t-elle ?
- Quand j’interroge une référence, quelle version me renvoie-t-on, et qui l’a décidé ?
- La personne qui connaît le métier peut-elle modifier le vocabulaire, ou faut-il un ticket ?
- Si une source est injoignable, la réponse le signale-t-elle ?
- À qui appartient le modèle de mon métier, et le garde-t-on si l’on part ?
Monarch lit à travers les systèmes que vous exploitez déjà, dans votre infrastructure. Rien n’est migré. Voyez-le sur vos données.
IBM, What is data fragmentation? : données dispersées entre systèmes, applications, clouds, bases et documents ; périmées quand elles atteignent leur usage ; consolidation dans un entrepôt ou un lac par des pipelines ETL/ELT parmi les remèdes. Source ↩︎
Wikipedia, Data virtualization : les données restent en place et l’accès en temps réel est donné au système source, à la différence de l’ETL ; parmi les limites, chaque source doit être joignable et l’approche ne convient pas aux instantanés historiques. Source ↩︎ ↩︎
Galahad, l’entreprise : Monarch tourne dans votre infrastructure, sous vos comptes, vos clés et votre juridiction ; Galahad n’héberge aucune de vos données. Le lire ↩︎