Architecture des processus métier : ce qu’elle est et pourquoi les cartographies ne suffisent pas

Vous avez les cartographies de processus. Peut-être même en avez-vous un grand nombre. Un membre de l’équipe a créé un diagramme en couloirs dans Lucidchart il y a deux ans. Un autre département maintient une page Confluence avec des organigrammes mis à jour pour la dernière fois lorsque tout le monde allait encore au bureau. Et lorsqu’un problème survient lors d’un passage de relais entre les Ventes et la Finance, ou qu’un nouveau projet d’automatisation s’emmêle en tentant d’intégrer trois systèmes différents qui décrivent tous le même concept différemment, quelqu’un dit : « Nous devrions mieux documenter cela. »

C’est le mauvais diagnostic. Les cartographies ne sont pas le problème, et en créer davantage ne le résoudra pas. Ce qui manque, c’est la structure qui les relie — le modèle de gouvernance qui vous indique quels processus existent, comment ils s’articulent, qui en est responsable et comment ils sont améliorés. C’est l’architecture des processus métier. Et ce n’est pas de la documentation. C’est une discipline.

L’affirmation centrale est vérifiable : la plupart des initiatives d’amélioration des processus et d’automatisation échouent à leurs interfaces, non pas parce que les cartographies de processus individuelles sont erronées, mais parce qu’aucune architecture ne les maintient ensemble. Corrigez les cartographies sans construire l’architecture, et vous reviendrez au même point dans 18 mois.

Ce que la plupart des équipes apprennent après leur deuxième initiative échouée

• L’architecture des processus métier (BPA) est un modèle opérationnel hiérarchique, et non une collection de diagrammes.
• Une seule cartographie de processus n’est pas une BPA : l’architecture organise l’ensemble de la hiérarchie et sa gouvernance.
• Pour fonctionner, la BPA nécessite des responsables de processus, des métriques et une gestion du changement ; la hiérarchie seule ne suffit pas.
• Le signal pratique indiquant que vous avez besoin d’une BPA : les projets d’automatisation échouent régulièrement aux points d’intégration entre les départements.

Ce qu’est réellement l’architecture des processus métier

L’architecture des processus métier est un modèle hiérarchique des processus métier d’une organisation, couvrant au minimum deux niveaux de la hiérarchie des processus : le niveau des processus de bout en bout et celui des groupes de processus qui les contiennent. C’est la définition de travail issue des recherches d’Eficio sur l’architecture des processus — et elle est plus précise que ce que la plupart des équipes imaginent.

Le mot « hiérarchique » est essentiel ici. Un unique diagramme en couloirs montrant comment un commercial fait progresser une opportunité à travers différentes étapes est une cartographie de processus. Il documente un processus. L’architecture des processus métier est le modèle organisationnel qui positionne cette cartographie aux côtés de tous les autres processus de l’entreprise, à plusieurs niveaux d’abstraction, et définit les relations entre eux. Sans la hiérarchie, vous n’avez pas une architecture. Vous avez un diagramme. Ce n’est pas la même chose.

La confusion est compréhensible. Les deux utilisent des boîtes et des flèches. Mais une architecture fournit à toute cartographie individuelle son contexte : qui est responsable de ce processus, où il se situe par rapport aux processus qui l’entourent, ce qui l’alimente et ce qu’il produit, et comment savoir quand il doit évoluer. Une cartographie de processus ne vous apporte rien de tout cela. Elle montre simplement les étapes.

En quoi l’architecture des processus métier diffère d’une simple cartographie de processus métier

Une cartographie de processus offre une vue d’un seul processus. L’architecture des processus métier est le système organisateur de tous ces processus. La couche architecturale définit un contexte que les cartographies individuelles ne peuvent pas fournir par elles-mêmes — c’est précisément pourquoi les équipes qui investissent massivement dans la cartographie finissent avec des contradictions qu’elles ne peuvent pas résoudre.

Voici ce que je constate régulièrement en pratique : le Marketing crée une cartographie du processus de qualification des prospects. Les Ventes créent une cartographie du processus de passage de relais. Aucune des deux équipes ne se coordonne au niveau architectural, ce qui signifie que les noms des champs diffèrent, que le déclencheur du passage de relais est défini différemment dans chaque diagramme et que, lorsqu’une personne tente d’automatiser les deux, l’automatisation échoue parce qu’elle doit réconcilier deux cartographies conçues sans cadre partagé. Vous pouvez nettoyer les deux cartographies, mais le problème reviendra dès que quelqu’un mettra à jour l’une sans modifier l’autre.

L’architecture des processus dans la gestion des processus métier résout ce problème en établissant d’abord la structure de gouvernance. L’architecture définit les groupes de processus, tels que « Prospect à encaissement » ou « Intégration des nouveaux clients », positionne les processus de bout en bout au sein de ces groupes, puis les cartographies individuelles s’inscrivent dans cette structure. Désormais, lorsque le Marketing met à jour sa partie, un cadre clair détermine les éléments affectés en aval par cette modification.

Sans architecture, les cartographies de processus dérivent. Elles se contredisent entre les départements. La responsabilité devient floue. Et les efforts d’amélioration s’enlisent parce que personne ne parvient à s’accorder sur le périmètre — car rien n’a jamais été cadré au niveau architectural dès le départ.

La hiérarchie qui fait de l’architecture bien plus qu’un diagramme

L’architecture minimale viable des processus couvre deux niveaux : les groupes de processus, c’est-à-dire des ensembles de processus associés par domaine métier ou chaîne de valeur, et les processus de bout en bout au sein de ces groupes. En dessous se trouvent les sous-processus, les activités et, à terme, les instructions de travail — même si toutes les organisations n’ont pas besoin d’aller aussi loin.

Ce qui fait de cet ensemble une hiérarchie plutôt qu’une liste plate, c’est que chaque niveau hérite du contexte du niveau supérieur. Un processus de bout en bout de « retour de paiement » n’a de sens que si vous savez qu’il se situe dans le groupe de processus des services de paiement, lui-même intégré à un ensemble plus large d’opérations financières. L’étude de cas mBank sur l’amélioration des processus de paiement illustre exactement cela : les architectes de la banque ont d’abord cartographié l’architecture des services de paiement, puis utilisé cette structure pour identifier et repenser le processus spécifique de « retour de paiement ». L’architecture a rendu l’effort d’amélioration possible parce qu’elle a permis à l’équipe de situer le problème dans le paysage plus large des processus.

Cette vision en couches est ce qui distingue l’architecture de la documentation. La documentation enregistre ce qui existe. L’architecture vous donne une structure cohérente au sein de laquelle tout existe, afin que vous sachiez toujours où vous vous situez.

Là où l’architecture métier et l’architecture des processus métier se recoupent — et divergent

Ces deux disciplines sont souvent confondues, et cette confusion fait dérailler les discussions de cadrage aux pires moments.

L’architecture métier est la discipline plus large : elle couvre la stratégie, les capacités, les chaînes de valeur et la conception organisationnelle d’une entreprise. Elle répond à des questions telles que « de quelles capacités avons-nous besoin pour être compétitifs ? » et « comment nos chaînes de valeur produisent-elles des résultats pour les clients ? ». Les éléments de l’architecture métier — capacités, chaînes de valeur, flux d’information — opèrent à un niveau stratégique et organisationnel.

L’architecture des processus métier s’inscrit dans cet ensemble. Elle reprend les chaînes de valeur et les capacités définies par l’architecture métier et pose les questions suivantes : quels sont les processus concrets qui les assurent, comment sont-ils organisés, qui en est responsable et comment sont-ils améliorés ? Une pratique d’architecture métier oriente généralement le niveau supérieur de la hiérarchie des processus, en guidant la BPA vers les bons regroupements et les bonnes priorités.

En bref : l’architecture métier traite du pourquoi et du quoi à l’échelle stratégique. L’architecture des processus métier traite du comment à l’échelle des processus. Les deux sont nécessaires. Aucune ne remplace l’autre.

Ce que contient réellement une architecture des processus métier opérationnelle

La recherche de Gluu sur la BPA l’exprime clairement : une architecture des processus opérationnelle ne se limite pas à un schéma hiérarchique. C’est un plan directeur qui comprend des structures de gouvernance, des responsables de processus, des normes, des définitions d’interfaces entre les processus, des mesures de performance et des balises reliant les processus aux systèmes et aux données qu’ils utilisent. La hiérarchie est le squelette. Tout le reste constitue le corps.

La plupart des équipes construisent le squelette puis s’arrêtent là. Le diagramme hiérarchique est produit, ajouté dans Confluence, et tout le monde a l’impression que le travail est terminé. Puis, six mois plus tard, quelqu’un demande qui est responsable du processus de qualification des prospects, et la réponse se situe quelque part entre un haussement d’épaules et trois fils Slack concurrents. L’architecture existe visuellement. Elle échoue sur le plan opérationnel.

Les balises relatives aux systèmes et aux données comptent davantage que ce que les gens imaginent. Lorsqu’un processus est associé aux systèmes qu’il touche, vous savez immédiatement quelles automatisations et quels outils entrent dans le périmètre lors d’une modification du processus. Sans ces balises, chaque projet d’automatisation commence par une phase de découverte où quelqu’un demande : « Attendez, ce processus touche-t-il Salesforce ou HubSpot ? » et la réponse est : « Nous pensons les deux, peut-être. »

Les mesures de performance constituent l’autre élément habituellement oublié. Une architecture sans métriques est une aspiration. Une architecture avec des métriques est un modèle opérationnel : vous pouvez réellement voir lorsqu’un processus se dégrade et réagir.

🤔 Réfléchissez à ceci :
La plupart des équipes investissent beaucoup de temps dans la cartographie des processus et presque aucun dans la responsabilité des processus. Le diagramme hiérarchique est construit. Personne n’est désigné pour en assurer la maintenance. Aucune métrique n’est définie. Ainsi, lorsqu’un processus se rompt, personne n’est responsable de le corriger et aucune mesure ne permet de confirmer qu’il est corrigé. L’architecture existe comme document. Elle ne devient jamais une discipline.

Gouvernance, responsables de processus et les éléments que la plupart des équipes ignorent

La recherche du BPMInstitute sur la BPA est explicite à ce sujet : une architecture efficace des processus exige une gouvernance, des responsables de processus, une gestion du changement et des mesures. Retirez l’un de ces éléments et l’architecture se dégrade en artefact statique.

La gouvernance signifie qu’il existe une structure de décision définie pour les changements de processus. Qui peut modifier un processus ? Qu’est-ce qui déclenche une révision ? Qui résout les conflits lorsque les processus de deux départements se contredisent ? Sans gouvernance, chaque équipe optimise sa propre partie et les points d’intégration entre les équipes deviennent un no man’s land.

Les responsables de processus sont les personnes précisément redevables de la performance des processus. Pas l’équipe. Pas le département. Une personne nommée. C’est l’élément que je vois le plus systématiquement négligé en pratique. Un processus sans responsable est un processus que personne ne met à jour lorsque la réalité change et que personne ne corrige lorsqu’un problème survient sur son parcours.

La gestion du changement et les métriques rendent l’architecture vivante plutôt qu’archivée. La performance des processus se dégrade au fil du temps. Les conditions de marché évoluent. Les systèmes sont remplacés. L’architecture doit inclure un cycle défini de révision et de mise à jour des processus — ainsi que les métriques qui vous indiquent lorsqu’une révision est due.

C’est là qu’interviennent la gouvernance, les responsables, la gestion du changement et la mesure. Ignorez-les et vous n’avez qu’un diagramme coûteux.

Cadres d’architecture et conception des architectures de processus

Deux cadres reviennent le plus souvent lorsque les équipes commencent à concevoir des architectures de processus, et ils répondent à des problèmes différents.

Le premier fournit une taxonomie de référence : une façon de vérifier que vous avez couvert l’ensemble du paysage des processus et un repère pour comparer votre structure à celle d’autres organisations. Le second fournit une méthodologie de conception : une façon de prendre des décisions structurelles sur l’organisation de votre architecture lorsque vous partez de zéro. En général, vous avez besoin des deux. L’un vous indique ce qui doit faire partie de l’architecture. L’autre vous indique comment l’organiser.

Les praticiens BPM identifient régulièrement les compétences de modélisation des processus et de conception d’architecture comme des compétences fondamentales pour 2026, précisément parce que concevoir une architecture de processus n’est pas une activité ponctuelle. Cela nécessite une réflexion méthodologique continue à mesure que l’organisation évolue. BPMN reste la notation standard pour modéliser les processus au sein de l’architecture, mais les cadres ci-dessous se situent au-dessus de cette couche : ils traitent de structure et de classification avant même que vous ne dessiniez un flux.

Le Process Classification Framework d’APQC comme taxonomie de départ

Le Process Classification Framework (PCF) d’APQC est une taxonomie intersectorielle qui organise les processus métier en 12 catégories à l’échelle de l’entreprise, de « Développer la vision et la stratégie » aux processus opérationnels, jusqu’à « Gérer les ressources financières ». Les organisations l’utilisent comme point de référence initial lorsqu’elles construisent ou valident leur propre architecture de processus, en faisant correspondre leurs processus existants aux catégories du PCF afin d’identifier les lacunes, les redondances ou les incohérences de dénomination.

La valeur du PCF réside dans la comparaison. Parce qu’il est intersectoriel et indépendant des fournisseurs, il offre aux processus de votre organisation un cadre de référence commun : vous pouvez ainsi comparer la structure et la performance de vos processus à celles d’autres entreprises de votre secteur qui utilisent la même classification. Il évite également l’erreur taxonomique la plus courante, qui consiste à organiser les processus autour de votre organigramme actuel plutôt qu’autour des activités métier réelles. Les organigrammes changent. Les processus clés exécutés par une entreprise évoluent beaucoup plus lentement.

Considérez le PCF d’APQC comme une carte de départ, et non comme une destination. Votre architecture s’en écartera selon les activités réelles de votre organisation. C’est normal. Le cadre est un contrôle de cohérence, pas une camisole de force.

Concevoir des architectures de processus selon le type de dossier et la fonction métier

Le modèle de conception bidimensionnel de Dijkman, documenté dans une recherche sur la conception d’architectures de processus métier, donne aux équipes un moyen concret de prendre des décisions structurelles : organiser les processus selon deux axes — le type de dossier, c’est-à-dire le type d’entité ou de demande traité, et la fonction métier, c’est-à-dire la capacité organisationnelle qui exécute le travail.

En pratique, cela signifie poser deux questions pour tout processus : qu’est-ce qui est traité — une commande client, un ticket de support, une demande d’intégration d’employé, un retour de paiement — et quelle fonction traite cet élément — Finance, Opérations, Réussite client. Là où ces dimensions se croisent, vous trouvez le processus. La chaîne de valeur devient alors un élément lisible sous forme de matrice plutôt que comme une simple séquence linéaire.

Cela importe pour la conception, car de nombreuses organisations sur-organisent soit autour de la fonction métier, ce qui aboutit à des architectures qui reflètent l’organigramme et deviennent impossibles à maintenir lorsque l’organisation change, soit insuffisamment autour du type de dossier, ce qui aboutit à des architectures dans lesquelles le même dossier traverse des processus multifonctionnels dont personne ne peut clairement être responsable. Le modèle de Dijkman maintient les deux dimensions visibles, ce qui rend l’architecture obtenue plus facile à maintenir et à utiliser comme base pour les projets d’automatisation et d’amélioration.

Niveaux d’architecture des processus métier : jusqu’où la hiérarchie doit-elle aller ?

La définition d’Eficio établit le minimum de deux niveaux — groupes de processus et processus de bout en bout — mais la hiérarchie peut s’étendre davantage dans les deux directions. Comprendre cette plage permet d’éviter les deux modes d’échec que je rencontre le plus souvent : des architectures si générales qu’elles sont inutiles pour les décisions opérationnelles, et des architectures si granulaires qu’elles deviennent impossibles à maintenir.

Voici une cartographie pratique des niveaux :

Les niveaux 1 et 2 constituent l’architecture au sens strict. Les niveaux 3 et 4 sont des modèles de processus. Le niveau 5 correspond à la documentation. L’architecture couvre ce qui doit exister au niveau organisationnel. Plus vous descendez, plus vous produisez du contenu de procédures opérationnelles, et non de l’architecture.

La plupart des équipes de moins de 200 personnes doivent maintenir rigoureusement les niveaux 1 à 3 et rendre les niveaux 4 à 5 disponibles sous forme de documentation pour les processus à haut risque ou à fort volume. Aller jusqu’au niveau 5 pour chaque processus dans une entreprise de taille moyenne est une bataille perdue d’avance. La charge de maintenance dépasse la valeur obtenue. Choisissez délibérément votre niveau de détail.

La question BPM qui bloque le plus souvent les discussions est généralement : « À quel niveau de granularité nos activités de processus doivent-elles être définies au niveau architectural ? » La réponse honnête est : assez précisément pour clarifier la responsabilité et cadrer AutomationProjectX, mais pas au point de créer du matériel de formation pas à pas. Ce sont des documents différents destinés à des publics différents.

Là où l’architecture d’entreprise se connecte aux niveaux de processus

L’architecture d’entreprise (EA) est le système organisationnel plus large auquel l’architecture des processus métier se rattache. L’EA couvre la technologie, les données, les applications et la stratégie : elle relie la stratégie à l’exécution à l’échelle de toute l’organisation. La BPA est une couche au sein de l’EA, centrée spécifiquement sur la dimension des processus.

En pratique, cela signifie que le niveau supérieur de votre hiérarchie de processus, c’est-à-dire les groupes de processus, doit s’aligner sur les capacités et les chaînes de valeur définies par l’architecture d’entreprise. L’EA vous indique quelles capacités l’organisation doit posséder. Votre architecture de processus organise les processus qui fournissent ces capacités. Sans cet alignement, l’architecture de processus peut dériver des priorités stratégiques : vous obtenez une image bien organisée de ce que fait l’organisation, plutôt que de ce qu’elle doit faire.

La structure organisationnelle est également pertinente ici : vos groupes de processus doivent être définis indépendamment de la structure organisationnelle actuelle, mais ils doivent être compréhensibles pour l’équipe dirigeante responsable de cette structure. Une architecture qui n’a de sens que pour les architectes ne gouverne rien.

Trois idées reçues qui bloquent les projets d’architecture de processus

Chaque projet d’architecture de processus bloqué que j’ai observé implique au moins une de ces idées reçues. Généralement deux.

• La BPA n’est qu’un diagramme de workflow

C’est l’idée reçue qui pousse les équipes à déclarer « nous avons déjà cela » lorsqu’une personne évoque le besoin d’une architecture de processus. Un diagramme de workflow cartographie un processus. L’architecture des processus métier les organise tous, à plusieurs niveaux, avec une gouvernance, des responsables de processus, des métriques et une gestion du changement. La conséquence critique : les équipes qui considèrent leur collection de diagrammes comme une architecture ignorent entièrement les couches de responsabilité et de mesure. Dès qu’un processus change, aucun mécanisme ne permet donc de mettre à jour l’architecture. En 12 mois, les diagrammes sont obsolètes et plus personne ne leur fait confiance. La cohérence s’effondre, une exception non documentée après l’autre.

• La BPA n’est utile que pour les grandes entreprises

Les petites organisations ont besoin d’une architecture proportionnée, pas d’une absence totale d’architecture. Cette idée reçue conduit les équipes de taille moyenne à ignorer complètement la structure, puis à se demander pourquoi leur projet d’amélioration des processus a produit des gains locaux tout en générant des reprises ailleurs. Une entreprise SaaS de 60 personnes, avec cinq départements et 12 intégrations produit, présente suffisamment de complexité de processus pour que les passages de relais non documentés génèrent constamment des erreurs. L’architecture n’a pas besoin d’être un cadre de 300 pages. Elle doit être suffisamment cohérente pour que quelqu’un puisse répondre à ces questions : qui est responsable de ce processus, et comment savons-nous qu’il fonctionne correctement ?

• La BPA peut être créée une fois puis laissée inchangée

L’architecture des processus n’est pas un document que vous classez. C’est une discipline opérationnelle qui évolue avec votre organisation. Les équipes qui la traitent comme un artefact ponctuel constatent qu’elle cesse de refléter la réalité en quelques mois : la stratégie évolue, les systèmes changent, les équipes sont réorganisées. Lorsque l’architecture diverge des opérations réelles, les collaborateurs cessent de la consulter et l’amélioration continue devient impossible parce que personne ne dispose d’une vision exacte de l’existant. Un projet d’amélioration des processus fondé sur une architecture obsolète vise la mauvaise cible.

📊 En pratique :
Selon BPMInstitute, une architecture des processus efficace exige une gouvernance, une gestion du changement et une mesure — pas seulement un schéma hiérarchique. Les organisations qui construisent la hiérarchie sans ces éléments de soutien abandonnent généralement l’architecture dans les 18 mois. L’artefact visuel survit. La discipline opérationnelle ne se forme jamais. L’exécution des processus continue de dériver du modèle documenté jusqu’à ce que l’écart soit trop important pour être comblé sans repartir de zéro.

Quand appliquer l’architecture des processus métier — et quand elle est excessive

L’architecture des processus métier n’est pas la bonne réponse à toutes les situations. Une startup de 12 personnes avec un produit et quatre processus n’a pas besoin d’une architecture formelle. Elle a besoin de responsabilités claires et d’une bonne documentation. Voici comment faire la différence.

Vous avez probablement besoin d’une architecture formelle lorsque votre organisation dépasse 50 à 75 personnes et que les passages de relais entre départements génèrent des erreurs ou des retards ; lorsque vous lancez une initiative de transformation numérique qui touchera plusieurs systèmes et plusieurs équipes ; lorsque vous avez des exigences de conformité ou d’audit nécessitant une responsabilité de processus traçable et un historique documenté des changements ; ou lorsque vous avez mené au moins deux projets d’amélioration des processus ayant résolu un problème local tout en en créant un nouveau ailleurs.

Le signal le plus fiable, d’après ce que je constate dans le support et les échanges communautaires : des projets d’automatisation qui échouent régulièrement aux points d’intégration entre les départements. C’est presque toujours le symptôme d’un problème d’architecture. Lorsque l’automatisation Marketing fonctionne, que l’automatisation des Ventes fonctionne, mais que le passage de relais entre les deux ne fonctionne pas, le problème ne vient pas de chacune des automatisations. Il vient de l’absence d’un modèle de processus partagé sur lequel elles auraient toutes deux été construites.

C’est excessif dans les cas suivants : une amélioration de processus au sein d’un seul département, un projet d’automatisation d’une petite équipe avec un responsable clair, ou toute situation où le périmètre est suffisamment limité pour qu’une personne puisse conserver l’ensemble de la vision en tête. Une architecture formelle implique une véritable charge de maintenance. Ne l’appliquez pas là où une cartographie de processus bien maintenue avec une responsabilité claire permet d’obtenir le même résultat.

Sur la question de l’automatisation plus précisément : construire une architecture de processus avant d’automatiser des workflows interfonctionnels constitue l’un des usages les plus clairement stratégiques de cette pratique. Lorsque les parties prenantes se sont alignées sur l’architecture, l’automatisation peut être conçue sur un modèle de processus stable plutôt que sur l’état ad hoc actuel. Une responsable des opérations d’une entreprise de taille moyenne avec laquelle je travaillais récemment l’a formulé simplement : dès qu’elle a esquissé l’architecture d’intégration — uniquement les niveaux 1 et 2, avec des groupes de processus clairs et des responsables clairement définis — les objectifs métier de l’effort d’automatisation sont devenus évidents. Elle pouvait voir exactement quelles étapes se prêtaient à l’automatisation et lesquelles nécessitaient un jugement humain. Avant l’architecture, elle procédait à l’aveugle. Elle a utilisé Latenode pour connecter son CRM, son système de facturation et son outil de ticketing dans une vue en temps réel de la position des clients dans le processus, avec une étape d’enrichissement par IA classant les signaux de risque provenant des tickets de support. La tarification par exécution signifiait que son workflow à plusieurs étapes était comptabilisé comme une seule exécution plutôt que comme six tâches distinctes. Mais la technologie n’était utile qu’à la hauteur du modèle de processus qui la sous-tendait.

Étapes de processus signalant une lacune architecturale

Ces schémas apparaissent dans la file de travail bien avant que quelqu’un admette que l’architecture fait défaut :

Les mêmes données existent dans deux systèmes avec des valeurs différentes. Personne ne sait avec certitude lequel fait autorité. C’est un problème d’architecture déguisé en problème de qualité des données.

Un projet d’automatisation échoue lors du passage de relais entre deux départements. Le BPM fonctionne correctement de chaque côté. L’interdépendance entre eux n’a jamais été définie dans un modèle partagé.

Les métriques de deux équipes se contredisent à propos du même processus. Les deux chiffres sont techniquement corrects selon la définition de chaque équipe. L’architecture n’a jamais existé pour établir une définition unique.

Un nouveau membre de l’équipe demande quel document de processus est à jour. La réponse implique plus de deux fichiers et la phrase « Je pense que ».

Tout goulot d’étranglement identifié dans plusieurs initiatives d’amélioration distinctes, mais jamais réellement résolu. Cela signifie qu’il se trouve à une frontière entre des zones de responsabilité de processus, là où se trouvent les lacunes architecturales.

Le résultat d’une étape de processus ne correspond pas à ce que l’étape suivante attend comme entrée. Une personne effectue une réconciliation manuelle dans une feuille de calcul pour aligner des processus et des données qui devraient déjà être alignés. C’est une lacune architecturale à plein temps déguisée.