Un projet MES suppose le plus souvent la collaboration de plusieurs personnes, voire de plusieurs équipes. Chez l’industriel, le responsable du projet MES sollicitera souvent les opérateurs pour la définition du cahier des charges, en particulier en matière d’ergonomie.
Pour la réalisation du projet, qu’elle soit confiée à une équipe interne ou à un intégrateur, il faudra le plus souvent disposer de compétences multiples, qu’il faudra amener à collaborer efficacement.
Historiquement, les premiers systèmes de MES ont été associés à des procédés fortement manuels, poussés par des exigences de qualité comme dans la pharmacie, ou par des exigences de productivité dans les industries à fort taux de main d’œuvre.
Ensuite, ayant démontré leur intérêt, les systèmes MES se sont aussi diffusés sur des procédés automatisés, mais avec une saisie manuelle des informations. Globalement, on reste donc dans le cadre d’un système informatique classique.
Mais l’exigence de fiabilité des informations collectées, ainsi que la nécessité d’éviter d’introduire des charges supplémentaires pour les opérateurs, conduisent à collecter en temps réel les informations du système MES sur les automatismes, comme nous l’avons vu dans les émissions précédentes.
La conséquence directe de ce dernier point est que des compétences d’automatismes qui n’étaient jusque-là pas requises deviennent nécessaires. Ces compétences ont souvent un profil différent de celui des informaticiens.
Il est intéressant de comparer les profils typiques des informaticiens et des automaticiens.
Commençons par l’automaticien…
Pour un automaticien, l’essentiel est que le processus de production s’exécute comme prévu, il aura donc un focus sur le process.
Historiquement, les automatismes ont pris la succession des relais électriques, et cela se ressent fortement dans les langages d’automatismes, comme le langage contact, et de manière générale un formalisme graphique proche du physique.
Assez lié aux langages qu’il utilise, l’automaticien a généralement une exigence de simplicité : il sera rebuté par une algorithmique trop complexe, et va privilégier des méthodes simples. C’est souvent une grande qualité, et parfois cela peut être aussi un handicap : l’emploi des temporisations par exemple, solution simple, plutôt qu’un protocole d’acquit d’exécution plus complexe peut rendre une programmation difficilement transposable d’une installation à une autre.
Tout autant que l’industriel lui-même, ou le mécanicien, l’automaticien place très haut la fiabilité d’un système matériel ou logiciel. C’est pour cette raison que le PC, ou le système Windows, ont à une époque été considérés comme inadaptés à l’informatique industrielle.
Enfin, proche des machines qui fonctionnent souvent à des cadences élevées, l’automaticien (tout comme l’opérateur) a une exigence forte sur la rapidité des temps d’exécution.
Passons maintenant à l’informaticien…
Il est rare que l’informaticien connaisse précisément le process. Il sera plutôt focalisé sur les données et les calculs.
Il va d’ailleurs être largement aidé en cela par les langages qu’il utilise, qui permettent de faire des calculs bien plus aisément que les langages d’automatismes. Certains informaticiens utiliseront des langages connus des automaticiens comme le Basic, mais la plupart utiliseront des langages plus évolués comme Java ou JavaScript, ou C#.
L’informaticien est habitué aux structures complexes, qui ne l’effraient pas. Là aussi, cela peut être un avantage si la gestion de cette complexité est réellement nécessaire, ou un inconvénient si elle est superflue et va rendre difficile la validation.
Il est clair qu’un bug, voire un blocage, sont beaucoup plus admissibles pour un informaticien que pour un automaticien. Les systèmes bureautiques l’illustrent tous les jours, même s’il faut reconnaître que les problèmes sont de moins en moins fréquents.
Enfin autant les ressources réduites des automates exigent en quelque sorte de faire un code efficace, autant les quantités de mémoire et de disque disponibles sur un PC font que la compacité du code et sa performance passent souvent au second plan. Le problème est d’ailleurs amplifié par le fait que les programmes informatiques utilisent souvent des logiciels tiers (progiciels et bases de données) dont dépend beaucoup la performance du programme développé par l’informaticien.
En résumé, on voit bien que la mise en place d’un système MES va mettre en contact des populations de cultures très différentes.
Heureusement, on constate une convergence de ces deux profils. Mais elle se réalise à petits pas
Ce qui progresse...
- Depuis plusieurs années déjà, l’apprentissage des langages informatiques a été intégré aux cursus d’automatismes. L’informatique n’est plus tout à fait étrangère aux
- Certains intégrateurs ont mis en place un travail en “plateau projet” où se trouvent rassemblés automaticiens et informaticiens, ce qui favorise bien sûr le partage de compétences.
- Les progiciels MES paramétrables sont de plus en plus nombreux, et leur mise en place n’exige pas de connaissances informatiques poussées.
- Enfin, longtemps étrangers au monde de l’informatique, les logiciels d’automatismes ont presque tous introduit la notion d’objet et leur programmation se rapproche des grands langages informatiques, presque tous dérivés du C++.
Si cette convergence est assez lente, c’est qu’il reste quelques freins...
- Concernant les langages, il faut reconnaître que si les automaticiens maîtrisent mieux l’informatique, les informaticiens ne maîtrisent pas beaucoup mieux le process : il est rarissime qu’un informaticien connaisse l’utilisation des environnements de développement d’automatismes.
- Si les équipes mixtes sont une bonne solution, il est difficile de dégager plusieurs ressources pour des projets de faible envergure, il faudrait alors pouvoir disposer de ressources réellement polyvalentes.
- Les progiciels MES paramétrables mettent incontestablement la mise en place accessible à un automaticien, sans nécessité de compétences informatiques fortes. Mais si on sort du cadre donné par le paramétrage, suivant le logiciel le passage au codage informatique sera rendu nécessaire de façon plus ou moins
- Un dernier point est plus culturel. Chez certains intégrateurs, la pratique est de séparer automatismes et supervision, et a fortiori MES, en deux sous-projets totalement distincts. Si cette pratique trouve son bien-fondé dans la responsabilité vis-à-vis des développements et une affectation plus simple des ressources, elle prive souvent d’une vision globale et va privilégier les choix techniques limitant les échanges entre les deux systèmes, ce qui n’est pas toujours optimal.
Automaticiens et informaticiens, en collaborant efficacement, vont assurer le succès technique du projet, c’est à dire que les fonctions techniques prévues soient assurées. Mais cela sera-t-il suffisant pour que le projet MES soit un succès ?
En fait, en se focalisant uniquement sur la technique, on risque de passer à côté d’un groupe important, les opérateurs.
En effet, il faut être conscient qu’un système MES va souvent amplifier les exigences qui portent sur les
opérateurs : renseignement d’informations supplémentaires, respect d’un ordre précis d’exécution, etc.
Un autre élément est que les opérateurs détiennent un savoir-faire important sur les processus de fabrication, souvent non formalisé. L’ignorer, c’est courir le risque que le processus de fabrication une fois le MES installé ne soit pas optimal, voire même qu’il conduise à des blocages.
Pour éviter cela, il est prudent d’impliquer les opérateurs au stade de la rédaction du Cahier des Charges : à la fois en informant les opérateurs des processus prévus pour recueillir leurs commentaires, et pour définir l’ergonomie. Sur ce dernier point, la reconduction d’une ergonomie antérieure peut être envisagée, mais ce n’est pas la panacée : d’une part il se peut que cette ergonomie ne soit que partiellement adaptée, d’autre part il est probable qu’une ergonomie ancienne ne permette pas de tirer parti de technologies plus modernes. Les opérateurs ont l’esprit souvent plus ouvert qu’on ne le croit, à condition que cela serve leur travail.
Pour toutes ces raisons, le transfert de compétences de l’intégrateur vers l’utilisateur final est essentiel, pour que ce dernier soit le moins dépendant possible pour faire évoluer son installation, alors que les ressources de l’intégrateur pourront être mobilisées sur d’autres projets.
On a parfois tendance à l’oublier, mais la vie du MES ne se termine pas avec son projet de mise en place. Le MES s’inscrit dans une démarche d’amélioration.
Continuer à améliorer la qualité, la productivité, va mettre en jeu de nouveaux indicateurs, et nécessiter de nouvelles données. Pour cela, des paramétrages, voire des développements supplémentaires sur le système MES vont être nécessaires.
L’industrie évolue elle aussi. Pour conforter et développer son marché, l’industriel va lancer de nouveaux produits, qui vont peut-être nécessiter des évolutions de l’installation, et des évolutions au niveau des automatismes et de l’exécution.
Mais il faudra aussi maintenir une « cellule MES », bien sûr moins importante que l’équipe projet initiale, mais mettant en jeu également automaticien, intégrateur et utilisateur pour assurer l’évolution du système dans de bonnes conditions.
Un petit résumé de ce que nous avons vu dans cette session.
Tout d’abord, nous avons vu le MES a contribué progressivement à faire collaborer deux profils de compétences
: automaticien et informaticien, qui ont des cultures assez différentes.
Ces cultures tendent à converger, mais il y a quelques freins qu’il importe de maîtriser pour assurer le succès du projet MES.
Un autre groupe humain est essentiel pour la réussite, les opérateurs, qu’il est souhaitable d’impliquer tout au long du projet.
Et après le projet, pour que le MES continue à délivrer ces bénéfices, ces différentes compétences devront rester présentes au sein d’une cellule MES
