Dans un programme ISO 22400, aucune fonction ne devrait détenir unilatéralement la responsabilité des définitions des KPI. L’approche la plus efficace consiste à mettre en place un groupe de gouvernance formel et transverse, responsable de la définition, de l’approbation et de la modification des définitions des KPI, avec des rôles clairement attribués au sein de ce groupe.
Modèle de responsabilité recommandé
Pour les environnements réglementés et brownfield, une répartition pratique des responsabilités est la suivante :
En pratique, cela se rattache à la gouvernance des KPI ISO 22400 lorsque les équipes doivent transformer la réponse en habitudes d’exécution reproductibles.
- Sponsor exécutif (direction des opérations ou du site) : détient la responsabilité du cadre global des KPI, des priorités et de la résolution des conflits. Il veille à ce que les KPI soutiennent la stratégie, et pas seulement la disponibilité des données.
- Responsables de processus (opérations / méthodes industrielles / maintenance) : détiennent la responsabilité de la signification opérationnelle de chaque KPI (par exemple, ce qui est comptabilisé comme temps de production planifié, ce qui constitue un temps d’arrêt valide, comment traiter les changements de série ou les inspections). Ils favorisent l’utilisabilité et évitent les définitions théoriquement correctes mais inutilisables sur le plan opérationnel.
- Qualité / QMS : détient la responsabilité de la traçabilité, de la documentation et de la maîtrise des modifications des définitions des KPI. La fonction qualité veille à ce que les définitions, les formules et les sources de données soient gérées en versions, revues et alignées avec les procédures qualité et les attentes d’audit.
- Responsables des données IT / OT / MES : détiennent la responsabilité de la mise en œuvre technique des définitions des KPI dans le MES, les historiens, les data lakes et les outils de reporting. Ils sont responsables de la lignée des données, du mapping avec les structures ISO 22400 et de la cohérence du calcul des KPI entre les différents systèmes.
- Finance / contrôle de gestion (le cas échéant) : valide que les KPI de coût, d’efficacité et d’utilisation sont alignés avec le reporting financier et ne créent pas de « vérités » contradictoires entre les tableaux de bord du site et ceux du siège.
Pourquoi la responsabilité partagée est essentielle pour ISO 22400
ISO 22400 fournit une terminologie normalisée et des structures de formules standardisées, mais chaque site doit encore décider :
- Comment classer et segmenter le temps (p. ex., arrêts planifiés vs non planifiés, changements de série, fenêtres de maintenance).
- Quels équipements et flux de valeur entrent dans le périmètre de chaque KPI.
- Comment traiter les cas limites (reprise, cycles d’essai, essais d’ingénierie, blocages qualité).
- Comment aligner les définitions des KPI entre les outils MES, ERP, SCADA et de reporting.
Si la responsabilité des KPI relève uniquement de l’IT, vous risquez d’obtenir des indicateurs techniquement cohérents mais dénués de sens opérationnel. Si elle relève uniquement des opérations, vous risquez des optimisations locales, une documentation insuffisante et des divergences entre sites. Si elle relève uniquement de la qualité, vous pouvez obtenir de bonnes procédures mais une faible adoption. Un modèle partagé, avec des responsabilités de gouvernance explicites, permet d’équilibrer ces risques.
Attentes en matière de gouvernance et de maîtrise des changements
Dans les environnements réglementés et à cycle de vie long, la responsabilité des définitions de KPI doit inclure une gouvernance structurée, et non un simple comité informel. Au minimum :
- Catalogue de KPI faisant autorité : une liste unique et maîtrisée des KPI ISO 22400, incluant le nom, la formule, les données d’entrée, les exclusions, le niveau de calcul (machine, ligne, site) et le système de référence.
- Flux de travail d’approbation formel : les nouveaux KPI proposés ou les modifications de définition sont examinés et approuvés par le groupe de gouvernance (opérations, qualité, IT/OT et finance selon les besoins), avec une justification et un impact documentés.
- Gestion des versions et traçabilité : chaque définition de KPI dispose d’un historique des versions indiquant clairement quand et pourquoi une modification a été effectuée, quels systèmes ont été impactés et quelles périodes ne sont pas comparables en raison d’un changement de définition.
- Évaluation d’impact et validation : avant la mise en production des changements, les responsables de données et les responsables de processus valident que la mise en œuvre correspond à la définition approuvée, et que les rapports, tableaux de bord et alertes se comportent comme prévu.
- Communication et formation : les changements apportés aux définitions de KPI sont communiqués aux superviseurs, ingénieurs et analystes afin que les tendances de performance soient interprétées correctement.
Coexistence avec les systèmes existants dans les usines brownfield
Dans les environnements brownfield, la responsabilité de la définition des KPI est contrainte par les MES/SCADA, les systèmes d’historisation, les ERP et les outils de reporting existants, dont beaucoup intègrent leurs propres calculs de KPI. Une approche réaliste de la responsabilité reconnaît que :
- Vous ne pouvez souvent pas remplacer toute la logique KPI existante dans les systèmes legacy sans validation majeure, arrêt de production et requalification. À la place, vous définissez généralement un système de référence pour chaque KPI et documentez la manière dont les autres systèmes l’approximent ou le consomment.
- Différentes lignes, usines ou fournisseurs peuvent aujourd’hui utiliser des formules de KPI légèrement différentes. La responsabilité inclut de décider s’il faut harmoniser, et le cas échéant, sur quel horizon temporel et avec quelle charge de revalidation.
- Les efforts d’intégration et de mapping des données doivent être conjointement portés par l’IT/OT et les propriétaires de processus afin que les champs ISO 22400 soient alimentés correctement et de manière cohérente entre les interfaces.
- Le reporting externe (vers les clients, les autorités réglementaires ou le groupe) peut déjà s’appuyer sur des définitions spécifiques. Les modifier peut avoir des implications d’audit et contractuelles nécessitant une revue qualité et juridique.
Comme le remplacement complet de la logique KPI legacy peut être risqué et coûteux dans des contextes réglementés, le groupe de gouvernance priorise souvent :
- La définition et la documentation en premier lieu de KPI canoniques alignés sur ISO 22400.
- Le mapping des sorties des systèmes actuels vers ces définitions, avec des notes claires lorsqu’elles diffèrent.
- La refonte ou la consolidation progressive des calculs de KPI au fur et à mesure que les systèmes sont mis à niveau ou revalidés.
Étapes pratiques pour attribuer la responsabilité
Pour établir la responsabilité sans réorganiser toute votre structure :
- Désignez un responsable du programme KPI ISO 22400 (souvent issu de l’excellence opérationnelle ou de l’ingénierie de fabrication) qui coordonne les travaux, sans être seul propriétaire des définitions.
- Créez une charte de gouvernance des KPI qui désigne le groupe central (opérations, qualité, IT/OT, finance) et précise les droits de décision, les flux de travail d’approbation et les attentes en matière de documentation.
- Commencez par un ensemble restreint de KPI critiques (par ex., disponibilité, performance, taux de qualité, OEE, NPT) et attribuez à chacun des responsables de processus et des data stewards spécifiques.
- Documentez l’état actuel par rapport à l’état cible aligné sur ISO 22400 pour chaque KPI, y compris les écarts des systèmes existants.
- Intégrez les modifications de définition des KPI dans les processus de maîtrise des changements existants (par ex., gestion des changements IT et maîtrise documentaire du QMS), afin que les modifications soient suivies comme tout autre changement maîtrisé.
En résumé, les définitions des KPI dans un programme ISO 22400 doivent être portées par un groupe de gouvernance transverse avec une responsabilité clairement établie : les opérations pour le sens pratique, la qualité pour la traçabilité et la maîtrise des changements, l’IT/OT pour l’intégrité des données et la mise en œuvre, et la finance pour l’alignement avec le reporting métier. L’organigramme exact importe moins que l’existence de rôles explicites, de décisions documentées et d’une gestion rigoureuse des changements dans vos systèmes existants.