Pourquoi l’ERP ne suffit pas pour l’exécution de la fabrication aérospatiale

La plupart des fabricants aérospatiaux s’appuient sur un système ERP comme colonne vertébrale de leur activité. Il contient les contrats, les besoins matières, les gammes, les coûts et les plannings. Sur le papier, il ressemble au système qui devrait tout vous dire sur l’usine.

En réalité, ce n’est pas le cas. Un ERP est fondamentalement un moteur de planification et de transactions, et non un environnement d’exécution. Il modélise ce qui devrait se produire. Il ne montre pas de manière fiable ce qui se passe maintenant sur une ligne, une cellule ou un centre de charge spécifique.

Pour les équipes qui mettent ce sujet en pratique au quotidien, les solutions d’exécution aérospatiale de Connect 981 aident à relier le concept à la traçabilité, à la réalité des ordres de fabrication et aux preuves prêtes pour audit.

Pour les équipes qui mettent ce sujet en pratique au quotidien, les systèmes d’exécution pour la fabrication aérospatiale, le pilotage de l’exécution en atelier aident à relier le concept à la traçabilité, à la réalité des ordres de fabrication et aux preuves prêtes pour audit.

Le même modèle opérationnel dépend également des parcours d’intégration ERP, MES et PLM, d’une plateforme d’exécution connectée, des recommandations de Connect 981 pour les opérations aérospatiales, des FAQ pratiques sur les opérations aérospatiales, en particulier lorsque les décisions doivent circuler entre qualité, production, fournisseurs et direction de programme sans perdre le contexte.

Le résultat est un schéma bien connu dans l’aérospatiale : les responsables de programme, les responsables de production et les équipes qualité passent leurs journées à rapprocher les données ERP avec des feuilles de calcul, des tableaux blancs, des e-mails et des tournées terrain. Le système de référence et le système de la réalité opérationnelle sont deux choses différentes.

C’est le même déficit de visibilité que celui abordé dans l’argument plus large selon lequel les tableaux de bord aérospatiaux de haut niveau peuvent induire fortement en erreur. Les livraisons, le chiffre d’affaires et le carnet de commandes masquent la vérité opérationnelle. Il en va de même pour un écran ERP qui paraît complet, mais qui ne contient pas le détail de l’exécution en temps réel.

Cet article explique où l’ERP fonctionne bien dans l’aérospatiale, où il s’arrête aux limites de l’atelier, et ce qu’une couche d’exécution dédiée doit fournir pour combler l’écart.

Ce que l’ERP fait bien dans la fabrication aérospatiale

L’ERP n’est pas le problème. Il est simplement conçu pour un rôle précis : coordonner la planification à long horizon, la finance et les structures de production de haut niveau. Dans un environnement réglementé et à cycle long comme l’aérospatiale et la défense, ces atouts comptent.

Planification à long horizon, MRP et modélisation de capacité

Les systèmes ERP excellent dans la description de programmes pluriannuels, de matières à longs délais d’approvisionnement et de capacités agrégées. Ils fournissent :

• La planification des besoins matières (MRP) à travers des nomenclatures (BOM) complexes et des chaînes d’approvisionnement multi-niveaux.
• Une planification de capacité à maille grossière qui met en adéquation la demande avec la disponibilité des ressources de haut niveau sur des semaines, des mois et des années.
• La prévision et la planification de scénarios pour de nouveaux programmes, des augmentations de cadence ou des modifications de conception.

Pour les structures d’aéronefs, les moteurs, l’avionique et le matériel spatial, cette vision stratégique est essentielle. Les composants à longs délais, les matières soumises au contrôle des exportations et les fournisseurs en source unique doivent tous être modélisés et engagés bien avant le démarrage des travaux en atelier.

Intégration financière, calcul des coûts et structures contractuelles

Les programmes aérospatiaux dépendent de leur architecture financière. L’ERP est le système qui relie les plans opérationnels aux contrats et à la trésorerie :

• La collecte et l’allocation des coûts à travers les structures de découpage des travaux et les comptes de coûts.
• La comptabilité des contrats et des projets pour les programmes gouvernementaux et commerciaux, y compris la valeur acquise et la facturation par jalons.
• La facturation, la comptabilisation du chiffre d’affaires et l’analyse de marge au niveau du programme, du lot ou de la configuration.

C’est également ainsi que les OEM et les maîtres d’œuvre coordonnent leurs activités avec les fournisseurs au niveau commercial. Les bons de commande, les réceptions et le rapprochement des factures passent tous par l’ERP, fournissant l’ossature financière attendue par les auditeurs externes.

Gammes de référence et ordres de fabrication de haut niveau

L’ERP contient la vision nominale de la manière dont le travail devrait circuler dans l’usine :

• Des gammes standard qui définissent les principales opérations et les centres de charge.
• Des ordres de fabrication planifiés qui décrivent quels assemblages passeront par ces gammes et à quel moment.
• Des références aux données de fabrication et d’ingénierie, telles que les références article, les révisions et les familles de configuration.

Ce niveau de structure est utile pour planifier la main-d’œuvre, se synchroniser avec le MRP et donner à la finance un moyen de comprendre l’avancement. Mais ce n’est pas le niveau auquel l’exécution aérospatiale se déroule réellement.

Là où l’ERP s’arrête : l’écart avec la réalité de l’atelier

Plus on se rapproche du point d’exécution, plus les limites de l’ERP deviennent visibles. Le modèle dans l’ERP est abstrait et relativement statique. L’usine, elle, ne l’est pas.

Séquencement dynamique du travail et priorités en temps réel

Au cours de n’importe quelle équipe, les superviseurs et les planificateurs réordonnancent en permanence le travail :

• Avancer des opérations afin de préserver un jalon de livraison.
• Réacheminer le travail pour contourner une machine à l’arrêt, un outillage indisponible ou un poste d’inspection bloqué.
• Ajuster les priorités lorsqu’une unité urgente arrive d’un client ou qu’un créneau d’essai critique se libère.

L’ERP peut représenter des séquences et des dates d’échéance planifiées. Il n’est pas conçu pour agir comme un système de dispatching en temps réel qui s’adapte minute par minute à l’évolution des contraintes. Il en résulte un décalage : ce que le planning ERP indique comme devant être en cours et ce que l’atelier exécute réellement sont souvent différents, la logique véritable résidant dans les connaissances locales, les e-mails et les dossiers suiveurs de fabrication papier.

Statut détaillé des opérations, blocages et perturbations

L’ERP enregistre généralement le statut au niveau de l’ordre de fabrication ou de l’opération majeure : lancé, en cours, terminé. L’exécution en aérospatiale exige une granularité beaucoup plus fine :

• Quelle unité spécifique se trouve à quel poste en ce moment précis ?
• Est-elle en cours de traitement, en attente de matière, ou en file d’attente derrière un autre lot ?
• Est-elle bloquée en raison d’un problème d’ingénierie, d’une non-conformité suspectée, ou d’une certification manquante ?

Capturer ce niveau de statut et de contexte dans l’ERP reviendrait à transformer une base de données transactionnelle en système d’événements à haute fréquence. La plupart des organisations choisissent de ne pas le faire ; elles reportent donc ce niveau de détail dans des dossiers suiveurs de fabrication, des feuilles de calcul locales, ou un outil de type MES, s’il en existe un. Conséquence : les systèmes centraux affichent l’avancement, mais pas les raisons qui expliquent les retards ou l’instabilité.

Traçabilité granulaire au niveau des composants et des lots

Les programmes aérospatiaux exigent une traçabilité approfondie — non seulement des ensembles finis, mais aussi des composants individuels, des lots et des étapes de procédé :

• Quels matériels exacts, lots de matières et procédés spéciaux sont intégrés dans une unité sérialisée ?
• Quel technicien a réalisé une opération spécifique, avec quels outils étalonnés et quelle révision de l’instruction de travail ?
• Comment parcourez-vous rapidement cette chaîne lorsqu’un problème fournisseur ou un événement en service déclenche une action de confinement formelle ?

L’ERP peut être capable de stocker une partie de ces informations, mais le faire à la résolution et au volume requis par l’aérospatiale moderne devient rapidement impraticable. Le modèle de données et l’expérience utilisateur ne sont pas optimisés pour saisir et parcourir le détail d’exécution au poste de travail.

Comment l’écart se manifeste dans les opérations quotidiennes

L’écart entre le modèle de l’ERP et la réalité de l’atelier n’est pas théorique. Il apparaît dans les contournements spécifiques sur lesquels les équipes aérospatiales s’appuient simplement pour exécuter la journée.

Systèmes parallèles : tableurs et tableaux blancs

L’un des indicateurs les plus évidents qu’un ERP ne suffit pas est la quantité d’informations critiques qui existent en dehors de celui-ci :

• Les superviseurs tiennent à jour des tableaux Excel avec leur propre vision des encours (WIP), des priorités et des contraintes.
• Les réunions de production s’appuient sur des rapports imprimés annotés à la main pour refléter la situation réelle.
• Les cellules et lignes suivent l’état d’avancement sur des tableaux blancs mis à jour entre les équipes.

Ces systèmes parallèles sont une réponse rationnelle à un besoin réel : les équipes ont besoin d’une représentation rapide, flexible et en temps réel du travail, que l’ERP ne fournit pas. Mais ils créent un risque. Ils ne sont pas maîtrisés, ne sont pas audités et ne sont pas visibles pour le reste de l’organisation.

Flux de travail qualité, inspection et non-conformité déconnectés

Dans un environnement AS9100, les processus qualité et d’inspection doivent être étroitement liés à l’exécution. Pourtant, ils fonctionnent souvent comme des flux parallèles :

• Plans d’inspection et check-lists dans des solutions ponctuelles ou des PDF.
• Rapports de non-conformité (NCR) dans un QMS séparé, avec un rapprochement manuel aux ordres de fabrication et aux numéros de série.
• Instructions de reprise et concessions communiquées par e-mail ou via un circuit manuel de documents.

L’ERP peut enregistrer l’existence d’un NCR ou d’un ordre de reprise, mais pas le parcours détaillé suivi par l’unité au fil des décisions qualité, ni les données exactes nécessaires pour démontrer la conformité lors d’un audit. Cette fragmentation rend l’analyse des causes racines, les investigations sur les non-détections et le reporting client lents et sujets aux erreurs.

Suivi manuel des statuts pour le reporting interne et client

Les revues de programme et les points d’avancement client mettent en évidence le problème de données sous-jacent. Pour répondre à des questions apparemment simples — « Quelles unités sont à risque ? » « Qu’est-ce qui bloque cette livraison ? » « Combien d’heures de reprise avons-nous engagées ce mois-ci ? » — les équipes ont souvent recours à un suivi manuel des statuts :

• Parcourir l’atelier pour confirmer visuellement où se trouvent les produits.
• Appeler ou envoyer des messages aux superviseurs et aux planificateurs pour rapprocher les écarts.
• Préparer des supports ponctuels combinant des données ERP avec des fichiers de suivi maintenus localement.

C’est précisément le schéma que l’industrie observe lorsque des tableaux de bord externes, comme les livraisons et le carnet de commandes, sont traités comme la vérité alors que le système d’exécution lui-même reste opaque. Le même désalignement existe au sein de nombreuses usines : les indicateurs de synthèse dans l’ERP semblent corrects, mais les mécanismes qui les produisent sont fragiles.

Pourquoi les extensions ERP résolvent rarement l’exécution

De nombreuses organisations aérospatiales tentent de combler cet écart en ajoutant des personnalisations ou des modules satellites à l’ERP. L’intention est raisonnable — étendre le système dont vous disposez déjà — mais des contraintes structurelles font obstacle.

Contraintes architecturales des systèmes transactionnels

Les architectures ERP sont optimisées pour l’intégrité transactionnelle et l’exactitude financière, et non pour capturer chaque événement qui se produit dans l’atelier. Pousser l’exécution détaillée dans l’ERP crée des difficultés :

• Les mises à jour de statut à haute fréquence peuvent mettre à l’épreuve les performances et les modèles de licences.
• Les flux de travail complexes, avec gestion d’état, sont difficiles à représenter au moyen de tables transactionnelles génériques.
• Les interfaces utilisateur conçues pour les planificateurs et les comptables ne sont pas idéales pour les opérateurs sur ligne.

Il en résulte souvent une mise en œuvre partielle : quelques champs supplémentaires, deux ou trois écrans personnalisés, et toujours une forte dépendance à des fichiers de suivi externes pour le travail réel.

Complexité de configuration et produits aérospatiaux riches en variantes

Le matériel aérospatial est fortement configurable. Les points de changement de configuration, les options propres aux clients, les rétrofits et les modifications d’ingénierie se recoupent tous sur les mêmes unités physiques. Représenter cette complexité au niveau de l’exécution nécessite :

• Une maîtrise fine de la configuration jusqu’au niveau de l’unité et de l’opération.
• Des instructions de travail dynamiques qui reflètent la configuration exacte présente devant l’opérateur.
• La capacité à fractionner et fusionner le travail, à suivre les achèvements partiels et à gérer les écarts sans perdre la traçabilité.

L’ERP est généralement construit autour des produits, des nomenclatures et des gammes — et non autour d’un graphe d’exécution propre à chaque unité, en évolution permanente. À mesure que la complexité de configuration augmente, l’écart entre le modèle statique de l’ERP et la réalité se creuse.

Besoins d’audit et de certification au-delà des modèles de données ERP standard

AS9100, les exigences répercutées par les clients et les exigences réglementaires (p. ex. contrôle des exportations, procédés spéciaux, composants critiques pour la sécurité) exigent un enregistrement auditable qui va au-delà des champs ERP standard :

• Qui a réalisé chaque étape, avec quelles qualifications, et à quel moment.
• Quelles procédures, quels plans et quelles révisions spécifiques étaient en vigueur.
• Comment les non-conformités, les non-détections et les actions correctives ont été identifiées et résolues.

Tenter d’intégrer a posteriori ce niveau de détail dans l’ERP aboutit souvent à des personnalisations hypertrophiées, difficiles à maintenir, qui ne correspondent toujours pas à la manière dont le travail est réellement exécuté. Les audits deviennent alors des exercices de reconstitution au lieu de simples requêtes sur un historique d’exécution propre.

Définir la couche d’exécution aérospatiale

Pour résoudre ce problème, les organisations reconnaissent de plus en plus la nécessité d’une couche d’exécution distincte, mais étroitement connectée. Il ne s’agit pas d’un système d’enregistrement concurrent pour la finance et la planification. C’est l’environnement opérationnel qui se situe entre le plan et la réalité.

Caractéristiques d’un système qui vit entre le plan et la réalité

Une véritable couche d’exécution aérospatiale présente plusieurs propriétés déterminantes :

• Tenant compte du plan sans y être contrainte : elle comprend les ordres de fabrication, les gammes et les configurations issus de l’ERP, mais permet le réordonnancement dynamique, les mises en attente et les changements de cheminement en fonction des conditions réelles.
• Centrée sur les événements : elle enregistre ce qui se passe réellement au poste de travail — démarrages, pauses, achèvements, inspections, NCR et signatures — sous forme d’un flux d’événements horodatés.
• Contexte au niveau de l’unité : elle suit les numéros de série ou les lots individuels tout au long de leurs cheminements propres, au lieu de se limiter à une agrégation par référence article ou par gamme.

C’est dans cette couche que les règles d’exécution et la réalité opérationnelle sont rapprochées en temps réel.

Suivi des encours (WIP) en temps réel, contexte d’opération et flux de travail utilisateur

Concrètement, une plateforme d’exécution doit permettre aux équipes de voir et de maîtriser les encours de fabrication (WIP) à un niveau que l’ERP ne peut pas fournir :

• Où se trouve chaque unité, sur quelle opération elle se trouve et ce qui la bloque, avec une mise à jour continue.
• Des flux de travail guidés pour les opérateurs, présentant les bonnes instructions, la bonne saisie de données et les bons contrôles à la bonne étape.
• Des visualisations des files d’attente, des contraintes et des encours vieillissants pour les superviseurs et les responsables de programme.

Au lieu de reconstituer l’état d’avancement à partir de plusieurs sources, la couche d’exécution devient la vision opérationnelle unique de l’usine — alimentée par les événements au poste de travail et alignée sur le plan dans l’ERP.

Traçabilité intégrée et maîtrise de la configuration au poste de travail

La traçabilité et la maîtrise de la configuration sont les plus robustes lorsqu’elles sont intégrées à la manière dont le travail est réalisé, et non ajoutées après coup. Dans une couche d’exécution, cela signifie :

• Capturer les numéros de série, les lots matière et les paramètres de procédé dans le cadre du flux de travail normal de l’opérateur.
• Garantir que seules les instructions et données correctes, validées et diffusées, sont disponibles pour la configuration spécifique présentée à l’opérateur.
• Construire automatiquement une généalogie complète et un historique des événements comme sous-produit de l’exécution, et non comme une tâche distincte de saisie de données.

C’est la différence entre être prêt pour l’audit par défaut et devoir assembler des preuves à partir des journaux ERP, de lecteurs partagés et de dossiers papier chaque fois qu’un client ou une autorité réglementaire les demande.

Intégrer l’ERP à une plateforme d’exécution connectée

Rien de cela ne fonctionne si l’ERP et la couche d’exécution sont isolés. La valeur vient de frontières claires et d’une intégration délibérée, et non de la tentative de faire accomplir toutes les tâches par un seul système.

Frontières de données : ce qui reste dans l’ERP par rapport à la couche d’exécution

Une architecture propre attribue explicitement les responsabilités :

• L’ERP reste le système de référence pour les contrats, les commandes, les nomenclatures (BOM), les gammes, les positions de stock et les transactions financières.
• La couche d’exécution devient la source de réalité opérationnelle pour l’état des encours (WIP), l’historique des opérations, les événements qualité, les interactions opérateur et la généalogie au niveau de l’unité.

Les deux sont synchronisés, mais ils ne se dupliquent pas. L’ERP n’a pas besoin de chaque frappe clavier de l’opérateur. La plateforme d’exécution n’a pas besoin de gérer les comptes clients.

Mises à jour pilotées par les événements, de l’atelier aux systèmes de planification

Au lieu de chargements par lots ou de transmissions manuelles d’états, la couche d’exécution doit alimenter l’ERP au moyen d’une intégration pilotée par les événements :

• Lorsque des opérations sont terminées, l’ERP reçoit les confirmations nécessaires pour la rétroconsommation, la collecte des coûts et les mises à jour du planning.
• Lorsque des blocages ou des écarts majeurs surviennent, l’ERP et les outils de planification reçoivent des signaux indiquant qu’un plan doit être réévalué.
• Lorsque des unités franchissent des jalons clés, les indicateurs au niveau du programme se rafraîchissent automatiquement.

Cette approche préserve le rôle de l’ERP comme colonne vertébrale de la planification et des finances, tout en garantissant que sa vision de l’avancement est ancrée dans les données d’exécution réelles.

Synchroniser les données de BOM, de gamme et de configuration

Dans l’aérospatial, la discipline de configuration est non négociable. L’intégration doit garantir que :

• Les nomenclatures (BOM), les gammes et les règles d’effectivité approuvées circulent depuis l’ERP et les systèmes d’ingénierie vers la couche d’exécution de manière maîtrisée.
• Les changements sont versionnés, avec des points d’introduction clairs afin que les unités en cours ne dérivent pas vers des états ambigus.
• La couche d’exécution peut enrichir cette structure avec un contexte propre à l’unité (par exemple, dérogations, numéros de série uniques, parcours locaux de reprise) sans rompre la logique de configuration sous-jacente.

C’est également là qu’un fil numérique pratique commence à émerger : la capacité à suivre une configuration depuis l’intention d’ingénierie jusqu’à la planification, l’exécution, les essais et la livraison, sans perte de continuité.

Exemples de modèles d’intégration pour les fabricants aérospatiaux

En pratique, les fabricants aérospatiaux adoptent souvent des modèles tels que :

• Intégration centrée sur l’ordre de fabrication : l’ERP crée et détient les ordres ; la couche d’exécution détient les étapes détaillées et les statuts, et renvoie les achèvements ainsi que les principaux indicateurs qualité.
• Intégration centrée sur le numéro de série : chaque numéro de série devient la clé commune entre l’ERP, l’exécution, les essais et les systèmes en service, permettant une traçabilité claire sur l’ensemble du cycle de vie.
• Signalement des jalons : la couche d’exécution pilote les jalons programme (par exemple, jonction, mise sous tension, essais terminés) que l’ERP et les outils de reporting utilisent comme base pour le suivi de l’avancement et la facturation.

Ces modèles correspondent aux réalités de l’aérospatial : cycles longs, assemblages complexes et nécessité de rapprocher les vues financières, opérationnelles et réglementaires d’un même produit.

Choisir les bons rôles système pour un environnement réglementé

Dans une organisation régie par AS9100, les choix d’architecture sont également des choix de conformité. La manière dont vous attribuez les rôles système influence votre capacité à démontrer la maîtrise, la traçabilité et l’intégrité des données.

S’aligner sur AS9100 et les exigences client répercutées

AS9100 met l’accent sur les processus documentés, les enregistrements maîtrisés et une responsabilité claire en matière de qualité. Une répartition bien conçue entre ERP et exécution y contribue en :

• Faisant de l’ERP la source faisant autorité pour les références article approuvées, les gammes et la planification de haut niveau.
• Utilisant la couche d’exécution pour capturer la manière dont ces processus ont réellement été exécutés, y compris les écarts, les approbations et les vérifications.
• Garantissant que les exigences client et réglementaires sont traçables depuis la spécification jusqu’aux étapes et contrôles spécifiques réalisés sur chaque unité.

Cela réduit l’écart entre la procédure et la pratique, qui est à l’origine de nombreux constats d’audit.

Garantir l’intégrité des données et l’auditabilité entre les systèmes

Disposer de plusieurs systèmes ne signifie pas nécessairement avoir des données fragmentées. Si cela est bien réalisé, cela peut au contraire accroître l’auditabilité :

• L’ERP détient les données de référence stables et les transactions financières, avec une maîtrise rigoureuse des changements.
• La couche d’exécution produit un enregistrement très détaillé des événements, approbations et mesures rattachés à des unités spécifiques.
• L’intégration fournit une chaîne de traçabilité claire : il est toujours visible comment les données de planification ont été utilisées, comment les données d’exécution ont été produites, et comment les deux se sont mutuellement alimentées.

Cette architecture prend également en charge une divulgation sélective : vous pouvez donner aux clients ou aux régulateurs une visibilité approfondie sur l’historique d’exécution sans exposer les structures financières internes.

Comment des plateformes comme Connect 981 complètent l’ERP sans le remplacer

L’orientation de l’industrie n’est pas d’abandonner l’ERP, mais de l’entourer de systèmes qui rendent ses informations exploitables en temps réel. Des plateformes comme Connect 981 opèrent dans cet espace d’exécution :

• Reprendre depuis l’ERP le plan, la configuration et le contexte contractuel.
• Fournir une vision en direct, au niveau de l’unité, du travail, de la qualité et de la traçabilité que l’ERP ne peut pas raisonnablement porter à lui seul.
• Réinjecter des signaux d’exécution propres et structurés dans les couches de planification, de reporting et de prise de décision.

Pour les fabricants aéronautiques et spatiaux, la question est moins « Peut-on faire en sorte que l’ERP fasse tout ? » que « Comment concevoir un système d’exécution connecté où l’ERP, l’atelier et la qualité voient tous la même réalité ? » La réponse consiste à adopter une couche d’exécution dédiée qui complète l’ERP, comble le déficit de visibilité et fait en sorte que le tableau de bord de haut niveau reflète l’état réel du système sous-jacent.