Pourquoi MES échoue à grande échelle (et comment y remédier)

La plupart des échecs MES sont généralement imputés aux personnes. L'équipe chargée du déploiement met en cause la formation, tandis que le chef d'équipe attribue l'échec au manque d'adhésion des opérateurs. Aucun de ces points de vue n'est nécessairement erroné, mais ils sont tous deux incomplets.

Lorsque l'adoption d'un système marque le pas sur plusieurs sites et dans plusieurs services, c'est généralement une question d'architecture qui explique ce décalage. Le système n'étant pas capable de s'adapter à la vitesse et au niveau de détail requis par le travail, ce sont les employés qui s'adaptent à lui.

Selon McKinsey, au moins 70 % des fabricants se trouvent dans une « impasse des projets pilotes », incapables de faire évoluer leurs initiatives numériques au-delà de leur phase de mise en œuvre initiale. Malgré une amélioration de la manière dont les entreprises appréhendent et gèrent Gestion du changement, ce chiffre est resté relativement stable.

Dans cet article, nous allons passer en revue les principaux points de blocage que l'on observe lors de MES dans des environnements multi-sites, expliquer pourquoi la cause profonde est presque toujours d'ordre architectural (et non comportemental), et voir à quoi ressemble une mise en œuvre réussie lorsque le système est conçu pour s'adapter au travail tel qu'il se déroule réellement.

À la fin, vous disposerez du vocabulaire nécessaire pour expliquer à votre comité de pilotage pourquoi le prochain déploiement pourrait achopper au même stade que le précédent, ainsi que d'une liste de questions relatives à l'architecture à inclure dans votre prochain appel d'offres destiné aux fournisseurs.

Si vous avez déjà participé à MES , vous savez sans doute à quoi ressemble l'approche standard en matière d'adoption. La plupart des fournisseurs et des intégrateurs proposent un plan d'action similaire, et Gestion du changement s'articulent autour des mêmes axes : définir des objectifs clairs, organiser la mise en place par étapes, investir dans des formations adaptées aux différents rôles, communiquer sur le changement, obtenir le soutien de la direction et impliquer dès le début les équipes et les parties prenantes concernées dans la réflexion sur la conception.

Dans tous les secteurs, les projets dotés de Gestion du changement solides ont environ cinq fois plus de chances d'être menés à bien dans les délais que ceux qui en sont dépourvus, et une communication claire à elle seule a été associée à une augmentation mesurable des taux de réussite. La formation, la communication, le soutien de la direction et l'implication des différentes fonctions y contribuent tous.

Mais ce que ce guide néglige, c'est la partie en amont. Il considère l'adoption comme une conséquence en aval de la manière dont le déploiement est géré, alors que l'adoption dépend également de la façon dont le système est conçu.

Si l'on applique le même Gestion du changement à deux MES différentes, les résultats peuvent être radicalement différents. Une entreprise étend le déploiement à dix usines, tandis que l'autre peine à aller au-delà de la première.

Ce qui explique généralement cet écart, c'est la capacité de l'architecture à s'adapter aux variations auxquelles sont confrontés quotidiennement les environnements de production réels. Lorsque nous travaillons avec des responsables opérationnels pour analyser un déploiement qui a échoué, les difficultés qu'ils décrivent correspondent rarement à des problèmes qu'un meilleur Gestion du changement aurait pu résoudre. Elles concernent plutôt des situations où le système n'a pas pu suivre le rythme du travail.

Nous avons constaté que MES qui s’enlisent échouent généralement de la même manière. Nous avons collaboré avec des fabricants multi-sites issus de divers secteurs complexes, et les quatre problèmes ci-dessous reviennent dans presque toutes les analyses rétrospectives auxquelles nous assistons. Ils trouvent tous leur origine dans le même problème d’architecture : la plateforme ne peut pas évoluer au même rythme que le travail, ce qui oblige l’équipe sur le terrain à mettre en place des solutions de contournement.

Vu d'en haut, au niveau du plan de projet, ces solutions de contournement peuvent passer pour des lacunes en matière de formation ou des problèmes de culture d'entreprise. Mais à y regarder de plus près, elles constituent une réponse rationnelle à un système qui ne répond pas aux besoins de l'équipe.

Les interfaces obsolètes et la nouvelle main-d'œuvre

La plupart MES anciennes MES ont été conçues à une époque où les ouvriers de production occupaient leur poste pendant des années et acquéraient une expertise dans la navigation dans les menus. L'interface était peu intuitive, mais les opérateurs s'y sont habitués et il n'existait pas nécessairement de meilleure alternative.

Deloitte et le Manufacturing Institute estiment que le secteur manufacturier américain pourrait avoir besoin de 3,8 millions de nouveaux travailleurs nets entre 2024 et 2033, avec jusqu’à 1,9 million de postes qui risqueraient de ne pas être pourvus. La nouvelle génération qui arrive sur le terrain s’attend à une expérience plus proche de celle des applications grand public : épurée, axée sur l’interface tactile et facile à prendre en main. MES traditionnels leur MES des écrans d’entreprise à base de menus qui ont été conçus, littéralement, il y a une génération.

Ce décalage se traduit par des courbes d'intégration plus longues sur chaque site. Le délai nécessaire pour maîtriser MES anciens MES s'étend sur plusieurs semaines au lieu de quelques jours, et les usines compensent ce retard soit en imposant des heures supplémentaires prolongées aux opérateurs expérimentés, soit en acceptant une baisse de productivité pendant la phase de montée en puissance. À mesure que le taux de rotation du personnel augmente, ces deux coûts s'accumulent.

L'économie des solutions de contournement et le coût du changement

Les processus opérationnels évoluent au fil du temps. Prenons l'exemple d'une équipe Qualité confrontée à un nouveau type de non-conformité que le formulaire de traitement existant ne permet pas de saisir. Dans un MES hérité, la modification du formulaire implique la création d'un ticket informatique, la mobilisation d'un fournisseur et un cycle de mise en production. Après plusieurs cycles de « nous nous en occuperons au trimestre prochain », l'équipe Qualité cesse de demander et commence à contourner le système.

Six mois après la mise en service, il suffit généralement de se rendre dans une usine pour constater ce que nous appelons « l'économie des solutions de contournement » : un ensemble parallèle de tableurs et de processus reposant sur un savoir-faire tacite qui se sont développés autour du MES le système officiel n'arrivait pas à suivre le rythme.

L'équipe Qualité tient un registre des non-conformités sur Excel, l'atelier de maintenance dispose de son propre outil de gestion des ordres de travail, et les autres services ont leur propre version de ce type d'outil. Le MES techniquement en place, mais le travail s'effectue en réalité dans les systèmes parallèles que chaque équipe a mis en place.

Tant que le coût lié à la modification du système officiel sera supérieur à celui de la solution de contournement, les équipes opteront systématiquement pour cette dernière. Une plus grande rigueur dans l'utilisation du système officiel n'y changera rien.

Rigidité multisite

Les déploiements sur plusieurs sites se heurtent à un autre problème. Chaque usine fonctionne différemment des autres : produits différents, équipements différents, exigences réglementaires différentes, cultures d'exploitation différentes, niveaux de maturité numérique différents. Un MES unique ne peut généralement pas s'adapter à la fois à toute cette diversité, mais de nombreux modèles existants sont conçus en partant du principe qu'il le peut.

En matière de déploiements multisites, la règle générale veut qu’un modèle global couvre généralement 70 à 80 % du déploiement, les 20 à 30 % restants étant réservés aux spécificités de chaque site. Si l’on pousse la standardisation au-delà de ce seuil, le site se retrouve soit contraint d’accepter un processus qui ne correspond pas au mode de fonctionnement de l’usine, soit obligé de dériver le modèle en une configuration unique que l’équipe centrale devra alors gérer séparément.

Composable permettent de résoudre ce dilemme en permettant à chaque site d'adapter les solutions à sa réalité opérationnelle, tout en partageant le modèle de données, la gouvernance et la stratégie de conformité qui doivent être uniformes à l'échelle de l'entreprise.

Le calendrier de mise en œuvre constitue un autre facteur aggravant. MES existants prennent généralement entre 18 et 36 mois avant la mise en service du premier site, et les déploiements multi-sites s'étendent sur plusieurs années supplémentaires. Lorsque le déploiement atteint le troisième ou le quatrième site, le déploiement initial n'est déjà plus en phase avec les opérations en cours sur le premier site.

Pourquoi la visibilité en temps réel ne parvient pas jusqu'à l'atelier

MES traditionnels MES conçus pour servir de système d'enregistrement. Les données saisies par l'opérateur à chaque étape sont enregistrées, compilées dans des rapports, puis transmises en amont au superviseur, au directeur d'usine et aux tableaux de bord de la direction. Le service chargé de la conformité dispose ainsi des informations nécessaires, les indicateurs clés sont calculés et la piste d'audit est établie.

Ce qui n'est pas toujours le cas, c'est le flux inverse. De nombreuses MES ne sont pas conçues pour transmettre des informations contextuelles en temps réel vers l'atelier. Un opérateur qui souhaite savoir si sa ligne de production est dans les temps peut se retrouver à consulter un tableau blanc que le chef d'équipe met à jour une fois par équipe.

Ce même décalage se manifeste au niveau des superviseurs, où les décisions sont prises sur la base d'informations datant de plusieurs heures, ainsi qu'au niveau de l'ingénierie des processus, où l'analyse des causes profondes s'appuie sur des exportations de lots plutôt que sur des données en temps réel.

Le choix architectural sous-jacent réside dans le système d'enregistrement. MES traditionnels MES conçus pour consigner ce qui s'est passé, et non pour faciliter la prise de décision suivante. Un système d'engagement comble cette lacune en mettant les données collectées par le système à la disposition des personnes qui peuvent les exploiter directement sur le terrain. La visibilité en temps réel cesse d'être une simple expression utilisée par la direction pour évoquer le reporting et devient une réalité vécue par les équipes de production.

Ces quatre problèmes sont tous liés à l'architecture. MES anciens MES conçus pour un monde où les employés occupaient des postes fixes, où les flux de travail évoluaient peu, où les opérations se ressemblaient d'une usine à l'autre et où les données ne devaient circuler que dans un seul sens, vers le haut de la chaîne. Aucune de ces hypothèses ne s'applique aujourd'hui à la plupart des fabricants, et ces anciens systèmes n'ont pas été conçus pour s'adapter au mode de fonctionnement actuel des usines.

La plupart MES traditionnelles sont conçues comme des systèmes monolithiques, où chaque fonctionnalité est étroitement liée à toutes les autres au sein d'un même système. L'ajout d'un simple champ de données à un contrôle qualité a des répercussions sur l'ensemble du code, ce qui explique pourquoi même de légères modifications peuvent nécessiter des semaines de développement, de validation et de déploiement coordonné. Ce même couplage, qui assure la cohérence interne et la gouvernance du système, est également ce qui rend toute modification structurellement coûteuse.

Un composable MES est conçu différemment. Il est constitué d’un écosystème d’applications et de services plutôt que d’un bloc unique, ce qui signifie que les workflows peuvent être ajoutés, modifiés ou supprimés indépendamment les uns des autres. Une modification apportée à un workflow de qualité ne nécessite pas de revalider un workflow de maintenance sans rapport avec celui-ci. Les équipes opérationnelles peuvent ajuster les applications les plus proches de leur travail sans imposer à l’ensemble de la pile un cycle de déploiement coordonné.

Cette différence architecturale se répercute sur le coût du changement. MES traditionnels utilisent MES des langages de programmation propriétaires et des schémas de données sous-jacents complexes, ce qui oblige les fabricants à faire appel à des intégrateurs de systèmes tiers, même pour des ajustements mineurs. La plupart des équipes appellent cela la « taxe d'intégration », et la plupart la sous-estiment lorsqu'elles calculent le coût total de possession. Chaque modification du flux de travail a un coût financier réel et un coût en temps réel, ce qui explique pourquoi les fabricants ont tendance à cesser complètement de modifier le système et à se contenter de solutions de contournement.

Une architecture composable ne garantit pas nécessairement son adoption. Les mauvaises implémentations de composable échouent tout de même, généralement lorsque l'équipe considère la plateforme comme une page blanche et espère que son adoption se fera d'elle-même.

Composable facilite toutefois la mise en œuvre. Son succès dépendra du modèle opérationnel que l'équipe mettra en place sur la plateforme.

Nous constatons que les entreprises qui réussissent le mieux à déployer leurs opérations numériques à l'échelle de tous leurs services et sites ont généralement fait trois choix en matière d'architecture et de modèle opérationnel que les guides traditionnels ont tendance à négliger. Chacun de ces choix répond directement aux défis identifiés ci-dessus, et ensemble, ils illustrent ce que nous entendons par un système conçu dès le départ pour être adopté.

Normalisation et flexibilité locale

Ce qui fait échouer la plupart des déploiements, c'est la standardisation des mauvais éléments. Dans les déploiements à grande échelle que nous avons observés, la solution réside dans ce que nous appelons souvent la « standardisation globale associée à une flexibilité locale » : une standardisation rigoureuse des modèles de données, des protocoles de sécurité, des pistes d'audit et de la gouvernance au niveau de la plateforme, associée à une configurabilité au niveau des flux de travail qui permet à chaque site d'adapter les applications à ses produits, à son équipement, à ses systèmes existants et à la culture de ses opérateurs.

Cela nécessite généralement un modèle de gouvernance fédéré. Un centre d'excellence (COE) sera chargé de gérer les éléments qui doivent être uniformisés d'une usine à l'autre. Les équipes sur site sont quant à elles responsables des éléments qui doivent être adaptés. Cette répartition permet à l'équipe mondiale de garantir le respect des exigences en matière d'audit et de sécurité sans imposer à chaque usine un même processus de travail qui ne tiendrait pas compte des réalités opérationnelles sur le terrain.

Développement citoyen encadré

Le compromis entre « agilité et contrôle » apparaît avec le plus de clarté lorsque la gouvernance est appliquée au niveau des projets. Chaque modification du flux de travail doit passer par des étapes d’examen, d’approbation, de validation et de déploiement, ce qui signifie que le rythme des changements est limité par la capacité de l’équipe centrale à traiter les demandes de modification. Ce compromis disparaît lorsque la gouvernance est intégrée à la plateforme elle-même.

Le développement citoyen encadré est un modèle opérationnel dans lequel les experts métier les plus proches du terrain (ingénieurs et opérateurs) développent et modifient directement des applications de production prêtes à l'emploi, tandis que la gouvernance au niveau de la plateforme, les contrôles d'accès, les workflows de validation et les pistes d'audit garantissent le respect des limites fixées par les services informatiques et de conformité. Le changement s'opère au rythme du travail, car la personne qui effectue le travail est également celle qui élabore et itère les solutions, et les limites sont respectées car elles sont appliquées en tant que fonctionnalités de la plateforme plutôt que négociées projet par projet.

Les équipes informatiques soulèvent une objection pertinente à l'égard de ce modèle, qu'il convient de noter. Le développement citoyen peut rapidement se transformer en « shadow IT » lorsque la plateforme ne dispose pas d'une véritable gouvernance intégrée. Les outils low-code génériques dépourvus de contexte industriel, de workflows de validation, de piste d'audit et de gestion des autorisations conduisent effectivement à ce résultat, et nous avons déjà vu des équipes informatiques en faire les frais par le passé.

Tulip directement Tulip ces préoccupations. La gouvernance s'inscrit dans le modèle d'autorisation de la plateforme, le contrôle de version, le processus de validation des modifications et la piste d'audit, ce qui signifie qu'un ingénieur qui met en place un processus de travail sur la ligne opère par défaut dans un cadre réglementé.

Ce modèle favorise l'adoption, car ce sont les personnes qui maîtrisent le métier qui conçoivent le processus. D'après notre expérience, les déploiements qui piétinent sont souvent ceux conçus par des personnes éloignées de l'opérateur, tandis que ceux qui parviennent à se généraliser intègrent directement les retours d'expérience des membres de l'équipe qui effectuent le travail.

Un système d'interaction, et pas seulement un système d'archivage

La couche de données constitue le troisième élément. Dans un système d'intervention, les données circulent dans les deux sens. L'opérateur génère des données tout au long du flux de travail, et il reçoit également des données en retour du système pour prendre la décision suivante. La direction conserve l'accès aux données et à la piste d'audit en amont, mais l'opérateur, le superviseur et l'ingénieur de procédés bénéficient de la visibilité dont ils ont besoin pour prendre des décisions en temps réel sur la ligne de production.

Les données sont collectées de manière passive, en tant que conséquence de l'exécution du travail, grâce aux relevés des capteurs, aux signaux des machines et aux confirmations de l'opérateur, qui sont intégrés à l'étape que l'opérateur effectuait de toute façon. Il n'y a pas de formulaire distinct à remplir ni d'étape supplémentaire à ne pas oublier.

La plupart des déploiements démarrent alors que l'architecture et le modèle opérationnel ont déjà été définis. Il ne reste plus qu'à prendre des décisions d'ordre tactique, et ce sont ces cinq domaines sur lesquels nous nous concentrons dès le début de toutes les implémentations sur lesquelles nous travaillons. Les réponses apportées s'enrichissent au fur et à mesure du déploiement.

Commencez par un opérateur, un poste de travail et une tâche

Dans tout projet de déploiement sur lequel nous travaillons, la première mise en œuvre la plus fiable consiste à créer une composable unique, conçue pour un seul opérateur dans un seul poste de travail. Choisissez une tâche spécifique que l'opérateur effectue à chaque quart de travail, de préférence une tâche qui posait des difficultés et que l'équipe contournait jusqu'à présent à l'aide de documents papier. Créez un flux de travail qui l'aide à mieux exécuter cette étape, déployez-le, puis laissez l'opérateur et son supérieur hiérarchique juger s'il vaut la peine de l'utiliser avant de l'étendre à d'autres applications, d'autres postes de travail ou d'autres sites.

L'approche ascendante est utile car la décision d'adopter une solution se prend au cas par cas, opérateur par opérateur. Dès qu'une application a fait ses preuves dans un poste de travail, l'équipe dispose de la crédibilité nécessaire pour déployer la suivante. Dès que plusieurs applications ont fait leurs preuves au sein d'un service, l'équipe dispose des bases nécessaires pour les déployer à l'échelle de l'ensemble du site.

Choisissez un site pilote représentatif du déploiement

La plante la plus docile est souvent celle qui pose le plus de problèmes. Les difficultés auxquelles le roulement finira par se heurter sont précisément celles que le pilote est censé mettre en évidence, et un pilote qui travaille sur la plante la plus facile obtient des résultats qui ne sont pas transposables.

Un site pilote plus utile est celui qui met en évidence les difficultés que le déploiement rencontrera par la suite : une usine où un MES hérité MES en service, ou un environnement de production réglementé doté de son propre cycle d'audit. Le rôle du site pilote est de repérer les points de défaillance avant que l'usine n° 3 ou l'usine n° 4 ne les mette en évidence, ce qui entraînerait des coûts plus élevés.

Donnez aux services la responsabilité de leurs processus

Souvent, les services ne partagent pas leurs processus. La logique de traitement des non-conformités du service Qualité ne s'applique pas vraiment à la planification de la production, et le cycle de maintenance préventive du service Maintenance suit sa propre logique en matière de main-d'œuvre et de pièces, dont le service Qualité n'a pas besoin. Tenter d'uniformiser l'atelier autour d'un modèle unique convient généralement assez bien à un service, mais très peu aux autres.

Composable permettent de résoudre ce problème. Chaque service peut adapter l'application qu'il utilise dans le cadre de la gouvernance au niveau de la plateforme évoquée précédemment. Il n'est pas nécessaire de créer un ticket de personnalisation à chaque modification du flux de travail, car celle-ci s'effectue dans les limites déjà imposées par la plateforme. L'équipe dispose ainsi d'un système qui répond aux besoins de son travail, tandis que l'équipe centrale conserve la piste d'audit et le niveau de sécurité dont elle a besoin.

Considérez le temps de formation comme un indicateur clé de performance (KPI)

Le temps nécessaire à un nouvel opérateur pour atteindre un niveau de maîtrise adéquat permet d'évaluer dans quelle mesure le système est adapté au travail à effectuer. Si les nouveaux opérateurs ont besoin de trois semaines à un poste avant de pouvoir le gérer sans supervision, cela signifie que le système laisse à la mémoire de l'opérateur des tâches que l'interface pourrait accomplir à sa place. Ce qui permet de raccourcir cette courbe d'apprentissage, ce sont des flux de travail numériques guidés qui intègrent la prochaine étape à suivre directement sur l'écran de l'opérateur. Une formation théorique plus poussée en amont ne suffit généralement pas à elle seule à combler ce déficit.

Prenons l'exemple de la division Implants Dentsply. Grâce à un système Tulip, conçu pour prendre en charge plus d'un milliard de combinaisons de kits, l'équipe a réduit de 75 % le temps de formation des nouveaux opérateurs par rapport à leur ancien processus de travail. Cette amélioration tient au fait que le système se charge désormais d'une grande partie du travail que l'opérateur devait auparavant mémoriser. Vous pouvez découvririci l'intégralité du récit sur l'adoption de Tulip Dentsply.

Planifiez les déploiements sur plusieurs sites en tenant compte des variations dès le premier jour

L'erreur la plus courante lors d'un déploiement multisite est le « clonage » du deuxième site. Le déploiement du premier site se déroule sans encombre ; l'équipe utilise alors ce déploiement comme modèle, et le deuxième site hérite d'un processus qui ne lui convient pas. L'équipe chargée du déploiement passe ensuite l'année suivante à adapter le premier site pour qu'il puisse gérer les problèmes mis en évidence par le deuxième site.

Concrètement, anticiper la diversité implique de limiter la taille du noyau central et de veiller à ce que la couche de configuration au niveau du site soit suffisamment flexible. Moins il y a d'éléments qui doivent être identiques d'une usine à l'autre, plus il est facile de mettre en service chaque nouveau site, et moins l'équipe chargée du déploiement aura à apporter de modifications a posteriori lorsque le deuxième site mettra en évidence une fonctionnalité que le premier site assurait implicitement.

Stanley Black & Decker en Stanley Black & Decker un excellent exemple. L'entreprise utilise Tulip 2018, et le Stanley Production System (SPX) est passé d'une initiative limitée à un seul site à un cadre mondial reliant plus de 50 usines et plus de 1 000 applications.

Au fil des années, à mesure que l'équipe de Stanley développait et perfectionnait son Tulip , elle a constaté une réduction des stocks de plus de 2 milliards de dollars, une amélioration de 15 points du niveau de service, ainsi que des progrès durables en matière de qualité et de sécurité. La clé pour favoriser l'adoption de la solution sur l'ensemble des sites a consisté à maintenir un noyau central global restreint, tout en laissant aux sites locaux la flexibilité nécessaire pour prendre en charge les divers environnements, produits et processus qui composent le portefeuille de Stanley.

MES qui réussissent présentent généralement une architecture commune : composable que l'équipe peut modifier sans avoir à ouvrir de ticket informatique, un petit noyau global que chaque site peut configurer sans avoir à créer de variante du modèle, et une couche de données qui offre au personnel de terrain la même visibilité en temps réel que celle dont bénéficient les superviseurs.

La plupart des difficultés d'adoption qui surviennent à mesure qu'une solution se déploie trouvent leur origine dans les choix architecturaux effectués dès le départ. La question la plus pertinente à aborder lors de votre prochain entretien avec le fournisseur est de savoir ce que l'architecture facilitera six mois après la mise en service, et ce qu'elle rendra difficile.

Si vous vous demandez comment évaluer ou mettre en place un MES opérateurs, MES services et MES sites,n'hésitez pas à contacter un membre de Tulip . Nous accompagnons les fabricants multi-sites précisément dans ce type de décision.