Capacités métier et chaînes de valeur

4.1 Objectif et décisions soutenues

Un modèle de capacités décrit ce que l’institution doit être capable de faire. Un flux de valeur explique comment ces aptitudes se combinent pour produire un résultat utile à un acteur. Ensemble, ils relient finalité et résultats de la section 03 aux responsabilités et aux investissements. Ils ne prescrivent ni application, ni organigramme, ni pile technologique.

Cette section aide à décider face aux aptitudes manquantes, responsabilités dupliquées, transferts fragiles et priorités d’amélioration. La première question n’est pas quelle plateforme acheter, mais si l’institution peut accomplir le travail de son mandat, y compris exceptions, correction et continuité.

Le chapitre propose une méthode et un exemple fictif. Aucune institution réelle n’a adopté ces cartes, accepté les responsabilités ou réussi les contrôles décrits. L’usage institutionnel exige une revue ; la publication reste un brouillon éditorial.

4.2 Distinguer les notions avant de dessiner

Ces notions répondent à des questions différentes. Les confondre produit des schémas séduisants mais peu utiles à la décision. Un département exerce plusieurs capacités, une capacité soutient plusieurs services et une application réalise des parties de capacités différentes.

La distinction entre aptitudes institutionnelles et progression de valeur figure également dans des publications d’architecture métier de l’OMG et de TM Forum. ZAF emploie ses propres exemples et identifiants délimités, sans revendiquer certification ni conformité à ces cadres.

Une capacité appelée « PostgreSQL » ou « Département finance » ne respecte pas cette distinction. PostgreSQL est une technologie ; la finance est une unité organisationnelle. « Autorisation financière » décrit une aptitude qui reste pertinente après changement de technologie ou d’organisation.

4.3 Définir le périmètre et les entrées

Partir du mandat de la section 01, des registres de contexte et de préoccupations de la section 02, puis des résultats et contrats de mesure de la section 03. Enregistrer les versions utilisées. Un résultat encore proposé et non approuvé ouvre une discussion ; il n’autorise pas à engager l’institution.

L’institution fictive comprend un siège, six bureaux régionaux et une petite équipe technique. L’évaluation reste limitée à un type de demande et un bureau pilote candidat. Dépôt, revue départementale, approbation financière, exécution et rapprochement constituent le parcours supposé à examiner. Aucun délai, volume ou niveau de maturité initial n’a été mesuré.

Préciser déclencheur, bénéficiaire, états finaux, acteurs, demandes exclues et dépendances externes avant de décomposer. La carte doit exposer les transferts importants du service retenu sans présenter le périmètre pilote comme une cartographie complète de l’entreprise.

Tous les identifiants CAP, VS, STG, H et DEC ci-dessous appartiennent à ZAF-I-04. Les renvois aux résultats conservent leur préfixe, par exemple ZAF-I-03-OUT-01. Réutiliser un numéro ailleurs ne désigne pas le même enregistrement.

4.4 Construire et nommer les capacités

Employer des noms métier stables exprimant une aptitude : réception des demandes, maîtrise des décisions, coordination d’exécution. Définir finalité, périmètre et aptitude observable plutôt qu’une liste d’écrans ou de postes.

Commencer assez largement pour comparer les responsabilités, puis décomposer uniquement lorsque propriété, exigences ou investissement l’exigent. Une capacité parente regroupe des aptitudes liées ; ses enfants sont des aptitudes plus précises, pas des phases arbitraires ou une liste de produits achetés.

Pour « Gestion des demandes opérationnelles », les enfants pourraient comprendre réception, maîtrise des décisions et coordination d’exécution. Un autre rapport décrivant la même aptitude ne constitue pas automatiquement une nouvelle capacité. Un glossaire commun doit résoudre synonymes, recouvrements et différences réelles de sens.

La carte proposée regroupe six aptitudes de service et deux aptitudes de soutien. Ces groupes ne définissent ni départements, ni frontières de déploiement, ni microservices.

Une capacité peut être réalisée manuellement, par un partenaire, par logiciel ou par combinaison. Enregistrer cette réalisation séparément. La définition doit rester valable lors du passage d’un tableur à une application sans prendre le nom du nouvel outil.

4.5 Tenir un registre et expliciter les responsabilités

Le responsable d’une capacité répond de l’aptitude, de sa performance attendue et des décisions d’amélioration. Les participants exécutent ; les propriétaires des données gouvernent sens et usage ; les responsables techniques exploitent les systèmes. Ces fonctions sont liées mais non interchangeables.

Ces rôles sont proposés, pas attribués. CAP-02 ne permet pas au département de passer outre la finance. Distinguer responsabilité de coordination et autorités séparées dont les décisions restent nécessaires.

En cas de désaccord, consigner la lacune et le responsable de son escalade. Ne pas attribuer automatiquement toutes les aptitudes métier non résolues à l’informatique. La section 05 développera le modèle opérationnel et la section 06 approfondira les domaines et responsabilités.

4.6 Décrire le flux comme une progression de valeur

ZAF-I-04-VS-01 est « Obtenir un résultat responsable pour une demande opérationnelle ». Le bénéficiaire est le demandeur du service retenu. Le déclencheur est l’intention de déposer ; les fins possibles comprennent exécution, refus ou retrait avec un état faisant autorité. L’exécution n’est donc qu’une issue légitime parmi d’autres.

Définir chaque étape par la valeur établie à sa sortie. « Envoyer un email » est une action ; « Demande reçue et reconnue » est une condition utile sur laquelle le demandeur et l’acteur suivant peuvent s’appuyer.

C’est une progression de valeur pour l’acteur, pas un workflow exécutable détaillé. Un refus peut terminer en STG-02 avec ses obligations de reporting sans passer artificiellement par l’exécution. Reporting et communication du statut interviennent tout au long du parcours.

4.7 Relier capacités, étapes et résultats

Une capacité soutient éventuellement plusieurs étapes. Chaque étape mobilise généralement plusieurs capacités, personnes, informations et pratiques. Une relation indique une contribution à examiner ; elle ne démontre pas l’efficacité de l’aptitude.

Tous les OUT abrégés renvoient à ZAF-I-03. Les relations sont proposées. Elles révèlent les lacunes : si aucune aptitude n’établit la réception, une interface soignée ne prouve pas l’acceptation institutionnelle.

Maintenir ces liens dans un registre autant que dans un diagramme. Chaque relation importante précise justification, preuves et observation susceptible de contredire la contribution supposée. Ne pas relier toutes les capacités à toutes les étapes pour donner une impression de complétude.

4.8 Définir le contrat de transfert

Une carte de capacités ne suffit pas à expliquer le passage de responsabilité. Pour chaque frontière importante, préciser rôle récepteur, sens des informations, condition d’acceptation et traitement des exceptions. Un email livré ne prouve pas la prise en charge du travail.

Pour chaque transfert, indiquer qui reconnaît l’acceptation, ce qui arrive sans reconnaissance et comment résoudre un état contesté. L’institution fixe attentes de réponse et escalade après revue probatoire ; ce brouillon n’invente aucun délai ni engagement.

Ces contrats expriment le sens métier. Le Livre II déterminera ensuite les mécanismes d’intégration et de cohérence. Chaque transfert n’exige pas automatiquement API, bus d’événements ou transaction distribuée.

4.9 Traiter exceptions et assistance

Le parcours nominal est insuffisant. Examiner correction avant approbation, modification après approbation, refus, retrait, exécution incomplète, double dépôt et perte de connectivité. Vérifier préservation de l’autorité et compréhension de l’état.

Un brouillon local reprend après interruption sans devenir une demande reçue. En cas de passage à une voie assistée, définir comment reconnaître la même demande et éviter des enregistrements contradictoires. Ne pas compter sur un tableur parallèle informel pour résoudre l’ambiguïté.

Après approbation, la correction peut nécessiter nouvelle version et décision. Conserver l’enregistrement approuvé original. La validité éventuelle de l’ancienne autorisation pour une partie du travail relève du service et des règles, pas d’une supposition du développeur.

Pour refus ou contestation, consigner voie suivante autorisée et limite de divulgation. Aucune prétention à un droit juridique universel n’est formulée. Le responsable des règles confirme l’applicabilité au type de demande. Relier les parcours non résolus aux préoccupations au lieu de les dissimuler dans une légende.

4.10 Évaluer les aptitudes par des preuves

Distinguer importance, aptitude démontrée, fragilité d’exploitation et confiance dans les preuves. Une capacité critique peut être peu documentée ; une capacité bien documentée peut produire de mauvais résultats. Fusionner ces dimensions dans une couleur unique peut masquer la décision.

Dans l’exemple, CAP-04 a des définitions de reporting non vérifiées. Cela justifie « définition non résolue », pas un niveau de maturité inventé. CAP-07 reste « non démontrée » avant l’exercice ; une capture de configuration de sauvegarde n’est pas un résultat de reprise.

Si une notation est adoptée ensuite, documenter échelle, évaluateurs, preuves et traitement des inconnues. Ne pas transformer une absence de preuve en score assuré ni laisser croire qu’un modèle coloré constitue une évaluation réalisée.

4.11 Comparer les améliorations et leurs dépendances

Utiliser les relations pour rechercher le plus petit changement susceptible de soutenir un résultat. Comparer clarification des processus, effectifs ou formation, accords d’information et évolution technique. L’achat d’une plateforme n’est qu’une option.

Il s’agit d’alternatives ou de changements dépendants, pas d’un backlog approuvé. L’approbation versionnée exige une règle d’autorité convenue. Le tableau de bord exige une définition de reporting. Prendre ces décisions avant de les figer dans des outils.

Enregistrer les décisions proposées ZAF-I-04-DEC-01 à DEC-04 pour ces quatre lignes. Chacune exige responsable, alternatives, justification, preuves manquantes et condition de réexamen. Leur présence illustrative ne signifie pas approbation institutionnelle.

4.12 Passer à l’ingénierie sans confondre les modèles

Une capacité métier n’est pas automatiquement un contexte délimité, microservice, dépôt ou équipe. Un composant soutient parfois plusieurs capacités ; une capacité mobilise plusieurs systèmes et du travail manuel. La décomposition exige analyse du sens, de l’autorité, de la cohérence et de l’évolution.

CAP-02 et CAP-03 pourraient être réalisées dans une même application ou des services distincts. Ce chapitre ne tranche pas. Examiner invariants, versionnement des décisions, défaillances tolérables et capacité d’exploitation avant de dessiner les déploiements.

Une communication du statut partagée ne justifie pas automatiquement une plateforme d’entreprise. Comparer besoins répétés, différences sémantiques, gouvernance et coûts. Standardiser les contrats communs utiles tout en préservant les différences de domaines qui portent une autorité ou un sens légitime.

Le transfert au Livre II comprend définitions, responsabilités ouvertes, contrats d’information, contributions aux étapes et scénarios. Infrastructure et adoption de Kubernetes demeurent des choix ultérieurs conditionnés par les exigences.

4.13 Valider avec les acteurs et maîtriser les changements

Faire parcourir un cas ordinaire et plusieurs exceptions importantes aux représentants des demandeurs, du service, des décisions, des informations et des opérations. Chacun explique l’état reçu et la responsabilité acceptée. Tenir une réunion ne suffit pas à valider un modèle.

Consigner interprétations contradictoires, capacités manquantes et transitions non justifiées. Ne pas résoudre les désaccords par l’esthétique du diagramme. Le sponsor accepte le modèle délimité après revue des responsabilités et traitement explicite des questions importantes encore ouvertes.

Versionner registre et carte avec leurs dépendances. Une modification de règles, un nouveau type de demande, une réaffectation organisationnelle ou une définition de reporting changée peut invalider un lien sans modification logicielle.

Conserver l’identifiant si un changement de nom ne change pas le sens. Lors d’une division ou fusion, maintenir les références précédentes et expliquer la migration des responsabilités et preuves. Ne pas réutiliser un identifiant retiré pour une autre capacité.

4.14 Livrables et critères de revue

Ces sept livrables sont des modèles proposés aux institutions, pas des documents clients réalisés. Lors de l’usage, consigner auteurs réels, responsables, versions, sources, limites et décisions.

Séparer validation institutionnelle du modèle et acceptation d’une conception technique. Une carte convenue n’autorise ni accès à la production, ni achat, ni déploiement. L’acceptation éditoriale de la section est également distincte : elle reste un brouillon.

4.15 Vérification et section suivante

• Distinguer capacités, résultats, processus, services, rôles et applications.
• Délimiter le service sans prétendre couvrir toute l’entreprise.
• Définir chaque capacité par une aptitude stable, pas un produit.
• Séparer responsabilité, participation et soutien technique.
• Donner aux étapes une sortie observable et des fins alternatives légitimes.
• Relier les contributions importantes aux résultats de la section 03.
• Définir acceptation de l’information et de l’autorité aux transferts.
• Exercer interruption, correction, refus et double dépôt.
• Conserver inconnues et confiance probatoire dans l’évaluation.
• Prendre les décisions de sens et de responsabilité avant leur réalisation technique.
• Valider avec les participants réels et conserver les désaccords.
• Maintenir traçabilité des identifiants, versions sources et révisions.

La section 05, Modèle opérationnel institutionnel, expliquera comment organiser et soutenir ces responsabilités : droits de décision, propriété du service, réalisation, exploitation, escalade et capacité. Elle utilisera capacités et transferts au lieu de déduire les responsabilités d’une topologie technique.

Références de lecture

• OMG · Business Architecture Overview
• TM Forum · Value Stream Framework