Concepts clés du programme FLOW
Cette page rassemble les concepts qui structurent la vision FLOW.
Elle ne remplace pas le glossaire.
Le glossaire définit les termes. Cette page explique les idées qui changent la manière de lire le programme.
Les phrases qui portent FLOW
FLOW ne cherche pas à mieux gérer les commandes.
FLOW cherche à mieux satisfaire les demandes.
La convergence n'est pas l'uniformisation.
Elle consiste à choisir le bon niveau de commun, au bon endroit, pour la bonne responsabilité.
Les consommateurs peuvent rester différenciés.
La plateforme doit être décloisonnée.
FLOW ne remplace pas tous les organes du SI.
FLOW reconstruit la colonne vertébrale qui leur permet de fonctionner ensemble.
FLOW ne doit pas seulement remplacer des applications.
Il doit remplacer la logique de tuyauterie projet par une logique de contrats de données gouvernés.
FLOW configure des capacités d'action.
Il ne reconstruit pas un grand miroir administratif de l'entreprise.
Carte des concepts
| Concept | Message clé |
|---|---|
| Bon niveau de commun | On ne choisit pas entre tout centraliser et tout laisser local : pour chaque responsabilité, FLOW décide ce qui doit être commun, fédéré ou différencié. |
| Demande / Demand | Le point de départ n'est plus la commande ou le document, mais l'intention à comprendre, décider, promettre, satisfaire et expliquer. |
| Case | Le Case porte une demande dans la durée : intention, contexte, décisions métier, événements, ressources, actions et documents. |
| Plateforme Demand | FLOW devient le lieu de cohérence des demandes, décisions métier, stock, promesses, événements et exceptions. |
| Colonne vertébrale opérationnelle | FLOW porte les responsabilités qui doivent rester cohérentes — demandes, décisions métier, statuts, événements, stock, promesses et orchestration — sans réécrire tout le SI. |
| Capacités d'intégration | Un service réintégré autour de FLOW doit pouvoir exposer des APIs, publier des événements, partager des statuts, corréler ses objets et participer à la réconciliation. |
| Contrat de données | Une information en transit doit être publiée, consommée, supervisée et gouvernée comme un actif durable, pas comme un flux projet opportuniste. |
| Stock Unifié | Le stock devient une capacité d'entreprise, pas une simple information locale extraite d'un système. |
| Fulfillment Network / Réseau d'exécution | Le réseau d'exécution décrit les nœuds, services, capacités, contraintes et conditions d'usage mobilisables pour satisfaire une demande. |
| Agreement | L'Agreement porte les conditions et règles de traitement qui permettent de gérer la variation sans multiplier les processus. |
| Variabilité gouvernée | Les singularités business sont portées par des règles, contraintes, policies, modèles de décision, patterns et algorithmes plutôt que par des chaînes de conditions. |
| Décision / règles / policies | Les décisions métier doivent être explicites, traçables, gouvernées et capables de faire évoluer le Case. |
| Arbitrage | Un arbitrage est un choix de programme ou d'architecture à rendre explicite ; il ne doit pas être confondu avec une décision métier exécutée dans FLOW. |
| Vues 360 | Les vues 360 donnent une lecture transverse d'une activité, d'un client, d'un fournisseur, d'une commande ou d'un Case. |
| Source de référence / projection | Une information fait référence lorsqu'elle est contrôlée par un processus responsable ; les projections, vues et agrégats la rendent consommable sans devenir automatiquement maîtres. |
| Projection locale de décision | Une décision critique doit disposer localement des informations nécessaires à son calcul, sans dépendre d'appels synchrones à des APIs externes. |
| Hotspot | Un hotspot est un point de tension à instruire avant de figer un arbitrage ou une architecture cible. |
| Domaine / responsabilité / capacité / produit | FLOW découpe les problèmes durables avant de parler d'applications, d'organisations ou de fonctionnalités. |
Bon niveau de commun
La convergence ne signifie pas que tout doit être identique partout.
FLOW ne cherche pas un niveau unique de convergence.
Il cherche le bon niveau de commun pour chaque responsabilité :
Centraliser
lorsque la cohérence est critique
Unifier
lorsque le modèle doit être partagé
Standardiser
lorsque la variation n'apporte pas de valeur
Fédérer
lorsque plusieurs modèles doivent coexister
Différencier
lorsque le business l'exige
Ce concept est important parce qu'il permet de sortir d'un débat trop pauvre : centraliser ou laisser local.
FLOW rend explicite ce qui doit devenir commun, ce qui doit être fédéré entre plusieurs modèles, et ce qui peut rester différencié parce que cela crée de la valeur.
Demande / Demand
La demande est le concept central de FLOW.
Elle représente une intention à traiter : commande, retour, litige, SAV, exception, engagement, demande fournisseur ou autre situation à instruire.
Ce que cela change :
- on ne part plus d'abord de la facture, de la commande ou du module applicatif ;
- on part de ce que l'entreprise doit comprendre, décider, promettre, satisfaire et expliquer ;
- les canaux et organisations deviennent des contextes de traitement, pas le centre du modèle.
Case
Le Case est la forme durable de la demande.
Il conserve :
- l'intention initiale ;
- le contexte ;
- les parties concernées ;
- les décisions métier ;
- les règles appliquées ;
- les événements ;
- les ressources mobilisées ;
- les actions réalisées ;
- les documents associés ;
- l'état courant.
Le Case permet de traiter des transactions longues qui traversent plusieurs processus, applications, domaines ou partenaires.
Plateforme Demand
FLOW est une plateforme Demand.
Cela signifie qu'elle porte le cœur commun nécessaire pour traiter les demandes, gouverner les décisions métier et mobiliser les ressources d'exécution.
Une plateforme n'est pas seulement une application centrale.
Elle gouverne des ressources communes, tout en ouvrant des processus contrôlés permettant à d'autres domaines de configurer, développer, étendre ou consommer ses capacités.
Colonne vertébrale opérationnelle
FLOW n'est pas tout le SI.
Il est la colonne vertébrale opérationnelle qui porte les responsabilités qui doivent rester cohérentes à l'échelle du groupe : demandes, décisions métier, statuts, événements, stock, promesses, allocations et orchestration transverse.
Les services spécialisés peuvent rester autonomes lorsqu'ils portent une valeur métier propre.
Mais ils doivent se brancher sur cette colonne vertébrale commune plutôt que reconstruire chacun leur propre logique de demande, statut, stock ou décision métier.
Capacités d'intégration des systèmes réintégrés
Réintégrer un service existant ne signifie pas seulement le conserver.
Cela suppose qu'il puisse interagir proprement avec FLOW.
Les capacités d'intégration minimales à étudier sont notamment : APIs contractuelles, événements métier, statuts, documents, identifiants de corrélation, supervision, reprise et réconciliation.
Sans ces capacités, on ne réintègre pas vraiment l'outil : on conserve un silo.
Contrat de données
Un contrat de données décrit la manière dont une information circule durablement entre une source, des consommateurs et une responsabilité métier.
Il précise notamment :
- l'information publiée ;
- la source de référence responsable ;
- les consommateurs connus ;
- le mode d'échange ;
- la granularité ;
- la fraîcheur attendue ;
- la qualité attendue ;
- les règles de supervision ;
- les mécanismes de reprise et de réconciliation.
Ce concept permet de sortir d'une logique de flux projet point-à-point.
Il prolonge l'intuition du demi-flux : distinguer la publication d'une information de sa consommation.
Stock Unifié
Le Stock Unifié n'est pas seulement une consolidation d'informations.
C'est une capacité d'entreprise qui doit permettre de répondre à des questions opérationnelles :
- quel stock existe ?
- quel stock est disponible ?
- quel stock peut être promis ?
- quel stock peut être réservé ou alloué ?
- selon quel contexte business cette disponibilité est-elle vraie ?
Le stock devient une ressource de décision métier.
Fulfillment Network / Réseau d'exécution
Le réseau d'exécution ne décrit pas seulement des lieux.
Il décrit ce que le réseau sait faire :
Nœud logistique
↓
Capacités disponibles
↓
Contraintes
↓
Services exposés
↓
Conditions d'usage
Ce concept permet à FLOW de raisonner sur la capacité réelle d'exécution, pas seulement sur une liste d'entrepôts, de magasins ou de partenaires.
Agreement
L'Agreement devient un concept central parce qu'il porte les conditions de traitement.
Il permet de rendre les commandes plus génériques : ce n'est plus la multiplication des types de commandes qui porte toutes les variations métier.
Le contexte, les Agreements et les règles pilotent dynamiquement les variations de processus.
Variabilité gouvernée
La variabilité gouvernée permet de préserver les singularités business sans transformer le SI en empilement de cas particuliers.
Les marques, canaux, clients, agreements, services, contraintes Supply ou promesses peuvent justifier des comportements différents.
Le risque est que chaque différence soit codée dans un workflow, une interface ou une chaîne de conditions.
FLOW doit au contraire expliciter cette variabilité dans des mécanismes gouvernés :
- règles métier ;
- policies ;
- moteurs de contraintes ;
- modèles de décision ;
- patterns Strategy ou extension contrôlée ;
- paramètres et jeux de données qualifiés ;
- assistance IA lorsque cela aide à classifier, recommander, détecter ou expliquer.
Ce concept est détaillé dans le principe 8.
Projection locale de décision
Une projection locale de décision est une projection conçue pour calculer vite et de manière autonome.
Elle répond à un principe simple : une décision critique ne doit pas dépendre, au moment du calcul, d'une chaîne d'appels à des APIs externes dont FLOW ne maîtrise pas le SLA.
La source de référence garde la responsabilité de l'information.
La projection locale donne au moteur de décision le modèle de lecture nécessaire pour décider, expliquer et tracer.
Ce concept est détaillé dans le pattern Projection locale de décision.
Décision / règles / policies
Une décision est un choix explicite qui fait progresser le traitement d'un Case.
Elle s'appuie sur des faits, des informations et des règles de comportement.
Elle doit pouvoir être comprise, tracée, auditée, simulée et modifiée.
Dans FLOW, le processus émerge des décisions successives prises sur le Case.
Arbitrage
Un arbitrage est un choix de programme, d'architecture ou de gouvernance qui doit être rendu explicite avant de stabiliser la trajectoire.
Il peut porter par exemple sur un périmètre, une frontière de responsabilité, une trajectoire de migration, un niveau de centralisation ou un modèle de gouvernance.
Un arbitrage n'est pas une décision métier exécutée dans le Case Management.
Cette distinction évite de confondre :
- les décisions fonctionnelles que FLOW doit prendre, tracer et expliquer ;
- les arbitrages de programme qui orientent la cible et la trajectoire.
Vues 360
Les Vues 360 agrègent des informations autour d'un objet, d'un acteur ou d'une activité.
Elles permettent de lire transversalement ce qui s'est passé : événements, statuts, documents, décisions métier, exceptions et faits utiles.
Elles ne remplacent pas les domaines sources.
Elles rendent l'activité plus lisible.
Source de référence / projection
FLOW ne reprend pas la catégorie Master Data comme un fourre-tout.
Une information doit être qualifiée par nature et par statut dans un domaine : source de référence ou projection.
Une source de référence est l'application, le service ou le domaine où une information est créée, validée ou maintenue par un processus responsable, avec un niveau de qualité suffisant pour faire référence pour un usage donné.
Une projection, une vue 360 ou un agrégat peut rendre l'information plus accessible, mais ne devient pas source de référence par simple visibilité.
Le risque à éviter est la copie devenue maître par accident : une projection ou une vue finit par porter les corrections et arbitrages parce que la vraie source est trop lente ou trop éloignée.
La bonne question devient :
Pour cet usage, cette décision métier et ce consommateur, quelle source de référence fait foi ?
Cette lecture est essentielle dans un SI distribué.
Elle est détaillée dans le pattern Sources de référence, projections et vues.
Hotspot
Un hotspot est un point de tension à instruire.
Il n'est pas encore un arbitrage stabilisé.
Il concentre souvent plusieurs dimensions : business model, application existante, responsabilité cible, règle, information, finance, exécution ou trajectoire de transformation.
Les hotspots évitent de masquer trop tôt les zones difficiles sous une architecture trop propre.
Domaine / responsabilité / capacité / produit
FLOW ne part pas d'abord des applications ou des organisations.
Il part des problèmes durables de l'entreprise.
Domaine
↓
Responsabilité
↓
Capacité
↓
Produit
↓
Fonctionnalité
Cette taxonomie permet de ne pas confondre un outil existant, une équipe, un processus et la responsabilité durable que l'entreprise doit continuer à assumer.
À retenir
Les concepts FLOW ne sont pas des mots nouveaux pour faire moderne.
Ils servent à déplacer le raisonnement : de l'application vers la responsabilité, du document vers la demande, de l'information miroir vers la capacité d'action, du flux projet vers le contrat de données, et de l'uniformisation vers le bon niveau de commun.