Approche de modlisation et comprhension de la structure des ERP Typologie des Business Objects (Objets de Gestion)

Franois Blondel professeur associ lEcole Centrale de Lyon - directeur gnral Kardol SA

Rsum : Cet article a pour objectif de proposer et de dcrire une mthode de modlisation de larchitecture des donnes utilises dans un ERP qui vise augmenter lefficacit, la productivit, et la ractivit des diffrents intervenants (consultants, dveloppeurs, utilisateurs clients) dun projet de mise en place. La mthode propose a des fondements informatiques rappels au travers de lhistorique de la notion dobjet de gestion, mais utilise aussi des simplifications permises dans les projets de Business Process Reengineering que sont les projets ERP. La deuxime partie prsente globalement le cadre propos puis pour chacun des ensembles de classes, dcrit les classes principales dobjets de gestion et le lien avec les autres ensembles de classes, afin que larchitecture du modle soit perue dans sa globalit. En conclusion, on prsentera les diffrents avantages concrets attendus de lapplication de cette mthode au sein des projets dimplantation ERP. INTRODUCTION .............................................................................................................................. 2 I HISTORIQUE SUCCINCT DE LA NOTION DOBJET DE GESTION .................................... 2 II OBJETS DE GESTION DANS LOPTIQUE DE LA COMPREHENSION DE LERP GENERALITES.................................................................................................................................. 6 III LES DIFFERENTS ENSEMBLES DE CLASSES DOBJETS DE GESTION ........................... 8 IV- UTILISATION DE LA METHODE PROPOSEE ET AVANTAGES ...................................... 13 BIBLIOGRAPHIE ............................................................................................................................ 14

Franois Blondel septembre 2002

page 1

INTRODUCTION
Les ERP1 ont envahi la vie quotidienne des oprateurs dans les entreprises. Mais les ERP ont toujours un ct magique comme la messe en latin ou lalchimie. Mais linverse (suppos) de cette dernire ; ils ne transforment pas le plomb(linformation) en or (prendre la bonne dcision). Mes expriences dans ce domaine mont laiss limpression douloureuse quune partie de cette magie tait entretenue plaisir pour des raisons lucratives, une autre parce que le pouvoir dans le pass appartenait aux gourous . Plus concrtement, la recherche en gestion des vingt dernires annes a souvent confondu gestion et informatique. Des approches diverses, la plupart trs(trop) gnralistes ont t tentes avec plus ou moins de succs, cest dire de diffusion dans les socits de consulting et chez les clients utilisateurs des ERP. Les raisons en sont multiples. Peut tre est-il illusoire la date daujourdhui de vouloir rconcilier chercheurs, au niveau dabstraction lev, consultants mtier et utilisateurs finaux. Mais linverse des projets informatique en gnral , les projets ERP prsentent un certain nombre dinvariants. Ceux-ci permettent une approche plus cible et plus performante. Notre objectif est de rendre les consultants et dveloppeurs qui travaillent sur les ERP plus efficaces, donc moins chers , la fois dans les phases dapprentissage du produit, et dans les projets effectus pour leurs clients. Le moyen employ est de permettre au lecteur (consultant, dveloppeur, manager responsable dune fonction de lentreprise..) de gagner en efficacit, productivit, ractivit, en analysant la structure dun ERP Y par comparaison avec celle dun ERP X, ou par rapport au modle dcrit ci-aprs, partant du constat que lefficacit dune personne passer dun ERP un autre est largement conditionne par la perception de lERP par cette personne. Dans la suite, nous allons dans une premire partie rappeler ltat de lart, cest dire noncer certains des apports de la recherche en informatique linformation pour la gestion. Puis, nous tenterons de fournir une grille danalyse des ERP, au travers de sa structure (le QUOI) et des actions possibles(le COMMENT). Celleci sappuiera sur deux concepts, celui dobjet de gestion et celui de processus. Ce premier article se limitera la dfinition du QUOI2, cest dire de la structure dun ERP.

I HISTORIQUE SUCCINCT DE LA NOTION DOBJET DE GESTION

1.1 Les fichiers
A la fin des annes 1970 existait la notion de fichier. A cette poque, Daniel Martin[MARTIN D., 1977] dfinit trois types de structures, lpoque encore appeles Fichiers (matre, historique, encours) et quatre types doprations sur ces structures (addition-soustraction, modification, slection, destruction-nettoyage). A ce stade, on sintresse aux oprations surtout dans un but de temps de traitement, la technologie encore balbutiante impose des astuces dans la conception et limplantation si lon veut assurer des temps daccs aux donnes compatibles avec limpatience de loprateur. Type de fichier Matre Addition Enregistrement entier, nombre de zones constant Modification possible Oui Frquence des additions Assez peu frquent Nb denregistrements ajouts Faible en une fois Frquence des soustractions Faible Nombre denregistrements Faible
1 2

En-Cours Entte dtail1 dtail 2 Oui Trs frquent Moyen Eleve Moyen

Historique Par enregistrement entier, nombre de zones variable Non Frquent Moyen Nulle Nul

Enterprise Resources Planning un article ultrieur traitera du Comment

Franois Blondel septembre 2002

page 2

soustraits en une seule fois Frquence de nettoyage

Faible

Eleve

Trs faible

Figure 1 : Typologie des fichiers la fin des annes 70 En 1981 Jean Dominique Warnier[WARNIER JD, 1981] redfinit les donnes et les traitements et ouvre son ouvrage par des notions mathmatiques : Axiome 1 : toute collection de donnes constitue un ensemble au sens mathmatique du terme Lorganisation est alors hirarchique : Tout ensemble de donnes doit tre subdivis en sousensembles en partant du niveau le plus lev et en employant les critres de subdivision appropris et On subdivise un ensemble de donnes sil comprend des sous-ensembles qui peuvent sy trouver un nombre de fois diffrent de 1 . Et lauteur insiste alors sur une rgle de base. A Dans une organisation hirarchique, il doit toujours y avoir application de chacun des ensembles dans tous les ensembles de niveau suprieur B Lorsquon met deux ensembles de donnes en correspondance, cette correspondance doit tre une application et stonne que ce ne soit pas toujours le cas. Exemple : dans lorganisation administrative de la France, certaines villes comportent plusieurs cantons, dans dautres cas plusieurs villes appartiennent un canton !!! Toujours la mme poque, lorsque lon veut reprsenter des donnes de gestion on le fait en utilisant la notion de fichier et en utilisant la norme des organigrammes.

Disque magntique

Stockage accs direct (plus utilis)

Traitement

Etat (papier)

Figure 2 Reprsentation donnes et traitements - organigrammes Notons que cette norme dsute et obsolte na toujours pas t remplace3. Il nest pour sen convaincre qu regarder les formes automatiques proposes dans les logiciels (MS Word, Micrografx Flowcharter).

1.2 Base de donnes relationnelle et tables mthode Merise

Un peu plus tard, apparat dans les logiciels de gestion la notion de base de donnes relationnelle. Celle-ci est ne des consquences de lalgbre de Codd (1970) et surtout de la possibilit pratique de son application due aux progrs dans les performances du matriel (hardware). Mais cette approche pour lanalyse en gestion souffre de deux dfauts rdhibitoires : 1 On sloigne du Quoi en mlangeant avec le Comment. 2 On sloigne de linformation et on fait de linformatique. Elle commence par dfinir un certain nombre de concepts, comme ceux de domaine ( ensemble de valeurs caractris par un nom support dun ou plusieurs attributs de relation ), de produit cartsien et de tuples (ou n-uplets), de relation( une relation sur D1, D2,..Dn est un sous-ensemble du produit cartsien D1xD2xD3x..DN ), dattribut( nom affect une composante dune relation ), ou de cl ( groupe dattributs minimum qui dfinit un tuple unique dans une relation , puis introduit la notion de table, en tant que structure de donnes deux dimensions compose de colonnes numrotes de 1 m et de lignes numrotes de 1 n. Lorsque une relation est matrialise par une table, un attribut est une colonne de la table, et un n-uplet est une ligne. Enfin, toute table nest pas forcment reprsentation dune relation car toute table possdant des tuples en double nest pas une relation. Ces
3

Le langage UML est notre avis encore incomplet et pas encore sorti des cnacles des spcialistes

Franois Blondel septembre 2002

page 3

postulats et thormes restent vrais(mais pas forcment respects) dans le monde daujourdhui et les grands ERP du march. Colonne 2 Table Attribut 1 Attribut 2 Attribut 3 Attribut 4 Ligne 1 Ligne 2 Ligne 3 Etc Figure 3 Bases de donnes relationnelles Lignes et colonnes de tables Au niveau de chaque table, on distinguera dans les colonnes celles dont la file de valeur est permanente ou non, selon une distinction introduite par Henri Briand [BRIAND H 1978]. Dans une table la file de valeurs est permanente si et seulement si : - les lignes ont une existence permanente cest dire si les entits reprsentes dans la table sont permanentes. A titre dexemple, les lignes dune table client ou article sont permanentes, celles d'une table lignes-commandes-clients ne le sont pas. Ces dernires apparaissent (cration) ou disparaissent (suppression lie au solde commande) chaque nouvelle journe. - lattribut prsent dans la colonne est permanent pour chacune des lignes concernes. Ainsi lattribut nom ou adresse est permanent, lattribut quantit en stock ou Chiffre daffaires ne lest pas. Cette distinction nous re-servira au niveau de la conception des objets de gestion. Enfin sur une base de donnes relationnelle, sappliquent alors les types doprations dfinies par les rgles de lalgbre de Codd : Union, Diffrence, Projection, Restriction, Jointure. Apparus peu prs en mme temps, la mthode Merise et le modle entit-association connaissent un succs important et qui sera durable dans la conception des systmes dinformation. La mthode Merise, ne en France dans les annes 70, a connu son premier succs mdiatique avec la parution de louvrage de Peter Chen[CHEN P 1977]. Ce modle est constitu de deux lments : les entits et les associations. Les entits sont des regroupements d'informations, et possdent des attributs(ou caractristiques). Les associations sont les liens logiques entre les entits, et sont quantifis par des cardinalits4 (( 0,1), (1,1), (0,n) (1,n)..)). La mthode introduit ensuite la notion de modle conceptuel de donnes (MCD) dont on dduit le modle physique de donnes (MPD), dans lequel toute entit est reprsente par une table. En mme temps que la mthode Merise natra la notion dAGL (atelier de gnie logiciel) qui permet de crer automatiquement le DDL (data description language) des tables de la base donnes relationnelle partir du MPD. Mais malgr son apport indniable, le modle Merise est trop oriente informatique et ne sait pas dfinir le QUOI correctement.

1.3 Mthodes objets et objets de gestion

Peu aprs la diffusion des langages orients objets apparaissent les premires dfinitions des objets de gestion. En 1995 est fond lOpen Application Group5 , un consortium industriel non lucratif regroupant de nombreux acteurs dans le domaine de l'interoprabilit des composants de logiciels de gestion. L'OAG a labor lOpen Applications Group Integration Specification (OAGIS) et dfini les Documents Objets de Gestion (ou BOD= Business Object Doucment). Un BOD dans sa dernire version est alors la reprsentation d'un processus de gestion standard qui s'applique au sein d'une entreprise ou entre plusieurs entreprises. Par exemple, l'ajout d'un bon de commande, l'indication de la disponibilit du produit ou l'ajout d'un bordereau de vente. Les BOD sont dfinis par l'OAG qui

4 5

Dans le langage UML utilis aujourdhui on parle plutt de multiplicit . www.openapplications.org

Franois Blondel septembre 2002

page 4

utilise XML.6 Daprs ces dfinitions un objet de gestion peut donc tre aussi du COMMENT (notion de processus). Ceci va nous gner pour comprendre la structure (le QUOI). Dans le mme temps la mthode UML (Unified Modeling Language) va simposer comme La mthode de rfrence en approche-objet, malgr un formalisme et un langage prsents comme simples mais trop complexes souvent pour les clients des projets ERP. A ct de ces approches normatives, coexistent des initiatives prives telles celle de SAP qui avec son produit R/3 occupe une position importante sur le march des ERP. Pour SAP, la technique et la programmation dobjets de gestion sont bases sur le concept des objets de gestion 7. Les objets rels , tels quun salari ou une commande client, sont reprsents comme des objets de gestion dans des systmes d'application de gestion, tels que le systme R/3 8. SAP compare ainsi les objets de gestion SAP des botes noires qui encapsulent les donnes et processus de gestion R/3, cachant ainsi les dtails de la structure et de limplmentation des donnes sous-jacentes. Un objet de gestion SAP est une entit couches multiples . Au cur se trouve le noyau. Il reprsente les donnes inhrentes lobjet. La deuxime couche ou couche dintgrit, reprsente la logique de gestion de l'objet, et comprend les rgles et contraintes de gestion qui s'appliquent l'objet de gestion. La troisime ou couche d'interface, dcrit limplmentation et la structure de l'objet de gestion et dfinit l'interface de l'objet avec le monde extrieur. Enfin la quatrime couche externe ou couche d'accs, dfinit les techniques permettant un accs externe aux donnes de l'objet, par exemple COM/DCOM (Component Object Model/Distributed Component Object Model) ou CORBA. Tous les types dobjets de gestion SAP et leurs mthodes sont identifis et dcrits dans le Business Object Repository (BOR). Dans loptique du dveloppement informatique, cette approche a peu de dfauts. Mais bien que plus proche de la ralit vcue elle est encore trop informatique et ne distingue pas structure (information) et implmentation(information et informatique).

1.4 Ltat actuel : Urbanisme, UML et ISO 9000-2000

Dans un article clbre[KRUCHTEN Ph, 1995], Philippe Kruchten9 a introduit la notion darchitecture et lapproche objet dans le domaine de linformatique de gestion avec la vue 4+1.
End-user functionnality Progammers Software Management functionnality

Logical view Scenarios Process view

Integrators Performance Scalability

Development view

Physical view
Systems Engineer Topology Commnunications - 1995 IEEE

Figure 4 4+1 view model

Mais contrairement la mthode Merise, qui avait t conue spcifiquement pour linformatique de gestion, la mthode UML avait t lorigine tablie pour linformatique industrielle. Lexemple pris dailleurs dans cet article par lauteur tait celui dun central tlphonique. La synthse avec le monde de la gestion restera difficile. De cela, nous reparlerons lorsque nous examinerons, dans un article ultrieur, l volution des scenarios et de la vue logique au travers des diagrammes de cas dutilisation ( Use cases ) et des diagrammes de classes de lUML, du Meta Object Facility (MOF) et de la cartographie des processus lie la version 2000 des normes ISO 9000.
6

A BOD defines a given business process, which may include multiple transactions between various companies. Issuing a purchase order is an example of such a process. Source OAGIS white papers version 7.2 7 voir http//help.sap.com 8 source idem note prcdente 9 Ingnieur Centrale Lyon (75), le Dr Philippe Kruchten est directeur du dveloppement des processus chez Rational Software, au sein de laquelle travaille la plupart des concepteurs de lapproche objet et du langage UML ( Booch, Jacobson, Rumbaugh..).

Franois Blondel septembre 2002

page 5

Une approche rcente ([JEAN G., 2000], [LONGEPE, C.2001]) tend cette notion darchitecture celle durbanisme et dfinit une approche 4 niveaux allant de larchitecture mtier larchitecture technique.
Architecture mtier Quels mtiers ?

Architecture fonctionnelle Quoi ?

Architecture applicative Comment ?

Architecture technique Avec Quoi ?

Figure 5 : Les quatre niveaux ou couches du cadre de rfrence (daprs Ch.Longp,page 36) Remarquons ce sujet que ce schma est inspir de la mthodologie CIMOSA10 [AMICE, 1993] dfinissant laxe de gnration suivant la vue fonction, la vue information, celle des ressources, puis de lorganisation. Au niveau du consultant ERP, les deux premiers niveaux sont les plus importants. Mais lapproche de lurbanisation si elle est intressante, montre aussi ses limites. Comme la dj remarqu Michel Volle11 dans un commentaire sur louvrage de Grard Jean[JEAN G., 2000] , la logique de linformation[..] est diffrente de celle dune ville [..]au moins autant qu'un immeuble est diffrent d'une information . De plus, dans toutes ces approches, une ambigut ma frapp. Elles sont beaucoup plus orientes dans un but de cration ex nihilo ( Business Engineering ) que dans un but de reprise dun existant (Business Process Reengineering ou BPR). Et lapproche de Christophe Longp est descendante ( top-down ) comme elle tait dj dans une approche procdurale (non objet ) alors que les approches conseilles dans les mthodes orientes objets (MOO) sont itratives et incrmentales. Dans le cas dimplantation dun ERP, ce dernier prexiste avant lorganisation de lentreprise. On est alors dans une situation de BPR et il importe de comprendre la structure de lERP avant de commencer tudier les processus. Jay Forrester[FORRESTER J., 1961] avait ds 1961 introduit le postulat de dualit EtatsMouvements. Cette diffrenciation Etats-Mouvements est aujourdhui la fois banalise et trs utile dans la comprhension dun ERP. Mais dans le mme temps, Jay Forrester avait insist sur la prminence de la structure par rapport au systme dot dun comportement . Cest pourquoi, dans la suite je commencerai par prsenter la structure (architecture fonctionnelle ou 2me niveau) avant de revenir au 1er niveau de larchitecture mtier puis de retourner larchitecture fonctionnelle pour la phase suivante de la mise en place de lERP. Dans les paragraphes suivants, nous nous attacherons une typologie des ensembles de classes sans voquer le formalisme attach aux diagrammes de reprsentation. Malgr leurs imperfections, le langage UML et son diagramme de classes simposent.

II OBJETS DE GESTION DANS LOPTIQUE COMPREHENSION DE LERP - GENERALITES

DE

LA

Ltude qui suit porte en particulier sur la couche 2 de larchitecture prsente ci-dessus. Pour donner une ide de la complexit dapproche des structures de donnes, il suffit de savoir que le nombre de tables varie selon les ERP entre quatre cents et deux trois mille, chacun de ces tables comprenant plusieurs dizaines de champs (donc de donnes lmentaires).
10 11

CIM Open System Architecture- (AMICE, 1993) http://www.volle.com

Franois Blondel septembre 2002

page 6

Nous proposons donc de classer les donnes de gestion dans un modle cinq classes sur cinq niveaux, dont nous allons dans la suite expliquer la dfinition et montrer les avantages. Nous avons voqu la notion de table relative des donnes de gestion. En effet il existe au sein de lERP, au del des objets de gestion, un certain nombre de tables relatives au comportement des programmes dans une situation donne (notion de transaction par exemple, ou paramtrage dun cran ). Ceci correspond une structure informatique et non plus une structure de gestion, et sera ignor dans la suite. Concrtement, la traduction dun objet de gestion pour la structure de lERP consiste en une ou plusieurs tables lies, les contraintes relationnelles, les notions dhritage et de polymorphisme associes. Contrairement la distinction traitementdonnes de la mthode Merise, on attachera certains traitements aux objets de gestion, et dautres seront lis aux processus. En effet, certains traitements sont par nature associs chacun des classes considres, car ils sont lies de faon univoque la classe (exemple : cration article li la classe dobjets de base article ).

Objets Entits de flux

Objets Mouvements

Objets Situation

Objets de base
objet base objet base objet base objet base objet base objet base

Objets Historiques

Figure 6 - Les cinq classes principales dobjets de gestion dans un ERP Tout objet de gestion sera identifi selon cinq classes au cinq niveaux suivants. 1 = objets Base 2 = objets Situation 3 = objets Mouvements 4 = objets Entits de flux et -1 = objets Historiques et Traces La dernire catgorie correspond ces classes dobjets passes et non prsentes ou futures. Cest pourquoi on les a ranges part, comme les archives la cave. Cette classification doit nous permettre didentifier pour chaque objet sa catgorie, et pour chaque table du modle de donnes relative des donnes de gestion, le sous-groupe dappartenance et la catgorie.

Franois Blondel septembre 2002

page 7

III LES DIFFERENTS ENSEMBLES DE CLASSES DOBJETS DE GESTION

3.1 Lensemble des classes Objets de Base (niveau 1)

3.1.1 Les classes dobjets principaux

Dans cette catgorie se trouvent les notions qui correspondent ce que lutilisateur a coutume dappeler les donnes de base . Du point de vue de la structure, chaque objet peut correspondre des ranges dune ou plusieurs tables. La structure peut tre de type unique (article en gnral par exemple), de type en tte+lignes (nomenclatures, gammes en gnral toujours par exemple). Noter que la structure en termes de tables peut varier dun ERP lautre mais la classe elle-mme se retrouve dun ERP lautre. A ces objets sont associes des rgles de gestion : -le nombre de colonnes de chaque table de ces objets est constant -La frquence de mise jour, dadditions et de soustractions, est faible -tous les attributs de chaque objet ont une stabilit forte (on ne change pas ladresse dun client ou ses conditions de rglement tous les jours). En reprenant la terminologie de Henri Briand vue plus haut, les files de valeurs sont permanentes. En consquence, pour que la structure de la base soit correcte dun point de vue gestion, je prconise quon ne trouve aucune colonne de type mise jour frquente dans chacune des tables associes ces objets.
Exemple : len-cours client (trs variable en fonction des factures et des rglements) ou les statistiques de marge ne concernent pas lobjet client. De mme la quantit en stock ce jour mme si elle est lie un couple (article, site ou magasin) ne doit pas appartenir lobjet de base article-site puisque sa valeur est variable et non permanente. On reverra ce point plus loin.

OBJET DE BASE PRINCIPAUX Tiers Clients

Commentaire Il sagit de la partie commune diffrents types de tiers dans lentreprise (clients, fournisseurs, transporteurs) Toutes les informations permanentes de la fiche client. En aucun cas lobjet client ne doit contenir dattribut non permanent (de type en cours, date de dernire commande, ou stats de vente) Idem client Ensemble des comptes utiliss dans lentreprise Fiches relatives aux diffrentes immobilisations de lentreprise Toutes les informations permanentes lies aux articles Toutes les informations permanentes lies aux magasins dun article (de type par exemple mode de gestion, emplacement principal, mode valorisation) lexclusion des zones non permanentes (quantit en stock, Prix Moyen Pondr) Dans la plupart des cas, il arrive que le tarif ne soit pas un objet de base En tte + lignes, et ventuellement diffrentes versions de nomenclatures de Repris ensuite dans les lignes de gammes

Fournisseurs Comptes comptables Immobilisations Articles Magasins ou sites

Tarifs Nomenclatures Oprations standard fabrication Postes de charge (ou Ensemble des caractristiques de capacit et de valorisation lies une sections) ensemble de machines ou de postes main duvre Calendriers Plusieurs par entreprise en gnral dfinis partir de profils de base et de jours non travaills. Gammes de fabrication En ttes + lignes, pour les diffrentes gammes lies chaque article de lentreprise. Un mme article peut avoir plusieurs gammes (multiplicit

Franois Blondel septembre 2002

page 8

(0,n)) et linverse plusieurs articles peuvent avoir la mme gamme mre (cardinalit (n,1)).

3.1.2 Tables de Paramtres

Ces tables de paramtres correspondent des objets de base annexes, Exemple : tables des units, des codes langues , des rgimes de TVA.. mais sont souvent peu intressantes du point de vue de la comprhension de la structure du systme et de la base associe.

3.1.3 Quelques objets secondaires

Certains objets sont prsents dans certains ERP, pas dans dautres en fonction de la couverture fonctionnelle plus ou moins large de lERP concern. On peut citer ce propos par exemple, sans recherche aucune dexhaustivit, les Fiches techniques ou les Questionnaires qualit.

3.2 Lensemble des classes Objets Entits de flux (niveau 4)

Lorsquune commande client (par exemple, ou un BL, un OF, une commande fournisseur, une facture, une criture comptable, etc) est cre dans lERP, elle est identifie, va rester un temps variable dans le systme, puis tre efface ou archive une fois compltement traite (solde ou clture). Cette commande est une entit de gestion qui participe au flux. Je propose de nommer la classe laquelle elle appartient classe dobjets Entits de flux, par analogie avec la thorie de Forrester sur les flux interconnects et la notion de jeton dans les rseaux de Petri orients objets (Objects inside Petri Nets[BASTIDE R. 1995]). Dans les annes passes, les diffrentes recherches sur ces phnomnes se sont beaucoup plus intresses lvnement gnrateur de ces objets quaux objets eux-mmes. Ainsi : - selon la norme CIMOSA, les vnements (events) reprsentent des changements d'tat instantans dans l'entreprise ncessitant une action. Ils sont dfinis par une source, un prdicat et une date. Ainsi, l'arrive d'une commande client12, une panne sur une machine ou la fin d'un traitement sont des exemples d'vnements. [VERNADAT F. 1998]. - selon les dfinitions de lUML, reprises par Christophe Longp[LONGEPE C. 2001] , un vnement est un signal qui peut tre reconnu. Il na pas de dure. - selon la socit SAP, les Event-driven processus chains comprennent des fonctions et des vnements. Les fonctions sont dclenches par des vnements et les fonctions produisent des vnements. Le contrle de flux dun processus de gestion est alors dcrit par une squence alternative dvnements et de fonctions [LOOS P., 1998] . Ces phnomnes avaient aussi ds 1997 t dcrits dune manire plus proche de la gestion et moins informatique ([BLONDEL F. 1997] - chapitre 12- Lentreprise intgre). Les objets Entits de flux sont par les vnement quils gnrent , les dclencheurs des actions dans les processus. Ils sont autonomes par rapport au reste du systme dinformation. Toute mise jour de ces objets fait appel la notion de transaction ( commit ) dans la base de donnes. Par rapport aux Entits de flux, les objets de base correspondent de plus une entre (au sens input des systmes) du systme dinformation. Les classes dobjets Entits de flux peuvent tre considres selon plusieurs points de vue selon lutilisateur du systme. Expliquons ceci par une mtaphore.
Exemple : Un automobiliste prend sa voiture pour rendre visite un ami, 100 km de chez lui. Il emprunte lautoroute. Du point de vue de lami, lentit de flux est une visite attendue pour un jour et une heure donns. Du point de vue de la socit des Autoroutes, lentit de flux est un client supplmentaire dans le rseau autoroutier. Du point de vue de la Gendarmerie, cette entit de flux est un gnrateur de trafic supplmentaire.
12

: et non la commande elle-mme (Note de lauteur)

Franois Blondel septembre 2002

page 9

Du point de vue du carnet dentretien de la voiture, lentit de flux supplmentaire rapproche la date de prochaine vidange de la voiture. Du point de vue dun automobiliste crois ou doubl(une autre entit de flux), il peut tre un conducteur dangereux ou pnible. Ici on utilise deux objets de base, la voiture et son conducteur. Lentit de flux est caractrise de surcrot et en sus par une destination, une route utilise, une date et une heure, etc.

Et si, comme on la vu plus haut propose de lurbanisme, toute mtaphore a ses limites, celle-ci nous permet de comprendre trois caractristiques importantes. - Une Entit de flux utilise des ressources diverses mais est en soi autonome. - Elle a une dure, et donc un statut (en cration, valid jusqu mort ou clos) et na plus dincidence aprs sa fin que sur les objets historiques. La liste des statuts possibles dpend de chaque ERP voire de chaque implantation de lERP. - Ds quune Entit de flux est cre, elle a une incidence sur divers lments du systme rel et du systme dinformation, selon le point de vue quon emprunte. Elle peut dans cette optique tre compare un objet multi-faces, quon ne regarde un instant t que sous une seule face la fois.
etc.. quota du reprsentant stock par lot (diminu du lot affect la commande)

Figure 7 Incidence dun objet Entit de flux sur les objets Situation Ainsi, dans un ERP une commande client peut augmenter le risque client, rserve le stock de larticle pour la date de livraison, rentre dans le quota du reprsentant de ce client, augmente le portefeuille de commandes, etcOn verra ci-dessous (paragraphe 3.4) que lEntit de flux impacte des objets au niveau Situation . Chaque fois que lobjet Situation impact doit pouvoir tre rtabli en cas dincident, ou chaque fois que lobjet Situation est impact dune certaine faon identique par des objets Entits de flux diffrents, il doit communiquer avec lobjet Situation par lintermdiaire dun objet Mouvement standardis (notion de prise ou de socket ). Lobjet Entit de flux peut correspondre une ligne dans une seule table mais le plus souvent correspond des ensembles de lignes identifiables (le plus souvent par un numro de pice unique) et regroupables dans un groupe important de tables. On trouvera ci-aprs les classes dobjets Entits de flux les plus courantes au sein dun ERP.
Ecritures comptables Commande client Offre de Prix (client) Devis (client) Commande fournisseur Ordres de fabrication Une criture est un sous ensemble logiquement indpendant, puisque quilibr par construction Une commande client est forme dune en-tte et de lignes En amont de la commande client . Elle doit pouvoir tre transforme en commande donc contenir cet effet les donnes ncessaires . Lobjet Devis est comparable une commande, avec moins de prcisions pour certains attributs. Il peut dailleurs tre transform en commande. Une Commande foursisseur est forme dune en-tte et de lignes Un OF est identifi par un code rfrence des couples (article,quantit) pour une date donne, une gamme et une nomenclature associe. En termes de tables, un objet OF peuvent tre associes dautres tables telles que celles relatives aux cots (prvisionnel et/ou rels) ou la planification (jalonnement, date des oprations ).. Proche de lobjet devis client

Appel doffre ou Consultation

Franois Blondel septembre 2002

page 10

(fournisseur) Demande dachat (fournisseur) Bon de Livraison client BL rception fournisseur Avis dexpdition (colisage)

Une demande dachat est forme dune en-tte et de lignes Un BL peut ou non tre issu de plusieurs commandes De mme, un Bon de rception peut ou non tre issu de plusieurs commandes. La liste de colisage est cre partir du BL client. Une ligne BL peut tre coupe en plusieurs colis ou plusieurs lignes du BL rassembles dans la mme palette.

3.3 Lensemble des classes Objets Mouvements (niveau 3)

Cette classe dobjets permet la communication entre les objets Entits de flux et les objets Situation. A chaque objet Entit de flux sont attachs des Mouvements permettant dimpacter les objets Situation Exemple : Une ligne commande client modifie le rserv dun article dans le stock. Une ligne composant dun OF modifie le rserv de larticle dans le stock. Il existe un ou plusieurs enregistrements dans des tables mouvements. Le cumul de ces mouvements correspond ltat dune colonne de la table Situation

Exemples
1) Mouvement de stock rel Les mouvements sont gnrs par des entits de flux en gnral modifiables (BL client, BL fournisseurs, dclaration de production, changement de dpt, etc..). Les mouvements doivent donc tre autonomes vis vis des objets situation et permettre un re-calcul a posteriori en tenant compte de lordre de ces mouvements (exemple : cas des BL fournisseurs dont la facture est connue sur la priode comptable suivant par exemple). charge sur une maille( mois, semaine, jour) de chargement

2) Dtail de la prvisionnelle 3) Mouvements de suivis de Une ligne par tche dont la dure est dfinie temps de production 4) Brouillard de saisie comptable Etc.

3.4 Lensemble des classes Objets Situation (niveau 2)

Un objet Situation est normalement lagrgation dobjet vnements vivants (exemple : rserv = somme des rservations issues de commandes clients ou composants pour OF) et dune situation de dpart ventuellement pour les objets Entits de flux morts (exemple : stock = stock dpart + somme des Mouvements issus dEntits de flux existantes). On a vu plus haut que pour une Entit de flux donne, il pouvait exister plusieurs mouvements chacun des mouvements correspondant une face de lobjet Entit de flux( cf figure 7) Il peut tre mis jour chaque cration de Mouvement lors de la modification dEntits de flux ou bien mis jour de manire diffre. Si le progiciel est bien fait ; alors pour des Entits de flux diffrentes mais dont limpact sur une Situation est le mme, lobjet Mouvement utilis est le mme. Pour des raisons de scurit de la base de donnes, il est souvent souhaitable dintroduire dans lEntit de flux des redondances permettant de connatre le Mouvement. On pourra alors en cas dincident rgnrer les mouvements partir des entits lmentaires de flux.

Franois Blondel septembre 2002

page 11

Exemple 1 Stock (prvisionnel et rel) - problmatique du stock ou en cours date La figure ci-aprs reprend lexemple du stock prvisionnel, impact par diffrentes Entits de flux. Entit de flux
Commande client Commande fournisseur

Ordre de fabrication

Autres Etc

Mouvements

Mouvement prvisionnel de besoin ou de ressource

Situation

Stock (prvisionnel)

Figure 8 Exemple dEntits de flux mettant jour un objet Situation, via un objet Mouvement Ainsi len-cours client, le solde comptable, le nombre de commandes en cours sont des attributs dun objet situation li au client . Le stock physique, le stock prvisionnel date, le PMP dcompos par catgorie de cots sont des attributs dun objet Situation li au couple (article, site). Autres exemples : 2-Grand-Livre et Balance Solde de compte et liens avec les critures associes comptable Situation charge prvisionnelle par poste de charge et par maille de temps 3-Plan de Charge et capacit considre Quantit et valeur et par article avec possibilit de dcote ultrieure 4- Inventaire 5-Valorisation de stock au PMP ou au FIFO

Figure 9 Relation entre Situation et Mouvements

Dans l exemple 5, on doit non seulement disposer de la situation un instant t, mais on doit tre capable de recalculer le PMP ou la valeur en FIFO une date t en balayant lensemble des mouvements entre la date de dernire situation non modifiable et les mouvements ayant eu lieu entre cette date et la date de fin t+x . Labsence de Mouvements relis la Situation rendrait cette dernire inexploitable.
Exemple (vcu) : Cest en appliquant cette mthode que jai pu montrer que dans certains ERP bien connus du march certains paramtrages pouvaient donner des rsultats errons - sans que cela ne soit document en aucune faon, ni que des protections empchent ces paramtrages de la part du client.

6- Portefeuille de commandes

Dans cet exemple, lobjet Situation correspondant est souvent temporaire, gnr par un traitement la demande partir des objets Entits de flux Commandes .

Franois Blondel septembre 2002

page 12

La structure des classes dobjets Situation est la plus reprsentative de la couverture fonctionnelle de lERP et du niveau de profondeur de chacune de ces fonctions, donc des possibilits globales du progiciel pour le client. Lensemble des classes dobjets Situation permet dexpliquer lEtat de lEntreprise un instant donn. Il nest fiable que si et seulement si les classes dObjets de base et dobjets Entits de flux le sont au pralable. Ceci nous permet de gnraliser et dtendre facilement toutes les fonctions de gestion dans lentreprise un certain nombre de rgles historiquement apparues dans le domaine du MRP, des stocks, ou du JAT (exemple : pour utiliser la mthode MRP, les nomenclatures doivent tre fiables 98 %, les stocks et les gammes 95 % [BLONDEL F. 2000]-page 348).

3.5 Lensemble des classes Objets Historiques

Cet ensemble de classes est le plus simple. Il comprend toutes les classes rendues ncessaires par le besoin de statistiques, dhistoriques, lis au contrle de gestion ou la traabilit des vnements, cette dernire tant lie la lgislation ou la scurit. Les objets de ces classes ne sont pas modifiables. Ils peuvent tre rgnrs tant que les vnements gnrateurs sont encore prsents dans la base( ventuellement avec un statut adquat). On peut citer titre dexemple les statistiques de facturation (par client, par article, par ligne de vente..), le Bilan de lexercice, les statistiques de fabrication, les statistiques reprsentants, etc

IV- UTILISATION DE LA METHODE PROPOSEE ET AVANTAGES

4.1 Vision globale par rapport un ERP
Comme nous lavons vu dans le premier paragraphe, ltude des classes ci-dessus dans lERP utilis est un pralable la vision mtier et la cartographie des processus. On passe donc du niveau 2 du schma durbanisme (architecture fonctionnelle) au niveau 1 (architecture mtier). La question Quels mtiers devient donc souvent Comment ? cette fois du point de vue de lutilisateur et non de linformaticien ou du consultant (le comment ? du niveau 3). Dans cette phase mtier , grce la typologie ci-dessus, le consultant va donc pouvoir assez facilement imaginer si le progiciel rpond au besoin exprim et sous quelle forme : - le progiciel rpond de manire standard (sous rserve de paramtrage correct) - le progiciel ne rpond pas ce besoin mais les objets de gestion relatifs au besoin sont prsents dans la structure. On pourra poursuivre lanalyse aux niveaux 2 et 3. - le progiciel ne rpond pas au besoin et les objets de gestion correspondants ne sont pas prsents, mais ne touchent pas au cur de la structure. On peut proposer au client une approche en dveloppement spcifique et poursuivre ensuite lanalyse au niveau 2. - le progiciel ne rpond pas au besoin, les objets de gestion ne comprennent pas linformation ncessaire, et ce besoin touche au cur de la structure (ensembles de classes dobjets Situations en particulier). Il vaut mieux essayer de contourner ce besoin en proposant une autre voie dapproche que de continuer lanalyse. Lors de la mise en place dun projet ERP, qui se situe dans un concept de Business Process Reengineering, cette mthode augmente donc lefficacit oprationnelle des consultants mtiers. En consquence, elle raccourcit la dure du projet et diminue le cot total du mme projet.

4.2 Capitalisation des connaissances ( Knowledge Management ) et rutilisation

Lapproche ci-dessus a galement lavantage de pouvoir tre transpose dun ERP lautre. Les consultants comme les dveloppeurs, dans leur vie professionnelle, sont amens travailler pour diffrentes socits donc passer de la pratique dun ERP X celle dautres ERP Y ou Z. Lorsquon connat le cot (fixe pour chaque nouvel embauch) de la formation sur un ERP, il est important de pouvoir minimiser ce cot en utilisant les connaissances de la personne sur un autre progiciel. La mthode des ensembles de classes propose ci-dessus permet ainsi de raccrocher la structure dun ERP celle dun autre ERP et de procder par analogie et comparaison.

Franois Blondel septembre 2002

page 13

4.3 Communication avec les clients managers et non informaticiens

Enfin, cette approche (mme si la prsentation qui en est faite ici est encore assez abstraite) a lavantage dtre assez facilement explicable lutilisateur non informaticien. Certaines approches normalisatrices sont parfois complexes et difficiles comprendre (Meta Object Facility de lOMG par exemple) pour un gestionnaire. On peut penser linverse que les notions de donnes de base, de mouvement, de situation, dvnement ou dhistorique lui sont plus habituelles. Seule lentit de flux ne lui est pas (encore) naturelle. En cela, cette approche correspond aussi aux prescriptions de Jay W.Forrester sur le lien entre le rseau des matires (Materials) celui des flux clients et fournisseurs (Orders) et le tissu connectif reprsent par le systme dinformation [FORRESTER J 1961]. Dans un article ultrieur, nous traiterons de lapproche mtier et des processus. Nous tenterons de la mme manire de proposer des simplifications applicables lors de limplantation des ERP.

BIBLIOGRAPHIE
AMICE 1993 AMICE. CIMOSA : Open Systems Architecture for CIM, 2me dition, Springer-Verlag, Berlin, 1993 BASTIDE Rmi 1995 - Approaches in unifying Petri nets and the Object-Oriented Approach- OOMC'95, 16th international conference on applications and theory of Petri nets, ICATPN'95, Torino, Italy. (1995) (http://lis.univ-tlse1.fr/bastide/Research/Papers) BRIAND Henri, COCHET Christian ,1978 Analyse Fonctionnelle Dunod BLONDEL Franois 1997 Gestion de la Production 1re dition Dunod [BLONDEL F 2000] : Franois BLONDEL Aide mmoire de Gestion Industrielle Dunod 2000 [BLONDEL F 2002] : Franois BLONDEL Gestion de la Production 3me dition Dunod 2002 [CHEN P 1977] Peter CHEN. - The Entity-Relationship Approach to Logical Data Base Design. The Q.E.D. Monograph Series: Data Management. Wellesley, MA: Q.E.D. Information Sciences, Inc 1977 [FORRESTER J 1961] Jay Wright FORRESTER. Industrial dynamics. Cambridge, Mass.: MIT Press. 1961 [GABAY J 2001] Joseph GABAY - Merise et UML pour la modlisation des systmes dinformation 4me dition Dunod 2001 [JEAN G 2000] Grard JEAN - Urbanisation du business et des SI - Herms 2000 [KRUCHTEN Ph 1995] Philippe KRUCHTEN - The 4+1 View Model of Architecture - IEEE Software, November 1995, 12 (6), pp.42-50 - 1995 IEEE [KRUCHTEN Ph 2000] Philippe KRUCHTEN - The Rational Unified Process: an introduction. 2nd edition. Addison Wesley. 2000. [LONGEPE C 2001] Christophe LONGEPE Le projet durbanisation du systme dinformation. Dunod 2001 [LOOS P 1998] Peter LOOS Thomas ALLWEYER. Process-Orientation and Object-orientation An approach for integrating UML and Event-driven Process Chains (EPC) Mars 1998- Institut fr Wirtschaftsinformatik Saarbrcken, Germany

Franois Blondel septembre 2002

page 14

[MARTIN D 1977] Daniel MARTIN Bases de donnes Mthodes pratiques Dunod 1977 [SIBERTIN 1985] C.A. SIBERTIN-BLANC - High-level Petri nets with data structure. 6th European workshop on Petri nets and applications, Espoo (Finland), June 1985. [SIMS O 1994] Oliver SIMS : Delivering Cooperative Objects for Client-Server 1994 IBM McGraw Hill series ISBN 0-707-7957-4 [VERNADAT F 1998] F. VERNADAT - La Modlisation en Entreprise par la Mthodologie CIMOSA Sminaire GRP-PROSPER La Modlisation d'Entreprise, Roissy, 27 janvier 1998 [VOLLE M 2000] Michel VOLLE Urbaniser un SI Confrence 21-11-2001 IAE de Paris http://www.volle.com [WARNIER JD 1981] Jean Dominique WARNIER - Les procdures de traitement et leurs donnes Editions Organisation 1981 Pour la mthode UML : Pour le logiciel SAP : Pour lOAG : http://www.omg.org/uml/ http//help.sap.com http://www.openapplications.org

Franois Blondel septembre 2002

page 15