Représentations architecturales

Dans cette section, nous illustrons par quelques exemples simples des représentations sur l’architecture logique et l’architecture physique d’un ERP.

5.2.3.1 Point de vue logique de l’architecture

La figure 5.1 décrit un processus invoquant plusieurs modules d’un ERP. Nous retrouvons, aussi bien, des domaines verticaux (métier) avec :

– la gestion des ventes : saisie et enregistrement des commandes,

– la gestion de la relation client : suivi de l’état d’avancement d’une commande au niveau de la livraison et de la facturation,

que des domaines transversaux (support et pilotage) avec :

– la gestion des données techniques : définition des produits et des procédés par des infor- mations utilisées dans les modules métier,

– le domaine d’administration du système : gestion des utilisateurs, gestion du paramé- trage...

Chacun des modules remplit une fonction particulière qui lui est propre. L’ensemble conduit à gérer la vente d’un article à un client, et à recevoir en contrepartie un paiement enregistré dans la comptabilité... Le processus se met en œuvre par une série de manipulations des acteurs

64 CHAPITRE 5. ARCHITECTURE D’ERP

Fig. 5.1 – Représentation macroscopique du processus sur l’architecture logique

métier sur cette suite de modules dans un sens déterminé par les flèches qui symbolisent le flux d’informations entre les fonctions (entrée, sortie).

Cette représentation permet de préciser les modules éligibles et leur interaction pour la réali- sation d’un travail donné. Elle définit le périmètre de l’application nécessaire pour le processus concerné. Elle est très orientée vers les fonctions, mais ne laisse pas de place aux utilisateurs, à leur logique de travail propre, aux documents produits, et même à la description plus détaillée des informations nécessaires pour chacune des fonctions. C’est pourtant le cœur même de la logique de fonctionnement de l’entreprise qui repose sur une notion de scénario où le processus est « mis en scène » au moyen de l’ERP. La représentation de la figure 5.1 est donc complétée par la représentation graphique de la figure 5.2. On y retrouve les éléments suivants :

– les événements déclencheurs des activités (réception devis, réception offre, validation...), – les activités au cœur du processus (devis, offre de prix, commande...),

– les documents générés par chacune des activités (édition devis, édition commande, édi- tion journal...),

– les informations utilisées ou produites par une activité (article, transporteur...),

– les acteurs intervenant dans chacune des activités par les rôles prévus dans l’application (administration des ventes, logisticien, comptable...).

À ce stade de définition, l’utilisation de l’ERP pour implanter le processus est suffisamment complète. C’est donc bien une modélisation de processus calquée sur la connaissance de l’ar- chitecture logique qui sert de base à la transition du point de vue fonctionnel au point de vue logique. Mais cette représentation dépasse le périmètre strict de la logique applicative pour intégrer l’environnement immédiat : acteurs, événement externe, document, ...

Cette approche a été reconnue depuis quelques années et a été appliquée avec succès à quelques cas. Elle est mise en œuvre par deux voies principales :

– les éditeurs d’ERP ont développé des modèles de référence de leur application. Il s’agit en général d’une base de données qui contient des représentations graphiques des diffé- rents traitements disponibles. Il est possible de les assembler sur une palette graphique, puis de les modifier afin de créer les interactions entre les traitements, et les modules. La sémantique du langage utilisé pour cet assemblage est plus ou moins évoluée selon

les éditeurs. Il n’y a pas de normes sur les modèles de référence permettant de s’af- franchir de l’aspect propriétaire. En phase de sélection du projet ERP, il faudrait donc théoriquement bâtir autant de modèles qu’il y a de candidats.

– Les éditeurs du marché de la modélisation des processus ont naturellement un rôle à jouer dans cette approche. Chaque éditeur propose un langage propre pour décrire les processus d’entreprise. En général, la sémantique de ces langages est plus puissante que celle utilisée nativement pour les modèles de référence dans les ERP. Partant de ce capital de connaissances, ils proposent de l’utiliser à des fins de définition, puis de maintenance du Système d’Information. Des fonctions spéciales sont développées pour trouver les relations entre ce modèle et celui de référence d’un ERP particulier. Mais les lois du marché et les contraintes économiques sont telles que seul SAP est présenté comme un partenaire dans ce cadre. Nous n’avons pas trouvé trace de développement couvrant une gamme de produits plus large...

Il y a donc un manque d’universalité dans la mise en œuvre de la démarche lorsqu’on prend la position du maître d’ouvrage et que l’on souhaite connaître et mesurer le potentiel d’une solution ERP donnée.

Il nous semble tout à fait intéressant, sur le plan académique, de pousser l’étude pour déter- miner de manière claire le pouvoir d’expression requis pour le langage de modélisation, qui dépasse peut être un simple modèle de processus. Mais le choix d’une représentation reste délicat car il est guidé par deux positions antagonistes :

– dans l’optique d’un dialogue entre MOA et MOE cherchant la mise en correspondance de l’architecture fonctionnelle avec l’architecture logique, nous devons aborder la ques- tion de l’acceptation de ce langage par les deux parties présentes, comme un moyen de communication efficace (l’équivalent des plans de l’édifice produits en architecture). Ceci signifie que le modèle de référence de l’ERP doit pouvoir être traduit dans ce langage. – Dans un souci de respect de la cohérence entre le modèle de référence et l’application

proprement dite, le langage doit être aussi proche que possible des langages mis en œuvre dans les processus de développement du génie logiciel, et donc par les équipes en charge du développement et de la maintenance de l’application. Cette dernière contrainte a pour but de minimiser l’effort de gestion des versions (et des configurations d’une même version) du modèle de référence. Enfin, les mécanismes de gestion de connaissances permettant de passer du modèle du besoin au modèle de référence, et vice versa, doivent être imaginés.

5.2.3.2 Point de vue physique de l’architecture

La figure 5.3 représente un exemple d’architecture physique de type client/serveur. Le cylindre de droite représente le stockage des données sous forme d’un ensemble de base de données structurées par thème (client, article, besoins, commande, production, ...). La partie client (rectangle de gauche) représente des traitements pris en charge par le poste client (client lourd). Un accès direct aux bases de données concernées est matérialisé par des flèches dont le sens désigne s’il s’agit d’une extraction ou d’une écriture d’information. Placé au milieu, le poste serveur est chargé des traitements consommateurs de temps de calcul, comme un calcul des besoins en composants dans un MRP, par exemple. Cette figure n’illustre pas le cas où un module serait distribué pour partie sur le client et pour partie sur le serveur, mais il existe. Dans ce cas, il est nécessaire de faire apparaître la couche de présentation, la couche de logique de communication entre client et serveur, la couche de traitements (logique métier) sur le serveur.

66 CHAPITRE 5. ARCHITECTURE D’ERP

Fig. 5.3 – Architecture physique