Ce qu’il y a derrière
Derrière chaque nœud, il y a plus qu’une case
Chaque unité d’organisation du modèle TAOM peut être décrite sur le plan métier et enrichie de son contexte opérationnel. Outre la structure et l’affectation, les tâches, responsabilités, exigences de qualité, systèmes, livrables et contrôles sont tenus directement sur l’objet d’organisation.
Un organigramme devient ainsi un modèle d’organisation vivant : on voit non seulement qui se situe où, mais aussi ce qu’une unité produit, ce dont elle répond et quelles exigences s’appliquent à son travail.
Deux vues distinctes, car ce sont deux questions différentes : Que fait l’unité ? et à quelles conditions le résultat est-il acceptable ?
Un exemple tiré du modèle ci-dessus
Vue d’ensemble
Objectif
Créer et maintenir les conditions techniques d’exploitation.
Systèmes
SAP Fiori
Transactions
IW21 CAT2
Sortie
Rapport technique · configuration système
À quelles conditions le résultat compte
Risques
données de base incomplètes · informations contradictoires · prescriptions techniques obsolètes
Contrôles
Exhaustivité · plausibilité · version et statut
Preuves
Certificats de contrôle · CoA · validations techniques
Validation
Uniquement une fois les défauts qualité réglés et les preuves complètes.
Ce à quoi l’unité est rattachée
Personnes Rôles RACI
Processus Systèmes Exigences
Décisions Savoir Tests
Si l’un de ces liens change, l’effet se produit là où l’on travaille – pas seulement sur l’image.
Même modèle, autre organisation
Parce qu’une unité d’organisation est un objet du jumeau numérique et non un dessin, la même structure vaut aussi en dehors d’un projet :
Program Management → PMO → Streams → Teams
Direction → Operations → Supply Chain → Production → Qualité
Global Process Owner → Process Owner → Process Expert → Key User
Humains · partenaires externes · effectif IA – dans la même chaîne, avec un humain au bout.