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, pas 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.

Il en résulte 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 d’enregistrement et le système de la réalité sont deux choses différentes.

C’est le même manque de visibilité que celui abordé dans l’argument plus large selon lequel les tableaux de bord aérospatiaux de haut niveau peuvent être profondément trompeurs. 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 d’exécution en temps réel.

Cet article explique où l’ERP fonctionne bien dans l’aérospatiale, où il s’arrête à la limite de l’atelier, et ce qu’une couche d’exécution dédiée doit fournir pour combler cet é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 à cycles longs comme l’aérospatiale et la défense, ces atouts comptent.

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

Les systèmes ERP excellent pour décrire les programmes pluriannuels, les matières à long délai d’approvisionnement et la capacité agrégée. Ils fournissent :

• La planification des besoins matières (MRP) sur des nomenclatures (BOM) complexes et des chaînes d’approvisionnement multi-niveaux.
• La planification capacitaire grossière, qui met en correspondance la demande avec la disponibilité des ressources à 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 aéronautiques, les moteurs, l’avionique et les équipements spatiaux, cette vision stratégique est essentielle. Les composants à long délai d’approvisionnement, 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 opérations en atelier.

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

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

• Collecte et allocation des coûts entre les organigrammes des tâches et les comptes de coûts.
• Comptabilité contractuelle et projet pour les programmes gouvernementaux et commerciaux, incluant la valeur acquise et la facturation à jalons.
• Facturation, reconnaissance du chiffre d’affaires et analyse des marges 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 commandes d’achat, 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 à haut niveau

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

• Gammes standard définissant les opérations principales et les centres de charge.
• Ordres de fabrication planifiés décrivant quels ensembles passeront par ces gammes et à quel moment.
• 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 structuration 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 à ce niveau que se situe réellement l’exécution aérospatiale.

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

À chaque équipe, les superviseurs et les planificateurs réordonnancent en permanence le travail :

• Avancer des opérations afin de protéger une échéance de livraison.
• Réorienter 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 de test 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 servir de système de dispatching en direct, s’adaptant 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 qui est effectivement réalisé dans l’atelier diffèrent souvent, la logique réelle 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 principale : lancé, en cours, terminé. L’exécution en aéronautique exige une granularité beaucoup plus fine :

• Quelle unité précise se trouve à quel poste en ce moment ?
• Est-elle effectivement en cours de travail, en attente de matière, ou en file derrière un autre lot ?
• Est-elle en blocage pour un problème d’ingénierie, une non-conformité suspectée ou une certification manquante ?

Saisir 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 détail dans les 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é :

• Quel matériel exact, quels lots de matière et quels 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 au niveau de résolution et au volume requis par l’aérospatial 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 de l’exécution au poste de travail.

Comment l’écart apparaît 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 se manifeste dans les contournements spécifiques sur lesquels les équipes aérospatiales s’appuient simplement pour faire fonctionner la journée.

Systèmes parallèles : feuilles de calcul et tableaux blancs

L’un des indicateurs les plus nets que l’ERP ne suffit pas est la quantité d’informations critiques qui vivent en dehors de celui-ci :

• Les superviseurs maintiennent des tableaux Excel avec leur propre vision de l’encours, 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 îlots 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 direct 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 checklists dans des solutions ponctuelles ou des PDF.
• Rapports de non-conformité (NCR) dans un QMS distinct, avec référence manuelle aux ordres de fabrication et aux numéros de série.
• Instructions de reprise et dérogations communiquées par e-mail ou par routage manuel de documents.

L’ERP peut enregistrer l’existence d’un NCR ou d’un ordre de reprise, mais pas le chemin détaillé suivi par l’unité au travers des décisions qualité, ni les données exactes nécessaires pour démontrer la conformité lors d’un audit. Cette fragmentation ralentit l’analyse des causes racines, les investigations sur les non-conformités passées au travers des contrôles et le reporting client, tout en augmentant le risque d’erreurs.

Suivi manuel des statuts pour le reporting interne et client

Les revues de programme et les mises à jour de statut destinées aux clients révèlent 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 consommées ce mois-ci ? » — les équipes recourent souvent à un suivi manuel des statuts :

• Parcourir l’atelier pour confirmer visuellement où se trouve le matériel.
• Appeler ou envoyer des messages aux superviseurs et aux planificateurs pour réconcilier les écarts.
• Assembler des diapositives ponctuelles combinant les 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 score externes comme les livraisons et le carnet de commandes sont traités comme la vérité, tandis que le système d’exécution lui-même reste opaque. Le même désalignement existe dans de nombreuses usines : les indicateurs synthétiques 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 que vous possédez déjà — mais des contraintes structurelles s’y opposent.

Contraintes architecturales des systèmes transactionnels

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

• Les mises à jour d’état à haute fréquence peuvent solliciter fortement les performances et les modèles de licence.
• Les flux de travail complexes et avec é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 outils de suivi externes pour le travail réel.

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

Le matériel aérospatial est hautement configurable. Points de changement de bloc, options propres à chaque client, rétrofits et modifications d’ingénierie se croisent tous sur les mêmes unités physiques. Représenter cette complexité au niveau de l’exécution exige :

• Une maîtrise fine de la configuration jusqu’à l’unité et à l’opération.
• Des instructions de travail dynamiques qui reflètent la configuration exacte devant l’opérateur.
• La capacité de fractionner et de fusionner le travail, de suivre les achèvements partiels et de 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é et 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 dépasse les champs ERP standard :

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

Tenter d’ajouter 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 reconstruction au lieu de requêtes simples 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 situé entre le plan et la réalité

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

• Consciente du plan, sans y être enfermée : elle comprend les ordres de fabrication, les gammes et les configurations provenant 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 validations — sous forme de 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 pièce ou par gamme.

C’est la couche où les règles d’exécution et la réalité opérationnelle sont conciliées en temps réel.

Suivi des encours 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 visualiser et de piloter les encours de production (WIP) à un niveau que l’ERP ne peut pas fournir :

• Où se trouve chaque unité, sur quelle opération elle se situe et ce qui la bloque, avec une mise à jour continue.
• Des flux de travail guidés pour les opérateurs, qui présentent 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 de l’ancienneté des encours pour les superviseurs et les responsables de programme.

Au lieu de reconstruire le statut à partir de multiples 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 avec 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 d’autant plus robustes qu’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.
• S’assurer que seules les instructions et les données correctes et validé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 ce qui distingue une organisation prête pour l’audit par défaut d’une organisation qui doit rassembler des preuves à partir des journaux ERP, de lecteurs partagés et de dossiers papier chaque fois qu’un client ou une autorité réglementaire en fait la demande.

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

Rien de tout cela ne fonctionne si l’ERP et la couche d’exécution sont isolés. La valeur provient de frontières claires et d’une intégration délibérée, et non de la tentative de faire couvrir tous les besoins par un seul système.

Frontières des 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 le système reflétant la 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 événements de l’atelier vers les systèmes de planification

Au lieu de chargements par lots ou de transmissions manuelles de statut, la couche d’exécution doit alimenter l’ERP au moyen d’une intégration pilotée par é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 de 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 programme se rafraîchissent automatiquement.

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

Synchronisation des données de nomenclature, 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 modifications sont versionnées, avec des points d’introduction clairement définis afin que les unités en cours ne basculent pas dans des états ambigus.
• La couche d’exécution peut enrichir cette structure avec un contexte propre à chaque unité (p. ex., dérogations, numéros de série uniques, chemins de reprise locaux) sans rompre la logique de configuration sous-jacente.

C’est également à ce niveau 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 terrain, permettant une traçabilité claire sur l’ensemble du cycle de vie.
• Signalement des jalons : la couche d’exécution pilote les jalons programme (p. ex., assemblage, 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 sont alignés sur les 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 matériel.

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

Dans une organisation régie par AS9100, les choix d’architecture sont aussi 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é clairement définie en matière de qualité. Une répartition bien conçue entre l’ERP et l’exécution y contribue en :

• Faisant de l’ERP la source faisant autorité pour les références d’articles 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 effectivement é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 nombreuses constatations 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 que les données sont fragmentées. Si c’est bien réalisé, cela peut accroître l’auditabilité :

• L’ERP conserve les données de base stables et les transactions financières, avec une maîtrise rigoureuse des changements.
• La couche d’exécution produit un enregistrement à haute résolution des événements, approbations et mesures associé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 permet également une communication sélective : vous pouvez donner aux clients ou aux autorités réglementaires 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

La tendance du secteur 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 interviennent dans cet espace d’exécution :

• Reprendre depuis l’ERP le plan, la configuration et le contexte contractuel.
• Fournir la vision en temps réel, au niveau de l’unité, du travail, de la qualité et de la traçabilité que l’ERP ne peut pas, en pratique, gérer directement.
• Réinjecter des signaux d’exécution propres et structurés dans les couches de planification, de reporting et d’aide à la décision.

Pour les fabricants aérospatiaux, la question est moins « Peut-on faire en sorte que l’ERP fasse tout ? » que « Comment concevoir un système d’exécution connecté dans lequel 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 l’écart 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.