Point de vue logique de l’architecture

L’architecture logique d’un ERP a les traits caractéristiques suivants (Jean-Michel Tysebaert, 2001) :

– construit autour d’un SGBD unique,

– offre des ensembles de traitements regroupés par métiers dans des modules,

– met à disposition des structures de données caractérisant les différentes ressources, – possède un système de contrôle de cohérence pour fixer des conditions de lancement des

traitements.

Nous reprenons ci-dessous chacune de ces caractéristiques.

Dans le but d’intégrer correctement les informations, les architectures d’ERP sont toutes construites autour d’un Système de Gestion de Bases de Données (SGBD). Ce SGBD a la charge d’une ou de plusieurs bases de données, en relation étroite avec le reste de l’application. La plupart des gros ERP offrent des adaptations aux bases les plus répandues du marché, ils sont dits « multibases ».

Un module est un sous-système de l’ERP qui remplit une fonction de haut niveau. Plusieurs modules sont en général mis à disposition et le périmètre fonctionnel couvert par l’application est relatif aux modules mis en service. Les modules peuvent être classés en trois domaines distincts :

– Le domaine métier est constitué d’un série de modules remplissant les fonctions des processus qui sont situés sur la chaîne de valeur de l’entreprise : des commandes à la livraison en incluant les achats et la facturation client. C’est le territoire intérieur à l’en- treprise où les flux d’information sont directement corrélés aux activités de production et de logistique. S’il s’agit d’une entreprise manufacturière, par exemple, nous parlerons de modules de gestion des achats, de gestion de production, de gestion des stocks, etc. – Le domaine du pilotage est constitué de modules dédiés à l’analyse et à la synthèse du

fonctionnement du système entreprise. Il peut s’agir de facilités d’accès à des prévisions, d’évaluation de performance, de consolidation des activités... Les activités financières et comptables, la relation client, les tableaux de bord du contrôle de gestion font partie de ce domaine.

– Le domaine du support prend en charge l’administration du système informatique. Ce domaine couvre l’ensemble des fonctionnalités permettant d’entretenir la structure de données et de modifier les paramètres de configuration de la solution logicielle.

Jean-Michel Tysebaert (2001) dresse un inventaire des principaux domaines d’activités de l’entreprise : la gestion commerciale, la gestion de production, la logistique des ventes et celle des achats, la gestion des stocks, la gestion des ressources humaines, la comptabilité, le contrôle de gestion et les finances. Pour chaque domaine, il utilise deux modes de représentation : une représentation externe et une représentation interne de l’entreprise, suivant différents niveaux de granularité (que nous présentons un peu plus loin). La représentation externe situe le fonctionnement de l’entreprise par rapport aux acteurs de son environnement. Par exemple, le client « achète » des produits à l’entreprise. La représentation interne détaille les traitements à effectuer au sein de l’organisation. Par exemple, l’acte de vente du produit à ce client induit un certain nombre de traitements : identifier le client, valider la référence produit, livrer le produit, facturer le produit, transférer ces informations à la comptabilité...

Les processus, ici la logique des traitements de l’information répartis dans différents modules, utilisent (en création, modification et suppression) un ensemble d’informations. Ces infor- mations sont régies par une structure de données particulière, souvent appelée référentiel de données. Cette structure caractérise les différentes ressources de l’entreprise. Ces ressources sont les moyens humains, matériels et financiers de l’entreprise. Par exemple, pour un calcul des besoins, nous allons utiliser les informations sur les machines (capacité, rendement, ...) et les produits (nomenclature, gamme, qualité, ...) afin de faire des propositions de planification des achats de composants, ou de lancement des opérations de production. Partant du principe qu’on ne peut pas transformer ce qu’on a mal décrit, les capacités de traitement de l’infor- mation sont dépendants de la nature et du type de l’information disponible. Le concept de granularité de l’information fait référence à ce degré de perception de la réalité. On ne peut pas gérer de la même façon selon que l’on a accès, par exemple, à une représentation des stocks à l’échelle d’une palette, d’un colis ou d’une référence produit.

Le système de gestion de la cohérence de l’information a plusieurs rôles. Un premier rôle, le plus simple, est la vérification des informations saisies et du type de ces informations (date, chaîne de caractère, numérique) par rapport au référentiel de données. Un deuxième rôle, plus complexe, est la vérification du bon usage de cette information par les différents acteurs métier. Une même information sera utilisée par plusieurs modules dans des traitements différents. Le système de gestion de la cohérence est chargé de signaler une incohérence lors d’un traitement. Pour cela, il dispose d’un jeu de conditions préliminaires à chaque traitement, qu’il va vérifier. En cas de problème, il peut être utile de proposer à l’utilisateur des pistes de diagnostic afin de poursuivre son travail. Par exemple, dans l’exécution du traitement « calcul du besoins », il est possible que le niveau de stock des produits soit mal saisi (stock négatif) ou soit omis (information manquante), dans ce cas un message explicite doit être produit. Notons qu’un moteur de workflow, qui désigne la prise en charge automatisée des processus par l’ordinateur, peut être considéré comme faisant partie de ce mécanisme de gestion cohérente, puisqu’il fixe des relations d’ordres partiels dans le traitement des tâches.

Pour prendre connaissance de l’architecture logique d’un ERP, il faut donc au minimum : – avoir étudié le référentiel de données,

– pour chaque module, savoir accéder aux traitements disponibles en fonction du besoin exprimé à différents niveaux de granularité de l’information, et appréhender le fonction- nement et les règles du système de gestion de cohérence.

Notons que pour les applications majeures du marché de l’ERP, telles que SAP R/3 ou Oracle Applications, il est impossible pour une personne seule d’atteindre ce seuil de connaissance

62 CHAPITRE 5. ARCHITECTURE D’ERP

minimum. C’est une intégration par un travail d’équipes avec plusieurs spécialistes qui amènera à la couverture requise du périmètre fonctionnel.

Peu de références dans la littérature fournissent des détails suffisants pour faire de l’auto- apprentissage sur cette architecture logique sur un produit ERP donné. Pour illustration, nous renvoyons le lecteur au handbook de Campus Press sur SAP (SAP, 1999). En plus de 1 200 pages de texte, vous ne pourrez pas reconstruire la structure de données, même au niveau des besoins d’un module. Le contenu, extrêmement intéressant, laisse in fine une impression de survol du sujet !

Il y a donc dans cet état de fait un élément clé de notre raisonnement, comment mener efficacement le travail de l’architecte sur le point de vue fonctionnel en se trouvant limité par la connaissance sur le point de vue logique ? Comment concevoir un référentiel sur lequel se baser pour avoir accès à cette connaissance ?