Dans la session d’aujourd’hui, nous allons nous intéresser à des termes un peu barbares comme « cartographie applicative » ou « urbanisation », mais qui sont des termes assez usuels dès que l’on parle de système d’information.
Le MES appartient à ce que l’on appelle généralement le système d’information industriel.
Au sein du système d’information, on peut parler de « cartographie applicative », qui décrit la couverture de chaque application dans le système d’information, ou parler d’urbanisation. La notion de cartographie donne une vision statique du périmètre des différentes applications, tandis que l’urbanisation se place plutôt dans une vision dynamique d’évolution du système
Ceux qui ont pu voir l’émission d’introduction de cette série se souviennent certainement de ce diagramme. Il montre la place centrale du MES et du MOM au sein du système d’information industriel que l’on peut considérer suivant trois axes :
- L’axe de la valeur ajoutée, allant des fournisseurs aux clients avec des applicatifs comme les SRM (Supplier Relationship Management) et les CRM (Customer Relationship Management).
- L’axe du cycle de vie produit, allant du design à la maintenance, avec des applicatifs comme les CAO et les outils de PLM
- L’axe de l’entreprise, allant de la production au business avec les applicatifs La couche métier représente la partie normalement la plus stable du modèle.
Le MES et le MOM se situent au croisement de ces trois axes, et ces applicatifs sont amenés de plus en plus à dialoguer avec tous ces autres outils, sans oublier les logiciels d’infrastructure collaborative comme les applicatifs BPM (Business Process Management).
d’information, que ces évolutions aient une origine technologique, stratégique ou métier.
Si l’on s’en réfère à Wikipédia, l'urbanisation du système d'information d’une entreprise consiste à faire évoluer son système d'information (SI) pour qu'il soutienne et accompagne de manière efficace et efficiente les missions de cette entreprise et leurs transformations.
Cette démarche va nous aider à voir comment le MES peut s’insérer de manière optimale dans le système d’information industriel.
Dans ce contexte, voyons quelle peut être la démarche d’urbanisation.
Le Cigref (Club informatique des grandes entreprises françaises) propose un modèle en 4 couches. Dans la plus haute de ces couches, le modèle traduit la stratégie de l’entreprise, c’est le niveau métier.
Juste au-dessous, le niveau fonctionnel traduit le système d’information de l’entreprise et son organisation.
Au niveau inférieur ou niveau application, on trouvera les composants applicatifs du système informatique.
Enfin au niveau technique, on trouvera l’infrastructure technique (ordinateurs, serveurs, réseau).
L’évolution de ce niveau technique peut faire évoluer le modèle. C’est d’ailleurs une cause majeure de la démarche d’urbanisation. Ces évolutions technologiques, l’entreprise peut bien sûr les subir ou les anticiper.
Ce qui va permettre de garder la cohérence entre ces différentes couches, c’est un ensemble de référentiels forts : des règles d’urbanisation, des normes, des règles de gestion.
La couche métier représente la partie normalement la plus stable du modèle.
Pour une entreprise de manière générale, les processus fondamentaux vont s’organiser autour des processus d’achat, de commerce et de vente.
Pour une entreprise industrielle, ces processus vont par exemple se décliner de la manière suivante : conception des produits, puis dans le cycle de production approvisionnement des matières premières, production et stockage des produits finis, commercialisation directe et distribution.
A ces processus vont s’ajouter des processus transversaux de contrôle, de maintien et de gestion des ressources humaines et techniques, de communication.
Tous ces processus ne se déroulent pas nécessairement sur le site de production. Le périmètre usuel d’un site de production est indiqué ici en mauve.
Pour définir la couche fonctionnelle, nous allons procéder en plusieurs étapes.
Il faut tout d’abord définir les domaines concernés. Pour un MES par exemple, ces domaines seront le contrôle de la production, en lien avec la gestion de l’entreprise.
Puis nous définirons les fonctions de ces domaines, de façon si possible exhaustive.
Cela nous permettra d’identifier les fonctions qui sont concernées, soit parce que les autres fonctions ne sont pas pertinentes dans un premier temps, soit parce qu’elles sont déjà traitées par d’autres applicatifs. Cela va nous permettre de définir le périmètre du système MES.
Une étape importante est la détermination des flux d’information concernés, qui vont impliquer des échanges au sein de l’applicatif MES, mais aussi avec d’autres composants applicatifs.
Ces flux d’informations vont être classés en catégories d’information, par exemple informations sur les matières, sur le personnel, sur le procédé, lesquelles vont conduire à des définitions de l’information.
Ces informations vont être échangées au sein du logiciel MES, mais aussi avec les autres logiciels du système d’information de l’entreprise. Nous allons voir les problèmes que cela peut poser au niveau des couches techniques et applicatives.
De manière assez classique, les nécessités croissantes d’échanges entre des applicatifs conçus indépendamment les uns des autres conduisent au développement au cas par cas d’interfaces entre les logiciels. Le nombre de ces interfaces croit avec le nombre de combinaisons possibles entre les différents applicatifs, chacune d’elles ayant de fortes dépendances avec les composants applicatifs mis en relation. Dès qu’un applicatif évolue, l’ensemble des interfaces concernés doit également évoluer, entrainant des charges importantes sans valeur ajoutée. C’est l’effet « plat de spaghettis » ou « sac de nœuds ».
Pour limiter l’impact d’une modification d’un des composants applicatifs, on se donnera dans l’urbanisation un objectif de cohérence forte / couplage faible, c’est à dire que les informations entretenues au sein des applicatifs soient cohérentes entre elles, mais que cette cohérence entraine le moins de dépendances possibles entre les logiciels. Nous verrons que cet objectif sera grandement facilité par les normes et les standards.
Pour orchestrer les échanges entre les composants applicatifs, on peut se focaliser soit sur les données, soit sur les processus. On fera ainsi intervenir deux types d’outils qui s’avèrent souvent complémentaires.
Nous verrons également que pour limiter le nombre des interfaces, on pourra s’orienter vers une architecture orientée services.
Quand on parle de cohérence forte et de couplage faible entre deux applicatifs, l’objectif est que chacun de ces applicatifs puisse évoluer indépendamment l’un de l’autre, tout en préservant la cohérence de fonctionnement de l’ensemble. A l’extrême, l’applicatif B pourrait être remplacé par un applicatif C de même périmètre fonctionnel sans compromettre le fonctionnement d’ensemble. C’est évidemment un idéal. Voyons les conditions nécessaires pour s’en approcher :
Tout d’abord, la communication de bas niveau entre les composants applicatifs nécessite une couche que l’on pourra appeler physique et transport. Aujourd’hui, cette couche est celle qui pose le moins de problèmes avec comme référentiels des standards de fait issus des technologies Internet très largement diffusés.
Le niveau supérieur d’échange est le niveau que l’on pourra appeler syntaxique, qui permet d’isoler les différentes données et objets échangés. Par exemple, OPC permettra d’échanger des données en temps réel entre les applicatifs SCADA et MES d’une part, et les composants d’automation (automates programmables, entrées/sorties) d’autre part, de manière indépendante des constructeurs. ODBC et JDBC permettront de stocker des données en bases de données, qu’il s’agisse de bases Oracle, Microsoft, ou IBM. SOAP, dans une architecture orientée services sur laquelle nous reviendrons, permet de définir des échanges standardisés entre deux services Web. La syntaxe B2MML décline le langage XML dans le contexte de l’ISA-95, etc.
Mais cela n’est pas suffisant, pour pouvoir agir de manière cohérente, deux composants applicatifs doivent également partager un référentiel sémantique. Savoir, par exemple, ce qu’est un ordre de fabrication, une matière première, ou un client. Les questions sémantiques sont rarement triviales, et la cohérence sémantique est essentielle pour la cohérence du système d’information. Par exemple, tel composant applicatif pourra appeler « client » une société qui est entrée en contact en vue d’acheter, et tel autre ne qualifiera de « client » que celle qui a déjà acheté. Les processus de traitement de ces deux cas peuvent être complètement différents.
Des standards comme l’ISA-95, que nous avons déjà vu dans l’émission d’introduction, sont essentiels comme référentiel de définition des objets manipulés par les composants applicatifs, et des relations entre ces objets.
Pour les échanges d’informations entre deux composants applicatifs, deux orientations sont possibles, une orientation « données » ou une orientation « applications ». Deux classes d’outils qui représentent ces deux approches sont les ETL et les EAI.
L’ETL, pour Extraction Transform Load, est une architecture orientée données, le plus souvent utilisée pour générer des entrepôts de données pour le décisionnel. L’ETL va puiser dans les bases de données des applicatifs tels que l’ERP, le MES, ou le LIMS pour garnir un entrepôt de données dont la structure est optimisée pour le décisionnel (Cube OLAP, technologies Big Data).
L’ETL fonctionne généralement sous forme de batch pour un traitement massif de données. Son flux est unidirectionnel et il sera essentiellement utilisé pour le décisionnel.
L’EAI, pour Entreprise Application Integration, est une architecture orientée applications, qui permet à des applications hétérogènes de communiquer en orchestrant le workflow qui les unit.
Son fonctionnement est événementiel et il va gérer un flux bidirectionnel. Si, plutôt qu’un système BI, on envisage le cas d’un applicatif PLM, on pourra mettre en place un EAI (ou un ESB, pour Entreprise Service Bus) pour orchestrer les échanges entre ces différents logiciels.
Le tableau à l’écran résume les caractéristiques de ces deux approches d’outils. En réalité, ils sont beaucoup plus complémentaires que concurrents. Dans la mesure où les techniques ETL sont unidirectionnelles et s’adressent presque exclusivement au BI (c’est à dire au décisionnel), l’urbanisation du système d’information va nécessairement passer par la mise en place d’EAI ou d’ESB.
La plupart des EAI ou ESB ont une architecture orientée services (Service Oriented Architecture) dont nous allons voir l’intérêt.
Les architectures orientées services ou SOA (Service Oriented Architecture) se sont diffusés avec l’essor des sites web, exigeant le dialogue entre plusieurs sous-systèmes : un serveur web, une ou plusieurs bases de données (clients, produits), et un ou plusieurs applicatifs métier : gestion d’un catalogue, gestion de commandes en ligne, systèmes de paiement.
Aujourd’hui, les démarches d’urbanisation des systèmes d’information vont toutes dans le sens des architectures SOA. Pour voir l’intérêt de ces architectures, nous allons prendre l’exemple de mise en œuvre d’un MOM (Manufacturing Operation management).
Comme nous l’avons vu auparavant, le MOM a un périmètre plus large que le MES. Il recouvre non seulement la production, mais également la qualité, la maintenance et la logistique. Dans la pratique, on ne trouvera pas l’ensemble des fonctions de ces quatre domaines dans le même applicatif. Un même éditeur pourra éventuellement fournir une suite couvrant ces domaines, mais ce ne sera pas un composant applicatif d’un seul tenant, ce qui est sans doute mieux pour l’industriel. Le plus souvent, nous aurons des logiciels distincts pour ces différents domaines, par exemple un MES pour la production, un LIMS pour la gestion de la qualité, une GMAO pour la gestion de la maintenance et un WMS pour la gestion de la logistique.
Bien évidemment, des échanges sont nécessaires entre ces différents composants applicatifs, qui présentent même peut-être des recouvrements sur certaines fonctions. Les flèches pleines représentent les échanges essentiels, les flèches en pointillés les échanges de moindre importance. Selon le métier, cela peut varier et les échanges peuvent être plus ou moins critiques.
Si l’on développe des interfaces de manière traditionnelle entre les composants applicatifs, on voit que l’on va être amené à développer 6 interfaces différentes entre ces composants applicatifs, et que 3 interfaces seront à revoir ou à redévelopper lors de l’évolution d’un composant applicatif.
Dans une architecture orientée services, chaque composant expose ses fonctions au travers d’un service, dont l’interface unique est définie par le référentiel, et donne accès à toutes les fonctions du composant, comme on peut le voir sur la figure. 4 services d’interface (au lieu de 6 interfaces spécifiques) sont à développer, mais surtout un seul service est à adapter en cas d’évolution d’un des composants applicatifs.
Pour mettre en œuvre la démarche d’urbanisation, voyons quelles sont les principales étapes.
La démarche d’urbanisation part naturellement d’un existant, en termes d’architecture métier, d’architecture applicative et d’architecture technique.
Comme l’urbanisation n’est pas instantanée, mais s’inscrit dans le temps, l’entreprise va évoluer. Par exemple, l’entreprise compte développer sa gamme de produits Bio qui vont passer par de nouveaux canaux de distribution, ou développer ses ventes par Internet. La stratégie de l’entreprise va alors amener à une architecture métier cible.
Pour assurer cette architecture métier cible, nous aurons besoin d’un certain nombre de fonctions, déjà existantes dans les applications actuelles ou nouvelles. On déterminera alors une architecture fonctionnelle cible.
Celle-ci, à son tour, va déterminer l’évolution de l’architecture applicative existante vers une architecture applicative cible, ainsi que l’évolution technique existante vers l’architecture technique cible.
Un petit résumé de ce que nous avons vu dans cette session très riche.
D’abord un rappel, le MES n’est pas seul, mais est au cœur d’un système d’information industriel de l’entreprise, qui fait lui-même partie du système d’information général de l’entreprise.
Nous avons présenté un modèle en 4 couches qui permet de prendre en compte à la fois les évolutions stratégiques de l’entreprise, et les évolutions technologiques.
En entrant dans le détail, nous avons vu comment déterminer le périmètre fonctionnel d’un applicatif et définir les informations manipulées.
Puis nous nous sommes intéressés aux différentes approches d’échange entre composants applicatifs, et aux outils de type ETL ou EAI, en montrant l’intérêt d’une architecture orientée services, en particulier pour le MES et le MOM.
Enfin nous avons vu les principales étapes d’une démarche d’urbanisation
ORDINAL Software - Siège