Une étude de l’intégration organisationnelle et

informationnelle. Application aux systèmes

d’informations de type ERP
Pierre-Alain Millet

To cite this version:

Pierre-Alain Millet. Une étude de l’intégration organisationnelle et informationnelle. Application
aux systèmes d’informations de type ERP. Autre [[Link]]. INSA de Lyon, 2008. Français. �NNT : �.
�tel-00343560�

HAL Id: tel-00343560

[Link]
Submitted on 2 Dec 2008

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
N° d’ordre 2008-ISAL-0071
Année 2008

Thèse

Une étude de l’intégration

organisationnelle et informationnelle

Application aux systèmes d’informations de type ERP

Présentée devant
L’institut national des sciences appliquées de Lyon

Pour obtenir
Le grade de docteur

École doctorale
École doctorale Informatique et Information pour la Société

Par
Pierre-Alain Millet
(Consultant, Professeur Associé)

Soutenue le 14 octobre 2008 devant la Commission d’examen

Jury MM.
Khalid Benali Maître de conférence HDR, Nancy Université Rapporteur
Valérie Botta-Genoulaz Professeur, INSA de Lyon Directeur
Jacques Erschler Professeur, Université de Toulouse Président
Alain Guinet Professeur, INSA de Lyon Examinateur
Hervé Pingaud Professeur, Univ. de Toulouse, Mines d'Albi Rapporteur
Michel Schneider Professeur, ISIMA Clermont Examinateur
Kurt Weiss Professeur, Resp. relations académiques SAP Examinateur

Laboratoire de recherche : LIESP, Laboratoire d'Informatique pour l'Entreprise et

les Systèmes de Production
Une étude de l’intégration organisationnelle et informationnelle.
Application aux systèmes d’informations de type ERP

Résumé

Les systèmes d'information (S.I.) d'entreprise se construisent à partir de progiciels configurés,

intégrés et déployés dans des organisations en mouvement. Les enjeux d'efficacité des projets,
d'efficience des usages, de performances opérationnelles, d'alignement aux stratégies d'entreprise
sont connus. Ils fondent la problématique de l'intégration organisationnelle et informationnelle,
avec la généricité nécessaire à la diffusion des bonnes pratiques et normes, dans une démarche
continue mêlant analyse de l'existant, conception et mise en œuvre par l'organisation. Un cadre
d'ingénierie dirigée par les modèles se diffuse progressivement à partir des travaux en modélisation
d'entreprise et en système d'information. Ce mémoire propose une approche centrée sur
l'intégration organisationnelle et informationnelle afin d'enrichir ce cadre dans les phases de
conception, d'intégration et d'usage pour prendre en compte les interdépendances entre les éléments
d'un système et entre les points de vue différents sur ce système. Ce cadre étendu repose sur un
méta-modèle de l’intégration et une démarche d’alignement entre les points de vue. Il s’appuie sur
la théorie des graphes pour définir une « distance » et un « voisinage » permettant de représenter
les différentes formes d'intégration qui conditionnent, permettent ou limitent les résultats des
projets. L’analyse de différents cas issus de référentiels métiers permet de valider la pertinence du
cadre proposé pour enrichir les représentations de ces modèles.

Mots-Clés : Modélisation, Système d'information, Intégration, ERP, graphe, partitionnement...

An analysis of organizational and informational integration.

Application to ERP Based Information Systems

Abstract

Enterprise Information Systems are built with commercial software packages, configured,
integrated and implemented in moving organizations. Mains issues are known regarding project's
success, use efficiency, operational performances, and strategic alignment. They based the
problematic of organisational and informational integration with the genericity required for the
dissemination of best practices and norms. This suppose a continuous approach including as-is
analysis, system design and implementation through the organization. A framework of model-
driven engineering emerges from works on enterprise modeling and information system. This
dissertation proposes an approach focused on organizational and informational integration to
enhance this framework in design, implementation and use phases. This approach highlights
dependencies between system elements and between the different model views of this system. This
extended framework is based on a meta-model of integration and on an alignment approach
between model views. It uses graph theory to define a « distance » and a « neighbourhood » and
represents different kinds of integration which condition, allow or limit project results. The
analysis of different cases resulting from business reference models, allows validating the
relevance of the proposed framework to enhance model representations.

Keywords : Modeling, Information System, Integration, ERP, graph, clustering...

Merci,

à Micheline et Jacques, syntaxe et syntacte mêlées qui m'ont donné la

vie... et un certain sens de la dialectique,

à Maryvonne et Joel qui m'ont permis de découvrir l'INSA et la recherche,

à Guy et Yannick dont les soutenances ont relancé utilement ma

motivation,

à France-Anne et Lorraine qui m'ont fait la cadeau inespéré d'un lieu de

travail plein de musique, de jeunesse et de fraternité,

à Alain, Jean, Pierre, Louis qui m'ont conseillé, aidé ou inspiré,

aux membres du LIESP et du département informatique de l'INSA qui

m'ont accueilli dans un incroyable espace de liberté,

à mes collègues du privé qui ont fait ce collectif de travail solidaire où ont
germées les interrogations de cette thèse,

aux nombreux contacts de la communauté scientifique du GDR MACS qui

ont écouté, questionné, commenté, conforté et souvent orienté les
présentations de mon travail,

à Valérie qui a dirigé, accompagné, soutenu, controlé mon travail de

recherche... des premiers articles à l'effort exigeant de rédaction pour
lequel son soutien a été déterminant,

à Marie-Christine qui a supporté dans tous les sens du terme ce long défi
qui n'avait pourtant d'autre justification que mon ego,

à mes filles qui restent et de très loin le plus important et le plus réussi
de ma vie...
 Ce document a été réalisé avec OpenOffice 2.4
La base bibliographique a été gérée dans le document grace à Zotero 1.0
Les calculs ont été réalisés avec Scilab 4.1
Nous avons tellement été habitués à penser que la démarche des
« sciences dures », avec son recours à la quantification,
l'expérimentation et la réplication, est fondamentalement supérieure, et
la seule qui soit véritablement orthodoxe, que toutes les autres
démarches ne peuvent paraître que bien faibles en comparaison. Mais les
sciences de type historique procèdent en reconstituant des séries
d'évènements contingents, en expliquant rétrospectivement ce qui
n'aurait pu être prédit. Que les preuves soient suffisantes, et l'explication
peut devenir aussi rigoureuse et sûre que n'importe quelle autre dans le
domaine de la science expérimentale

Stephen Jay Gould, Comme les huit doigts de la main (Editions du Seuil,
Paris, 1993, p83)

Qu'est donc dans le tout ce quelque-chose à expliciter qui n'est pas la

simple addition de ses parties et qui pourtant ne saurait leur être
étranger sans ressortir au deus ex machina ? Ce quelque chose, c'est
son organisation en tant que tout, la connexion d'ensemble de ses
éléments et sa logique, laquelle, dans la situation d'émergence, est
justement l'effet inédit de la nouvelle mesure surgie au « point
spécifiant ». Étayée pas sa double négation, telle est donc en fin de
compte l'affirmation dialectique à quoi nous conduit Hegel : le nouveau
quelque-chose ne s'explique pas plus par ses éléments que sans eux;
il s'explique par leurs rapports, base explicative de sa qualité, qui
mutent à des seuils de quantité.

Lucien Sève, Emergence, complexité et dialectique. Sur la dynamique des

systèmes non linéaires (Edition Odile Jacob, 2005, p151)
 Table des matières générale

Partie 1
Introduction....................................................... 9
Chapitre 1.1
Pertinence économique et académique.............................13
1.1.1 Le sigle et la chose............................................................................14
1.1.2 Réussites, échecs et tendances historiques..........................................15
1.1.3 Efforts et résultats économiques pour l’entreprise................................17
1.1.4 Enjeux organisationnels et culture d'entreprise ...................................20
1.1.5 Positionnement académique...............................................................22

Partie 2
Etat de l’art industriel et académique.................. 29
Chapitre 2.1
Caractéristiques et définitions de l'ERP.............................33
2.1.1 Des origines aux définitions................................................................34
2.1.2 Méthodologies et spécificités des projets ERP.......................................46
2.1.3 Enjeux de la standardisation...............................................................55

Chapitre 2.2
Modélisation d’entreprise................................................65
2.2.1 Evolution des méthodes de modélisation ............................................66
2.2.2 Vers le cadre 19439 et le méta-modèle 19440 ....................................70
2.2.3 Modélisation et système d'information.................................................75
2.2.4 Modélisation et modèles de référence..................................................86

Chapitre 2.3
Systèmes d’information et usages...................................97
2.3.1 De l’informatique au système d’information.........................................98
2.3.2 Ingénierie des Systèmes d’Information..............................................102
2.3.3 Maturité des usages d'un S.I. ..........................................................110

Chapitre 2.4
Intégration organisationnelle et informationnelle.............117
2.4.1 Intégration et organisation...............................................................118
2.4.2 Intégration et standardisation...........................................................129
 Partie 3
Démarche d'ingénierie orientée intégration........ 135
Chapitre 3.1
Cadre et méta-modèle de l'intégration...........................139
3.1.1 Cadre de modélisation de l'intégration...............................................140
3.1.2 Méta-modèle de l'intégration............................................................145
3.1.3 Référentiels métiers pour les modèles d'entreprise.............................159

Chapitre 3.2
Graphe d'intégration du modèle d'entreprise...................181
3.2.1 Graphe des dépendances..................................................................182
3.2.2 Sous-graphes d'intégration...............................................................189
3.2.3 Définition de mesures de l'intégration................................................197
3.2.4 Partitionnement d'un graphe d'intégration.........................................201
3.2.5 Couplage et voisinage d'intégration...................................................203
3.2.6 Complexité des algorithmes..............................................................207
3.2.7 Dépendances et maturité des usages des S.I.....................................208

Chapitre 3.3
Ingénierie d'entreprise orientée intégration ...................213
3.3.1 Démarche d'alignement....................................................................215
3.3.2 Démarche d'ingénierie .....................................................................217
3.3.3 Démarche d'alignement et graphe d'intégration.................................223

Chapitre 3.4
Illustration sur des cas académiques et réels..................233
3.4.1 Illustration sur un cas académique....................................................234
3.4.2 Illustration sur le cas BAAN..............................................................245
3.4.3 Illustration sur le cas SCOR..............................................................252

Partie 4
Conclusions et Perspectives.............................. 257
Chapitre 4.1
Conclusions et perspectives académiques.......................259
4.1.1 Conclusion au détour du terrain........................................................260
4.1.2 Perspectives pour le cadre de modélisation........................................265
4.1.3 Perspectives pour le graphe d'intégration...........................................267

Chapitre 4.2
Perspectives d'applications industrielles..........................271
4.2.1 Navigation non hiérarchique dans un ERP .........................................272
4.2.2 Re-conception architecture applicative ERP .......................................273
4.2.3 Vers un configurateur de projet ERP..................................................274

Partie 5
Annexes ........................................................ 279
Annexe 1 Liste des fonctions de l'ERP BAAN....................280

Annexe 2 Liste de construits de modélisation..................281

Annexe 3 Liste des blocs de construction SAP A1............282

Annexe 4 Définition des briques applicatives...................283

Annexe 5 Algorithmes utilisés........................................287

Annexe 6 Bibliographie.................................................291

Annexe 7 Listes des figures ..........................................305

Annexe 8 Listes des Tableaux........................................307

 Partie 1

Introduction

Dans cette première partie, nous introduisons notre problématique à

partir des enjeux émergents des projets d'intégration de système
d'information à base de progiciel et nous précisons le plan général de
ce document. Nous présentons ensuite les enjeux économiques et
industriels de ces projets à partir des échecs et des gains potentiels,
en identifiant notamment la dimension organisationnelle des difficultés
qui fondent la nécessité de nos travaux. Nous illustrons enfin le
positionnement académique de la recherche d'une définition claire des
conditions de réussite des projets de système d'information et
d'efficience des usages de ces systèmes.
 Introduction / Introduction

Chapitre 1.1
Pertinence économique et académique.............................13
1.1.1 Le sigle et la chose............................................................................14
1.1.2 Réussites, échecs et tendances historiques..........................................15
1.1.3 Efforts et résultats économiques pour l’entreprise................................17
1.1.4 Enjeux organisationnels et culture d'entreprise ...................................20
1.1.5 Positionnement académique...............................................................22

L es systèmes d’informations (S.I.) des organisations privées ou publiques sont

désormais le plus souvent construits à partir d’applications standard du marché
qui doivent être configurées, paramétrées et intégrées dans un environnement
spécifique à chaque entreprise. Ils deviennent des « Systèmes d'informations
intégrés » dans le double sens d’un plus fort couplage entre leurs composants
applicatifs et d’une plus forte interdépendance entre les outils informatiques et les
pratiques collaboratives que développent les organisations avec le support de ces
outils.
Dans le cycle de vie de ces systèmes d’information, l’intégration est
devenue un facteur critique de la configuration, de la mise en œuvre et de l’usage.
Cette intégration informationnelle accompagne et permet en effet l’intégration des
processus opérationnels dans un contexte d’accélération des flux physiques,
informationnels et financiers et de réduction des temps de cycles de conception, de
production et de distribution.
Concrétisant les idées générales de l’intégration des systèmes de
production étudiée dans le « Computed Integrated Manufacturing » (CIM) des
années 80 qui ont connu des applications nombreuses sur l’organisation de la
production et commencé à peser sur les systèmes de gestion, les S.I. sont de plus
des « systèmes socio-techniques » dans lesquels le facteur humain joue un rôle
prépondérant qui ne peut se réduire à un mécanisme. Les compétences mises en

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Partie 1
Institut National des Sciences Appliquées de Lyon 10
 Introduction / Introduction

œuvre, les modes de management, les conflits d’intérêts, les réorganisations

économiques conditionnent et parfois transforment les usages des S.I. qui sont ainsi
des systèmes évolutifs et complexes. Comprendre et maîtriser l’intégration des S.I.
est un élément essentiel de la maîtrise de leurs usages, de leur amélioration continue
au service de leur contribution à la performance.
Cette intégration peut s’analyser de l’intérieur des S.I par la
compréhension des contraintes d’intégrité, d’interopérabilité, de synchronisation qui
traduisent dans les objets techniques des S.I leur interdépendance fonctionnelle.
Elle nécessite aussi d'étudier les S.I. comme outils supports des processus
d’entreprises, donc d’articuler objets techniques et processus métiers dans un
modèle permettant d’évaluer la contribution des composants aux performances des
processus ou d’évaluer les conséquences de la ré-ingénierie de processus sur les S.I.
L’articulation entre cette vue interne ou technique et une vue externe ou d’usage des
S.I permet de proposer une modélisation de la complexité organisationnelle,
fonctionnelle et informationnelle qui soit à la fois un outil d’évaluation et un outil
opérationnel de pilotage.
La place des applications appelées « Enterprise Resource Planning » (ERP)
est significative de cette tendance lourde à la construction de S.I à partir
d’applications standards. Leur étude comme application informatique, en tant que
projet de mise en œuvre et en tant que système d’information en exploitation est
donc représentative des problématiques actuelles de contribution des technologies
de l’information à la performance du pilotage des organisations. Nous proposerons
au chapitre 2.1 un historique des définitions de ce trigramme en nous limitant dans
un premier temps à l’acception courante de progiciel standard de gestion intégrée
d’entreprise diffusé sur le marché et qui conduit à la traduction de « Progiciel de
Gestion Intégré » (P.G.I.).
Cette première partie présente le contexte du travail réalisé et souligne les
enjeux industriels et financiers que représentent la tendance longue vers plus
d’intégration et de standardisation des systèmes d’information, la nécessité de
coordonner les points de vue des sciences de gestion, de l’information et de
l’ingénieur. Elle définira ainsi la pertinence économique et académique de l’objet
d’étude « ERP » pour mieux caractériser la problématique d’intégration, dans une
démarche de retour d’expérience.
La deuxième partie présentera un état de l’art des recherches académiques
sur les ERP et leurs conséquences sur les systèmes d’information et proposera une
histoire des définitions de l’ERP afin d’en dégager les tendances de fond que
recouvrent la profusion des sigles et des offres. Elle éclaircira notamment l’enjeu de
la modélisation d’entreprise comme cadre de conception, d’intégration et de
pilotage des S.I. et élargira leur approche en prenant en compte leur usage dans ses

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Partie 1
Institut National des Sciences Appliquées de Lyon 11
 Introduction / Introduction

dimensions humaines et organisationnelles, avant de caractériser le concept

d'intégration comme un ensemble de dépendances. Cette partie contient des
contributions réalisées dans une activité de recherche préparant cette thèse dans les
années 2000-2005 notamment sur la caractérisation de l’intégration sous-jacente
aux ERP, les méthodologies spécifiques des projets, les conditions d’efficacité des
usages des systèmes d’information à base d’ERP.
La troisième partie étudie l'intégration organisationnelle et
informationnelle en utilisant les concepts et outils de la modélisation, des systèmes
d'information et de l'intégration présentés précédemment. Elle propose un cadre et
une démarche d'ingénierie autour d’un modèle de cohérence organisationnelle et
informationnelle reposant sur un « graphe d'intégration ». Ce graphe d'intégration
enrichit la modélisation et repose sur l'étude des objets, modèles et référentiels
existants. En permettant une « mesure » de l'intégration, il permet d'outiller la prise
en compte des modes d’intégration dans la modélisation, de construire des
représentations utilisables des dépendances organisationnelle et informationnelle. Il
permet ainsi de proposer une ingénierie d'entreprise orientée par l'analyse de
l'intégration mettant l'accent sur la maîtrise de l’alignement des composantes du
modèle d'entreprise et notamment des systèmes d’information aux stratégies
d’entreprise. Le cadre et la démarche proposée sont illustrées sur un cas académique
et des cas réels issus de l'expérience.
La quatrième partie présente les perspectives industrielles et académiques
ouvertes par le cadre proposé, esquisse des applications support de cette prise en
compte de l'intégration dans l'ingénierie des S.I. et propose en conclusion d'ouvrir
un champ de recherche sur une ingénierie dirigée par les modèles orientée pour et
par l'intégration.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Partie 1
Institut National des Sciences Appliquées de Lyon 12
 Introduction / Pertinence économique et académique

Chapitre 1.1
Pertinence économique et
académique

Dans ce chapitre, nous présentons le sigle répandu symbole de notre

problématique, « ERP », et l'histoire des enjeux perçus des projets de
systèmes d'information construits à partir de ce type de progiciel
standard. Nous éclairons la pertinence d'un travail de connaissance sur
cette présence désormais incontournable de « briques » standard dans
l'ingénierie d'entreprises, à partir du constat des échecs initiaux et des
enjeux économiques constatés par les acteurs. Nous insistons sur leur
forte dimension organisationnelle qui fonde la pluridisciplinarité de
notre objet de recherche.

La réalité d’un marché généralisé et ses différentes formes de

communication dans les entreprises utilisatrices ou prestataires ne
représentent pas nécessairement un enjeu de recherche ou
d’innovation. Mais les enjeux économiques confirment la nécessité
d’un effort de recherche aidant à mieux caractériser les facteurs de
succès et d’échec pour proposer des approches et méthodes facilitant
leur maîtrise. Cet effort de recherche se développe dans les années
1990/2000 et constitue le contexte de cette thèse.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 13
 Introduction / Pertinence économique et académique

1.1.1 Le sigle et la chose

L e terme ERP est proposé en 1990 comme une extension du sigle MRP par un
organisme de conseil des états-unis, le Gartner Group (Wylie 1990). Comme
tous les sigles qui apparaissent régulièrement sur le marché informatique, il est
d’abord une dénomination marketing, mais peut révéler une évolution historique
réelle. C’est le cas puisque après sa diffusion rapide au cours des années 90 et sa
mise en cause autour de l’année 2001, il est resté un terme communément utilisé,
parfois de manière extensive pour désigner toute application de gestion proposée sur
le marché, de celles destinées à de très petites entreprises et assurant les fonctions
de base de gestion comptable et commerciale, jusqu’à de grandes applications dont
l’étendue fonctionnelle s’enrichit à chaque version pour couvrir les besoins
évolutifs de très grandes multinationales, de l’aide à la décision ou la planification
stratégique à l’exploitation, de la maintenance de sites industriels, la gestion
internationale des ressources humaines à la gestion prévisionnelle des flux de
devises.
Le sigle est loin de résumer les réalités des entreprises utilisatrices. Le plus
souvent, elles n'intègrent pas réellement les fonctions de planification, ne gèrent
pas non plus précisément les ressources au delà du contrôle de gestion. Mais le
troisième terme portant sur l'entreprise traduit la vraie ambition de l'ERP; la
capacité d'intégrer toutes les fonctions de l'entreprise autour d'un seul système
servant les besoins des différents départements (Koch et al., 2000). Cette intégration
est mise en valeur par la traduction française de Progiciel de Gestion Intégré (P.G.I.)
qui oublie malheureusement le terme entreprise. Mais quelque soit le sigle, les
définitions retenues et les différences importantes constatées selon les projets et les
usages, le terme ERP reste pertinent pour identifier une tendance de fond et de
longue durée à l’évolution des systèmes d’information d’organisations vers une
intégration toujours plus forte.
D'autant que les ERP mis en œuvre d’abord dans de grandes entreprises se
sont progressivement généralisés jusqu’aux petites et moyennes entreprises. Une
enquête de 2002 en France évalue à 54% les entreprises de plus de 100 personnes
étant en exploitation ou en cours de mise en œuvre auxquels s’ajoutent 13%
d’entreprises étudiant un tel projet (Canonne et Damret 2002). Le phénomène n’a
pas été stoppé par la crise internet des années 2000-2001. La durée des projets étant
le plus souvent supérieure à 1 an (64% entre 1 et 4 ans) tout comme la durée de vie

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 14
 Introduction / Pertinence économique et académique

de l’ERP installé estimée selon la même étude à 81% de plus de 5 ans et même pour
31% de plus de 10 ans, conduit à constater que ce phénomène est durable et
représente une réelle transformation des systèmes d’information. Ces chiffres
confortent les études réalisées aux USA (Mabert et la.,2000) qui montrent que plus
de 75% des entreprises industrielles de toute taille ont installé un ERP ou sont en
cours de projet, comme celles réalisées dans de nombreux pays (Kumar et al., 2002)
au Canada, (Olhager et Selldin 2003) en Suède ou (Zhe Zhang et al. 2005) en Chine.
Le niveau de pénétration des ERP sur un marché semble être aussi
dépendant des caractéristiques nationales et culturelles comme le montre le nombre
d’éditeurs en Europe du Nord et le taux élevé d’installations en entreprise y compris
de taille moyenne (75% en 2003 dans les entreprises industrielles de taille moyenne
en Suède). Ce développement se diffuse dans tous les secteurs, y compris loin de
l’industrie discrète, dans la construction (Bergstrom et Stehn 2005), ou le secteur
public au Canada (Kumar et al., 2002). L'ERP est bien une réalité de l'entreprise.

1.1.2 Réussites, échecs et tendances historiques

L a littérature académique et économique relate de nombreux échecs de projets

de type ERP, décrit les difficultés de ces systèmes à répondre aux attentes des
entreprises, et propose souvent des alternatives possibles aux acteurs dominants de
ce marché.
Dans un premier temps, des applications connexes à l’ERP ont joué un rôle
grandissant et semblait mettre en cause l’intégration sur une seule plateforme. Le
CRM à la fin des années 90, puis le SCM aux débuts des années 2000 ont joué ce
rôle « alternatif » à l’ERP dans la construction des architectures applicatives.
Autour des années 2000, dans le contexte de la crise de la « nouvelle économie »
liée au développement d’Internet, des professionnels ont même parlé de fin d'un
mythe, ou de « mort de l’ERP » (Bond et al., 2000). Mais les années suivantes ont
montré la permanence et la généralisation du phénomène ERP notamment dans les
entreprises de taille moyenne, et dans le déploiement en interne dans les
multinationales.
De fait, les principaux éditeurs d’ERP ont progressivement pris en compte
ces solutions (souvent par rachat externe) pour les intégrer dans leur plateforme
principale. Cela a conduit certains à parler d’ERPII, évolution du sigle proposée
encore par le Gartner Group qui n’aura pas le succès du sigle initial bien que repris
par d’autres auteurs pour illustrer l’extension de l’intégration des fonctions de
l’entreprise sur les nouvelles versions des ERP (Paulus 2002), (Weston Jr. 2003),
(Møller 2005), (Beatty et Williams 2006).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 15
 Introduction / Pertinence économique et académique

De plus, si les enquêtes menées dans les années 1990 faisaient ressortir que
seuls moins de 20% des projets étaient réalisés dans les délais et le budget,
l’enquête de Deloitte & Touche réalisée en France en 2002 (Labruyere et al., 2002)
indique que 56% des projets ont respecté le budget initial, et que la moitié des
projets ont démarré dans les temps impartis. Le marché de l’ERP est désormais un
marché plus mature, les compétences disponibles dans les entreprises utilisatrices,
comme chez les éditeurs et les prestataires sont expérimentées et les processus de
décision autant commerciaux que techniques sont mieux connus et maîtrisés.
Enfin, le nombre d’éditeurs d’applications de gestion couvrant tous les
domaines applicatifs continue à se réduire par concentration économique des
acteurs1 . Les solutions applicatives s’intègrent ainsi progressivement sur quelques
plateformes technologiques communes, des bases de données centralisées, des
processus métiers transverses tournés vers l’intégration.
Si la réalité des systèmes d’information d’entreprise reste marquée par la
diversité des applications cohabitant, c’est d’abord le fait de l’histoire de ces
systèmes dans les fusions, cessions, restructurations de ces entreprises. L’objectif le
plus souvent affiché de standardisation et de centralisation se réalise dans des
projets pragmatiques qui conduisent souvent à conserver une certaine hétérogénéité
quand le coût de l’intégration n’est pas justifié dans un contexte économique donné.
Le constat de cette diversité des applications existantes dans une entreprise
a conduit à proposer la standardisation de l’interopérabilité entre applications
comme une alternative à la standardisation et la concentration des applications sur
quelques leaders. Une telle approche permet à des « équipementiers » du logiciel de
proposer des applications ciblées sur un domaine ou une fonction particulière dans
des conditions assurant la facilité de leur intégration à de « grands » systèmes de
type ERP.
Pourtant les tendances du marché jusqu’en 2006 n’ont pas réellement
confirmé ces attentes. Si le sigle « EAI » (Enterprise Application Integration) 2 a
progressivement laissé la place au « SOA » (Service Oriented Architecture)3, les
innovations technologiques proposées sont en fait intégrées par les grands éditeurs
d’ERP. Et si les principaux acteurs annoncent des stratégies d’ouverture aux
produits partenaires, c’est toujours dans le cadre de leur plateforme technologique.
Les produits partenaires doivent alors être compatibles avec les structures des objets
métiers, les protocoles d’échange, la gestion des données de base des ERP avec
lesquels ils veulent interagir.

1 voir le site [Link] qui liste la succession des rachats)

2 [Link]
3 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 16
 Introduction / Pertinence économique et académique

Ces innovations confortent ainsi la prédominance économique de solutions

standardisées même si la présentation commerciale cherche à couvrir la diversité
des besoins. On voit ainsi se multiplier les versions « pré paramétrées » adaptées à
un marché ou un pays particulier, reproduisant ainsi les mécanismes de
« différenciation retardée » de l’industrie automobile, puisque ces versions pré
paramétrées sont de fait des solutions standard adaptées par un travail de
« packaging » à des secteurs d’activité précis. Certains évoquent des architectures à
base de progiciels « commercial off the shelf (COTS) » (Abts et Boehm 1997)
(Albert et Brownsword 2002) et proposent de nouvelles démarches de projets
associées.

1.1.3 Efforts et résultats économiques pour

l’entreprise

L es enjeux économiques sont classiquement ceux des dépenses informatiques et

du célèbre paradoxe de Solow
« You can see the computer age everywhere but in the productivity statistics. »4.
Mais les enjeux des projets ERP sont surtout mesurables à l’importance des
risques d’échecs et de leurs conséquences pour l’entreprise. Un des échecs les plus
connus est celui de la Fox Meyer Drug, géant de la distribution pharmaceutique
conduit à la faillite après un projet ERP et revendue pour une part infime de sa
valeur précédente (Boston Group 2000). En 1997, aux dires de ses dirigeants, après
2 ans ½ d’efforts et plus de 100 millions de dollars d’investissements, l’entreprise
ne traitait plus que 2,4 % des commandes quotidiennes gérées avec l’ancien
système, et ce, avec de nombreuses erreurs. D’autres cas sont connus comme
l’abandon d’un projet jugé trop rigide pour la croissance rapide de DELL après 10
millions de $ de dépenses (Trunick 1999). Ce constat n’est pas limité aux projets
ERP proprement dit mais est général aux projets S.I. dont 2/3 sont abandonnés (Kim
2004). Plus globalement, les titres d’articles de la presse économique sont
significatifs de la prise de conscience des risques (Buckhout et al., 1999), « Au
secours, l’ERP arrive dans mon entreprise! » (Chardavoine 2002). De nombreux
autres témoignages illustrent cette réalisé des risques économiques, comme le cas
de la société GRAINGER qui voit ses bénéfices réduit de 45% selon elle, suite à
l’installation d’un ERP (Stedman 2000). Une étude plus générale évoque la
controverse sur la réalité des retours sur investissements (Donovan 2000).

4 (Robert Solow, New York Review of Books, 12 juillet 1987)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 17
 Introduction / Pertinence économique et académique

Les enjeux se mesurent aussi aux coûts de possession de ces systèmes

étudiés par le META Group qui publie une étude sur le coût total de possession
(Total Cost of Ownership : TCO) des ERP, incluant le matériel, les logiciels, les
prestations de services et les coûts des acteurs internes, pour le projet d’installation
et les deux premières années de fonctionnement avec les coûts réels de
maintenance, amélioration et évolution du système. Les résultats font apparaître
pour un panel représentatif de la diversité des entreprises en terme d’activité et de
taille, un TCO de 15 Millions de $, le minimum étant de 400 000$ et le maximum
de 300 millions de $. Cette étude permet de constater que le coût de possession de
l’ERP est élevé quelque soit le type de l’entreprise concerné (Koch et al., 2000). De
fait, les gains économiques ne sont pas toujours au rendez-vous, notamment
concernant les coûts de structure, et pire, les difficultés du projet peuvent conduire à
une augmentation des coûts comme le montre une étude du cabinet AMR Research :
« Studies show that while inventory may be reduced, planned headcount
reductions are often unachieved. After years of lean manufacturing operation,
many companies find little opportunity to further reduce cost under traditional
ROI metrics,[...] Worse yet, experienced managers know that ERP
implementations done badly can create more transactions and increase costs.»
(Caruso 1999)
Cela conduit certains à prendre en compte des éléments qualitatifs dans les
calculs de retour sur investissements (Murphy et Simon 2002) en considérant que
des résultats immatériels peuvent influer à terme sur les prix, les coûts et le volume
des ventes. Dans cette perspective, certains considèrent l’ERP comme une
immobilisation incorporelle qui peut apparaître en tant qu’élément d’actif dans un
bilan. C’est ce que souhaitent 80% des analystes financiers de la Société Française
des Analystes Financiers qui constatent que le capital immatériel prend une part
toujours plus importante dans la vie économique, plus de 80% de l’investissement
en système d’information des entreprises, plus de 4,5% du PIB des USA en
technologie de l’information et processus organisationnels associés (CIGREF 2006).
Sans nier la réalité des échecs et des actions correctrices significatives
nécessaires, certains considèrent que ces difficultés viennent d’abord de projets mal
définis et mal planifiés, sans objectifs réalistes d’amélioration des processus.
« Positive ROI comes from changing the way business was performed in the
past to more streamlined, faster and lower cost processes that better serve the
needs of customer » (Donovan 2000).
Ces résultats potentiels positifs sont confirmés par les résultats de l’usage
à moyen terme établis par les analystes financiers. Une étude longitudinale sur les
performances financières comparées de 60 entreprises américaines ayant mis en

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 18
 Introduction / Pertinence économique et académique

œuvre un ERP (adopters) comparées à des entreprises similaires ne l’ayant pas fait
démontre un avantage clair à moyen terme :
« Results indicate that return on assets (ROA), return on investment (ROI), and
asset turnover (ATO) were significantly better over a 3-year period for
adopters, as compared to non adopters » (Hunton et al., 2003).
Cette étude confirme des résultats antérieurs qui, tout en soulignant
l’absence de résultats mesurables financièrement à court terme, montraient à partir
de 3 ans de mise en exploitation un impact significatif sur le prix de revient des
marchandises vendues, ainsi que sur la productivité totale exprimée en effectifs
comparés aux revenus (Poston et Grabski 2001). De nombreux témoignages
montrent qu’une fois passée la première année difficile de fonctionnement, des
améliorations sont obtenues par une meilleure intégration de l’ERP dans
l’organisation (Lombard 2002).

L a problématique du projet ERP ne concerne pas que la phase initiale de

découverte par l’entreprise et de mise en œuvre dans un périmètre souvent plus
réduit que prévu. La situation plus ou moins avancée résultante du projet initial est
une étape dans un cycle de vie complet des S.I. dans lesquels les phases de
changement de version, d’évolution de périmètre peuvent impliquer des décisions
d’investissements aussi importantes que le projet initial. Un exemple illustratif est
donné par (Shepherd et Boulanger 2000) à partir d’une étude sur un panel
d’entreprise ayant mis en œuvre SAP R/3 et dont la plupart n’ont pas réalisé le
projet dans le périmètre prévu, laissant pour des phases ultérieures de nombreuses
entités ou filiales. Ces entreprises sont alors confrontées à des décisions
stratégiques liées à la poursuite ou non de la transformation de leur S.I. autour de
l’ERP choisi : mise en œuvre d'une nouvelle version majeure de l'éditeur (de SAP à
mySAP), poursuite du déploiement dans l'organisation, réorientation des ressources
sur des domaines liés à la relation client ou la chaîne logistique. Ces questions sont
bien sûr fortement dépendante de l'appréciation sur la capacité de l'éditeur à fournir
les technologies et les applications nécessaires à un marché mondial.
L’enjeu économique des projets ERP n’est donc pas limité à une période
historique qui serait terminée et correspondait à la diffusion d’une innovation
technologique, mais bien à une transformation du rôle des S.I. qui oblige à
s’interroger sur leur contribution à la performance de l’entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 19
 Introduction / Pertinence économique et académique

1.1.4 Enjeux organisationnels et culture d'entreprise

L a dimension organisationnelle des projets ERP est soulignée bien entendu par
les sociologues du travail comme l’Association Nationale pour l’Amélioration
des Conditions de Travail (ANACT) qui, étudiant les conséquences des projets ERP
souligne que
« L’usage et la mise en place de cet outil demandent du temps et de
l’investissement. (...) seule une véritable réflexion sur l’organisation peut
permettre à ce système de révéler ses capacité,. (...) Les effets attendus des
applications informatiques sont de grande ampleur quand on fait évoluer en
même temps l’organisation, les hommes et les systèmes d’information »
(ANACT 2004).
L’étude conduite pour l’ANACT révèle les conséquences fortes sur
l’organisation et les acteurs humains d’une mise en œuvre d’un ERP :
changement du travail, voire du métier dans certaines fonctions,
structuration de fonctions qui n’existaient pas auparavant comme telle,
perception nette des conséquences d’une saisie de donnée désormais effectuée
une seule fois et utilisé par tous les services concernés…
rôle du contrôle renforcé car les erreurs sont beaucoup plus couteuses,
représentation du système de travail des utilisateurs clefs leur donnant enfin une
vision de ce que les autres font dans l’entreprise. Ce qui, à terme, a des effets
positifs sur la coordination d’ensemble.
Cette dimension organisationnelle des projets ERP explique l’importance
des conflits qui peuvent être révélés ou provoqués par les changements qu’un tel
projet génère. Ces conflits peuvent être
« des conflits concernant les tâches à réaliser et les moyens optimaux de le
faire, des conflits de définition des postes et de la perception de leur contenu et
de leur valeur selon les sites ou les pays, enfin des conflits de gouvernance
concernant la répartition des pouvoirs et les contributions de chaque acteur à
la performance » (Besson 1999).
Ces conflits révèlent souvent des enjeux « culturels » liés aux
représentations que les acteurs se font de leur rôle et de la nature du contrôle que
l’entreprise exerce sur eux. C’est la conclusion d’une étude sur des entreprises
considérant avoir « réussi » leur projet ERP. Les auteurs concluent que la difficulté
principale n’était ni dans le nouveau système, ni même dans le fait du changement
par lui-même, mais dans l’introduction d’une discipline contrôlée dans une
organisation « relativement indisciplinée » :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 20
 Introduction / Pertinence économique et académique

« This was a major cultural change - one that to many employees did not
immediately seem an improvement » (Ross et Vitale 2000)
Les mêmes constats sont faits dans des cas de réussite de projet ERP lourd
comme le projet Rolls Royce (Yusuf et al., 2004).

U ne étude dans les grandes entreprises françaises identifie des caractéristiques

communes aux projets ERP et soulignent des enjeux organisationnels
typiques (Dubarry et Bauvais 1999) :
de nouveaux processus, profils et compétences pour les utilisateurs,
des projets qui échappent à la direction informatique,
la nécessité de la création d’un centre de compétences ERP.
Des études plus précises montrent des changements effectifs de certains
métiers fortement impactés par l’existence d’ERP. Bien que les ERP furent critiqués
pour leur insuffisante aide à la décision, la construction d’une base de données
commune à l’ensemble de l’entreprise permet de mettre en relation les résultats et
les évènements ayant contribué à ces résultats, transformant profondément les
métiers du contrôle de gestion et plus généralement l’aide à la décision. Des
fonctionnalités clefs des ERP transforment les processus de décision : base de
donnée intégrée, disponibilité d’informations transversales, volume de donnée
disponible, responsabilité des données, données multi-organisationnelles,
indicateurs financiers et non financiers disponibles (O'Donnell et David 2000).
Les enjeux organisationnels ne peuvent être pris en compte seulement par
un effort de formation ou de « préparation » des acteurs humains au projet. Au
contraire, les attitudes dépendantes des métiers et des positions dans l’entreprise
sont un facteur crucial des projets.
« Employee attitudes toward ERP systems and how these systems are
introduced into organizations can either hinder or facilitate implementation
success, despite the rational approach to change an organization may take.
Furthermore, employee attitudes toward ERP systems are dynamic, changing
over time as employees experience the ERP system more directly » (Abdinnour-
Helm et al., 2003)
Ces attitudes préalables peuvent être considérées comme des « croyances »
qui ne peuvent évoluer que par une interaction humaine dans les pratiques même du
projet ERP et qui nécessitent des moyens importants de formation et de
communication afin d’agir sur les représentations que les acteurs se font de
l’utilisabilité et de l’utilité de la technologie :
« both training and project communication influence the shared beliefs that
users form about the benefits of the technology and that the shared beliefs

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 21
 Introduction / Pertinence économique et académique

influence the perceived usefulness and ease of use of the technology »

(Amoako-Gyampah et Salam 2004).
Plus généralement, le rôle des technologies de l’information dans la
collaboration rendue virtuelle par la distance entre les acteurs que créent les réseaux
et la centralisation suppose une « confiance » qui doit être créée par le
management :
« higher utilization of ICT for supporting collaborative work is largely
dependent on the business strategy, which promotes trust among parties »
(Hossain et Wigand 2004).
C’est enfin dans le cycle de vie des entreprises que doivent être envisagés
les ERP dont les projets sont impactés ou même parfois provoqués par des
restructurations d’entreprise à l’occasion de fusions ou cessions, notamment dans un
contexte international (Bouillot 1999).

1.1.5 Positionnement académique

L a recherche sur les ERP s’est construite progressivement selon les disciplines
et s’est accéléré avec la généralisation de ces systèmes dans les entreprises.
Des numéros spéciaux ERP apparaissent d'abord dans le domaine du management
des systèmes d’information (S.I.) .
« Several recent, or about to appear, journal special issues on ERP (Journal of
Information Technology, Journal of Decision Systems, Database, Journal of
Management Information Systems, Business Process Management Journal, and
Australian Accounting Review... » (Klaus et al., 2000).
Les auteurs présentent une analyse des thèmes des articles parus entre
1997 et 2000 dans les conférences S.I. qui concerne les problèmes de mise en
œuvre, l’enseignement avec les ERP et la description de recherches en cours. Ils
proposent une explication du « retard » apparent des recherches académiques sur le
déploiement des ERP sur le marché à partir d’un questionnaire complété par 12
chercheurs réputés dans le domaine des systèmes d’information qui parfois
contestent ce retard, parfois le considèrent comme normal compte tenu du temps
nécessaire pour évaluer et prendre en compte une tendance du marché, ou parfois
soulignent les difficultés logistiques et de compétences que pose une recherche
appliquée sur des systèmes de très grande taille, certains évoquant cependant une
« mise en cause » des compétences existantes induites par ce « packaging » à
grande échelle des applications.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 22
 Introduction / Pertinence économique et académique

Sans doute la rapidité du phénomène commercial a-t-elle des explications

économiques. L’importance du marketing dans un contexte de croissance forte d’un
marché innovant ou les parts de marché à acquérir pour fonder les gains futurs a pu
masquer les tendances de fond à l’intégration qui étaient pourtant connues au plan
académique et faisaient l’objet de nombreuses publications qui ne semblaient pas
avoir d’effet sur les décisions d’investissements.
« Enterprise and business process modelling is still seen as the domain of
consultants in re-engineering projects rather than as a decision support tool in
day-to-day operation. Therefore, an information dissemination and
demonstration campaign is still needed to get the industrial community to know
and to accept enterprise engineering and integration as a new tool helping
them » (Kosanke et Nell 1999).
Les statistiques montrent cependant que la recherche sur les ERP devient
mature en 2000 avec de premiers numéros spéciaux de revues comme le montre la
Figure 1.1 (Klaus et al., 2000) .
Il est vrai que la prise en compte des compétences nécessaires aux projets
ERP dans les cursus universitaires devient un enjeu (Watson et Schneider 1999).
C’est de la confrontation entre l’expérience concrète des projets ERP et les
problématiques de recherche académique existantes qu’il a été nécessaire
d’identifier les pistes de recherche adaptées induites par ces projets d’intégration
basés sur des ERP (Millet et Botta-Genoulaz 2002).

SAP R/3 Strong ERP

SAP R/3 released in coverage in the
released the USA trade press

1992 1995 1996 1997/1998 2000

ERP first T Davenport ERP at IS ERP in IS
mentionned megapackages conferences journals

Figure 1.1: Adoption of the ERP concept in IS academie .

Ces recherches sont toujours d’actualité comme le note l’éditorial d’un

numéro spécial de la revue European Journal of Operational Research :
« Overall, what we see in this special issue is that we are still early in the
research life cycle on ERP systems where we are still trying to understand what
is making them work and what does and does not work in organizations »
(Sarkis et Gunasekaran 2003).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 23
 Introduction / Pertinence économique et académique

L’état des lieux des recherches dans un numéro spécial de la revue

« Computer In Industry » confirme une croissance des publications académiques au-
delà des revus spécialisées en système d’information (Botta-Genoulaz et al., 2005).
La recherche porte notamment sur les enjeux organisationnels de ces projets
(Davenport 1998), (Bouillot 1999), (O'Donnell et David 2000), (Ross et Vitale
2000). De nombreuses études illustrent encore plus profondément l’enjeu culturel
de ces projets comme le montre une analyse d’un projet de gestion des ventes dans
une grande entreprise pharmaceutique en Europe du Nord :
« Results provide evidence for an association between organisational culture
and ERP implementation problems but no direct evidence for an association
between national culture and implementation problems » (Krumbholz et Maiden
2001).
De même les phases amont des projets sont étudiées pour prendre en
compte les aspects culturels et les spécificités nationales, les stratégies
organisationnelles et les processus de prise de décisions, dans les démarches de
Business Process Reengineering (BPR) des projets . (Saint-leger et al., 2002) .

D e nombreuses études ont portées sur les méthodologies de projet donnant

désormais un cadre reconnu des principales phases d’un projet ERP (Poston et
Grabski 2001), (Boutin 2001), (Kumar et al., 2003), (Deixonne 2001), (Markus et
Tanis 2000), (Ross et Vitale 2000). Ces méthodologies sont associées à des facteurs
clefs de succès largement discutés eux-aussi (Al-Mashari et al., 2003), (Holland et
Light 1999) et (Mabert et al., 2001). De premières études ont portés sur la relation
entre les facteurs clefs de succès des projets et les facteurs critiques de performance
dans les phases d’après-projet et la perception des utilisateurs (Nicolaou 2004),
(Somers et Nelson 2004), (Calisir et Calisir 2004). Il en ressort que :
« la complexité potentielle d'un projet d’intégration ne réside pas uniquement
dans l'ERP d'un coté et l'entreprise de l'autre, mais bien dans leur mode de
rapprochement » (Botta-Genoulaz 2005).
C’est d’ailleurs dans l’étude d’un projet ERP « comme une suite de conflits
qui s'accélèrent et s'amplifient à mesure que le projet se concrétise » que la
recherche en management cherche les conditions de la maîtrise de ce rapprochement
(Besson 1999).
Il ressort de l’ensemble de ces études à la fois la nécessité de méthodes de
conduite de projet tournées vers l’alignement entre les systèmes d’information et la
stratégie d’entreprise et l’importance de ne pas considérer uniquement les phases de
mise en œuvre de projet, mais de prendre en compte le cycle de vie complet depuis
les phases amont qui définiront le contexte de réalisation du projet avec ses
dimensions culturelles et managériales, et les phases aval qui sont de fait les phases

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 24
 Introduction / Pertinence économique et académique

ou les résultats pourront ou non être construits par le « bon usage » des systèmes au
service de la performance de l’entreprise.

D ans ce cadre, comme le note le rapport de l’action spécifique PRODLOG du

CNRS il est essentiel d’avancer dans la « modélisation et mesure de la
complexité organisationnelle, fonctionnelle et informationnelle » (Erschler 2003).
Cet enjeu est abordé par Lam et Shankararaman (2004) proposant un « mapping »
des processus sur les composants, ou par Verwijmeren (Verwijmeren 2004) et Choi
(Choi et al., 2004) qui étudient dans une démarche sociotechnique les
caractéristiques des standards de modélisation de processus et leur capacité à faire
converger les technologies.
De même, si les publications sur le cadre méthodologique des projets ou
les facteurs clefs de succès sont désormais nombreuses, leur efficacité à représenter
le cycle de vie des ERP dans l’entreprise reste incomplète comme le montre l’étude
comparant pour les acteurs et activités significatives des projets, l’importance
évoquée dans la littérature académique et l’importance mesurée en questionnant les
acteurs clefs d’un grand nombre de projets (Somers et Nelson 2004). Les auteurs
concluent sur l’importance des phases de pré-projet et post-projet qui représentent
les écarts les plus importants :
« Its focus beyond the adoption and acceptance stages of implementation to
include both pre- and post-implementation behavior. This appears to be
particularly important for ERP systems ».

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 25
 Introduction / Pertinence économique et académique

L ’objectif de cette thèse est de prolonger les travaux reliant le point de vue
interne de ces systèmes de gestion intégré, et notamment la modélisation de
leur complexité informationnelle, avec les points de vue externes explicitant les
conditions d’efficacité des usages et leur contribution à la performance d’une
organisation. Pour cela, elle mobilise les points de vue de la modélisation
d’entreprise et de la modélisation des systèmes d’information afin de repérer
les concepts nécessaire à la modélisation de l’intégration, autant au plan des
rôles, responsabilités, processus, organisations et de leurs relations qui
permettent d'expliciter l’intégration organisationnelle, qu’au plan des
applications, fonctionnalités, données programmes, interfaces et de leur
interopérabilité qui permettent d’expliciter l’intégration informationelle. Pour
ces différents concepts, des « modèles de référence » sont recherchés afin de
tenir compte de l’impact des solutions standard et des « bonnes pratiques » sur
cette double intégration organisationnelle et informationnelle. L’intégration est
explicitée sous forme de « dépendances » entre différents types d’objets
organisationnels ou informationnels afin de proposer un modèle de la
complexité des systèmes d’information intégrés.

C ette cohérence entre point de vue externe et interne oblige à s’interroger

avec les sciences sociales et humaines, les sciences de la gestion et du
management sur les interactions entre les technologies et l’organisation, entre
les systèmes et les acteurs, c'est-à-dire à proposer un double point de vue :
systémique à partir des disciplines des sciences de l’ingénieur, de la
modélisation des systèmes, mais aussi « sociologique » en interrogeant le point
de vue des utilisateurs et la réalité des « usages » dans leur dimension
conflictuelle et incertaine.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 26
 Introduction / Pertinence économique et académique

Les enjeux économiques que soulève la place des ERP dans les
systèmes d’information sont bien réels, concernent les entreprises de
toutes activités et de toutes tailles, et sont, au-delà des projets ERP
eux-mêmes, des enjeux permanents sur la place et le rôle des
systèmes d’information comme composant et support de la stratégie
d’entreprise.

Les ERP ne constituent pas un défi uniquement technique, centré sur

les systèmes d’informations et leur support informatique. Au contraire,
tout montre que les principaux enjeux relèvent de l’organisation et du
facteur humain dans les entreprises. Les projets ERP conduisent à des
transformations de l’organisation, depuis de simples changements de
procédure et de mode d’interaction entre acteurs, à des redéfinitions
de postes de travail, voire de services, et toujours à une redéfinition
des modes de pilotage et de contrôle. Ces transformations ont une
dimension culturelle et sociale dont la prise en compte est essentielle à
la réussite des projets.

La recherche sur et autour des ERP s’est progressivement développée

à partir des approches « système d’information » et « management ».
Elle est devenue indispensable à la maîtrise de la contribution des
systèmes d’information à la performance des organisations, mêlant
ainsi dans une approche pluridisciplinaire les technologies
informatiques (architectures, interopérabilité, intégration), l'ingénierie
d'entreprise et les pratiques managériales (pilotage d'entreprise,
conduite du changement, différenciation, performance) dans la
conception, l’intégration et l’usage de ces systèmes. Elle fait une
grande place aux approches processus à la fois comme facteur de
réussite des projets et comme cadre de représentation conceptuelle
des relations entre système d’information et pratiques métiers dans
l’organisation.

Cette première partie nous a permis d'établir la pertinence

économique et académique d'un champ de recherche lié aux projets
d'intégration de système d'information en entreprise. Sa nature
profondément pluridisciplinaire mêlant problématique informatique,
d'ingénierie, de management nous conduit à mettre au cœur de nos
travaux la notion d'intégration dans ses dimensions informationnelles
et organisationnelles. Nous formulons ainsi la problématique générale
de l'alignement des S.I. comme la recherche de cohérence entre les
points de vue possibles sur l'intégration, cohérence que nous
chercherons à caractériser dans un cadre de modélisation d'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 1 / Chapitre 1.1
Institut National des Sciences Appliquées de Lyon 27
Partie 2

Etat de l’art industriel et

académique
 Etat de l’art industriel et académique / Etat de l’art industriel et académique

Si le terme « ERP » a acquis une légitimité due essentiellement à sa

notoriété et à sa lisibilité sur le marché, il n’en reste pas moins très
flou pour identifier l’objet de la recherche qui est rendue nécessaire. Si
une définition usuelle de « progiciel regroupant sur une même base de
donnée le plus grand ensemble possible de fonctionnalités de gestion
d’entreprise » semble dans un premier temps suffisante, on peut
évoquer derrière ce sigle le progiciel conçu, développé et distribué par
un éditeur (le « produit » ERP), le projet de mise en œuvre de tels
progiciels dans une entreprise (le « projet » ERP), le système
d’information en exploitation construit sur de tels progiciels (l’ERP en
« usage »), ou plus profondément encore les transformations de long
terme des systèmes d’information que révèlent le marché de l’ERP
comme l’intégration et la centralisation, tendances qui concernent
aussi d’autres types de progiciels ou même des développements
spécifiques reproduisant certaines caractéristiques des ERP.

Après avoir identifié ce que recouvre le terme « ERP », défini les

principaux enjeux et points de vue rencontrés, proposé une définition
et un cadre d'étude pluridisciplinaire de cette réalité, prenant en
compte les systèmes et leurs usage, les méthodologies de projet et le
cycle de vie des systèmes, caractérisé la tendance longue à la
standardisation des systèmes d'information, nous proposerons
successivement :

● une étude des méthodes de modélisation d'entreprise et des

systèmes d'information et de leur contribution à la maîtrise des
projets ERP sur lesquels nous nous appuierons ensuite pour
établir un méta-modèle et identifier notre cadre de
modélisation.

● une étude des systèmes d’information, dans leurs dimensions

technologiques et humaines pour caractériser l'importance des
usages et des pratiques dans la contribution de ces systèmes à
la performance organisationnelle.

● une étude de l'intégration dans l'entreprise d'un point de vue

organisationnel et inter-organisationnel, des rapports entre
intégration et systèmes d'information, technologies et
modélisation pour identifier les enjeux d'une intégration
organisationnelle et informationnelle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Partie 2
Institut National des Sciences Appliquées de Lyon 30
 Etat de l’art industriel et académique / Etat de l’art industriel et académique

Chapitre 2.1
Caractéristiques et définitions de l'ERP.............................33
2.1.1 Des origines aux définitions................................................................34
1 Diversité des origines...............................................................................34
2 Définitions et évolutions...........................................................................37
3 Outils et usages........................................................................................44
2.1.2 Méthodologies et spécificités des projets ERP.......................................46
1 Facteurs clefs de succès............................................................................46
2 Méthodologies de mise en œuvre...............................................................48
3 Cycle de vie et centres de compétences.....................................................53
2.1.3 Enjeux de la standardisation...............................................................55
1 Standardisation des technologies, des applications et des pratiques............55
2 Standardisation, intégration et modélisation..............................................57
3 Standardisation et centralisation...............................................................59
4 Standardisation et innovation ...................................................................61

Chapitre 2.2
Modélisation d’entreprise................................................65
2.2.1 Evolution des méthodes de modélisation ............................................66
1 Suite IDEF................................................................................................66
2 Méthode GIM et modèle GRAI....................................................................66
3 Méthode CIM-OSA.....................................................................................67
4 Méthode ARIS...........................................................................................68
5 Méthode GERAM.......................................................................................69
6 Synthèse proposée par le modèle ATHENA.................................................69
2.2.2 Vers le cadre 19439 et le méta-modèle 19440 ....................................70
2.2.3 Modélisation et système d'information.................................................75
1 Modélisation d’entreprise et de système d'information................................75
2 Modélisation d'entreprise et ERP................................................................78
3 Outils de modélisation pour les projets ERP................................................83
2.2.4 Modélisation et modèles de référence..................................................86
1 Manuel de processus du MIT......................................................................88
2 Norme ISA S95.........................................................................................90
3 Modèle SCOR : référentiel des processus de la chaîne logistique.................91
4 Modèles de références, taxonomies et ontologies.......................................93

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Partie 2
Institut National des Sciences Appliquées de Lyon 31
 Etat de l’art industriel et académique / Etat de l’art industriel et académique

Chapitre 2.3
Systèmes d’information et usages...................................97
2.3.1 De l’informatique au système d’information.........................................98
2.3.2 Ingénierie des Systèmes d’Information..............................................102
1 Zachman : un premier cadre d'ingénierie des S.I. ...................................103
2 Approche USDP.......................................................................................105
3 Alignement des S.I. et de l'organisation...................................................106
2.3.3 Maturité des usages d'un S.I. ..........................................................110
1 Apprentissage et confiance......................................................................110
2 Modèles de maturité ..............................................................................111
3 Matrice de maturité d'usage d'un système ERP.........................................113

Chapitre 2.4
Intégration organisationnelle et informationnelle.............117
2.4.1 Intégration et organisation...............................................................118
1 Intégration et coordination......................................................................118
2 Intégration informationnelle....................................................................121
3 Intégration, dépendance et couplage.......................................................122
4 Intégration et partitionnement................................................................125
2.4.2 Intégration et standardisation...........................................................129
1 Intégration et ERP..................................................................................129
2 Intégration et modélisation d’entreprise...................................................131

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Partie 2
Institut National des Sciences Appliquées de Lyon 32
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

Chapitre 2.1
Caractéristiques et
définitions de l'ERP

Les origines des différents systèmes se présentant comme des ERP

sont très diverses. Depuis les offres construites pour les centres de
décision de très grandes multinationales jusqu’aux « produits sur
l’étagère » destinés aux très petites entreprises, de l’industrie
manufacturière aux activités de services à la personne, des exigences
de haute sécurité des industries de la défense aux besoins de flexibilité
de l’industrie de la mode, les produits, les projets et les pratiques liés
à l’ERP se sont construits dans une grande variété de situations. Les
définitions qui ont été proposées se sont progressivement dégagées
des origines dominantes de l’industrie manufacturière et du MRP pour
se généraliser autour des concepts d’intégration, de modèles,
d’alignement organisationnel.

Ce chapitre propose un historique des tentatives de compréhension de

cette « vague » ERP qui a déferlé sur les entreprises avant d'être
étudiée par les chercheurs. Il discute les définitions qui ont été
proposées, les caractéristiques de ce que recouvre le sigle, autant en
terme de produits, de systèmes que de projets et de pratiques. Il
propose ainsi d'identifier les tendances de fond qui transforment les
systèmes d'information des entreprises de tout type, et plus
généralement des organisations économiques et sociales.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 33
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

2.1.1 Des origines aux définitions

1 Diversité des origines

L es définitions proposées pour ces systèmes de gestion intégrés d’entreprise sont

marquées à la fois par la diversité des entreprises engagées dans leur mise en
œuvre et par la prédominance dans les premières années des secteurs de l’industrie
discrète, qui ont été les premiers à généraliser les ERP. C’est sans doute ce qui
explique que de nombreuses définitions proposées s’inscrivent dans la continuité du
MRP considéré comme une étape dans l’intégration des fonctions de l’entreprise
autour de la production, l’ERP venant étendre cette intégration de manière plus
systématique autour de la gestion financière. (Klaus et al., 2000). Une revue
américaine donne ainsi après les premières années de la vague commerciale ERP un
taux de pénétration par secteur économique (Tableau 2.1) très différencié selon les
secteurs :

Secteur Industriel Pas de projet Recherche ou projet En place

Tous secteurs 47% 34% 19%
Ingénierie de production 25% 35% 40%
Ingénierie mécanique 5% 31% 64%
Electronique 4% 33% 63%
Distribution 50% 32% 18%
Banque et Finance 39% 48% 13%
Assurance 65% 27% 8%
Santé 64% 26% 10%
Secteur public 50% 34% 16%
Transport 57% 33% 10%
Administrations 62% 25% 13%

Tableau 2.1 : Taux de pénétration ERP par secteur (Harriss et Huneke 1999)

Cette diversité du niveau de pénétration des ERP se retrouve aussi dans le

niveau de satisfaction des utilisateurs (Tableau 2.2) très différencié selon les
fonctions, avec 89% de satisfaits et très satisfaits pour la finance contre 41% de très
mécontents pour la R&D et un équilibre de 32% de très satisfaits et 24% de très
mécontents pour la planification ou seulement 37% de très satisfaits pour le contrôle
de gestion présenté pourtant souvent comme le point fort de l’ERP.
L’étude serait sans doute très différente selon les ERP dont les marchés
d’origine ont marqués l’étendue et l’enrichissement fonctionnel; SAP pour la

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 34
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

finance notamment dans les grands groupes et la capacité à modéliser des

organisations complexes, PeopleSoft pour la gestion des ressources humaines, ou
BAAN pour la gestion industrielle et la recherche d’une mise en œuvre des concepts
du MRPII définis par l’APICS.
Comme le souligne un mémoire sur les ERP la diversité des situations
vécues en regard de l’ERP explique une diversité de perceptions et donc de
définitions (Mourlon et Neyer 2002). C’est la parabole de l’éléphant 5, comparant
l’ERP à un objet d’une si grande taille que chacun n’en perçoit qu’un aspect, tirant
alors des conclusions erronées.
Satisfaction Utilisateur <10% <25% <50% <75% <100% 100%
Module
Finance / Comptabilité 0,0% 5,6% 5,6% 25,9% 57,3% 5,6%
Gestion des matières 3,5% 5,3% 15,8% 21,0% 38,6% 15,8%
Planification de production 6,8% 16,9% 15,2% 28,9% 27,1% 5,1%
Gestion Commandes client 0,0% 1,7% 15,5% 29,3% 36,2% 17,3%
Achats 1,7% 5,1% 11,9% 23,7% 49,1% 8,5%
Contrôle de gestion 7,7% 5,8% 11,6% 38,4% 30,7% 5,8%
Logistique et distribution 8,7% 6,5% 10,9% 41,3% 28,3% 4,3%
Immobilisations, RH, qualité 11,1% 11,1% 8,3% 25,0% 36,2% 8,3%
Maintenance 28,6% 4,7% 14,3% 14,3% 28,6% 9,5%
Gestion R&D 35,3% 5,9% 23,5% 5,9% 17,6% 11,8%
TOUT DOMAINE 10,3% 6,9% 13,3% 25,4% 35,0% 9,2%

Tableau 2.2. Satisfaction Utilisateur par Module (Canonne et Damret 2002)

I l faut cependant éclairer l’origine dominante des projets dans l’industrie

discrète ; l’ERP comme prolongement des approches MRP. Ce point de vue se
trouve légitimé par le constat que les éditeurs qui faisaient la une du marché en
explosion des années 95 étaient des éditeurs de solutions MRP et de solutions
financières dans les années 80. C’est le cas des principaux acteurs coté au Nasdaq à
l’époque ; SAP, INTENTIA, BAAN, ORACLE, JD Edwards, QAD… SAP R/2
prédécesseur de l’ERP leader apparait en 1973 comme une application de gestion
intégrée bien avant le sigle ERP. Les premières applications logicielles packagées

5 « Il était une fois, en Hindoustan, six aveugles fort curieux qui décidèrent de « voir » l’éléphant. Le premier
s’approche de l’animal, il heurte son large flanc. Aussitôt de s’exclamer : « Mon Dieu, que cet éléphant est dur !
Sûr, ce doit être un mur. » Le deuxième palpe une défense, la trouve ronde et lisse et pointue : « Pour moi, c’est
l’évidence, cet éléphant est une lance ! » Le troisième se trompe sur la trompe : « Cet éléphant tient vraiment du
serpent ! » Le quatrième tâte le genou : « Je dis que c’est un arbre de chez nous. » Le cinquième, qui caresse
l’oreille, conclut à un éventail tandis que le sixième, guère plus malin, s’agrippe à la queue comme au bout d’un
filin. Et voilà nos six aveugles qui se disputent haut et fort, chacun ayant un peu raison, et tous globalement tort.
» (Mintzberg et al, 1998)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 35
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

l’ont été pour la comptabilité et le support de démarche MRP (sous le nom de

GPAO en France). Mais malgré les concepts de « boucles » dans le MRPII, la
plupart des mises en œuvre MRP ont été « linéarisés » compte tenu de l’absence
d’outils facilitant la recherche de l’équilibre entre besoins et ressources (Scheer
1994b). La recherche d’une plus grande intégration a conduit à l’émergence du CIM
« Computed Integrated Manufacturing » défini comme
« The integrated management of information for all business and technical
functions of a manufacturer » (Scheer 1994b).
Basé sur le MRP et les fonctions de conception aidée par informatique
(CAO, CFAO), ce cadre orienté industrie a pu être facilement étendu à des secteurs
comme la distribution (Beckert et al., 1997). Cette intégration du CIM se
concentrait sur les aspects industriels tout en insistant sur la recherche de modèles
de données communs et de processus partagés, bien que les applications packagées
ne soient pas encore disponibles. De ce point de vue l’ERP est la continuation de la
recherche de l’intégration du CIM, un des premiers articles académiques évoquant
l’ERP le situant d’ailleurs sous le titre de « CIMII the integrated manufacturing
enterprise » (Lopes 1992).
La filiation au MRP est soulignée par Davenport pour qui l’ERP est :
« a turbocharged version of manufacturing resource planning (MRP II),
modified and strengthened to help manufacturers face the competitive
challenges of the 1990s ». (Davenport 1996)
L’ERP est considéré à cette époque par l’APICS simplement comme un
nouveau support technique de mise en œuvre complète de l’approche MRPII
« Un Système d’Information orienté finance pour identifier et planifier les
ressources globales de l’entreprise nécessaires pour fabriquer, livrer, et
facturer aux clients. Un système d’ERP diffère d’un système typique MRP II
suivant des impératifs techniques tels que l’interface utilisateur, la base de
données relationnelle, l’utilisation d’un langage de développement évolué et
d’outils d’ingénierie logicielle, l’architecture client/serveur, et la définition
d’un système ouvert et portable. » (APICS 2002)

C ependant, l’ERP introduit plusieurs nouveautés, étendant le domaine de

l’intégration de la fabrication que traitait le CIM à l’ensemble de l’entreprise
dans ses relations avec ses partenaires fournisseurs et clients. Contrairement à son
acronyme insistant sur la gestion des ressources, l’ERP est d’abord centré sur une
vue processus et ne propose pas généralement de solutions de planification de
ressources plus avancées que les applications MRP précédentes. De nombreux
auteurs proposent des termes plus généraux, comme « Enterprise Systems »
(Davenport 2000), (Laudon et Laudon 2000).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 36
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

Cette diversité d’origine des offres et des projets est soumise à une phase
de concentration économique dans les années 2000 qui provoque une nouvelle
vague de standardisation. Cette phase de concentration se constate sur tous les
segments de marché. C’est le cas des plus grands (Oracle rachetant en 2005
PeopleSoft qui avait racheté en 2003 JdEdwards, soit les numéros 2,3 et 4 du
marché), mais aussi des offres de taille moyenne : intégration de Geac, Infor, SSA,
BAAN pour produire un groupe de taille mondiale intégrant des dizaines de
solutions dont la plupart sont en fin de cycle de vie, et encore du marché des petites
entreprises pour lesquelles se déroule une guerre des moyens avec le rachat par
Microsoft de Great Plains et Navision qui venait de racheter Damgaard, de Sage
achetant Concept et Timberline, et de SAP achetant Business One pour être présent
sur ce segment. Cette concentration provoque bien sûr une standardisation des
fonctionnalités portées par les différents offreurs, mais a aussi comme conséquence
d’élargir toujours plus la diversité des activités concernées par l’ERP et donc la
diversité des fonctionnalités nécessaires, des processus à supporter, des contextes
juridiques et métiers à respecter.

2 Définitions et évolutions...

L e terme a été utilisé pour la première fois par le Gartner Group (Wylie 1990)
organisme de conseil qui avait été un des promoteurs du concept du MRP et
avait diffusé le sigle MRPII. Il est cité comme le nouveau paradigme des systèmes
d’information dans un article proposant le concept de « CIMII » allant au-delà du
MRPII dans l’intégration des fournisseurs et clients (Lopes 1992) .
Davenport introduit le terme dans le monde académique des systèmes
d’informations en proposant le terme de « mega-package » (Davenport 1996)
soulignant l’assemblage de plusieurs applications souvent préexistantes que
représente l’ERP. Il utilisera ensuite l’expression « Enterprise System » pour étudier
comment la standardisation des processus impliqués par les ERP est une contrainte
qui peut être transformé en une aide efficace à la ré-ingénierie et l’optimisation de
ces mêmes processus (Davenport 1998). Les années suivantes voient se multiplier
les présentations en conférences puis les articles de revues qui proposent des
définitions et des caractérisations diverses des ERP.
La littérature a beaucoup tergiversé sur la « définition » d’un ERP. Les
premières définitions « informatiques » insistent sur les conséquences techniques de
l’intégration et de la centralisation notamment des données. C’est ainsi que l'ERP
est initialement défini comme un système transactionnel émanant d'un concepteur
unique et garantissant l'unicité d'une information mise à jour en temps réel, avec un

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 37
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

audit permettant la traçabilité des opérations de gestion et couvrant plusieurs

fonctions de gestion. (Tomas et Miranda 1999). Complétant ces premières
caractéristiques par l'existence d'un référentiel unique des données, d'autres
définitions prennent en compte la relation entre spécificité de l'entreprise et
standardisation en demandant à l'ERP une capacité d'adaptation rapide aux règles de
fonctionnement de l'entreprise et l'existence d'outils de personnalisation de
compléments applicatifs (Lequeux 1999). Dans le même souci, d’autres auteurs
soulignent que les modules de l’ERP doivent être fortement paramétrables et qu’ils
embarquent dans les processus et méthodes codés dans le logiciel les « meilleures
pratiques » des processus d’un secteur d’activité.
Une des premières conséquences de cette unicité de l'information est la
centralisation qu'implique toujours l'ERP et ses effets sur les systèmes existants
souvent associés à chaque direction de l’entreprise, et dans le résultat sur un
système cible proposant dans une base unique de répondre aux besoins transversaux
de toute une entreprise.
« That is a tall order, building a single software program that serves the needs
of people in finance as well as it does the people in human resources and in the
warehouse. Each of those departments typically has its own computer system,
each optimized for the particular ways that the department does its work. But
ERP combines them all together into a single, integrated software program that
runs off a single database so that the various departments can more easily
share information and communicate with each other. » (Koch et al., 2000).
C’est encore ce que traduit la définition proposée par le Club des
Directions Informatiques des Grandes Entreprises Françaises.
« On définit par ERP (Enterprise Resource Planning), un sous-ensemble du
système d’information capable de prendre en charge la gestion intégrale de
l’entreprise, incluant la gestion comptable et financière, la gestion de la
production et de la logistique, la gestion des ressources humaines, la gestion
administrative ainsi que la gestion des ventes et des achats. » (Dubarry et
Bauvais 1999).
Si l’ERP semble conçu d’abord pour supporter des processus répétitifs
(achats, production), il s’étend progressivement à des processus moins structurés et
peu régulier comme le marketing ou la gestion de projet, ainsi qu’à d’autres
secteurs économiques dont les services ou les administrations conduisant à
l’intégration de nouvelles fonctionnalités liées aux métiers rencontrés dans ces
secteurs (administration, hôpitaux, universités…) (Grimson et al., 2000), (Bakker et
Leguit 1999), (S. V. Scott et Wagner 2003), (Kumar et al., 2002), (Pegah et al.,
2003). Ce développement dans les services étend fortement l’intégration des

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 38
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

ressources humaines avec les fonctions de planification (Botta-Genoulaz et Millet

2006).
Un périmètre fonctionnel type d’un ERP de taille moyenne dans le secteur
industriel est illustré par la liste des fonctions principales du modèle standard de
référence de l’ERP BAAN6. Cette liste propose une décomposition modulaire qui
représente une configuration grossière d’un périmètre applicatif (Tableau 5.1 en
page 280). On trouve une traduction moins technique de ces définitions dans une
note de l’association nationale pour l’amélioration des conditions de travail qui
anime un groupe de réflexion sur les conséquences de l’informatisation sur les
pratiques de travail
« Garantir l’unicité de l’information, assurer la mise à jour en temps réel des
informations modifiées dans tous les modules affectés, fournir des possibilités
d’audit basées sur la garantie d’une totale traçabilité des opérations de
gestion » (ANACT 2004).
Ces premières définitions provenant d’utilisateurs ou de consultants
insistent sur l’étendue fonctionnelle couverte par les ERP alors que les définitions
provenant des sciences de gestion et du management sont plus tournées vers la
conduite du changement et les enjeux organisationnels. Cette évolution est illustrée
par les deux définitions anglo-saxonnes proposées à trois ans d’intervalles par
l'association américaine d’ingénieurs en génie industriel, l’APICS. En 2002, la
dixième édition de son dictionnaire définit l’ERP comme :
« An Enterprise Resource Planning system is an integrated software package
composed by a set of standard functional modules (Production, Sales, Human
Resources, Finance etc.), developed or integrated by the vendor, that could be
adapted to the specific needs of each customer. It attempts to integrate all
departments and functions across a company onto a single computer system
that can serve all those different departments’ particular needs. » (APICS 2002)
En 2005, la onzième édition du même dictionnaire la définition devient :
« Framework for organizing, defining, and standardizing the business
processes necessary to effectively plan and control an organization so the
organization can use its internal knowledge to seek external advantage. »
(APICS 2005)
De fait, il faut un certain temps pour voir émerger une relative cohérence
entre les points de vue technologique, fonctionnel et managérial dans la définition
des ERP, chaque expert proposant une définition dépendante de sa perspective ou de
son intention avant de premières définitions « multi vues »

6 dans sa version 6 (appelée depuis le rachat de BAAN par SSA puis INFOR, INFOR ERP LN)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 39
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

« A comprehensive, packaged software solutions seek to integrate the complete

range of a business's processes and functions in order to present a holistic view
of the business from a single information and IT architecture » (Klaus et al.,
2000).
Au-delà de la centralisation, cette définition met l'accent sur la
transversalité que représente une approche processus support d’une plus grande
intégration des rôles des acteurs, les auteurs précisant que le support d'un processus
d'affaires à travers les fonctions conduit un utilisateur à interagir avec un système
sans nécessairement savoir dans quel module fonctionnel il travaille.
De même, le suivi des activités de l’entreprise que permet l'ERP ne suffit
pas à en assurer l’intégration. Les processus de décision et de pilotage sont (plus ou
moins bien) supportés par l’entreprise. Les ERP sont ainsi difficilement classable
dans les catégories traditionnelles des systèmes d’informations identifiés
précédemment. L’ERP est à la fois un système transactionnel et un système
décisionnel (Alter 1999).
Mais ces systèmes n’existent pas en dehors des projets qui les mettent en
œuvre. L’ERP « sur l’étagère » est bien un produit dont les spécifications techniques
et fonctionnelles sont plus ou moins documentées, mais qui est entièrement défini
par elles. L’ERP installé dans une entreprise a été configuré dans un environnement
technique donné (système d’exploitation, système de gestion de base de donnée,
système d’authentification des accès, connexion aux ressources d’impression, de
services réseau, langues d’utilisation, activation de particularités nationales ou de
secteur d’activité, de certains modules et pas tous…). Il est accessible à travers des
environnements de formation, de test, de développement, de production qui
contiennent ou non des bases de données de test (jeux d’essais, scénarios de
présentation…). Cet ERP « installé » est déjà en partie spécifique au projet qui va
progressivement renforcer cette « spécialisation » aux caractéristiques de
l’entreprise en positionnant de très nombreux paramètres, en codifiant des données
de base qui vont en faire un « ERP configuré» (ou « paramétré »). De plus,
l’entreprise va souvent adapter certaines parties de l’ERP à ses besoins propres en
modifiant des écrans, des états ou même des programmes pour que le résultat
corresponde à une pratique de gestion de l’entreprise non directement existante dans
le standard. On obtient alors un ERP « adapté », (on dit souvent « personnalisé » à
partir de l'anglicisme « customisé »). L’ERP installé, paramétré et adapté ainsi
déployé dans une organisation qui va pouvoir produire des données et des
documents devient un « système d’information ERP » ou ERP « utilisé ». On obtient
ainsi une vue des transformations du « produit » ERP en système « ERP » qui
représente le processus principal du « projet » ERP (Figure 2.1):

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 40
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

ERP ERP ERP ERP ERP

Acheté Installé Configuré Adapté Utilisé

Figure 2.1: les différents "systèmes" ERP dans le cycle de vie d'un projet S.I.

Ces différentes étapes du cycle de vie d’un ERP au sein d'une entreprise
conduisent à classifier les actions d’adaptation d’un ERP au contexte spécifique
d’une entreprise. On peut distinguer les actions suivantes (Brehm et al., 2001) :
Configuration (customization, dans le vocabulaire SAP); paramétrage ou
codification d’une donnée de base
Mise en œuvre de modules tiers complémentaires
Masques d'écrans, adaptation des écrans de l’interface utilisateur
Editions, réalisation d’état ou documents issus des données ERP
Programmation de procédures, créant des procédures non standard utilisant des
transactions standard de l’ERP
Déclencheurs de base de donnée. Technique de base de donnée déclenchant un
programme externe sur un évènement dans la base de donnée
Programmation ERP, utilisation de l’environnement technique de l’ERP pour
créer de nouveaux programmes, données et transactions
Développement d'interfaces, échanger des données avec des systèmes externes
Modification de sources, modification des sources de l'ERP avec un impact très
important sur la maintenabilité du système résultant.
Mais ces activités techniques ne peuvent résumer un projet ERP. Au
contraire, une analyse détaillée de ces activités confirme leurs caractères multivues
centrés sur la construction d'un système « support » de processus et d'organisations.
Une synthèse des différentes définitions de l’ERP en tant que produit support des
processus de l’entreprise est proposé par Botta-Genoulaz.
« Un ERP est une application informatique paramétrable, modulaire, intégrée
et ouverte, qui vise à fédérer et à optimiser les processus de gestion de
l’entreprise en proposant un référentiel unique et en s’appuyant sur des règles
de gestion standards » (Botta-Genoulaz 2005)
Mais cette définition n’évoque pas l’extension des offres ERP à des
domaines couverts par des applications connexes sur lesquelles insistent les auteurs
introduisant le sigle ERPII :
« Un ERP est une suite d’application de gestion incluant la gestion financière,
la gestion des ressources humaines et soit au moins l’une des deux suivantes :
SCM ou CRM » (Paulus, 2002; Møller 2005)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 41
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

En 2005, l’APICS, situant le cœur de l’ERP dans l'intégration de la

fabrication, du marketing, des ventes et de la finance dans un système d'entreprise,
note l’extension du périmètre de l’intégration :
« Today, the ERP system is complemented by various add-on subsystems, like
advanced planning systems, manufacturing execution system, EDI, data
collection, etc. » (APICS 2005).
Le dictionnaire anglophone du Gartner Group 7 propose trois définitions : la
première concernant la stratégie d’intégration dans le pilotage de l’entreprise, la
deuxième concerne l’ERP dans son périmètre initial d'application intégrant les
domaines de l'entreprise dans un système unique pour optimiser ses processus et
aider à la décision, la dernière associé au sigle ERPII intègre stratégie et application
dans l’entreprise étendue aux relations avec ses partenaires :
« An application and deployment strategy that expands from traditional
enterprise resource planning (ERP) functionality to achieve integration of an
enterprise’s key internal and external collaborative, operational and financial
processes. ERP II starts as an application strategy, setting a vision for the
integration of all enterprise centric, commerce-oriented business processes,
without requiring a single-vendor strategy. As a deployment strategy, ERP II
enables enterprises to determine the degree of single-vendor-centricity needed
to fulfill enterprise process requirements and — through native integration
capabilities — to include best-of-breed components from multiple vendors. ERP
II includes capabilities specific to the enterprise, as well as the ability to
connect the enterprise to key business partners directly or through a private e-
marketplace. The process domain of ERP II includes all collaborative,
operational and financial processes that have the enterprise at the center. See
ERP and e-marketplace. » (GARTNER 2003)
Cette nécessité d’identifier l’ERP comme une stratégie d’intégration dans
l’entreprise étendue est soulignée par un des promoteurs du sigle ERPII :
« the automation and integration of information, processes, and functions in a
manufacturing (or other) environment with the result being a closed loop,
functionally integrated, real-time planning, execution, and control system that
is location- and language-independent and that increasingly includes
customers, vendors, and partners » (Weston Jr. 2003).

P renant en compte cette extension de l’intégration à la connectivité externe de

l’entreprise et renforçant la dimension stratégique de l’intégration
organisationnelle, nous proposons une réécriture de la définition de Botta-Genoulaz
de la manière suivante :
7 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 42
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

« une offre progicielle regroupant des applications paramétrables,

modulaires, intégrées et ouvertes, s’appuyant sur un référentiel unique de
données, de procédures et de règles de gestion. Configuré et adapté au
contexte d’une entreprise, il devient le support d’une stratégie d’intégration
qui vise à fédérer et à optimiser les processus de gestion de l’entreprise et de
relation avec ses partenaires »
Cette définition orientée « ERP II » ne supprime pas la nécessité de définir
aussi les sigles d’autres applications parfois présentés comme alternatifs à l’ERP
qui seront présentés dans l'annexe 5 page 283) et qui rythment les évolutions des
S.I. La Figure 2.2 croise les évolutions dans la nature des informations (des données
nécessaires aux transactions aux connaissances utiles à la gestion des compétences)
et le périmètre d’activité concerné (de la fonction isolée au réseau des partenaires
de l’entreprise).

Business
Knowledged Advanced Decision Game
Ingtelligence
management Support Systems ? Theory ?
Packages
Information
Scope Original Functionnality
ES Standard of ES packages with Supply-Chain
Process Contribution
Equipment added functionnality of management
management Measurment
bold-ons and integration
?

Baseline Increasing
Transaction « pre- Automated
Functionnality of ES Database
Automation history » Ordering
Databases Integration

Internal Internal Integrated Supply Chain Peer Group

Indivudal
Business domain

Figure 2.2: Future application of enterprise system (Davenport 2000)

Ces transformations de longue durée font évoluer les S.I. et leurs marchés
dans une rencontre entre les logiques à l’œuvre du coté des demandes des
entreprises et les logiques technologiques et économiques des éditeurs. Les
demandes évoluent sur deux axes vers la gestion d’information de plus en plus
riches et orientées vers les connaissances nécessaires aux décisions d’acteurs
interagissant dans un réseau de partenaires. Les éditeurs d’ERP chercheront à faire
évoluer leur offre pour étendre leur part de marché dans les dépenses en système
d’information des entreprises et de nouvelles caractéristiques de leur progiciels

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 43
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

émergeront dans le futur. L’exercice des définitions à donc ses limites. Pourquoi
tenter de définir une réalité en perpétuel mouvement. Comme l’écrit Wittgenstein,
ceux qui demandent des définitions sont comme des
« tourists who read Baedeker while they stand before a building and through
reading about the building's history, origins, and so on are kept from seeing it »
cité dans (Klaus, Rosemann, et Gable 2000).

3 Outils et usages

C omme le montre la Figure 2.1 page 41, l’ERP peut être étudié en tant qu’objet
technique, progiciel commercialisé par un éditeur, comportant un certain
nombre de composants (programmes, documents, export de bases de donnée…) qui
deviendront un système informatique configuré pour une entreprise. Mais une fois
adapté à un contexte d’utilisation donné, il devient un des éléments support d’un
système d’information d’entreprise qui va héberger des données et documents
représentant une part de la connaissance des acteurs de l’entreprise. Il est à la fois
une « instanciation » de l’objet technique standard qui fait de chaque installation un
système spécifique, et un « déploiement » de cet objet par les données que les
utilisateurs vont manipuler et qui vont transformer l’objet technique en système
d’information.
L’usage de l’outil ne peut donc se réduire à la définition technologique de
cet outil. Si avec plusieurs milliers d’objets, un progiciel ERP est un outil
compliqué, lorsqu’il est implanté dans une entreprise au service de la gestion des
processus opérationnels et utilisé par des acteurs humains, il devient un système
« socio-technique » complexe. Dans de tels systèmes , les sciences de gestion ont
depuis longtemps montré que les décisions ne pouvaient être des raisonnements
parfaits ayant pour finalité l’atteinte de choix optimaux, mais devait prendre en
compte des processus plus itératifs dans lesquels des acteurs limités dans leur
capacité d’accès et de traitement de l’information cherchaient des compromis
acceptables dans des alternances de réflexion et d’action (Simon 1996).
L’étude des relations entre acteurs et technologies d’un point de vue
sociologique conduit à distinguer les interactions « technologies – technologies »
dans lesquelles les acteurs ont conçu l’interaction pour l’automatiser, les
interactions « hommes – technologies » dans lesquelles les fonctions des systèmes
sont en permanence le résultat des actions des acteurs pour adapter et piloter les
systèmes techniques, et enfin les interactions « hommes – hommes » où ce sont les
technologies qui servent de médiation à l’interaction humaine (Gilbert 2001) . De ce
point de vue, les ERP contiennent des éléments des trois catégories, automatisation

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 44
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

des échanges dans le pilotage d’un flux logistique établi, mise sous contrôle de
processus de gestion comme les approvisionnements ou la planification impliquant
des mesures régulières de performance et des actions correctrices de pilotage ou
paramétrage des systèmes, et enfin processus collaboratifs de décision supportés par
les indicateurs de performance et tableaux de bord fournis par l’ERP. Le facteur
humain est très souvent cité dans les difficultés des projets ERP. Une étude sur un
grand projet a montré l’importance de l’attitude des employés dans la réussite d’un
projet :
« Employee attitudes are a key factor in determining ERP implementation
success or failure. Early attitudes about ERP systems, even before these
systems are implemented, shape employee views that may be difficult to change
once the systems become fully operational» (Abdinnour-Helm et al., 2003)
Pourtant, les attentes des employés peuvent être contradictoires entre
demande de fonctionnalités nouvelles, espoir dans les possibilités (souvent
surévaluées) des technologies et crainte de changement dans leurs pratiques et
relations de travail. L’impact des comportements des différents acteurs va ainsi
marquer profondément le projet et son résultat, c'est-à-dire le système d’information
résultant du projet. Loin de n’être qu'une simple « instanciation » du progiciel, il est
une construction humaine dans laquelle la culture de l’organisation dans la prise en
compte des êtres humains jouera un rôle décisif.
Plus généralement, la technologie ne peut être considérée comme le pilote
de l’entreprise, même si elle a pris une place stratégique au même titre que les
ressources financières ou humaines.
« ERP systems promise to allow managers to retrieve relevant information from
the system at any time and one knows that information is the key determinant of
wealth in the modern economy. However, companies need to realise that if the
ERP system is given too much control, then the foresight that is essential to
quickly adapt to changing external factors can become blunt by an over-
reliance on the technology driving the business. A lack of foresight will almost
certainly mean loss of business » (Davenport 1998)
Une étude sur les publications ERP de 1998 à 2002 montre ainsi que la
standardisation recherchée le plus souvent dans les projets de même que la nécessité
d’aboutir rapidement à un résultat positif ne permet pas de faire apparaître des
avantages compétitifs de la mise en œuvre de l’ERP par lui-même. C’est au
contraire dans la qualité de la mise en œuvre, le raffinement dans la définition des
processus, et l’alignement entre l’ERP et la stratégie d’entreprise que réside les
avantages potentiels :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 45
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

« An examination of the existing research suggests that ERP systems may not
provide a competitive advantage based upon the premises of system value,
distribution, and imitability. This is largely due to the ‘common systems’
approach used for the implementation of most ERP systems. Instead, the source
of competitive advantage may lie in the careful planning and successful
management of ERP projects, refinement of the reengineering of the
organization, and the post-implementation alignment of the ERP system with
the organization’s strategic direction.»(Beard et Sumner 2004).
C’est bien l’usage de l’ERP qui peut être créateur de valeur et non sa seule
mise en œuvre comme le montre encore une étude régionale d’un groupe de travail
du pole productique Rhône-Alpes confirme l’importance d’un travail continu sur
l’amélioration des usages en mesurant la permanence de budgets, de structures et de
projets dans une enquête auprès d’entreprises de taille moyenne de la région (PPRA,
2003). Les conclusions d'études académiques ou professionnelles sont nombreuses
pour le confirmer :
« Unarguably, ReturnOn Investiment comes from process improvments ERP
supports, not from new ERP software » (Donovan 2000) « In essence, ERP
deployment in itself saves nothing and does not improve anything. It’s the
people and processes that create benefits » (Kumar et al., 2003).« la vraie
question n’est plus de savoir si l’entreprise possède le meilleur outil, mais
plutôt de se demander si elle forme les meilleurs artisans pour l’utiliser
efficacement » (Tomas et Miranda 1999)

2.1.2 Méthodologies et spécificités des projets ERP

1 Facteurs clefs de succès

L es difficultés connues des entreprises confrontées aux ERP ont très vite conduit
à étudier les caractéristiques de ces projets afin de rechercher des éléments de
différenciation entre les projets maîtrisés et les projets difficiles, notamment les
conditions de prise en compte des contraintes préexistantes de la solution
progicielle dans les phases traditionnelles de spécification et de conception de
l'ingénierie de système d'information. Tout montre que les ERP portent des
« modèles implicites » qui doivent être pris en compte dans les projets (Boutin
2001). Les études vont très vite conduire à la définition de « facteurs clefs de
succès » qui se diffuseront progressivement dans le monde académique et industriel
(Mabert et al., 2003) Ils mettent en lumière l’importance de l’implication de la

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 46
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

direction générale se traduisant par un comité exécutif de projet fort, une stratégie
claire de formation. Le Tableau 2.3 compare l’importance de différentes activités
mesurée dans des projets ERP en séparant les projets qui sont restés dans le cadre
du budget et ceux qui l'ont dépassé. L'écart mesure ainsi l'importance de l'activité en
tant que « facteur clef » de maîtrise du projet (Labruyere et al, 2002).
La double dimension technique et organisationnelle de ces projets est donc
très vite identifiée, avec de nombreuses études soulignant la nécessité d’aligner les
projets concernant les systèmes d’information avec la stratégie compétitive de
l’entreprise, ce qui rend nécessaire de prendre en compte les dimensions culturelles
et nationales (Yen et Sheu 2004), (Saint-leger et al., 2002).
Hors Dans le Ecart
Activités de préparation du projet ERP budg Budget
et
Définir des indicateurs de performance 53 50 -3
Définir un plan de communication ERP de l'entreprise 92 93 1
Créer une équipe projet ERP avec une salle dédiée 92 100 9
Diffuser les nouvelles données et les résultats juste rapidement 78 87 9
Développer les attendus en matière de gestion 72 87 15
Développer des stratégies claires de changement organisationnel 50 67 17
S'assurer d'un fort soutien de la direction 75 93 18
Définir clairement les résultats attendus 56 77 21
Développer des stratégies claires de formation 67 97 30
Créer un comité exécutif ERP ayant des pouvoirs 69 100 31
S'assurer d'une forte implication de la direction 42 77 35
Posséder les technologies et les infrastructures 50 97 47

Tableau 2.3 : Facteurs de différenciation / Budgets de projet

Les facteurs clefs de succès identifiés par Holland et Light (Holland et

Light 1999) soulignent que les projets ERP sont des projets d’entreprise. Les
facteurs « stratégiques » suivants sont identifiés :
« Legacy systems » pour prendre en compte l’existant de l’entreprise en termes de
processus, d’organisation et de système d’information.
« Business Vision » dont la maîtrise par l’équipe projet conditionne les processus
de prise de décision.
« ERP strategy » qui peut aller du « Big Bang » sur un périmètre large à la mise
en œuvre initial d’un « squelette » réduit aux processus principaux permettant une
montée en puissance progressive de l’ERP dans le système d’information de
l’entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 47
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

« Top Management support » sans lequel le projet ne peut être que vu comme un
projet technique qui ne nécessite pas d’engagement de l’encadrement pour la
conduite du changement.
« Project Schedule and plans » qui suppose une connaissance préalable des
spécificités des projets ERP.
Les facteurs tactiques sont ceux des projets IT de manière générale
auxquels s’ajoute un élément propre aux projets ERP :
« Business Process Change and Software configuration » ou l’adéquation entre
l’organisation et le système d’information se joue dans la capacité à définir les
“bonnes pratiques” pertinentes pour l’entreprise et configurables dans l’ERP.
Une taxonomie proposée de ces facteurs clefs de succès met en relation ces
facteurs de succès et les résultats en termes de « réussite » du projet et de
« bénéfices » résultants pour l’entreprise. La réussite du projet est évaluée par
rapport à l’adéquation du système d’information aux objectifs du projet, à la
maîtrise du budget et du planning de projet, à l’attitude positive des utilisateurs
envers le système et à la réponse aux attentes des utilisateurs. Ces facteurs de
succès illustrent les spécificités et les enjeux pluridisciplinaires des projets ERP et
la nécessité de méthodes de gestion de projet adaptés prenant en compte les
dimensions organisationnels, technologiques et humaines (Al-Mashari et al, 2003).

2 Méthodologies de mise en œuvre

L 'existence de progiciels conçus indépendamment d'un projet qui commençait

traditionnellement par l'expression des besoins de l'entreprise bouleverse la
démarche d'ingénierie de projet informatique (Figure 2.3), mêle les questions
d'architecture et de conception, de marché et de contexte des besoins exprimés
(Oberndorf 2000). Les éditeurs d’ERP ont très vite répondu à cette nécessité en

Figure 2.3: Approche traditionnelle/Approche progicielle

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 48
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

proposant une méthode et des outils de gestion spécifique; ASAP pour SAP
([Link] TARGET pour BAAN ([Link] SIMPLEX pour
MOVEX... ([Link] L’étude de ces méthodes utilisées par les
entreprises révèle une grande diversité de vocabulaire utilisé. Mais elles peuvent
être facilement comparées pour identifier des phases communes dont peut émerger
une généralisation. C’est ce que propose la qui résulte d’une étude de méthodes
académiques et de prestataires de services.
Il apparaît ainsi des points communs qui permettent très vite d’identifier
des caractéristiques propres à ces projets (Botta-Genoulaz 2005) :
l'utilisation plus ou moins poussée de modèles, préexistant ou non,
l'externalisation des compétences, ses avantages et limites, l'implication des
différents acteurs de l'entreprise (de la direction aux syndicats…),
la formation et les plans de gestion des ressources humaines, les modes
d'identification des transformations de postes de travail, de l'accompagnement des
mutations correspondantes,
le phasage du projet en plusieurs étapes de mise en œuvre caractérisées par le
niveau de détail des processus automatisés ou la couverture fonctionnelle ou
d'activité du projet,
le type de démarche de mise en exploitation (big bang ou progressive) et les
modalités de déploiement multi-sites des solutions opérationnelles…
Il s'agit bien de méthodologies de gestion de projet différentes de celles
issues du génie logiciel. Si des tentatives sont faites pour utiliser les approches
existantes du génie logiciel, comme MERISE, elles se heurtent à la caractéristique
principale des projets ERP : le logiciel, sa base de données et donc le modèle de
donnée lui-même est prédéfini au projet alors que dans la méthode MERISE,
comme dans les approches objets, le modèle de données (ou les diagrammes de
classe) sont des outils utilisés en amont des projets dans les phases de conception,
alors que la simple découverte du modèle de donnée d’un ERP est une tâche lourde
qui n’est accessible qu’à des experts après un long apprentissage du référentiel de
l’ERP. De plus, les méthodes classiques sont très fortement centrées sur les
données, et plus limitées dans l'expression des processus pourtant au cœur de
l'intégration dans l'ERP.
Une autre spécificité forte des projets ERP est la coopération nécessaire
entre des acteurs de l’entreprise et des acteurs externes. Comme le montre Deixonne
(2001), un projet ERP requiert une connaissance à la fois des métiers de l’entreprise
et la maîtrise du produit choisi. Or cette double compétence existe rarement en
début de projet ce qui implique un mode de fonctionnement en binôme entre
intervenants internes (apportant la connaissance et le savoir-faire de l’entreprise au

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 49
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

niveau métier) et intervenants externes (apportant le savoir-faire vis-à-vis du

produit choisi et de la mise en œuvre de ce type de projet)
La différenciation entre maîtrise d’œuvre et maîtrise d’ouvrage est ainsi
brouillée puisque les résultats du projet dépendent fortement de l’implication de
l’entreprise. C’est ainsi que des avocats spécialisés préconisent la recherche d’un
« intégrateur maitre d’œuvre » qui ne soit pas le prestataire de compétences ERP
(Meillassoux 2002). En dehors de ces situations limites, la cohérence entre les
processus et les rôles décrits dans un projet et les compétences et connaissances des
acteurs est essentielle (Worley et al., 2005). On parle de méthodologie en spirale
processus-configuration-prototypage dans lequel l’étape processus est une étape de
conception non pas du logiciel, mais de son usage, la configuration est une étape de
production, non pas du logiciel mais de son paramétrage, et le prototypage une
étape de test et recette qui est ici intimement lié à la conception puisque c’est de
manière itérative à partir des simulations effectuées sur le prototype que les
décisions se prendront sur les processus et la configuration correspondante.
La diversité des méthodes et le poids des méthodes propriétaires
nécessitent un travail de standardisation des concepts et des vocabulaires propres
aux projets ERP La littérature académique va progressivement faire émerger
différents modèles de phasage de projet ERP à partir d'études comparatives de
méthodologies propriétaires et de retours d'expériences (Tchokogue et al., 2005)).
Le Tableau 2.4 présente une liste de travaux ou méthodes en éclairant la diversité
des phasages définis.
Authors Type Year Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Rogers Academic 1983 Adoption Implementation
Cooper and Academic 1990 Initiation Adaption Adoption Acceptance
Zmud
Soh and Academic 1995 IT IT assets Organizational
Markus expenditure (implementation) impacts (post-
(adoption) implementation)
Target Vendors 1996 Project Business Mapping ERP Piloting EPR
(Baan) preparation migration
Markus and Academic 2000 Project Project shakedown onwards and
Tanis chartering configuration upwards
Parr et Academic 2000 Planning Project Enhancement
Shanks
Asap (SAP) Vendors 2001 Project Busines blueprint Realization Final phase Go live
preparation
Yussuf et al Business 2004 Strategy & Planning analysis Early Focus on Pilot
Case direction & convergence deployment operations focus

Tableau 2.4 : Méthodologies de mise en œuvre

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 50
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

Ces travaux ont convergés vers le cycle de vie du système ERP défini par
Markus et Tanis (). Il recouvre d’autres études comme (Ross et Vitale 2000) qui
évoque de manière imagée « l’approche » pendant la phase de « design », puis la
« plongée » dans la phase d’ « implementation », puis la « remontée à la surface »
pendant la phase de « stabilization », avant la « nage » pendant la phase de
« continuous improvment », permettant enfin à l’entreprise de maîtriser sa
transformation).Les étapes du modèle de Markus et Tanis sont les suivantes :

Phase de contractualisation ou “fondation” (“des idées au budget”). Cette phase

porte les décisions qui conduisent à l’approbation du projet et à son financement.
Elle implique les dirigeants, spécialistes informatiques, prestataires et offreurs.
Elle peut être pilotée par l’informatique avec une faible implication des dirigeants
ou piloté par la direction avec une faible implication de la direction informatique.
Phase de projet (“du budget aux dépenses”). Elle regroupe les activités de mise
en fonctionnement du système dans une ou plusieurs entités organisationnelles.
Elle concerne un chef de projet et une équipe projet, divers experts techniques et
consultants, les dirigeants membres du comité de pilotage, et d'autre acteurs de
l’organisation dans un rôle consultatif.
Fouille (“des dépenses aux impacts”). C'est la période commençant à la mise en
exploitation jusqu’au retour à une situation normale ou les usages quotidiens ont
été établis. Elle implique les responsables opérationnels, les utilisateurs, les
acteurs restants de l’équipe projet, les ressources du support informatique et du
support externe.
Avancée et progrès (“des impacts aux résultats”). C'est la période d’exploitation
jusqu’au remplacement du système qui nécessite d'organiser la maintenance du
système, le support aux utilisateurs, mais aussi l’amélioration et le changement de
version. Elle concerne encore les responsables opérationnel et utilisateurs, les
ressources de support informatique et de support technique externe.

Ideas to Dollars to Assets to Impacts to

dollars Assets Impacts performance

Phase 1 Phase 2 Phase 3 Phase 4

The Project
Project (configure Onward
Chartering & Roll out) Shakedown and Upward

Figure 2.4: Enterprise System Experience Cycle (Markus et Tanis 2000)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 51
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

La phase de projet est relativement bien détaillée désormais et on peut

distinguer les étapes principales (Botta-Genoulaz et al., 2001) :
Optimisation des processus. Etape qui peut se situer en amont du projet avec le
risque de concevoir des processus optimisés en théorie sans tenir compte de
l’ERP ou qui peut se situer après le choix du système avant la formation des
acteurs, ou même après la formation des acteurs pour leur permettre d’y
participer. De fait, cette optimisation des processus intervient souvent à la fois en
amont et pendant le projet.
Analyse du système et de l’organisation existante. Cette analyse ne devrait pas se
réaliser dans l’objectif de « décrire une solution », mais au contraire d’identifier
les critères de sélection et de décision nécessaire sur les priorités du projet.
Choix du système ERP et contractualisation.
Formation de l’équipe projet.
Paramétrage de l’ERP et formalisation des procédures de travail.
Réalisation des interfaces, outils de migration de données, et développements
spécifiques.
Formation des utilisateurs finaux et finalisation des procédures opérationnelles.
Déploiement du nouveau système.
Accompagnement à la montée en charge et à la stabilisation.
De nombreuses publications soulignent l’importance des compétences
nouvelles que suppose le pilotage de ces projets souvent importants en nombre et
diversité des acteurs concernés. Elles permettent de lister les compétences
nécessaires à la réussite d’un projet (Kræmmergaard et Rose 2002) :
Compétences organisationnelles (travailler avec l’organisation, sa culture, la
répartition et l’historique des pouvoirs),
Compétences stratégiques (relier l’usage de l’ERP aux objectifs et besoins de la
stratégie d’entreprise),
Compétence en gestion de projet (planification, objectifs et identification des
acteurs qualifiés),
Compétences technologiques (politiques informatiques appropriées),
Compétences ERP (connaissances des modules et des données de configurations,
spécifications des écarts),
Compétences en ressources humaines (développer les connaissances des acteurs,
évaluer les besoins en formation et les organiser) ,
Compétences de direction (motiver les acteurs, piloter les adaptations
organisationnelles et les rendre opérationnelles),
Compétences en communication (communiquer les informations pertinentes de
manière appropriée aux différents acteurs),

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 52
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

L es projets de mise en œuvre de solutions de type ERP nécessite des

méthodologies adaptées pour prendre en compte la diversité des acteurs
internes et externes, la diversité des compétences dont la coopération est nécessaire,
pour coordonner les activités techniques, applicatives, organisationnelles et
humaines que nécessitent ces projets. Si le cadre général d'une méthodologie est
désormais connu, il n'existe pas encore de référentiel académique ou normatif des
activités, des rôles et des livrables de tels projets.

3 Cycle de vie et centres de compétences

Le projet ERP ne s’arrête pas à la première mise en exploitation. Au
contraire, le système d’information construit va vivre et se développer ce qui
conduit à considérer le cycle de vie global du système qui est souvent découpé en
phases proches de la proposition de Markus et Tanis. La mise en œuvre proprement
dite de l'ERP n'est qu'une phase dans le cycle de vie du S.I. qui commence par la
préparation et l'organisation du projet, se poursuit par la configuration et le
déploiement de l’ERP, puis vérifie la stabilisation des pratiques afin de maîtriser la
maintenance et les évolutions nécessaires.
Un ERP en usage est en effet un système socio-technique qui nécessite une
fonction de support à l’exploitation, autant pour le bon fonctionnement opérationnel
des processus mis en place (maintenance logicielle, résolution des cas particuliers et
des aléas, gestion des compétences acquises…) que pour l’accompagnement de
l’évolution de l’entreprise (nouveaux produits, nouveaux moyens de production,
formation des nouveaux acteurs, nouvelle activité, réorganisation,…) ou de
l’évolution du système lui-même (performances, sécurisation en extranet,
changement de version, intégration application tiers…).
Mais les attentes « post-projet » sont bien entendu très dépendantes des
résultats du projet lui-même. Dans certains cas, les difficultés et les insuffisances du
projet conduisent à des situations dégradées ou la première préoccupation est de
recréer les conditions d’une maîtrise opérationnelle du système d’information avant
une réelle contribution à la performance de l’entreprise. Les facteurs de succès des
projets sont ainsi étroitement liés aux dimensions critiques des phases suivant la
mise en œuvre comme le montre l’étude approfondie de deux situations réelles,
l’une d’un projet maîtrisé dont les résultats initiaux était positif et l’autre d’un
projet difficile qui a nécessité une longue phase « post-projet » qui a été presque
assimilé à un nouveau projet (Tableau 2.5).
Mais quelle que soit la situation résultante du projet initial, l’usage de
l’ERP sans organisation de support se dégrade progressivement, autant par les
pertes de compétences liées aux départs et restructurations, que par la non réponse

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 53
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

aux cas particuliers ou aléas qui génère la recherche par les acteurs de solutions de
contournement qui, se multipliant, reconstruisent un système d’information en
dehors, parfois contre les processus officiels de l’ERP.
Critical Factors of ERP Critical Dimensions of Success in Post
Implementation Implementation Stage
Top management support and Evaluation of fit with strategic vision.
commitment to project; fit to Review of project planning effectiveness.
business strategy. Evaluation of infrastructure development.
Alignment of people, process, Review of fit resolution strategies.
technology. Evaluation of system integration attainment and
reporting flexibility.
Anticipated Benefits from ERP Evaluation of level of attainment of expected system
implementation project. benefits.
Motivation behind ERP Review of driving principles for project.
implementation (business- vs. Review of project justification practices.
systemled).
Scope of user training. Review of user learning.
Evaluation of effective knowledge transfer (among
project team members and other users).

Tableau 2.5 Aspects critiques de projet et d'après-projet (Nicolaou 2004)

C’est ainsi que la notion de « centre de compétences » se répand

progressivement dans la diversité des situations post-projet. Ce constat se confirme
par de nombreux témoignages qui soulignent l’importance des ressources affectées à
l’exploitation de l’ERP pour améliorer en permanence la contribution du système
d’information aux processus. Cela conduit souvent à des automatisations de
séquences de tâche standard dans l’ERP, des interfaces avec des systèmes externes
ou des éditions de synthèse facilitant la prise de décision.
« La dizaine d’améliorations principales a coûté 0.45 million d’euros incluant
60 mois de développement soit environ une personne par an. Elles ont rapporté
1,7 million d’euros, soit environ 50% du résultat ARO-France avant impôts.
Concernant l’effectif informatique affecté à l’implémentation et à
l’amélioration de l’ERP, le total de l’ERP représentait 8 personnes au
démarrage, 3.5 personnes aujourd’hui » (Lombard 2002).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 54
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

2.1.3 Enjeux de la standardisation

1 Standardisation des technologies, des applications et des pratiques

L a croissance des revenus des éditeurs ERP, malgré la crise des années 2000
traduit un processus continu de standardisation des systèmes d'information.
Cette standardisation concerne bien sûr les technologies qui jouent un rôle clef dans
la réduction du coût des échanges entre entreprises, ce qui pousse malgré la
multiplication des acteurs sur le marché au développement de normes et d’outils ou
plateformes d’échange les supportant. Elle concerne aussi les applications avec la
progression continue du marché des progiciels. Elle concerne enfin les pratiques
métiers, avec les efforts de diffusion de bonnes pratiques, les indicateurs de
performances permettant la comparaison des résultats obtenus, la modélisation de
processus qui ouvre la possibilité de comparer l’organisation de l’entreprise dans
ses processus de gestion indépendamment de ses applications informatiques. De
telles démarches de modélisation permettent la diffusion plus rapide de modèles de
référence comme le modèle SCOR de pilotage de la chaîne logistique (voir section
3.1.3 de la partie 2).
Cette standardisation est identifiée comme un enjeu dans de nombreuses
études sur les facteurs pertinents et les points clés de la contribution des S.I. à la
performance des entreprises. Ainsi Gunasekaran, Ngai et Mc Gaughey (2006)
caractérisant le rôle et l’implication des technologies de l’information dans la
gestion de la chaîne logistique soulignent le besoin de développement de standards
pour leur application à la gestion des chaînes logistiques et la nécessité de recherche
complémentaire pour l’alignement du modèle d’information sur le modèle « supply
chain ».
Cette standardisation sur tous les niveaux (informatique, applicatif et
métier) conduit à un changement majeur du rôle de l’informatique dans l’entreprise.
Les activités de « production » du système d’information ne sont plus centrées sur
le code du logiciel mais comprennent des activités de paramétrage, de modélisation,
de comparaison, de simulations… L’intégration technique des systèmes
d'information (interfaces, échanges de données...) est une part essentielle des
dépenses informatiques, notamment dans les projets ERP et l’intégration
organisationnelle constitue l’essentiel des charges de mise en œuvre, depuis la
modélisation support de la redéfinition du poste de travail à la conduite du
changement pour créer les conditions de la mise en œuvre effective du progiciel.
On peut parler de la naissance d’une nouvelle activité, le « génie progiciel », qui est

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 55
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

encore largement marqué par ses origines informatiques, mais nécessite des
compétences et des méthodes spécifiques.

L a standardisation est parfois opposée à la personnalisation nécessaire des ERP.

Cette contradiction semble difficile à trancher. La moitié des projets suppose
des développements spécifiques jugés « significatifs » ou « très importants », 48%
selon Canone (2002)), mais on peut en déduire que la moitié des projets se limitent
à des développements spécifiques mineurs (46% dans la même étude). Or les
éditeurs continuent à faire évoluer fonctionnellement leurs solutions. Il est fréquent
d’entendre dire sur le marché que la fonctionnalité manquante dans l’ERP dans sa
version « i » sera disponible dans la version « i+1 » ou « i+2 », c'est-à-dire dans un
délai de 2 à 4 ans.
Le Tableau 2.6 montre le résultat d'une étude cherchant à rapprocher
l'importance de la personnalisation et le résultat perçu du projet. Elle montre une
corrélation forte entre respect du standard et résultats perçus. Elle conduit les
auteurs à considérer que :
« les entreprises qui maîtrisent leur budget mettent en œuvre davantage de
fonctions que les autres, elles ont moins de modifications de toute nature que
les autres. Ces modifications engendrent un accroissement de durée du projet
de 50 % et un retard de 6 mois. »

Mesures concernant les fonctions maîtrisant le sous-estimant le

budget budget
Nombre moyen de fonctions/modules 8,1 7,3
installés
Nombre moyen de fonctions/modules 1,7 2,2
ayant subi une légère modification
Nombre moyen de fonctions/modules 0,6 1,6
ayant subi une modification importante

Tableau 2.6 Personnalisation et Budget de projet ERP (Mabert et al 2001)

La standardisation est donc un phénomène réel qui n’épuise pas les besoins des
entreprises mais modifie profondément la place de l’informatique dans
l’organisation. Ce que confirment Tomas et Miranda (1999) :
« L’entreprise n’accroît pas sa compétitivité par le développement de sa propre
solution applicative mais par sa juste configuration, son bon déploiement et sa
pleine utilisation ».
Cette évolution s'accompagne d'ailleurs d'une réelle centralisation, de
retour autant pour l’exploitation des serveurs que pour les architectures
applicatives. Les informations de toute l’entreprise réunies dans une même base de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 56
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

données mises à jour par tous les sites et services pousse à créer des indicateurs
communs, à maîtriser les processus transverses et donc conduit à définir
globalement les procédures de travail qui ne sont plus de la responsabilité locale des
directions hiérarchiques, mais le résultat de projets de réingénierie supposant une
approche plus globale cherchant les synergies et les dépendances transverses à
l’organisation.
Bien sûr, l’ERP ne modifie pas la nature des relations hiérarchiques, mais
il en modifie fortement le contexte et notamment la manière dont est obtenue une
information et dont elle peut être utilisée. Ainsi, dans un système non intégré,
chaque responsable prépare à partir des données sous sa responsabilité le tableau de
synthèse qui lui permettra de présenter ses résultats en tenant compte de ses intérêts,
de sa stratégie. Dans un système intégré, sa marge de manœuvre est beaucoup plus
étroite. Les tableaux de bord sont produits par le système lui-même, ils utilisent des
données partagées par plusieurs fonctions… il n’est pas possible de les « travailler »
directement pour faciliter une présentation « orientée ». Les responsables
intermédiaires sont ainsi souvent bousculés par les premiers mois d’utilisation d’un
ERP avant que les équilibres ne se retrouvent dans le nouveau contexte. Il y a une
véritable crainte de la perte du contrôle qui passait traditionnellement par la
maîtrise de l’information.
Cette standardisation progressive est donc un enjeu technologique,
organisationnel et humain qui rend nécessaire d'éclairer ses causes et ses
conséquences, en un mot ses enjeux.

2 Standardisation, intégration et modélisation

L a standardisation répond d'abord au besoin toujours plus grand de

l’intégration. Face aux exigences de contrôle automatisé et régulier, bien au-
delà du « reporting » manuel et périodique, comme l’est le traditionnel inventaire
annuel, l'entreprise cherche constamment à rapprocher des informations, à corréler
des actions, à synchroniser des données, bref, à intégrer toujours plus fortement les
systèmes de pilotage des différentes activités et fonctions. Cette intégration conduit
à transformer les relations entre acteurs. Une donnée erronée ne peut plus être
corrigée sans trace (ce dont les comptables ont l’habitude depuis longtemps !). Les
erreurs de saisie se propagent immédiatement et peuvent être bloquantes pour des
utilisateurs éloignés. L’utilisateur devient concrètement responsable de la qualité de
la saisie que ses collègues proches ou lointains vont pouvoir utiliser
immédiatement.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 57
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

Un système d’information est intégré quand les logiques propres de chaque

fonction et les liaisons entre ses fonctions sont transparentes à l’utilisateur
opérationnel, qui travaille alors selon des processus métiers transverses. La
mesure de performance opérationnelle se fait alors sur la base
d’indicateurs par processus.
Nous étudierons en détail cette dimension essentielle des systèmes
d’information dans le chapitre 2.4.
Si l’organisation est étroitement liée au système d’information, il est
nécessaire de pouvoir la représenter de manière claire et utilisable le plus
directement possible par les applications. Car cette organisation évolue toujours
plus rapidement. C’est l’enjeu de la modélisation autant des systèmes d'information
que des organisations elles-mêmes. C’est ainsi que se développe fortement depuis
2000 le marché du Business Process Management (BPM8), de l'urbanisation ou de la
cartographie applicative. On trouve différents outils qui permettent de modéliser la
structure d’une entreprise, les échanges entre sites ou entités, les processus
transverses de l’entreprise, les relations entre applications, afin de permettre
d’organiser et mesurer la performance en cohérence avec le S.I. et de conduire les
changements nécessaire. Parfois, ces approches cherchent à piloter directement le
S.I. à partir des processus, par exemple en gérant directement les autorisations, les
menus et postes de travail, voire en contrôlant le flux d’activité directement
(workflow). On parle ainsi de « modélisation d’entreprise » dans la mesure ou
c’est l’ensemble du système d’information (outils, données, procédures et rôles des
acteurs) qui doit être « outillé » afin de permettre au management d’inclure le S.I.
dans la stratégie de l’entreprise au même titre que les ressources humaines, le
marché, ou les processus de conception, production et distribution. Nous étudierons
l’enjeu de la modélisation dans le chapitre 2.2.
Mais cette modélisation ne peut aboutir à un système « automatisé » en
dehors de quelques fonctions de pilotage (acquisition sur un flux, synchronisation
de systèmes...). La caractéristique organisationnelle de l'ERP repose au contraire sur
la réalité des pratiques des acteurs qui interagissent dans une organisation à travers
le système. Les enjeux de la conduite du changement et des conflits que ce
changement peut générer rend nécessaire d'identifier au delà du « système », ce
qu'est la réalité du « système avec ses acteurs », de la maturité des usages acquis
pour la contribution de ses systèmes d'information à sa performance. C'est ce que
nous étudierons dans la chapitre 2.3.

8 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 58
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

3 Standardisation et centralisation

L es difficultés des projets ERP ont souvent conduit certains acteurs à proposer
des alternatives à ce qui était perçu comme une contrainte trop forte de
centralisation et d’intégration. Après la généralisation des ERP dans les années 90,
de nombreuses applications nouvelles se sont développés créant apparemment de
nouveaux marchés pouvant apparaître comme concurrents ou alternatifs à l’ERP.
Cela a conduit à proposer une approche plus distribuée laissant à chaque fonction le
choix de la meilleure application possible ou « best of breed » (Light et al., 2001),
renvoyant l’intégration à une fonction propre au pilotage du système d’information
et supposant des outils et techniques permettant d’en réduire le coût. De nombreuses
offres commerciales de services ou de technologie ont proposé de construire cette
intégration du système d’information de manière plus progressive, sans rupture avec
l’existant, acceptant l’hétérogénéité des systèmes et des acteurs. A l’image des
architectures massivement parallèles d’ordinateur, une approche « faiblement
couplée » des composants d’un système d’information se caractérise par des
technologies et des méthodes facilitant l’interopérabilité entre systèmes. A l'inverse
de l’ERP, système de grande taille dont un fournisseur assure l’intégration et la
cohérence, ces approches tentent d’offrir un cadre de construction de l'intégration et
de la cohérence entre des applications diverses, de plus petite taille, supportées par
des acteurs différents.
L’intégration d’application d’entreprise (EAI), puis les architectures de
« bus » applicatif, enfin les architecture orientées services (SOA) se présentent
comme le cadre technique d’une telle intégration « faiblement couplée ». C’est ce
qu’évoquait déjà Davenport :
« `monolithic'' enterprise applications will become more modular and flexible.
They will, according to this view, evolve to a model in which the basic ES is a
``backbone'' into which disparate ``best of breed'' applications can be plugged
and played,... » (Davenport 2000)
Cette recherche d'une architecture distribuée fait écho aux approches
informatiques “composants”. Mais pour 12 chercheurs seniors interviewé dans une
étude, elle est peut-être comme le Saint Graal :
« tout le monde le cherche, mais il n’a jamais été trouvé » (Klaus et al., 2000)
Les bénéfices ques les grands acteurs des solutions d'entreprise peuvent
attendre de ces approches sont incertains. Comment générer des revenus plus
importants en vendant un “bus” ou une “plateforme” par rapport à la vente
d'applications ? Comment collaborer avec ses concurrents pour rendre ses
applications massivement interopérables ? (Davenport 2000). D’autant que

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 59
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

l’intégration ne se résume bien entendu pas à ses supports matériels dont les
conditions technologiques se diffusent progressivement avec la publication par les
éditeurs de « connecteurs » respectant des normes d’interopérabilité pour les
échanges inter-entreprises, ou avec le développement des prestataires
d’interopérabilité que sont Ariba9, Elemica10 ou SupplyOn 11. Au contraire,
« l’ERP, qui cherche avant tout à assurer une couverture complète et dispose
d’une ossature pérenne, demeure un pré-requis pour maîtriser l’intégration
fonctionnelle et organisationnelle et résoudre les dysfonctionnements les plus
courants. Malgré les nouveaux outils qui ne cessent de le défier, l’ERP reste
une plate-forme pour assurer des avantages concurrentiels » (Deixonne 2001).
D’autant que si la plupart des éditeurs ERP ont une stratégie d’architecture
SOA, la décomposition d’un S.I. en « services » pose de redoutables problèmes de
granularité et de cohérence. Ainsi les données de toutes natures sont au cœur de
l’ERP et de sa base de données. Ces données sont fortement corrélées. Elle doivent
être pourtant « réparties » dans les différents services web recherchées ce qui
nécessite de différencier les données « internes » au service, qui ne sont pas ou très
faiblement corrélées aux données « externes » au service, qui doivent être
transmises dans les messages que les services échangent. Ces messages pour être
utilisables par des services autonomes doivent être définis de manière indépendante
(normalisée) et extensible. La difficulté réside justement dans ce partitionnement
des données entre services qui nécessite de créer des redondances, introduisant la
nécessité de « versionner » et « d’historiser » les données, chaque service ayant des
données internes « actuelles » et des données échangées qui peuvent dater du
précédent message reçu et donc être désynchronisées des données équivalentes
traitées au même moment par un autre service. Ces difficultés conduisent à
introduire des notions de « collections partagées » et « d’artefacts historiques »
comme différentes formes de données de référence des messages échangées entre
services (Helland et al. 2000).
Afin de maîtriser ces enjeux de cohérence, SAP propose une approche SOA
qui agrège des services à un niveau pertinent pour l’entreprise. L’offre de cet éditeur
se structure sous forme de « services d’entreprise » qui décompose l’ancien ERP en
entités plus petites, mais d’une taille suffisante pour assurer une cohérence forte, et
facilitant aussi leur commercialisation. Si cette architecture permet à un service de
faire l’objet d’une « prestation » fournie par un éditeur dédié proposant un
composant ou par un hébergeur, il est clair que la cohérence nécessitera pour tous

9 [Link]
10 [Link]
11[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 60
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

les partenaires possibles de se conformer aux normes de fait que représentent les
structures de données de base de SAP.
Ces architectures SOA ne représentent donc pas une alternative aux ERP,
mais viennent plutôt accompagner leur évolution vers une plus grande flexibilité de
configuration et d’intégration dans un système inter-entreprise. Cette tendance
pousse à l’émergence de normes techniques. Ainsi en 2005 les principaux acteurs
ont officialisé une nouvelle spécification d’architecture de composants orientées
service (SCA12) permettant leur réutilisation et introduisant la notion
« d’assemblages de services » représentant une application correctement configurée.
Elle nécessite aussi la construction de normes métiers pour définir les objets
échangés (ordre de vente, d’achat, de fabrication…) comme cela a été fait pour les
échanges de données techniques. C’est ce que propose l’Open Management Group
(OMG) avec la norme SBVR 13 « Semantics of Business Vocabulary and Business
Rules ».

4 Standardisation et innovation

L a tendance à la standardisation ne limite pas l’évolution technologique des

solutions. Ainsi, des alternatives sur la conception même des ERP continuent
d’apparaître avec un succès plus oui moins important. Mais ces innovations ne
conduisent pas à un retour vers un système d’information développé de manière
spécifique à chaque entreprise. L’ERP est à la fois poussé par les innovations
technologiques, mais aussi facteur influençant les innovations qui deviendront une
réalité durable, quand elles sont portées par les acteurs principaux du marché (Loos
2000). Les innovations pertinentes sont prises en compte par les éditeurs dont les
plus importants possèdent des moyens considérables pour faire évoluer
l’architecture même de leurs solutions. Ainsi SAP est passé de son langage
propriétaire ABAP au langage JAVA en assurant la compatibilité des deux approches
pendant de longues années avant de développer de nouvelles solutions
exclusivement en JAVA. Les promesses des architectures orientées service (SOA)
devait permettre à une entreprise de construire un système d’information par
assemblage de services hétérogènes. Elles deviennent par la puissance des
principaux acteurs, une facilité pour intégrer l’ERP leader dans un système
d’information évolutif. C’est l’approche proposée par SAP des « Enterprise
Services »14 dont l’objectif affiché en ouvrant la possibilité à des éditeurs
partenaires de s’appuyer sur le middleware SAP est de fait de réduire la part des

12 [Link]
13 [Link]
14 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 61
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

spécifiques modifiant les programmes standard afin d’augmenter les revenus de

licence et de réduire les coûts de maintenance. De même, le développement des
langages de modélisation de processsus et des capacités à les exécuter, les
orchestrer afin de faciliter l'interopérabilité de systèmes hétérogènes, l'apparition de
normes comme BPEL 15 pour exécuter les processus et BPMN 16 pour les modéliser
se diffusent chez les principaux éditeurs dont SAP 17, et parfois deviennent pour eux
des vecteurs marketing (Westervelt, 2005).
Il est possible que sur la base d’une technologie réellement innovante, de
nouveaux acteurs puissent émerger mais la logique économique qui nécessite
d’augmenter toujours le nombre de clients utilisateurs d’un progiciel conduira
comme dans d’autres secteurs à une banalisation de ces alternatives. Les approches
du logiciel libre en s'affranchissant de cette contrainte du revenu de licence peuvent
être un facteur d'innovation. Pourtant compte tenu de la taille des grands systèmes
ERP, la conception de la plupart de ces solutions libres s'est faite par analogie avec
les spécifications existantes et en s'appuyant sur des environnements techniques
éprouvés dans d'autres secteurs. Il faut noter toutefois la solution erp5 18 qui propose
une architecture nouvelle associant données et documents et proposant un méta-
modèle générique innovant (Smets-Solanes et Atem de Carvalho 2003) et la solution
OpenBluelab19 qui repose sur la génération du système par les modèles d'entreprise.
De fait, les solutions libres doivent elles aussi trouver les modes de financement de
l'investissement que représente l'innovation.
Cette innovation peut venir des approches issues du Workflow et des
réseaux de Petri qui sont pour certains des architectures de support de plateforme
orientée processus permettant d’utiliser des techniques de datamining pour produire
par rétro-ingénierie le processus « tel que réalisé » à partir des journaux
d'évènements (van der Aalst et Weijters 2004; van der Aalst 2005)
De la même manière, l’intégration inter-entreprise dans une chaîne
logistique multipliant les échanges et les besoins de synchronisation entre des
progiciels de type ERP conduit à des propositions d’architectures étendues
(Verwijmeren 2004) qui préfigure certains aspects des fonctionnalités multi-site des
ERP ou surtout des modalités de coordination entre plusieurs ERP, au-delà des
relations client-fournisseur et du support de l’EDI dans cet échange.
Pour l’instant, ces innovations technologiques qui semblent incessantes ne
remettent donc pas en cause les tendances historiques d’évolution des systèmes
d’information vers la standardisation, la centralisation, l’intégration et la
15 [Link]
16 [Link]
17 [Link]
18 [Link]
19 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 62
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

modélisation. De fortes logiques économiques les poussent, autant du coté de l’offre

avec la concentration des éditeurs et le leadership désormais incontesté de SAP, que
du coté de la demande avec les tendances longues à l’externalisation de
l’exploitation où de la maîtrise d’œuvre informatique, à la ré-ingénierie continue
des entreprises qui pousse à la standardisation des moyens d’échanges, de pilotage
et d’exploitation.

L ’évolution du marché dans les années récentes confirme ainsi une tendance
longue à la construction de systèmes d’information de gestion à base de
progiciels du marché. L’ERP est une réalité qui nécessite une nouvelle approche des
systèmes d’information de gestion et donc de la place de l’informatique dans
l’entreprise. Elle concerne tout le cycle de vie des systèmes d’informations, des
phases amont de sélection aux phases aval de stabilisation et optimisation. Des
facteurs clefs de succès sont désormais bien identifiés. Un cadre méthodologique
académique se construit sans avoir pour l’instant de traduction opérationnelle dans
la diversité des méthodes propres à chaque éditeur.
Les usages des systèmes de type ERP sont aussi importants que les outils
eux-mêmes comme le souligne le témoignage industriel concluant la rencontres
« Propos raisonnables sur les ERP » organisée en 2002 par l’Ecole des Mines de
Paris et l’INSA de Lyon :
« Les ERP ont-ils finalement changé en profondeur la vie des entreprises ?
Non, ce ne sont pas les outils qui changent mais plutôt les hommes et les
femmes qui apprennent à les connaître et à les utiliser mieux. La vie de l’ERP
commence donc aujourd’hui, nous sommes à l’aube de la connaissance. Après
les outils, il nous faut repenser les usages, repenser le contexte de travail, et
surtout utiliser la matière grise qui restera la matière première d’une
entreprise. » (Corniou 2002)
Les promesses technologiques peuvent conduire à des ruptures pour de
nouvelles conceptions d'ERP du futur. Mais les réalités du marché poussent toujours
à la consolidation sur quelques vendeurs majeurs qui n’utiliseront certainement pas
ces innovations pour réduire leur domination économique, mais au contraire pour
étendre toujours plus leur capacité à accompagner les systèmes d’information des
entreprises. Ce sont donc bien, derrière les technologies et les marchés, les
tendances de fond qui structurent les transformations des systèmes d’information
d’entreprise qui doivent être éclairées.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 63
 Etat de l’art industriel et académique / Caractéristiques et définitions de l'ERP

Nous avons vu dans ce chapitre que le sigle ERP permet d’identifier

facilement les caractéristiques de S.I. se répandant dans les
entreprises de toute taille, fortement intégrés, prenant en compte
toujours plus de fonctions, de situations, d’activités, contribuant à un
pilotage des S.I. centré sur l’alignement de la stratégie d’entreprise,
de son organisation, de ses compétences, de ses outils. Ces systèmes
d’information intégrés sont de plus en plus construits à partir de
progiciels proposés dans un marché marqué par la concentration. Le
compromis entre standardisation et différenciation, diversité et
cohérence reste dans ce contexte un enjeu pour les acteurs. Nous
avons proposé une définition et un cadre d'étude des « systèmes
construits à base de progiciels intégrés de type ERP » dont nous avons
identifié les évolutions de long terme qui feront l'objet des chapitres
suivants :

● La modélisation des entreprises et des systèmes nécessaires à

la maîtrise des projets de l'expression du besoin au pilotage de
la performance obtenue,

● L’appropriation des systèmes d'information par les acteurs pour

une plus grande maturité des usages dans un contexte de
centralisation des systèmes.

● L’intégration informationnelle et organisationnelle par la

standardisation des technologies, applications et pratiques

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.1
Institut National des Sciences Appliquées de Lyon 64
 Etat de l’art industriel et académique / Modélisation d’entreprise

Chapitre 2.2
Modélisation d’entreprise

La modélisation d’entreprise fait l’objet d’un groupe de standardisation

ISO TC184 SC5 WG1 dénommé « Industrial-automation systems and
integration, Architecture, communications, and integration
frameworks, Modelling and architecture ». Ce groupe de travail
propose des standards dans quatre domaines qui révèlent la
multiplicité des points de vue nécessaires : process representation,
integrating infrastructure, semantics-resolving utility, and
representation of human involvement.

La modélisation est donc tout à la fois organisationnelle,

informationnelle et humaine. Elle repose sur une forte diversité des
usages et des acteurs, depuis les fonctions de management de
ressources humaines, aux fonctions de simulation de flux et de
capacités ou encore à l’aide au pilotage de projet de mise en œuvre de
systèmes d’information.

C’est pourquoi nous étudierons dans un premier temps les techniques

de modélisation existantes, pour situer les efforts de normalisation et
de standardisation. Nous caractériserons alors leur rapport avec le
système d’information, les usages de la modélisation dans les projets
ERP avant d’aborder la notion essentielle de modèles de référence au
cœur de la contribution de la modélisation à la standardisation des
systèmes d'information.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 65
 Etat de l’art industriel et académique / Modélisation d’entreprise

2.2.1 Evolution des méthodes de modélisation

1 Suite IDEF

L a suite IDEF20 (Icam DEFinition) a été développée dans les années 70 par l’US
Air Force dans un projet nommé ICAM (Integrated Computer Aided
Manufacturing). Elle contient les vues suivantes (NIST 1993) :
1. IDEF0 : Formalisme du « point de vue fonctionnel ». Le point de vue
fonctionnel est la représentation structurée des fonctions, activités ou process du
système modélisé ou du sujet d’étude ; Plus connue sous le nom de SADT
(Structured Analysis Design Technique), elle propose un point de vue fonctionnel
sous la forme d’un graphe d’activités transformant un flux « entrant » en un flux
« extrant » sous la directive de « contrôles » et avec le moyen de « mécanismes ».
La représentation est hiérarchisée sous forme d’un enchaînement de diagrammes.
2. IDEF1 : Formalisme du « point de vue informationnel ». S’appuyant sur un
dictionnaire contenant une définition explicite de chaque élément du modèle, elle
propose des diagrammes contenant les règles et les procédures caractérisant la vue
fonctionnelle dans l’objectif de définir et construire la base de donnée
correspondante.
1. IDEF2 et IDEF3 : Utilisées pour obtenir un « point de vue dynamique »
qui représente les caractéristiques comportementales par rapport au temps du
système modélisé ou du sujet d’étude. Le formalisme IDEF2 base la modélisation
de la dynamique du système sur le principe des files d’attente. Le formalisme
IDEF3 complète la représentation des processus de IDEF0 en introduisant des
connecteurs logiques pour expliciter les situations de synchronisation, séquence,
parallélisme d’activités.

2 Méthode GIM et modèle GRAI

L a méthode GIM (GRAI Integrated Methodology) a été développée par le

laboratoire GRAI de l’université de Bordeaux dans le cadre des projets
européens ESPRIT Open CAM et IMPCAS (Doumeingts 1984). Elle s’appuie sur le

20 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 66
 Etat de l’art industriel et académique / Modélisation d’entreprise

modèle de référence GRAI et ses différents langages de modélisation, une approche

structurée permettant de faire évoluer un système par étape d’un état existant vers
un état cible, et un ensemble d’indicateurs permettant d’évaluer différents points de
vue (cohérence, fiabilité…). Elle propose une méthode orientée utilisateur et une
méthode orientée technologie. La première transforme les besoins utilisateurs en
spécifications en termes de fonctions, informations, décisions et ressources. La
deuxième transforme les spécifications utilisateurs en spécifications techniques en
termes d’information, de composants technologiques nécessaires à la mise en œuvre
du système.
Cette approche propose une démarche originale reposant sur un modèle du
système décisionnel de l’entreprise, la « grille GRAI » qui définit des « centres de
décision » par le croisement d’une fonction de l’entreprise et d’un couple
horizon/période de décision. Cette notion conduit à différencier les échanges de
décision qui représentent une dépendance fonctionnelle entre centres de décision
des simples échanges informationnels. Un centre de décision est détaillé en un
réseau d’activité différenciant les activités de décision et d’exécution.
La méthode GIM utilise les formalismes entité-relation de la méthode
MERISE (Tardieu, Rochfeld, et Colletti 1983) pour la vue informationnelle et le
formalisme IDEF0/SADT pour la vue physique et la vue fonctionnelle.

3 Méthode CIM-OSA

L e consortium ESPRIT « AMICE » a développé une architecture système

ouverte pour l’intégration des entreprises industrielles (Computed Integrated
Manufacturing, Open System Architecture CIM-OSA) comme un langage de
modélisation pouvant devenir normatif (Zelm et al., 1995), (Kosanke 1995). L’objet
principal de CIM-OSA est de supporter la modélisation orientée processus
d’entreprises industrielles et de proposer un environnement support aux opérations
des systèmes d’entreprise basés sur ces modèles. Elle identifie trois phases dans un
projet d’entreprise (la spécification des besoins, la conception et la mise en œuvre).
Ces phases représente un des trois axes de l’architecture de référence dénommée
usuellement le « cube CIMOSA ». Le deuxième axe (génération) est constitué de
quatre vues (fonction, information, ressource et organisation) dont sont issus les
« construits » de base du langage de modélisation. Enfin, le troisième axe de
spécialisation (instanciation) est celui de la méthodologie descriptive supportant le
cycle de vie du modèle d’entreprise et permettant de transformer le modèle
générique en modèle partiel représentant un modèle de référence, puis d’adapter ce
modèle partiel pour le spécialiser en un modèle spécifique à l’entreprise considérée.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 67
 Etat de l’art industriel et académique / Modélisation d’entreprise

Ce modèle particulier peut être mis en œuvre dans le système opérationnel de

l’entreprise.
Cette approche de modélisation des processus décrit toutes les activités de
l’entreprise d’une manière commune (depuis les opérations industrielles en ateliers,
jusqu’aux processus de gestion et d’administration). Pour cela, CIMOSA propose
une approche modulaire et hiérarchisée définissant l’entreprise par « domain »
(DM) décrit à travers des « domain process » (DP) détaillés en « business process »
(BP). Ceux-ci sont finalement décrits en « Activity » détaillées en « Functional
Operation ».
Des extensions du modèle CIMOSA sont proposées pour répondre aux
attentes de processus simultanées et de leur coordination, aux besoins de
modélisation des ressources techniques et humaines, aux besoins de modélisation
des organisations. (Berio et Vernadat 1999).

4 Méthode ARIS

U ne architecture de systèmes d’information intégrés (ARIS, The ARchitecture

of Integrated Information Systems) est proposée pour les phases d’analyse et
de définition des besoins d’un système d’information de gestion (Scheer 1994a).
Elle prend en compte les vues suivantes :
La vue organisationnelle modélise les relations entre les entités d’entreprise et
leur hiérarchisation.
La vue des données décrit les objets, leurs attributs et leurs relations. Elle
contient les évènements qui peuvent déclencher et contrôles les processus.
La vue fonctionnelle représente les fonctions présentes dans les processus et
détermine par la création et la modification des objets et évènements.
Les vues de contrôle permettent la définition de l’aspect dynamique liant les trois
autres vues.
Les construits les plus important sont les fonctions et les évènements qui
permettent de représenter les processus sous la forme de « chaîne de processus
dirigée par les évènements » ou « Event driven Process Chain » (EPC). Le modèle
EPC contrôle le flux dans le processus et permet de représenter la dynamique des
processus jusqu’au niveau opérationnel. D’autres modèles sont proposés par cette
méthode dont une vue plus globale des processus permettant de représenter la
chaîne de valeur (Value Chain). La représentation sous forme EPC a acquis une
notoriété liée à la place des projets SAP. Mais cette technique n’est pas
formellement et sémantiquement complètement définie et ne peut donc faire l’objet
des mêmes « preuves » qu’un formalisme de réseau de Petri. Une traduction des

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 68
 Etat de l’art industriel et académique / Modélisation d’entreprise

EPC en Réseau de Petri est proposée pour permettre de vérifier ainsi l’exactitude de
l’EPC (van der Aalst 1999).

5 Méthode GERAM

L a méthode GERAM (Generalized Enterprise Reference Architecture and

Methodology) a été développée dans le cadre d’un groupe de travail IFAC/IFIP
sur la modélisation d’entreprise à partir du constat que les méthodes existantes
devaient être étendues pour devenir une architecture complète et une méthodologie
guidant les entreprises de la conception initiale jusqu’à la mise en œuvre et
l’utilisation. La méthode GERAM organise ainsi des méthodes et langages existants
(Bernus et Nemes 1996). Elle est le résultat de généralisations basées sur les trois
architectures précédentes les plus complètes (CIM-OSA, GIM et PERA). Elle
permet de lier les cycles de vie des produits, des entreprises et des projets.
L’objectif affiché de GERAM est d’aboutir à la normalisation d’une
méthode d’ingénierie d’entreprise (GEEM : Generic Enterprise Engineering
Methodology, qui suppose un langage, Generic Enterprise Modelling Language
GEML et des outils associés, Generic Enterprise Modelling tools, cohérents avec
des modèles d’entreprise, Generic Enterprise model (GEM). GERAM distingue les
concepts orientés “humains”, les concepts “processus” et les concepts
“technologiques”. Des langages de modélisation devant permettre de décrire un
processus de manière compréhensible par l’homme et par les outils.

6 Synthèse proposée par le modèle ATHENA

L e projet ATHENA 21 « Advanced Technology for interoperability of

Heterogeneous Enterprise networks and their Applications » est une initiative
dans le cadre du 6ème plan de recherche européen destiné à proposer un cadre de
réponse aux besoins d’interopérabilité entre entreprises que suscitent leurs
collaborations croissantes (ATHENA 2006). Ce projet auquel ont participé de
nombreuses entreprises industrielles, éditeurs de logiciels et prestataires de services
européens a produit une version finale d’une « carte » des recherches sur
l’interopérabilité identifiant les pistes prometteuses pour sortir de l’émiettement des
initiatives, normes et modèles. Le rapport s’inscrit dans une vision d’un
environnement économique constitué d’une diversité d’écosystèmes d’entreprises,
en évolution continue à travers lesquels les entreprises collaborent et sont en

21 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 69
 Etat de l’art industriel et académique / Modélisation d’entreprise

compétition les unes avec les autres. Les activités de recherche scientifique et
technique ont porté notamment sur la modélisation d’entreprise (projet A1) dans
l’objectif d’étendre les méthodes existantes et de les intégrer sur des plateformes
d’exécution. La modélisation peut être utilisée seule pour produire différentes vues
d’un modèle, comme portail d’un autre système, ou pour contribuer à fournir un
environnement utilisateur contextuel dans :
L’ingénierie et la ré-ingénierie d’entreprise,
La gestion du cycle de vie des produits,
Le choix et la mise en œuvre de solution informatiques ,
L’architecture d’entreprise pour le support des opérations.
Un langage d’échange entre différents langages de modélisation
d’entreprise est proposé sous la dénomination de « POP* » pour (Process,
Organisation, Product…) (Grangel et al. 2006). Il propose cinq dimensions qui
caractérisent un élément d’entreprise :
La dimension processus décrit les activités et tâches réalisées dans l’entreprise et
les objets nécessaires pour les réaliser,
La dimension organisationnelle décrit les structures et les parties prenantes et
relations qui forment cette organisation,
La dimension produit décrit les produits et services proposés,
La dimension décisionnelle décrit les processus de décision et les structures qui
leur sont nécessaires,
La dimension infrastructure décrit l’infrastructure informatique.
Le modèle POP* identifie des « objets d’entreprise » comme tout ce qui
concourt ou est une part d’une activité de l’entreprise. Ils jouent des « rôles » dans
l’entreprise et peuvent avoir des « aptitudes » et un « emplacement ». Les objets
peuvent être représentés selon les différentes dimensions. Celle des processus
permet d’identifier les différents types de rôles qu’un processus peut avoir dans
l’entreprise : « contrôle » en fonction d’un « évènement », « entrée » ou « sortie » et
« ressource ». Ces rôles sont portés par des « flux » qui relient deux « points de
décision », concept générique représentant tout ce qui définit la séquence globale du
processus.

2.2.2 Vers le cadre 19439 et le méta-modèle 19440

L es efforts de recherche des années 1990 conduisent a un cadre normalisé pour

répondre aux besoins d’une approche systémique de l’entreprise. La
modélisation d'entreprise est définie par le projet ATHENA comme la capacité à

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 70
 Etat de l’art industriel et académique / Modélisation d’entreprise

« extérioriser, construire et partager » des connaissances sur l’entreprise (ATHENA

2006). Elle est utilisée pour :
comprendre et analyser la structure et le fonctionnement de l’entreprise,
prévoir le comportement et les performances des processus opérationnels avant
leur implantation,
choisir la (ou les) meilleure(s) alternative(s) d’implantation(s),
identifier les risques d’implantation à gérer,
justifier les choix d’implantation sur des critères liés aux ressources et aux coûts,
bâtir une vision commune du fonctionnement de l’entreprise et la communiquer
facilement au plus grand ensemble possible du personnel.
Ses dimensions informationnelles, organisationnelles et économiques sont
ainsi étroitement liées et en font une activité pluridisciplinaire impliquant les
sciences de gestion et du management, des systèmes d’information et de
l’informatique, de l’ingénierie d’entreprise. Cette diversité de points de vue est
illustrée par la classification des usages qu’en propose le Tableau 2.7, identifiant ses
objectifs, ses utilisateurs potentiels et les bénéfices qui en sont attendus.
User Used to How to use Benefits
Supervisor Define process guidelines Evaluate alternative Improved validation of
in accordance with scenarios guidelines and policies
enterprise policies and
strategies
Designer Design enterprise Create, validate and Reduced effort in
operationnal processes verify process design process design and
according to process through simulation. improved process
guidelines, professional Evaluate process quality (less redesign
exprience and examples alternatives efforts)
(reuse of models)
Process Support decision making Monitor processes. Faster decision
owner in exception handling Evaluate alterantive in malingand improved
exception handling decision quality
Operator Perform operation and Support operation Improved Product
train operationnel staff activities and provide quality. Reduced
on-line training courses training time

Tableau 2.7.: Utilisation potentielle des modèles de processus

La multiplication des méthodes et des normes a conduit à de nombreux

travaux de synthèse présentant les différents aspects de la modélisation, modèles,
outils, technologies support. En 1999, un programme de travail est ainsi défini pour
identifier les normes existantes, groupes de travail et perspectives à partir de l’état
de l’art que représente à cette date la méthode GERAM (Kosanke et Nell, 1999). Ce

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 71
 Etat de l’art industriel et académique / Modélisation d’entreprise

programme illustre les efforts d’unification progressive des représentations

existantes vers un vocabulaire reconnu et partagé.
La norme ISO 14258, (Concepts and rules for enterprise models, ISO 14528
2003) propose une approche systémique de l'entreprise pour permettant
d’analyser, de concevoir, voir d’opérer une entreprise.
La norme ISO 15704, (Requirements for enterprise-reference architectures and
methodologies, ISO 15704 2005) définit les exigences attendues d’une
architecture de modélisation d’entreprise pour être complète.
La norme ENV12204 propose une première spécification des éléments
nécessaires à la modélisation dénommés des « constructs » que nous traduirons de
manière littérale par « construits » dont les principaux sont les suivants :
« Enterprise Activity », « Business Process », « Event », « Resource »,
« Enterprise Object », « Object View », « Object State ».
La proposition de norme ISO18629 issu de travaux du « National Institut for
Standard of Technology » (NIST) définit un langage dénommé « Process
Specification Language » (PSL) pour l’interopérabilité entre les outils de
modélisation de processus. Ce langage est construit comme un réseau de modules
spécialisant des concepts de modules sous-jacents avec au cœur le module « PSL
core » qui utilise les construits suivants : « activity », « activity-occurrence »,
« object », et « timepoint ». La grammaire de PSL est définie dans un langage
formel de premier ordre permettant de réaliser des transformations en un autre
langage défini formellement (XML) (Schlenoff, 1997).
A partir des travaux parallèles sur PERA aux USA, et GRAI et CIMOSA
en Europe, GERAM a représenté une première convergence dans les années
1991,1995. Le processus de normalisation s'est poursuivie pour aboutir en 2002 à la
norme ISO EN 40003. Chen et Vernadat (2001) ont proposé une classification de
ces normes en les classant en « modèles d'entreprise », cadre d'ingénierie, langages
de modélisation et infrastructures informatiques. Les travaux de comparaison ou de
synthèse de méthodes conduiront à une tentative de normalisation des échanges
entre modèles représentés dans des méthodes différentes. Ce sera l’objet du projet
UEML qui propose un état de l’art en 2002 des nombreuses méthodes, outils et
projets industriels existants et identifie les concepts et besoins d’une norme assurant
l’interopérabilité entre les différentes méthodes et outils (Petit et Doumeingts,
2002).
Cet état de l’art confirme la recherche de standardisation et
d’interopérabilité qui fait évoluer les normes existantes pour prendre en compte
toujours plus globalement les besoins émergents de modélisation (Figure 2.5). La
norme ENV12204 est ainsi reprise dans la proposition de norme CEN/ISO 19440
qui définit les construits de modélisation nécessaires. La norme CEN/ISO 19439

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 72
 Etat de l’art industriel et académique / Modélisation d’entreprise

définit les dimensions de phases, de vues et de généricité. Elle répond au x

exigences de la norme ISO15704 en proposant un cadre de modélisation dans les
trois dimensions ; les phases du cycle de vie du projet, la généricité permettant
d’aller du générique au particulier, les vues permettant de filtrer le modèle pour en
simplifier la lecture.

Figure 2.5: Standard de l'ingénierie d'entreprise (UEML)

La norme ISO19439 présenté sous forme de cube dans la Figure 2.6

identifie sept phases dans le cycle de vie des modèles :
La définition du domaine étudié : Do (Domain Identification),
La définition des concepts nécessaires : C (Concept Definition),
La définition des besoins de l’entreprise : R (Requirements Definition),
La conception du modèle : D (Design Specification),
La mise en œuvre du modèle : I (Implementation description),
L’usage du modèle dans les opérations : O (domain Operation),
Le retrait ou l’arrêt des opérations : Dc (Decommission definition).
Elle propose quatre vues sur ces modèles :
la vue organisationnelle
la vue informationnelle
la vue fonctionnelle

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 73
 Etat de l’art industriel et académique / Modélisation d’entreprise

la vue des ressources

Figure 2.6 le cadre de modélisation 19439

Enfin, les trois niveaux de généricité sont :

Le niveau générique des construits réutilisables dans tout contexte,
Le niveau partiel des prototypes adaptés à des typologies d’entreprise,
Le niveau particulier, modélisant un domaine particulier d’une entreprise.
Dans ce cadre de modélisation, Les construits proposés par la norme 19440
constituent le vocabulaire d'un langage de modélisation d'entreprise et sont
présentés dans la Figure 2.7.
Ce modèle de construits rejoint sur de nombreux points les résultats du
projet UEML qui présente un « méta-modèle » dépendant du contenu et spécifique
au domaine de la modélisation d’entreprise. Ces efforts de mise en cohérence des
méta-modèles restent un enjeu de recherche comme le montre la comparaison des
construits UEML et ISO 19440 (Wohed et al., 2006) ou la proposition résultante du
projet ATHENA d'une norme d’échange entre formalismes dénommé « POP* »
(Process, Organization, Product,…), ou encore la proposition d'un langage
complémentaire pour la modélisation des compétences (UCML) (Pépiot et al. 2007).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 74
 Etat de l’art industriel et académique / Modélisation d’entreprise

Figure 2.7 Les construits du méta-modèle 19440 et les 4 points de vue

Le cadre représenté par les normes ISO19439 et ISO19440 peut être

considéré comme un état de l'art opérationnel pour étudier le pilotage par les
modèles des entreprises et des systèmes d'information.

2.2.3 Modélisation et système d'information

1 Modélisation d’entreprise et de système d'information

D ès l'origine de la modélisation d’entreprise, la différence entre la modélisation

des processus de l’organisation et la modélisation des systèmes informatiques
qui la supporteront sont clairement différenciés. Ainsi si le modèle CIMOSA
propose des « construits » orientés informatique, ils ne font pas partie du modèle de
processus lui-même :
« These constructs cover all the important aspects of a manufacturing process.
IT oriented modelling constructs complement this set for use by system design
and implementation experts. However, these constructs are not part of the
CIMOSA Business Modelling Process as described… » (Zelm, Vernadat, et
Kosanke 1995)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 75
 Etat de l’art industriel et académique / Modélisation d’entreprise

De fait, les acteurs concernés par la modélisation d’entreprise sont

multiples, depuis le décideur du type d’organisation recherché, du niveau
d’intégration ou au contraire d’autonomie des différentes entités, jusqu'à
l’utilisateur opérationnel réalisant les activités décrites dans le modèle en utilisant
des outils décrits dans le modèle, en passant par l’utilisateur qui aura la possibilité
d’adapter certains processus à des niveaux de détail divers pour tenir compte d’aléas
ou de cas particulier. C’est ainsi que deux méthodes de modélisation sont proposées
pour l’expert en modélisation et l’utilisateur métier dans le cadre de la méthode
CIMOSA :
« Whereas the modelling expert will be involved in creating new models,
structuring the model contents and developing new modelling components, the
business user will use process models for decision support. The latter therefore
has a need to modify and adapt enterprise models to represent operational
alternatives. » (Kosanke et Zelm 1999).
Dans cette approche, la différence entre le point de vue expert et le points
de vue utilisateur relève de la méthode qui fait l’objet de l’étude, mais qui s’appuie
pour les deux points de vue sur un modèle et un outil de représentation commun. De
fait, c’est le périmètre d’usage des outils et de la contribution au modèle qui
constitue la différence, l’expert intervenant en amont et l’utilisateur en aval sur les
objets CIMOSA créé par l’expert.
Considérant que « ‘‘enterprise engineering’’ projects are of broader scope
then ‘‘software engineering’’ projects », il est tentant de chercher à assurer la
cohérence d’un point de vue « métier » et d’un point de vue « informatique » en
proposant d’associer deux techniques de modélisation adaptées. C’est ainsi qu’une
démarche d’intégration en modélisation d’entreprise est proposée en utilisant en
amont des projets UML une définition des besoins utilisant les normes IDEF (Kim
et al., 2003) . Pour ces auteurs, la modélisation d'entreprise utilisée comme frontal
de la modélisation de logiciel, permet d'assurer la cohérence entre plusieurs points
de vue de modélisation. Ils soulignent que les systèmes d’entreprise à base de
composants auront besoin dans un futur proche d’être conçu, réalisé, distribué, mis
en œuvre et modifié dans un contexte global commun (« a big picture »). Cela
suppose d’approfondir les synergies entre les concepts, modèles et outils des
modèles d’entreprises et des architectures de systèmes d’information distribués.
Le projet UEML identifie ainsi comme perspective de recherche après la
réalisation de l’interopérabilité entre méthodes de modélisation d’entreprise, la
clarification du lien entre modélisation d’entreprise et les logiciels du système
d’information. Cette relation concerne autant les spécifications de sélection
d’applications standard (ERP, SCM, CRM…), que les outils d’intégration de type
EAI ou encore les spécifications de logiciels spécifiques (Figure 2.8).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 76
 Etat de l’art industriel et académique / Modélisation d’entreprise

Figure 2.8: Modélisation d'entreprise et application informatique (UEML)

Cette vision conduit à considérer que les applications standard d’entreprise

devront perdre leur architecture centralisée au profit d’une architecture distribuée
permettant la sélection de fonctions à partir de la granularité souhaitée dans le
modèle d’entreprise. Une telle transformation ne peut pourtant être pensée en
dehors des réalités économiques qui poussent au contraire à la concentration
toujours plus forte des éditeurs de telles applications d’entreprise autour de leaders
mondiaux comme SAP. La problématique de la cohérence entre un modèle
d’entreprise et le modèle implicite porté par les applications standard est donc un
enjeu de recherche essentiel au cœur de cette thèse. Il faut noter cependant que si
les acteurs de la modélisation d’entreprise cherchent à « piloter » les systèmes
d’information, les acteurs des systèmes d’information cherchent à « modéliser » les
organisations et processus d’entreprises. C’est ainsi que de nombreux travaux
portent sur l’extension de UML par l’ajout de nouveaux formalismes dédiés à la
représentation de processus métiers. Un exemple de ce type de représentation se
diffuse progressivement dans les outils UML (Eriksson et Penker 1997). De même,
l’organisme OMG propose de travailler à une évolution des modèles d’activité de
UML avec une nouvelle méthode dénommée Business Process Definition
Metamodel (BPDM).
Cette dualité est illustrée concrètement dans l’architecture de l’ERP BAAN
qui sera le support d'une application de nos travaux présentée dans la partie . Les
entités de l’organisation sont modélisées dans l’outil de modélisation de cet éditeur
(DEM) mais sont aussi des données de base des applications informatiques. Cela se
traduit très concrètement par un module gérant les entités organisationnelles d’un
point de vue modélisation d’entreprise (le module « Enterprise Management »,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 77
 Etat de l’art industriel et académique / Modélisation d’entreprise

tcemm) et d’un point de vue système d’information (le module « system tables »,
tcmcs). On retrouve dans les deux modules les notions de magasins, centres de
charge, service achat, service commercial, dans leur double sens d’entité
organisationnelle et informationnelle.

2 Modélisation d'entreprise et ERP

L ’enjeu de la modélisation comme outil support des méthodes de projets ERP

apparaît très tôt comme une condition de réussite des projets, afin d’aider à la
conduite des décisions de projet et au compromis entre adaptation de l’ERP et
adaptation de l’organisation. La conduite des changements décidés devient en effet
l’enjeu principal des projets et suppose une capacité de représenter ces changements
et leurs impacts sur les processus et l’organisation de l’entreprise. Cette
confrontation entre besoin de l’entreprise et solutions standard de l’ERP est
identifié comme une évolution de projets qui ne sont plus
« centrés sur la conception d'un modèle mais sur la configuration de modèles
partiels prédéfinis supportant les solutions les plus standards possibles des
progiciels » (Botta-Genoulaz 2005).
Dans cette démarche, la modélisation est d’abord identifiée comme
complémentaires aux tâches d’implémentation d’un ERP, notamment comme outil
de spécification des besoins d’un projet ERP :
« The finality of the specifications book is to evaluate the appropriateness
between an answer of both integrator / editor of packages and the requirements
of the enterprise » (Doumeingts et al. 2000).
Si la connaissance la plus précise de l’existant et des améliorations
nécessaires est le meilleur critère de réussite du projet ERP, la réalisation du projet
ainsi défini relève souvent d'abord de tâches techniques de paramétrage :
The use of parameterized or standard components does not render business
models redundant, but shifts the modeling focus even more from technical
aspects to the real-world business processes. (Gulla et Brasethvik 2000)
Une comparaison est faite avec la modélisation de produit pour prendre en
compte la variabilité en cherchant à rendre les modèles « configurables » pour
représenter une entreprise particulière (JC Wortmann 2001) La notion de variabilité
est commune aux modèles (configurables) et aux applications (paramétrables).
Des outils de modélisation apparaissent dans les projets (ARIS Tool Set,
DEM, Workbench, Livemodel…), ce qui permet de premiers travaux permettant de
les situer par rapport aux techniques de modélisation du génie logiciel (Merise,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 78
 Etat de l’art industriel et académique / Modélisation d’entreprise

UML, IDEF0…) ou de la modélisation d’entreprise (CIM-OSA, GRAI-GIM…). La

multiplicité des points de vue nécessaires est illustrée par une classification des
pratiques de modélisation constatées dans un grand projet européen. Celles-ci sont
classées selon trois axes : modélisation « fonctionnelle » qui décrit ce que propose
la solution ERP, modélisation « workflow » qui décrit la dynamique des acteurs et
modélisation « business » qui décrit les objectifs d'entreprises, les risques et la
performance. (Gulla et Brasethvik 2000). Une approche issue des sciences de
gestion conduit à identifier quatre modèles (Figure 2.9) en jeu dans un projet ERP à
partir du croisement entre les processus, le système d’information et la culture de
l’organisation :
Le modèle de l’existant « ASIS » qui décrit la culture existante dans
l’organisation, les processus et le système d’information existant.
Le modèle cible « TOBE » qui décrit le système objectif idéal dont les
changements nécessaire dans l’organisation, les rôles, les règles de gestion, donc
comprenant
Le modèle ERP (EMM), qui est marqué par la culture de ses concepteurs
le modèle probable « MIGHTBE » qui est le résultat de la mise en œuvre des
nouveaux processus et des nouveaux logiciels par les acteurs dans le contexte de
leur culture

Figure 2.9: Les modèles d'un projet ERP (Krumbholz et Maiden 2001)

La réalité d’un modèle propre à l’ERP ne fait pas de doute malgré la

capacité de ces systèmes à s’adapter à des situations variées. De fait, un processus
est supporté par des fonctionnalités logicielles qui sont des programmes standard
s’appuyant sur des modèles informatiques. C’est notamment le cas pour le modèle
de données qui se traduit dans toutes les applications de gestion par une base de
données relationnelle dont les contraintes d’intégrité sont figées dans l’application.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 79
 Etat de l’art industriel et académique / Modélisation d’entreprise

Leur modification est toujours lourde de conséquences dans la maintenance future

du système. Il y a donc bien des contraintes dans la capacité du logiciel à supporter
tel ou tel processus. Ces contraintes pourraient être levées en supprimant les
contrôles d’intégrité de la base pour les réaliser dans les programmes eux-mêmes
afin de les rendre paramétrable en fonction des processus. L’efficacité de la base de
données repose pourtant sur sa performance dans l’optimisation des requêtes
complexes, ce qui suppose au contraire le maximum de règles dans la base de
données.
Le modèle de référence implicite de l'ERP et son rapprochement avec le
besoin de l'entreprise doit alors être placé dans le cadre de référence. C'est ce que
propose Darras (2004) qui place la solution standard, le système d'information
résultant, le modèle de référence et le modèle cible dans les deux axes de généricité
et d'instanciation du cadre GERAM (Figure 2.10).

Figure 2.10: Un cadre de référence (Darras 2004)

Cette recherche de généricité dans le modèle se retrouve dans les tentatives

« d’extraire » de l’application la définition des processus en les formalisant dans un
système de Workflow venant piloter des actions élémentaire sur la base de données.
En effet, un ERP peut être vu comme un système de gestion des processus qui sont
déclenchés par et provoquent des transactions informatiques et des flux
d’informations. Mais la différence essentielle entre les deux types de systèmes
concerne bien le modèle de processus qui représente le comportement du système
dans une situation donnée. Un système de Workflow se comporte exactement sur la
base du processus spécifique modélisé de manière spécifique dans la conception du

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 80
 Etat de l’art industriel et académique / Modélisation d’entreprise

système, alors qu’un ERP se comporte sur la base du processus standard défini par
le concepteur de l’ERP tenant compte des paramètres défini dans le projet ERP. La
comparaison peut être formulé ainsi :
le modèle de processus dans un ERP est implicite, standard et paramétrable
le modèle de processus dans un Workflow est explicite et spécifique
C'est aussi ce qu'affirme les promoteurs de l'approche des « commercial off
the shelf (COTS) » ou produit sur l'étagère, qui fondent leur approche
méthodologique des projets progiciels sur le constat suivant :
« Products have built-in assumptions about how they will be used. These may
not match the processes of the system’s users, resulting in clashes. Each
product is built around some idea of how it will be used, whether those ideas
are explicit or implicit; if those process ideas do not match the end-users’
ideas, then clashes result » (Oberndorf 2000).
L’ERP est donc bien porteur d’un modèle de référence propre, mais le plus
souvent largement implicite si des actions n’ont pas été réalisées pour en proposer
des représentations complémentaires à l’ERP, le plus souvent supporté par des outils
de modélisation externes aux applications transactionnelles. C’est le cas du
référentiel de processus SAP utilisé dans l’outil de modélisation ARIS ou du modèle
de référence utilisé dans le module DEM de BAAN. Il faut donc des architectures
rendant ce modèle plus explicite, voire le plus externe possible à l’ERP lui-même,
tout en conservant la pertinence d’un référentiel standard et son intégration avec
l’ERP pour en faciliter le paramétrage et la mise en œuvre.
Ce contexte de la place de la modélisation dans un ERP peut être éclairé
par les activités de projet qui sont les cas concrets d’utilisation de la modélisation
d’entreprise dans un projet ERP (Botta-Genoulaz et al., 2001).
La modélisation est utilisée dans les projets de mise en œuvre d’ERP pour aider à
la configuration de l’ERP en plaçant les paramètres nécessaires dans le contexte
des processus de gestion clairement définis,
Elle est aussi utilisée dans le pilotage du changement dans les S.I. basées sur un
ERP pour tenir compte d’une nouvelle activité de l’entreprise,
Elle peut être enfin utilisée pour la génération d’environnement d’exploitation de
l’ERP correspondant à l’organisation définie par les processus. Ce peut être le cas
par exemple de la génération des autorisations, des postes de travail…
Cette modélisation n’a donc pas pour but de « concevoir » ou « générer »
le logiciel qui existe déjà. C’est ce « point de vue » de modélisation qui différencie
la modélisation ERP de la modélisation du S.I. La modélisation doit avoir pour but
de « configurer », « paramétrer », « intégrer » les processus standard de l’ERP.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 81
 Etat de l’art industriel et académique / Modélisation d’entreprise

Une architecture distribuée de « composants logiciels » peut supporter les

différentes vues d’un modèle CIMOSA en plaçant l’ERP, le PLM, le CRM…,
comme des ressources échangeant des messages avec les processus pilotés par
l’application conçue avec CIMOSA (Abdmouleh et al., 2004). Mais la modélisation
qui porte l’intégration de l’entreprise est alors externe aux ERP qui ne jouent qu’un
rôle de « transaction » échangeant des messages avec l’architecture assurant le
pilotage. Or l'ERP porte les dépendances qui représentent l'intégration. Il peut y
avoir conflit entre l'intégration assurée par l'ERP et le processus modélisé dans
l'architecture d'entreprise. Cette approche ne suffit pas à prendre en compte la place
structurante prise par les ERP dans les architectures des systèmes d’information
d’entreprises.
La relation profonde entre modélisation d’entreprise et modèle implicite de
l'ERP suppose de mieux identifier les objectifs de la modélisation, de
l'automatisation d'une transaction au pilotage de la conduite du changement
organisationnel. La méthode GRAI situe ainsi la modélisation d'entreprise dans
l’aide au pilotage de projet ERP. Dans le contexte de cette méthode, la modélisation
aide à la construction du cahier des charges pour la recherche d’un
éditeur/intégrateur. Le contenu des besoins détaillés de ce cahier de spécifications
est classique (functionnal requirements, data description, interfaces, constraints..)
ce qui conduit à un questionnaire pondéré. Le modèle d’entreprise est réutilisé
pendant le projet pour aider au compromis entre « adapter l’entreprise au progiciel
ou adapter le progiciel à l’entreprise ».
Pour assurer la cohérence entre les deux niveaux, il faut rechercher les
conditions d'un pilotage par les modèles du système d'information d'entreprise, clef
d'une compréhension globale de l'entreprise, ce que certains proposent de désigner
sous le sigle ERPIII (Delen et al., 2005). Des architectures de pilotage par les
modèles (MDA) proposées en informatique permettent de formaliser les processus,
informations, entités organisationnelles et systèmes afin de rapprocher les modèles
d'applications hétérogènes comme un ERP et une solution CRM (Charalabidis et al.,
2005).
Pour éclairer cette relation entre modélisation et ERP, les différentes
approches doivent être situées dans leur objectif, de l’aide à la décision humaine
comme objectif « managérial » à l’instanciation informatique comme support
d’exploitation des objets modélisés. C’est ce que propose le cadre de
positionnement des techniques de modélisation proposée par Katzy et Sung (2003).
La Figure 2.11 situe les techniques de modélisation sur un premier axe définissant
le destinataire de la modélisation, acteur humain ou informatique, et sur un
deuxième axe définissant l’objectif de l’utilisation du modèle, modèle de
compréhension ou modèle support à l’exploitation. Le positionnement dans la

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 82
 Etat de l’art industriel et académique / Modélisation d’entreprise

matrice à des conséquences importantes sur le niveau exigé de granularité et donc

d’effort nécessaire et de flexibilité possible. Une démarche d'intégration de la
modélisation d'entreprise dans l'ingénierie des S.I. doit se situer dans ce cadre.

Figure 2.11: Cadre de positionnement des techniques de modélisation

3 Outils de modélisation pour les projets ERP

L es outils de modélisation existants sont nombreux mais de nombreux projets

utilisent uniquement des outils de représentation graphique facilitant la
communication entre acteurs dans l’équipe projet. Nous nous intéresserons aux
outils de modélisation qui proposent un cadre spécifique de modélisation
d’entreprise et/ou une intégration particulière avec un ou plusieurs ERP. Ces outils
sont les mieux à même d’illustrer la problématique évoquée précédemment. En
effet, pour que la modélisation soit le support du pilotage du projet et du système
d'information, il faut que le paramétrage et l'adaptation du système d'information
puisse se faire en conformité avec le modèle. Cela nécessite une cohérence entre le
référentiel de l'ERP et celui de modélisation :
If business processes are properly redesigned and business process models
document the improved situation accordingly, ERP systems can be configured
by these conceptual models. However, this requires that the process models are
linked with the repository of the respective ERP system (Scheer et Habermann
2000)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 83
 Etat de l’art industriel et académique / Modélisation d’entreprise

C ertains outils sont directement issus des méthodes académiques de

modélisation d’entreprise. La méthode GRAI-GIM est ainsi traduite dans un
outil de modélisation : IMAGIM de la société créée par les auteurs de la méthode
GRAISOFT. Il permet la représentation graphique des différents modèles de la
méthode : Actigramme, Grille GRAI, réseau GRAI et entités/relations. Les auteurs
soulignent l’enjeu de la modélisation d’entreprise pour maîtriser la difficulté d’un
projet ERP (Doumeingts et al, 2000). La méthode CIM-OSA a été traduite dans
plusieurs outils génériques de modélisation dont CImTool de la société RGCP
(Gaches et Chaumont 1999) principalement dédié à la mise en œuvre de CIM-OSA
et FirstSTEP Process Modeler développé par la société Interfacing Technologies
Corporation qui est un outil de modélisation générique (Levi et Klapsis 1999). Les
projets s’appuyant sur une modélisation CIMOSA ont deux résultats reconnus selon
l'éditeur de CImTool :
une aide à la compréhension et à la communication auprès des utilisateurs,
la possibilité d’outiller le modèle dans une approche Workflow
Cependant, l’utilisation de tels modèles dans un contexte ERP n’est pas
évoquée. Le cas étudié se déroule pourtant dans une grande entreprise équipée d’un
ERP. Les activités de maintenance et de réparations sur les installations qui font
l’objet du projet ont nécessairement des conséquences de gestion, entre autres sur le
suivi des stocks consommés et des temps passés. Ces conséquences de l’intégration
dans l’entreprise et qui sont traduites dans l’ERP ne peuvent être prises en compte
qu’à travers le travail de modélisation par les acteurs du projet. Le « modèle »
implicite de l’ERP doit être reconstitué dans un processus nécessitant des
simulations, donc de nature « essai/erreur ». Il est tout à fait possible qu’un modèle
valide du point de vue CIM-OSA ne soit pas réalisable dans l’ERP sans
modification substantielle de l’ERP. L’outil de modélisation d’entreprise n’est pas
encore en situation de « piloter » le système d’information.

L a méthode ARIS a été dès l’origine traduite dans un outil de modélisation aux
capacités larges, mais dont le développement a accompagné la diffusion de la
méthode elle-même. Cet outil permet de représenter de nombreux modèles
différents tout en assurant leur cohérence à travers des vues de contrôle permettant
de relier les objets des différents modèles. L’outil qui était dénommé « ARIS
Toolset » et s’appelle désormais « Business Architect » pour un usage avancé et
« Business Designer » pour un usage de base. De nombreux modules
complémentaires sont proposés dans la suite (simulation, gestion de performance).
De plus, une version propre à l’ERP SAP intègre la capacité de synchroniser les
modèles réalisés dans ARIS avec des objets de l’outil de gestion de projet SAP, SAP
Solution Manager. La synchronisation peut être utilisée dans les deux sens. Elle
permet de réaliser une forme de « rétro ingénierie » des processus SAP en créant le

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 84
 Etat de l’art industriel et académique / Modélisation d’entreprise

modèle ARIS correspondant à un ensemble de fonctions SAP. Elle permet à

l’inverse de gérer de manière dynamique le périmètre fonctionnel SAP
correspondant à un ensemble de modèles de processus ARIS (Scheer et Habermann
2000).

L e concept de modélisation dynamique d’entreprise a été proposé par l’éditeur

de l’ERP BAAN (Van Es et Post 1996), aujourd’hui édité par la société
INFOR. Il propose la modélisation de l’organisation et des processus de l’entreprise
comme outil de configuration de l’ERP et de pilotage des projets. En complément
de l’outil, des modèles de référence, adaptés à différentes typologies et secteurs
d’activités sont proposés. Cet outil et ces modèles de référence sont utilisés dans les
phases de sélection de solution en avant-vente des projets ERP comme un support
de la recherche de l’adéquation entre le besoin et la solution. Ils sont utilisés
pendant les projets comme outil de définition d’un périmètre, d’identification des
écarts en terme d’organisation et de processus métiers, puis de configuration de
l’ERP par la possibilité de générer les paramètres et les postes de travail
utilisateurs. Ils sont enfin utilisés en phase d’optimisation comme support des
démarches de ré-ingénierie facilitant la traduction des changements métiers décidés
en actions sur le système d’information.
Le premier niveau de modélisation est celui de l’entreprise organisée en
entités centres de profits « Business Unit » qui se décompose en société logistiques
« Logistics Units » responsable des flux d’ordres et des flux logistiques, des
fournisseurs aux clients, et en société financière « Financials Units » qui
comptabilise les flux financiers. Une entité centre de profit, est le croisement d’une
société logistique et d’une société financière et est décrit par un modèle de contrôle
métier « Business Control Model ». Ce modèle identifie les principales fonctions,
les principaux déclencheurs externes ou internes afin de définir les principaux
processus métiers qui pilotent les ordres, les flux physiques et les flux de gestion.
Ce modèle est détaillé en un modèle de fonction « Business Function Model » qui
permet de construire l’adéquation avec le référentiel fonctionnel de l’ERP. Les
processus sont eux détaillées en utilisant le formalisme des réseaux de Petri en
traitant les places comme des états d’informations ou d’ordres liés à un flux et les
transitions comme des activités qui peuvent être réalisées à l’aide de l’ERP ou
d’autres outils.
La relation ainsi établie à un niveau détaillé des activités des processus et
des composants du système d’information permet d’aborder la conduite de
changement d’un système d’information comme la mise en œuvre d’un changement
de version d’un produit en conception mécanique. L’ensemble des relations entre
composants et processus représentent une forme de « nomenclature » qui permet

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 85
 Etat de l’art industriel et académique / Modélisation d’entreprise

d’organiser la mise en œuvre de nouveaux composants dans le cadre du modèle

d’entreprise (JC Wortmann 2001)
Une comparaison entre CIM-OSA et DEM permet de considérer que DEM
est un point de départ cohérent avec la modélisation CIM-OSA qui doit être
complétée par les concepts de ressources et d’informations. (Cuenca, Hawa, et Ortiz
2001). Une comparaison entre d’une part CIMOSA, ENV 40 003, ARIS et DEM, et
d’autre part les caractéristiques des outils de modélisation issus de l’ingénierie de
conception produit, conduit à identifier plusieurs enjeux de la modélisation
nécessaires à la robustesse des outils proposés en terme de gestion des versions des
objets modélisés, des différentes vues et représentations possibles, du cycle de vie
et du statut des objets, de la généricité de modèles et des possibilités de paramétrage
des instances facilitant leur mise en œuvre dans un ERP (Wortmann et al., 2000).
Les outils provenant du marché des ERP sont ainsi de bons supports
potentiels des méthodes plus générales de modélisation d’entreprise et apportent
une capacité d’intégration au système d’information qui répond à une exigence des
acteurs industriels.

2.2.4 Modélisation et modèles de référence

L ’existence de méthodes et langages de modélisation conduit à poser la question

de la nature des modèles réalisés avec ces méthodes et langages. Destinés à
faciliter la compréhension humaine avant tout, ils peuvent donner lieu à une forme
de « capitalisation » des connaissances permettant leur réutilisation d’un projet à un
autre. C’est bien d’ailleurs le sens de la notion de généricité porté par les méthodes
de modélisation qui propose de modéliser non de manière spécifique à chaque cas
étudié, mais à partir de « modèles de référence » qui ont été construits dans une
démarche de standardisation. Un « modèle de référence » est à la fois un modèle au
sens du « patron » des couturiers, facilitant la construction d'un artefact par copie et
une référence faisant autorité dans une communauté. Les systèmes construits avec
sont plus facilement analysables et comparables car leur structure est partiellement
connue « de l'extérieur ».
Cette standardisation concerne d’abord la capacité à interpréter et échanger
des modèles. C’est ce qu’identifient les promoteurs de CIMOSA;
« To provide the required model inter-operability, the models have to adhere to
a common representation for both model enactment and human
understandability. International standardisation is a means to provide the
necessary model commonality » (Kosanke et Nell 1999)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 86
 Etat de l’art industriel et académique / Modélisation d’entreprise

Mais le contenu possible de la standardisation des modèles fait beaucoup

plus discussion et les mêmes auteurs limitent cette standardisation à ce qui
conditionne l’échange entre entreprises :
« Standardising the enterprises, parts of the enterprise, the products, the
information transferred, and the processes, is probably not going to be a
productive use of standard-making resources. What seems more usable is to
standardise the interfaces between components, the nomenclature, and the
formats »(Kosanke et Nell 1999)
Pourtant, on peut constater le développement de pratiques de pilotage
d’entreprises identifiées et traitées comme des éléments de connaissance et de
compétences pouvant faire l’objet de formations, d’évaluations, d’analyses
comparatives.
C’est le cas depuis longtemps de pratiques comptables s’appuyant sur la
normalisation du plan de compte selon les règles légales de chaque pays, mais
conduisant à des processus reconnus comme des « bonnes pratiques » pour, par
exemple, la clôture comptable, l’imputation des coûts indirects. Une méthode de
gestion comme la comptabilité des coûts par activité fait l’objet de pratiques
métiers fortement structurées et diffusées.
C’est aussi le cas depuis les années 60 des méthodes de gestion des
approvisionnements comme le MRP. Les processus et les rôles des acteurs de la
planification industrielle et commerciale, du plan directeur, des
approvisionnements ont été progressivement formalisés et diffusés sous des
formes variées mais conduisant à l’identification de « bonnes pratiques » qui sont
nécessairement à la base de tout travail de modélisation des processus de
planification d’une entreprise industrielle.
C’est encore le cas du modèle de pilotage d’une chaîne logistique avec le modèle
de référence SCOR (Stephens 2001) qui propose un ensemble de processus,
indicateurs, pratiques, fonctionnalités définies du point de vue de leur utilité dans
le pilotage de la performance d’une chaîne logistique.
La standardisation est de fait une réalité économique liée à la nécessité de
réduire les coûts d’appropriation de pratiques en évitant de « reconcevoir la roue »
à chaque projet. Les modèles de référence qui proposent des référentiels de contenu
dans un langage de modélisation donné sont donc un enjeu essentiel de la
modélisation d’entreprise.
C’est ainsi que GERAM introduit les « generic enterprise models » qui
sont de trois types (Bernus et Nemes 1996) :
« Blocs de base » qui représentent des parties communes à plusieurs classes
d’entreprises et peuvent être utilisé comme blocs de construction d’un modèle
complet.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 87
 Etat de l’art industriel et académique / Modélisation d’entreprise

« generique » (abstrait) qui modélisent des standards (« commonalities ») de

classes d’entreprises en laissant de coté les détails pour être réutilisables dans un
projet de modélisation comme une base à compléter,
« prototypes » qui représentent une entreprise d’une certains classe et peuvent
être utilisés comme base pour développer un modèle cible d’un cas particulier.
Des exemples de « blocs de base » existent (Reyneri 1999). Leur
spécialisation dans des métiers ou des typologies particulières d'entreprise nécessite
de normaliser les vocabulaires métiers utilisés. De ce point de vue, un modèle de
référence représente une connaissance dont la compréhension doit être partagée par
différents acteurs et différents points de vue. Cette connaissance ne peut être
formalisée uniquement par le méta-modèle des concepts qu'elle utilise, mais aussi
de manière extensive par les listes de leur instance et de leurs relations. C'est ce rôle
que jouent plusieurs normes définissant le contenu des échanges de données dans le
commerce électronique (RosettaNet 2002), les échanges collaboratifs industriels
(Odette 2004), les échanges techniques avec la norme STEP (ISO 10303 2006).
C'est ainsi que les ontologies deviennent un enjeu de la modélisation d'entreprise
pour passer des modèles génériques à des modèles particuliers instanciés dans des
contextes d'entreprise particuliers (Osterwalder 2004).

1 Manuel de processus du MIT

L e projet « handbook process » du MIT propose un référentiel de processus issu

de projets dans de grandes entreprises (Malone et al., 1999). Il est un support
pour analyser les processus à différents niveaux d'abstraction, en capturant ensuite à
la fois les détails des processus spécifiques et leurs structures profondes tenant
compte de leurs similarités.
Pour cela, contrairement aux techniques proposant uniquement une analyse
hiérarchique des processus décomposant un processus en ses composants sur une
dimension, le projet du MIT organise la connaissance de l’entreprise autant par une
décomposition d’un processus en ses composants, que par une analyse croisée des
typologies de composants nécessaires constituant ainsi une « boussole de
processus » dans laquelle la dimension verticale représente la décomposition en
composants, et la dimension horizontale illustre les différentes situations ou
contextes dans lequel s’exprime ces composants. Ainsi, la décomposition d’un
processus de vente qui inclut une activité de saisie de commande, aura un certain
nombre de variantes selon une typologie commerciale, industrielle ou technologique
(ventes en ligne, vente au détail, ventes à un distributeur… ). On retrouve l'axe de
généricité ISO19439.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 88
 Etat de l’art industriel et académique / Modélisation d’entreprise

Sur l’axe de ces « typologies » qui permettent d’organiser la généralisation

/ spécialisation des processus se trouve au premier niveau, l’activité la plus générale
qui est désignée sous le verbe « act » et qui peut se spécialiser en ; Create , Modify,
Preserve, Destroy, Combine, Separate, Decide, Manage, Unclassified. Les domaines
couverts par ce modèle de référence recouvrent l’essentiel des activités d’une
entreprise industrielle avec les domaines suivants : Procurement, Supply Chain
Management, Marketing, Sales, Information Systems, Human Resources, Strategic
Planning, Finance/Accounting, Manufacturing/Logistics, Engineering. Enfin,
l’approche par spécialisation s’inspire des approches objets en génie logiciel en
considérant qu’un processus spécialisé « hérite » des propriétés et notamment de la
décomposition de son père, sauf à venir la redéfinir en « surchargeant » la définition
du processus spécialisé. L’activité « deliver » du processus « sell per mail order »
est héritée du processus plus générique « sell », alors que l’activité « identifying
prospect» est remplacée par l’activité « obtaining mailing list ».
En complément, le modèle du MIT propose une classification des
« dépendances » entre processus en s’inspirant des travaux de Thompson (1967) sur
les dépendances entre organisations. Les différentes situations de dépendances entre
processus sont analysées :
« Fit » où deux processus contribuent à produire la même ressource,
« Flow » où un processus amont produit une ressource nécessaire à un processus
aval,
« Share » où deux processus utilisent la même ressource.
Ces différentes situations de dépendances permettent d’identifier les
mécanismes adaptés de coordination complétant le modèle de processus par un
modèle de coordination. Ces mécanismes recouvrent notamment les méthodes de
pilotage industriel (Make To Order/Make To Stock, Quantité économique ou
Kanban…) et viennent compléter le référentiel de processus en s’inscrivant dans la
même structure d’un axe de décomposition et d’un axe de spécialisation.
Cette notion de spécialisation de processus venant prendre en compte le
contexte d’instanciation du processus dans une entreprise suppose de pouvoir
définir et identifier clairement ces contextes sous forme de typologies ou
taxonomies de contexte. Cela recouvre la notion répandue de « modèle métier ».
Au-delà des typologies économiques existantes, la notion de « business model » est
ainsi étroitement associée aux modèles de référence orientée processus. C’est ainsi
que le MIT propose un « Business Model Architecture » à travers une approche plus
globale définissant des « modèles d’entreprise », non par une analyse détaillée des
processus impliqués, mais par une classification générale de ce qui est vendu et de
comment cela est vendu (Wei et al., 2005).
Le Tableau 2.8 représente les 16 typologies classées selon deux axes :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 89
 Etat de l’art industriel et académique / Modélisation d’entreprise

Le premier axe identifie ce qui est vendu en terme de droits (bien physique, droit
d’usage, mise en relation) en détaillant le « créateur » du bien d’un
« distributeur » et proposant ainsi 4 modèles génériques de base (Fabriquant,
Distributeur, Propriétaire, Courtier).
Le deuxième axe identifie ce qui est vendu en termes de nature (marchandise,
biens financiers, connaissance, ou « homme ». Cette dernière catégorie étant
présentée comme « illégale » dans un contexte sans esclavage (annontée par une
* dans le tableau), mais intégrée pour des raisons de symétrie du modèle.

Basic Business Model Archetype What type of asset is involved?

Financial Physical Intangible Human

Creator Entrepreneur Manufacturer Inventor Human

Creator*

Distributor Financial Wholesaler/ Retailer IP Trader Human

Trader Distributor*

Landlord Financial Physical Landlord Intellectual Contractor

Landlord Landlord
Broker
Financial Physical Broker IP Broker HR Broker
Broker

Tableau 2.8 MIT Business Model Architecture

2 Norme ISA S95

L a norme ISA-S95 proposé par l’organisme américain de normalisation

Instrument Society of America s'inscrit dans une architecture générale de
modélisation d'entreprise en niveaux dont le niveau 4 représente les activités de
pilotage et le niveau 3 les opérations de contrôle. La norme S95 définit les
interfaces entre les activités de pilotage de niveau 4 et les activités de contrôle
opérationnel du niveau 3. Elle se situe ainsi comme la norme d’échange entre ERP
et MES et prend en compte les fonctions de contrôle de production,
d'ordonnancement, de traitement des ordres de fabrication, d'administration des
expéditions de production, de comptabilisation des coûts de production...
Elle est constituée de plusieurs modèles et est supportée par un modèle de
donnée relationnel listant les attributs nécessaires à la caractérisation des produits,
ressources... utilisées. Elle propose une modélisation hiérarchique d’un domaine
décomposé en fonctions puis en détails entre lesquels sont identifiés des flux
d’informations portant des structures de données et leurs attributs. Tenant compte de
la dynamique des échanges, ce modèle contient donc implicitement un modèle de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 90
 Etat de l’art industriel et académique / Modélisation d’entreprise

processus métiers. Les flux d’information entre fonctions et les données qui sont
échangées sont normalisées sous forme objet dans la partie 2 de la norme. Par
exemple, le concept de capacité de production est décrit comme un ensemble de
capacité personnel, équipement, matières et segments de procédés. La capacité
équipement a des propriétés qui sont des éléments de modèles d'équipements. Il
s'agit bien d'un référentiel normalisant les concepts nécessaires à la modélisation
des échanges entre ERP et MES.

3 Modèle SCOR : référentiel des processus de la chaîne logistique

L 'amélioration de processus dans une chaîne logistique nécessite la définition

des éléments constituants cette chaîne dont la standardisation est un enjeu pour
permettre la comparaison entre chaînes logistiques. En 1996, soixante-neuf
industriels (dont Dow Chemical, Texas Instruments, Allied Signal, Merck & Co.,
Federal Express…) assistés de PRTM et d'AMR se sont regroupés pour former le
Supply Chain Council (SCC) afin de développer le modèle SCOR (Supply Chain
Operations Reference model). Ce modèle offre un cadre méthodologique complet
composé des éléments suivants (Stephens 2001) :
Descriptions standard des éléments composants les processus de la chaîne,
Indicateurs permettant de comparer la performance des processus à des références
externes,
Descriptions des meilleures pratiques associées aux éléments de processus,
Identification des progiciels commerciaux et de leurs fonctionnalités qui
permettent la mise en œuvre de ces meilleures pratiques.
SCOR ne propose pas de modélisation des systèmes d’information support
de la chaîne logistique, mais il identifie des « bonnes pratiques » et des
fonctionnalités associées qui font souvent référence à des noms d’applications (ERP,
SCM,…), mais aussi à des fonctionnalités de ces applications (inventaire cyclique,
contrôle des coûts par activité), parfois à des pratiques rendues possibles par ces
applications (sélection à base de règles d’un transporteur en expédition), à des
technologies (code à barre, RFID…). Ce référentiel est donc une base solide pour
permettre un travail d’alignement des S.I. aux processus. Il est nécessaire de
l’étendre aux autres domaines d’activité (relation client et conception notamment),
et de poursuivre l’effort de normalisation de l’ensemble des objets nécessaires à la
maîtrise de cet alignement.
Le modèle SCOR intègre l'ensemble des processus, des flux et des
transactions intervenant du fournisseur du fournisseur au client du client sur quatre
niveaux de détail pour la description des processus :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 91
 Etat de l’art industriel et académique / Modélisation d’entreprise

Le niveau 1 établit le modèle de la Supply Chain avec les processus génériques :

planification, approvisionnement, fabrication, livraison et retour.
Le niveau 2 définit différentes catégories à l'intérieur de chacun des quatre
processus (par exemple, distribution directe ou indirecte, fabrication sur
commande ou sur prévisions). Cette configuration reflète la stratégie retenue par
l'entreprise pour ses opérations.
Le niveau 3 permet aux entreprises d'affiner leur modélisation en précisant les
étapes de chacune des catégories de processus définies au niveau 2. C'est
également à ce niveau que sont identifiés les flux d'entrée et de sortie des
différentes étapes, les indicateurs de performance associés, ainsi que les
meilleures pratiques et les fonctionnalités des progiciels commerciaux et des
outils existants.
Le niveau 4 est spécifique à chaque entreprise, et assure la mise en œuvre
effective des meilleures pratiques. Il décrit les procédures propres à l'entreprise et
de leurs modes d'application.
Grâce à ces différents niveaux de modélisation, les entreprises ont les
moyens de décrire rapidement et sans ambiguïté leur chaîne logistique. Les
processus ainsi décrits peuvent aisément être modifiés ou reconfigurés dans le but
d'atteindre les objectifs de compétitivité souhaités. Leur structure est standard et
représentée dans la Figure 2.12 qui est une copie du tableau standard de description
d'un processus SCOR dans le document de référence du modèle. Il permet de mettre
en valeur les notions utilisées pour décrire un processus; indicateurs, pratiques,
fonctionnalités et informations.
Le niveau 4 reste spécifique à l'organisation de l'entreprise et à son
système d'information. Il constitue donc le support de l'alignement de l'organisation
et du système d'information à la stratégie logistique de l'entreprise. La
standardisation SCOR porte donc sur les processus et leurs indicateurs de
performance, ensuite sur leur rapport avec le système d'information en terme
d'informations et de fonctionnalités. L'alignement peut donc être très souple car
aucun modèle « interne » au système d'information n'est contraint (aucun modèle de
donnée, d'organisation, de procédure...). La standardisation porte sur la finalité du
processus et laisse ouverte ses modalités de mise en œuvre.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 92
 Etat de l’art industriel et académique / Modélisation d’entreprise

Figure 2.12: La structure d'un processus SCOR

De plus, l'adéquation entre les éléments informationnels de SCOR et le

standard des principaux ERP est facilement vérifiable, comme nous le verrons dans
la partie 3. La version 8.0 inclut d'ailleurs une première définition des informations
échangées par les processus qui s'appuie sur la norme ISA S95.

4 Modèles de références, taxonomies et ontologies

D ’autres modèles de référence métiers existent. Certains sont dédiés à une

activité particulière comme la proposition de norme d’échange (POSC 2005)
et de modèle de processus dans l’industrie du pétrole 22. Mais la diffusion de
modèles de référence dans le monde économique se fait le plus souvent en dehors
des normes de langage de modélisation et même des méta-modèles évoqués

22 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 93
 Etat de l’art industriel et académique / Modélisation d’entreprise

précédemment. De fait, ces modèles de référence répondent d'abord au besoin

pratique de «dictionnaires » communs pour échanger des données, interagir entre
des systèmes hétérogènes ou encore plus simplement les comparer. Mais la
production d'un dictionnaire est une activité ancienne qui a conduit à de nombreuses
recherches pour faciliter le classement et la recherche des informations, d'abord
physiquement dans les bibliothèques puis avec des systèmes d'information. La
première structure de classification est le plus souvent hiérarchique. On parle de
« taxinomie », terme issu des efforts des sciences de la vie pour classer
systématiquement les espèces vivantes en les regroupant dans un arbre hiérarchique
et utilisé en informatique pour représenter un arbre de classification comme
l'arborescence de navigation d'un site internet. Mais les bibliothécaires ont besoin
d'indexations multiples de documents et de relations non hiérarchiques. Ils
produisent des « thesaurus » avec des relations d'association ou d'équivalence entre
termes. Cela conduit à rechercher une représentation formalisée des connaissances
permettant de les partager et les réutiliser avec des systèmes informatisés. La
spécification de telles représentations est appelée une « ontologie » (Gruber 1993)
et repose sur une représentation en graphe symbolisée naturellement par Internet.
Une ontologie n'est pas un dictionnaire, mais le cadre, la structure
permettant une organisation effective des dictionnaires (Poli 1996). Une ontologie
n'est cependant pas un méta-modèle, car elle ne cherche pas à être une «synthèse
explicative » du domaine qu'elle représente, mais le support d'une description
utilisable et partageable. Une ontologie a une finalité. Elle peut être plus ou moins
formelle, notament selon qu'elle est destinée à résoudre un problème de
communication entre personnes ou organisations, d'interopérabilité entre systèmes
ou de spécifications en ingénierie (Uschold et Gruninger 1996). C'est d'ailleurs ce
qui conduit à l'existence de nombreuses ontologies pour chaque domaine d'étude,
même si des efforts de généricité sont ensuite recherchées pour permettre des
traductions ou regroupements entre ontologies. La norme en cours de validation par
l'OMG Group des règles et du vocabulaire métier contient ainsi non pas une liste
d'objets et de règles utilisées, mais une proposition de structuration d'un discours
permettant la description sémantique des objets et règles métiers. Ce constat
correspond bien à la réalité des systèmes d'information de gestion pour lesquels le
« vocabulaire » se développe par domaines de gestion (finance, logistique,
ingénierie...).
Une ontologie au service de l'ingénierie d'entreprise est proposée par
l'université d'Edinburgh pour améliorer les outils de modélisation d'entreprise
(Uschold et al. 1998). Elle est décrite à la fois textuellement et dans un langage
semi-formel (Ontolingua). Dans le même esprit, pour supporter une approche
d'ingénierie d'entreprise dirigé par les modèles, une ontologie d'activité est proposé

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 94
 Etat de l’art industriel et académique / Modélisation d’entreprise

par l'université de Toronto (Tham, Fox, et Gruninger 1994). Un modèle ouvert

proposé par des organismes de normalisation informatique (Open Information
Model de l'OMG Group) décrit en UML les méta-données techniques et métiers de
l'entreprise (Prothman 2000). Après une comparaison de ces différentes
propositions, une ontologie globale pour l'entreprise est proposée dans une approche
hiérarchique (Bertolazzi, Krusich, et Missikoff 2001) qui définit un « Core enteprise
Ontology ». Enfin, une ontologie portant sur les concepts « d'affaires » prenant en
compte les typologies d'entreprises vient compléter les ontologies centrées sur la
structure des entreprises (Osterwalder 2004) en différenciant ainsi le « modèle
d'affaire » du « modèle d'entreprise ».
Les ontologies peuvent être vues comme complémentaires à l'utilisation de
méta-modèles. D'une part, le travail sur des ontologies rend nécessaire d'enrichir les
méta-modèles qui permettent leurs échanges, travail très avancé dans le domaine
des bibliothèques (Lagoze et Hunter 2001). D'autre part, la grande dimension d'un
système d'information moderne et la pluridisciplinarité des métiers sous-jacents
rend impossible la production d'une ontologie unique pour la multiplicité des
domaines couverts. On peut rechercher une approche hiérarchique positionnant un
méta-modèle général articulant des modèles métiers eux-mêmes détaillés dans
l'univers du discours. Des approches à trois et quatre niveaux sont comparées par
Naumenko et Wegman (2003). Mais la cohérence entre modèles est un enjeu ouvert
qui rejoint les problématique d'alignement entre points de vue. Une approche de
mapping reposant sur une notion de « holon » regroupant l'objet physique et l'objet
informationnel est proposée dans le cadre d'une architecture MDA ((Baïna et al.
2006)). Un cadre permettant de positionner des ontologies ou thesaurus dans un
méta-modèle support d'un S.I. est ainsi proposé pour l'ingénierie des systèmes
d'information (Terrasse et al. 2006). De même, des ontologies sont utilisés pour
assister l'alignement des processus métiers aux standard du e-commerce (Seng et
Lin 2007). On peut donc considérer que si un modèle de référence doit pouvoir se
décrire à l'aide des construits d'un méta-modèle, il peut s'appuyer sur des
ontologies pour permettre l'échange et le partage des connaissances qu'il représente.

La modélisation d’entreprise s’est développée dans une approche

systémique de l’entreprise pour supporter des méthodes scientifiques
d’organisation et de pilotage des activités économiques. Elle est
rendue nécessaire par la complexité du couplage entre flux de
décisions, d’informations et flux physiques, condition de l’intégration
toujours plus forte des fonctions de l’entreprise. Elle s’est développée

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 95
 Etat de l’art industriel et académique / Modélisation d’entreprise

dans les années 1990 à partir d’une diversité d’approches qui ont
convergées vers la généralisation de concepts désormais répandus
dans les projets d’ingénierie d’entreprise. Le cadre de modélisation de
la norme ISO 19439 est une synthèse actuelle de ces concepts
articulés autour de plusieurs dimensions.
● La dimension du cycle de vie qui permet notamment d’identifier
les transformations nécessaires, de l’expression des besoins de
réingénierie d’une entreprise au pilotage de l’usage des
systèmes mis en œuvre. La modélisation d’entreprise est alors
le cadre le plus naturel de pilotage des projets de système
d’information, et peut proposer des méthodes et des outils
permettant d’aller vers la « génération » de certaines parties du
système d’information, vers la « configuration » de composants
standards du commerce, ou le « paramétrage » de certaines
fonctionnalités (autorisations, interface de navigation…).
● La dimension des « vues » qui permettent de construire un
modèle partiel en s’attachant à un « point de vue » permettant
d’isoler des éléments de description de l’entreprise pour en
faciliter l’étude et la représentation. Ces éléments se
construisent dans un langage utilisant un nombre limité de
concepts de base qui sont des « construits » à la disposition des
langages de modélisation.
● La dimension de généricité pour construire un modèle à partir
de modèles de référence qui se développent dans différents
domaines, gestion industrielle, contrôle de gestion, gestion de la
performance, chaîne logistique. Ces référentiels métiers se
constituent en parallèle à la standardisation des méthodes et
langages de modélisation et fournissent le contenu nécessaire
pour répondre aux attentes de standardisation et de réduction
des temps de cycles de projet.

La modélisation d'entreprise est largement utilisée dans les projets

ERP à travers des outils dédiés mais son positionnement dans les
méthodologies de projet reste discutée, entre support à la décision
dans la conduite du changement d'un projet et recherche d'un
environnement de pilotage ou d'exploitation de l'ERP. Dans tous les
cas, l'adéquation entre standard de l'ERP et processus modélisés
repose sur l'existence de modèles de référence support de l'alignement
entre organisation et système d'information.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.2
Institut National des Sciences Appliquées de Lyon 96
 Etat de l’art industriel et académique / Systèmes d’information et usages

Chapitre 2.3
Systèmes d’information et
usages

La place des technologies de l'information dans l'entreprise ne peut

être étudiée sans penser ses rapports avec les autres dimensions de
l'organisation. Prendre en compte l'ensemble de l'entreprise dans ses
dimensions techniques, économiques et humaines nécessite une
approche globale permettant de comprendre ce qu'est un « système
d'information ».

Dans ce chapitre, nous situerons donc l'origine des définitions de

« système d'information » dans l'approche des « systèmes », donc en
nous référant aux origines de la « systémique », pour caractériser les
différentes dimensions d'un tel système. Nous étudierons ensuite deux
approches d'origine informatique, l'architecture de Zachman et la
méthode USDP, avant de situer le contexte de l'alignement des
systèmes d'information à la stratégie d'entreprise, notamment dans
les démarches méthodologies issues de la standardisation des
applications.

Enfin, nous situerons l'importance d'analyser non seulement les

systèmes, mais plus encore leurs usages qui en font des systèmes
socio-techniques. Nous étudierons les approches portant sur la
maturité des acteurs, de l'organisation, dans la mise en oeuvre,
l'exploitation et le pilotage de ces systèmes.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 97
 Etat de l’art industriel et académique / Systèmes d’information et usages

2.3.1 De l’informatique au système d’information

L ’informatisation est visible dans l’entreprise d’abord par ses composants

technologiques qui s’installent sur les bureaux sous forme d’ordinateurs,
d’imprimantes et de câbles de toutes sortes, puis structure profondément
l’architecture des bâtiments et l’organisation même du travail, avant d’aboutir à une
« virtualisation » apparente d’organisations qui fédèrent temporairement des
travailleurs « mobiles » transportant avec eux l’ordinateur support de leur capacité à
agir, se connectant toujours plus étroitement à des réseaux étendus, mobilisant à
tout instant ce que leur offre cette « entreprise virtuelle étendue ».
Pourtant, si cette visibilité forte des technologies, et leur propension à
s’afficher par de puissants moyens marketings est certaine, elle masque souvent la
nature organisationnelle et humaine de leur déploiement, et ne permet donc pas
d’identifier ses succès et ses difficultés. De nombreux travaux ont donc cherché à
proposer un point de vue plus global sur la place de ces technologies dans
l’entreprise en adoptant un point de vue « systémique » cherchant à considérer les
moyens informatiques dans le contexte de l’organisation et de sa dynamique en
terme de d’action, de décision, de transformation.
La systémique est définie par l'AFSCET comme :
« une discipline qui regroupe les démarches théoriques, pratiques et
méthodologiques, relatives à l'étude de ce qui est reconnu comme trop
complexe pour pouvoir être abordé de façon réductionniste, et qui pose des
problèmes de frontières, de relations internes et externes, de structure, de lois
ou de propriétés émergentes caractérisant le système comme tel, ou des
problèmes de mode d'observation, de représentation, de modélisation ou de
simulation d'une totalité complexe » (Donnadieu, et al. 2003).
Cette définition centrée sur le système à étudier peut être complétée par la
finalité des démarches considérant alors la systémique comme une « méthodologie,
permettant de rassembler et d’organiser les connaissances en vue d’une plus
grande efficacité de l ’action » (Rosnay 1977) . Ces deux dimensions de la
complexité et de la finalité sont présentes dans les projets qui nous intéressent.
Ceux-ci nécessitent une représentation générique des systèmes permettant d’en
expliquer et parfois de prévoir les comportements. La représentation la plus
fréquente d’un système est celle d'un ensemble organisé de ressources transformant
des évènements externes considérés comme des stimuli en comportements
considérés comme des réponses du système. Elle est au cœur de l’approche
systémique de l'entreprise. Tout un courant de pensée s’est développé autour de
cette méthodologie, pour l’appliquer à ces organisations particulières que sont les

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 98
 Etat de l’art industriel et académique / Systèmes d’information et usages

entreprises (Blumenthal 1969; Le Moigne 1977). Cette approche systémique de

l'entreprise conduit à identifier trois sous-systèmes :
le système de transformation (S.T.) des intrants en extrants. Il est composé de
fonctions opérationnelles constituées de sous-ensembles physiques dont la
combinaison délivre un produit ou/et un service,
le système de pilotage (S.P.) est divisé en niveaux décisionnels (centres de
décision) délivrant les objectifs, les plans et les ordres d’exécution,
le système d’information (S.I.) reçoit des informations de l’environnement et du
S.T. et une représentation des décisions du S.P. pour construire de nouvelles
représentations utiles au S.P.
Une ville, une entreprise, une machine peuvent être considérée comme des
« systèmes ». Cependant, les systèmes qui comprennent des acteurs humains ne
peuvent se réduire à une vue « technique ». La dimension d'interaction entre les
acteurs et les composants techniques du système conduit à considérer l'interaction
homme-machine comme base d'un « système utilisateur-machine intégré »
(Peaucelle 1999). La prise en compte de l'organisation dans laquelle cette
interaction se situe conduit à parler de « système d'information organisationnel » car
« le problème n’est pas de faire circuler toute la connaissance
systématiquement, mais de la rendre économiquement accessible à la demande,
sans contraindre tous les acteurs de l’organisation à la consommer malgré
eux » (Le Moigne 1986)
Plus généralement, on parle de « systèmes socio-techniques » et de
nombreux chercheurs tentent d'intégrer dans l'approche systémique du management,
des éléments conceptuels venus de la psychologie sociale, de la sociologie, de
l'anthropologie (Donnadieu 1997). Comme l'évoque un sociologue travaillant sur la
place des technologies dans « l'efficience productive » :
« La différence entre une machine performante et une machine mal utilisée
provient d'une mauvaise perception de la partie immatérielle d'un système
socio-technique de production » (Ruffier 1998).
Une première étape est de prendre en compte les acteurs dans le système
d'information qui est vu alors comme :
« Un système composé d’entités diverses (employés, ordinateurs, réseaux,
applications, bases de données, règles. . .) chargées de stocker et de traiter les
informations relatives au système opérant afin de les mettre à disposition du
système de pilotage. Il peut recevoir des informations du système de pilotage. Il
peut émettre vers le système opérant des informations » (Reix 2002).
Mais il faut étudier plus précisément la relation entre système
d'information et organisation, les aspects informationnels de l'organisation :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 99
 Etat de l’art industriel et académique / Systèmes d’information et usages

« An information system is a sub-system of an organisational system,

comprising the conception of how the communication- and information–
oriented aspects of an organisation are composed (e.g. of specific
communicating, information-providing and/or information-seeking actors, and
of specific information-oriented actands) and how these operate, thus
describing the (explicit and/or implicit) communication oriented and
information–providing actions and arrangements existing within that
organisation » (Falkenberg et al. 1998).
Plus précisément encore, l’informatisation accompagne l’accélération des
cycles d’exécution et de décision qui se développe avec la croissance des échanges
et la spécialisation des acteurs par le partage des tâches. Cette répartition des tâches
à l’intérieur d’une organisation comme entre organisations crée des besoins de
coordination pour répondre aux impératifs de cohérence, donc utilise le traitement
et l'échange d’information qui apparaît alors comme le lien indispensable,
l’instrument majeur de la cohérence organisationnelle. Les tâches de traitement de
l'information peuvent être classées en capture, transmission, stockage, requête,
manipulation, présentation (Alter 1999).
Mais l’information est aussi un élément de l’ouverture et de
l’apprentissage d’une organisation. Pour agir de manière efficace, l’organisation
doit disposer de représentations pertinentes de son environnement afin d’interpréter
les signaux reçus de manière utile à ses objectifs, ses actions. L’organisation va
ainsi chercher à apprendre, donc à sélectionner des réponses efficaces aux stimuli
qu’elle reçoit. Ces processus d’apprentissage supposent l’existence de dispositifs de
mémorisation de l’information au sein de l’organisation, ce qui rend nécessaire leur
hiérarchisation, leur priorisation, et donc un « système » de traitement de ces
informations permettant de constituer une « base » de connaissances mobilisables
pour le système de décision, de pilotage et de transformation. On peut ainsi
distinguer trois points de vue complémentaires du S.I. (Darras 2004) :
Un point de vue fonctionnel pour lequel le S.I. est :
capable de collecter l’information provenant de la partie opérante,
capable d’organiser cette information en vue de son traitement,
capable de publier cette information à destination des puits d’utilisation
concernés (utilisateurs ou autres systèmes),
capable de mémoriser l’information, mais aussi de la connaissance sur
l’organisation du travail,
capable d’aider les acteurs de l’organisation dans l’exercice de leur métier,
en particulier supporter la décision au sein de l’organisation.
Un point de vue structurel pour lequel le S.I. est :
une suite d’interactions entre l’homme et des moyens informatiques,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 100
 Etat de l’art industriel et académique / Systèmes d’information et usages

décomposable au niveau des moyens en une collection d’entités matérielles

et logicielles dont l’agencement est variable, et de plus en plus désigné par
le terme d’architecture.
Un point de vue organisationnel pour lequel le S.I. est tout à la fois :
en osmose avec l’organisation, et en cela il est fortement sensible à une
modification organisationnelle,
un inducteur de mutation et de changement culturel pour l’entreprise.
Le point de vue structurel peut être décomposé en système informatique et
système de traitement de l’information (Morley et al. 2005). Cette décomposition
éclaire la relation profonde entre technologies et pratiques d’usage de l’information,
et met en exergue la nécessité de caractériser les conditions d’efficacité du support
des outils aux processus informationnels qui interagissent avec les systèmes
opérationnels et de décision (Figure 2.13).

Système d'Information

Système de traitement de l'information

Acteurs Information

Processus

permet S'appuie sur

Système Informatique

Matériels Logiciels

Applicatifs

Figure 2.13: Structure du système d'information (Morley et al., 2005)

Cette structure fait clairement apparaître les acteurs et les processus

comme composants essentiels du système d’information. Loin d'un simple problème
d’automatisation des tâches administratives répétitives, la question de l’utilisation
efficace et efficiente des technologies de l’information et de la communication,
autrement dit des conditions d’efficacité des S.I., est devenue aujourd’hui

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 101
 Etat de l’art industriel et académique / Systèmes d’information et usages

stratégique, et concerne toute organisation quelle que soit sa taille et son domaine
d’activité.

2.3.2 Ingénierie des Systèmes d’Information

S i la multiplicité des points de vue est essentielle à la compréhension des S.I.,

notre objectif d'étude est bien centrée sur leur maîtrise autant en termes de
projet que de pilotage. Elle doit être située par rapport au cadre de l'ingénierie des
systèmes définit par l'Association Française d'Ingénierie des Systèmes (AFIS) :
« Approche coopérative interdisciplinaire pour le développement progressif et
la vérification d'une solution pour le système, équilibrée sur l'ensemble de son
cycle de vie, satisfaisant aux attentes d'un client, et acceptable par tous »
(2004).
Bien que la notion d'information soit très présente dans ce glossaire, il ne
définit par le S.I.. Les exemples illustrant les processus relèvent de métiers liés à
des systèmes physiques (avion, voiture, usines...) qui contiennent des composants
informatiques, et même de véritables S.I., mais sans une étude particulière,
l'informatique étant vue comme une des technologies mobilisable en ingénierie des
systèmes, comme l'ingénierie des connaissances. Le cadre général de l'ingénierie
des systèmes est cependant utile pour caractériser l'ingénierie des systèmes
d'information. La Figure 2.14 présente une histoire des cadres d'ingénierie des
systèmes et d'architecture des systèmes d'entreprise. Le domaine de l'ingénierie des
S.I. apparaît ainsi comme origine des approches d'architectures d'entreprise (Farrel
2007). De plus, l’enjeu organisationnel a toujours été reconnu dans les projets
informatiques, même si les méthodes du génie logiciel se sont concentrées sur les
techniques de conception (généricité, réutilisabilité, qualité...). Les exemples
nombreux d’incompréhension entre les « incompétents » que sont les utilisateurs et
les « autistes » que sont les informaticiens ont conduits à la recherche de nouveaux
cadres de maîtrise des projets informatiques prenant en compte les dimensions
organisationnelles qui conditionnent les dimensions informationnelles.
« From the beginning, we should be recognizing the organizational issues; from
the beginning, we should be dealing with multiple locations; from the beginning
we should be explicitly concerned with timing – events, schedules, and so
forth » (Zachman 1987)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 102
 Etat de l’art industriel et académique / Systèmes d’information et usages

Figure 2.14: Ingénierie système et système d'information

Nous étudierons deux cadres d'ingénierie des S.I. pour identifier leur
apport aux enjeux évoqués de la standardisation et de l'intégration.

1 Zachman : un premier cadre d'ingénierie des S.I.

U n premier cadre d’ingénierie de système d’information a été proposé dans les

années 80 par analogie avec le métier d’architecte (Zachman 1987), prenant
en compte le caractère progressif de la définition du besoin, centrée sur les objectifs
au départ, puis se précisant au fur et à mesure de la réalisation du projet. Cela le
conduit à ne pas centrer sa démarche sur un « phasage » du projet mais à permettre
de mettre en cohérence les points de vue des différents groupes d’acteurs
contribuant au projet. Ces points de vue sont ceux des acteurs :
Le décideur dans l’entreprise, préoccupé par le périmètre et les objectifs d’un
projet dans le contexte du projet et de l’entreprise.
Le manager dans l’entreprise, responsable du point de vue métier , autrement dit
du « modèle d’affaire » (Business Model)
L’architecte du système cible. Il propose un modèle du S.I. considéré comme une
instanciation du modèle d’affaires plus rigoureux et plus cohérent d’un point de
vue informationnel.
Le concepteur du système qui décrit comment les technologies vont être utilisées
pour répondre aux besoins identifiés par l’architecte.
Le développeur qui réalise les programmes, bases de données, configurations
réseaux nécessaires

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 103
 Etat de l’art industriel et académique / Systèmes d’information et usages

L'utilisateur du système en fonctionnement après sa mise en œuvre dans une

organisation.
Chacun de ses points de vue est concerné par différents types d’objets ou
livrables qui seront modélisés dans le projet : les données (quoi), les fonctions
(comment), le réseau(où), les acteurs (qui), le temps (quand), la motivation
(pourquoi). La Figure 2.15 présente la matrice des acteurs et des questions.
Chaque cellule de la matrice que constitue ce cadre de référence est décrite en
proposant ses formalismes propres de représentation.

Figure 2.15: Le cadre de référence d'une architecture d'entreprise Zachman

Le cycle de réalisation du projet devient donc un cycle de transformation

des différents objets modélisés en cohérence avec les différents points de vue.
Zachman qualifie son approche « d’architecture d’entreprise », à la fois pour le
fonctionnement de l’organisation et celui du S.I.. Il anticipait une tendance
identifiée aujourd’hui en français comme le besoin d’une « urbanisation » des
systèmes d’information (Buffard 2006).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 104
 Etat de l’art industriel et académique / Systèmes d’information et usages

2 Approche USDP

A u cours des années 90, le développement des technologies orientées objet a

rendu nécessaire de nouvelles méthodes de conduite de projet. Des efforts de
convergence ont aboutis à la méthode USDP. C'est une des premières méthodes de
développement de système informatisé qui utilise explicitement le modèle comme
support de cohérence des différentes étapes et points de vue. Cette approche repose
sur un cycle en spirale. Des tâches d’un cycle de base sont répétées pour acquérir
une connaissance progressive dans l’espace de formulation du problème, et dans
celui de la proposition de solutions.(Jacobson et al., 1999; Scott 2001). La démarche
identifie quatre phases, de la modélisation du contexte et de la capture des besoins
jusqu’à la mise en place d’une version chez le client. La Figure 2.16 présente cette
démarche qui mobilise différentes « disciplines » au fil des phases du projet.
La phase « d’inception » (ou « commencement ») établit la faisabilité du projet,
en définit le périmètre et une architecture générale, identifie les principaux rôles
dans le projet et estime les délais, moyens et ressources nécessaires.
La phase d’élaboration réalise les premières analyses du système et planfie les
principales tâches de construction
La phase de construction bâtît le système, en finalise le développement et
l’assemblage afin de permettre la vérification de conformité aux exigences
La phase de transition prépare les activités de déploiement et de mise en service
avec les utilisateurs
Cette démarche place la relation entre les exigences ou attendus du projet
et les fonctionnalités du système qui sera conçu au cœur du projet afin de permettre
aux projets informatiques de mieux prendre en compte :
la nécessité de montrer à la maîtrise d’ouvrage l’état d’avancement du projet afin
de lever au plus tôt les risques inhérents au développement ;
la gestion des exigences formalisées de manière à ce que toutes les
fonctionnalités définies correspondent à une ou plusieurs exigences, et que le
respect des exigences puisse être contrôler en continu ;
une architecture logicielle privilégiant la construction du logiciel par
assemblage de composants ;
une communication plus rigoureuse entre développeurs et utilisateurs en
s’appuyant sur des modèles UML communs ;
la gestion des demandes de changement.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 105
 Etat de l’art industriel et académique / Systèmes d’information et usages

Figure 2.16: Démarche de projet USDP

Des compléments à la méthode USDP ont été proposées dans certaines

solutions pour situer les systèmes d'information dans le contexte plus large de
l'ingénierie des systèmes (IBM RUP-SE RUP for Systems Engineering (IBM RUP
2003) ou pour prendre en compte l'existence de progiciels standard dans la
conception de solutions (RUP Plug-In for COTS Package Delivery) (Péraire et
Pannone 2005). Cette préoccupation de la relation entre S.I. et système d’entreprise
est issue de travaux en ingénierie des S.I. et donc portée par des « informaticiens ».
Elle éclaire la nécessité de modèles facilitant la mise en cohérence des points de
vue, ce que beaucoup de travaux évoquent sous le terme « d’alignement » entre
système d’information et stratégie d’entreprise.

3 Alignement des S.I. et de l'organisation

L es enjeux des relations entre acteurs de l'entreprise et acteurs informatiques ont

conduit très tôt à des études pour les caractériser et mesurer l'impact d'actions
tendant à mettre en relation enjeux organisationnels et technologies de l'information
(Miller 1993). La notion d'alignement a été formalisée notamment par les travaux
du MIT qui propose en 1990 un cadre général de l'adéquation entre technologies,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 106
 Etat de l’art industriel et académique / Systèmes d’information et usages

organisation, stratégies, acteurs et processus de management dans un environment

technique et d'entreprise ( Figure 2.17).

Figure 2.17: Cadre proposé par le MIT en 1990

« ...an organizational structure and set of business processes that reflect the
interdependence of enterprise strategy and information technology capabilities.
The attention paid to the linkage of information technology to the enterprise
can significantly affect the competitiveness and efficiency of the business »
(Luftman, Lewis, et Oldach 1993)

U n autre cadre distingue un point de vue externe sur les technologies (la
stratégie) et un point de vue interne (infrastructure et process) soulignant ainsi
la dimension stratégique de l'alignement (Henderson et Venkatramen 1992). Ce
cadre est enrichi sur un deuxième axe différenciant l'organisation et les technologies
informatiques représentant alors des démarches qui peuvent avoir comme origine
une action stratégique sur l'organisation ou sur le système d'information, ou une
action opérationnelle sur l'organisation ou le système d'information.
Ce cadre d'alignement nous paraît porteur d'un élément essentiel de la
problématique de l'intégration qui n'est pas nécessairement une approche « top-
down ». Certains projets ERP naissent d'abord d'une volonté de la direction
informatique, qui peut avoir des motivations internes, et qu'il faudra ensuite
« vendre » aux directions opérationnelles. A l'inverse, certains projets ERP sont
déclenchés par une volonté ou une nécessité de ré-ingénierie et ce sont alors les

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 107
 Etat de l’art industriel et académique / Systèmes d’information et usages

conséquences sur le S.I. existant, qui peut par ailleurs donner satisfaction, qui
seront l'enjeu d'un projet. Enfin, des projets peuvent provenir du terrain, par
exemple de la nécessité opérationnelle de s'adapter à une nouvelle relation
commerciale imposant un certain format d'échange. Cette relation étroite entre
technologies et organisation se retrouve dans la chaîne logistique où l'alignement
des technologies de l'information contribue à l'intégration inter-entreprises. (Seggie
et al., 2006). Si cette notion d'alignement s'internationalise très vite dans le monde
du conseil, tout indique pourtant que les attentes des entreprises sont différenciées
selon les cultures nationales (Watson et al., 1997).
Ce défi de la cohérence entre les actions métiers et les projets
technologiques dans les grandes entreprises internationales conduit à chercher
comment donner à des acteurs différents une vue globale commune, une vision
cohérente de l'organisation permettant à chaque compétence de situer positivement
les autres :
«Business/IT parts of a company desperately need to work together as part of
an equal partnership and communicate together in such a way that the
organisation can simultaneously recognise group specialities and expertise,
whist presenting a united front » (Coughlan et al., 2005)
De fait, les premiers facteurs de succès dans l'alignement des technologies
aux stratégies d'entreprise sont à la fois, l'engagement des dirigeants dans
l'utilisation stratégique des technologies, la connaissance des acteurs des
technologies des métiers de l'entreprise, et la confiance des dirigeants dans l'équipe
informatique (Teo et Ang 1999) . Cette exigence est parfois désignée dans le monde
professionnel comme “Business Process Alignment” (Haan 2006) ou « Business
Process Mapping » (Lynch et Cross 1995) soulignant l'objet principal de cet
alignement dans la pratique : le processus. Elle peut être cependant étudiée en
distinguant les structures et les stratégies mises en œuvre dans les métiers et dans
les technologies. On peut parler de « co-alignement » structurel et stratégique
(Bergeron, Raymond, et Rivard 2004).
Mais une décennie après ses premières formulations, elle reste le plus
souvent identifiée simplement comme une situation « d'harmonie » entre métiers et
infrastructure de support sans que l'ingénierie des systèmes n'en propose réellement
de démarches ou modèles détaillée (McKeen et Smith 2003). On identifie pourtant
différents modes de conduite du changement dans des projets qui peuvent être des
ruptures technologiques (ERP) ou organisationnelles (BPR), mais qui peuvent aussi
être constitués d'actions d'améliorations continue. Cette classification sur le rythme
de changement sur les deux dimensions techniques et organisationnelles conduit
ainsi à 4 typologies d'intégration dont le big bang (projet dont la mise en œuvre
construit l'intégration organisationnelle et technologique) et à l'opposé une

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 108
 Etat de l’art industriel et académique / Systèmes d’information et usages

intégration « socio-technique » reposant sur un processus continu (Bygstad,

Nielsen, et Munkvold 2005).

U ne piste de progrès est sans doute liée à la croissance du marché des progiciels
et à sa dynamique qui pousse à considérer que l'offre devient un facteur
déterminant de la définition des processus cibles. L'expression des besoins de
l'entreprise n'a pas de sens sans prendre en compte les processus proposés par les
solutions standard existantes, ce qui implique de mettre en cause tous les aspects de
l'alignement entre organisation et système d'information.
« When processes are changed, people, organizations, business practices, and
management practices must change as well to support them. In other words, the
move to COTS-based systems development is not just an engineering or
technical change—it is a business, organizational, and cultural change as
well » (Oberndorf 2000).
Un livre récent intitulé « Business Process Change », définit le BPM à
trois niveaux : entreprise, processus et mise en œuvre. Pour ce dernier niveau ses
auteurs proposent une approche « ERP-Driven Redesign » (Harmon et Davenport
2007). Ainsi, la modélisation n'a pas pour but de traduire un modèle conçu dans une
démarche séquentielle classique en système spécifique « instanciant » le modèle
conçu. Elle est bien le support de la mise en conformité des différents points de vue,
le modèle porté par l'ERP étant tout autant une contrainte dans le projet que tout
autre élément du « contexte système » au sens de Oberndorf.
On arrive ainsi a une démarche d''alignement qui repose sur la comparaison
entre un modèle du système provenant des solutions progicielles et un modèle du
besoin établi par l'entreprise (Soffer 2003). Leur comparaison conduit à
l'identification des écarts (Gap Analysis) dont la résolution demande d'abord la
reformulation des besoins à la lumière de l'analyse d'écart effectuée, donc en
prenant en compte le modèle proposé par le progiciel. La démarche d'alignement,
que nous adaptons légèrement en considérant que l'analyse d'écart ne peut être
automatique, est alors itérative (Figure 2.18).
Cette démarche est proche de celle proposée par Boutin (2001) qui définit
le prototypage de l'ERP sélectionné en interaction avec le modèle de système cible
issu de l'expression des besoins et mis en relation avec le modèle de l'ERP choisi.
Cette démarche est aussi une démarche humaine, car le compromis
nécessaire dans la reformulation des besoins conduit à des changements de
l'organisation et des rôles des acteurs, changements qui vont représenter un enjeu
majeur des projets d'ingénierie. On ne peut donc comprendre complètement cette
problématique sans étudier le point de vue de l'utilisateur.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 109
 Etat de l’art industriel et académique / Systèmes d’information et usages

Enterprise
Requirments
Model

Enterprise System
Matching
Model

Match ang Gap Requirments

Analysis Reformulation

Aligned Model

Figure 2.18: Démarche d'alignement itérative (adapté de Soffer 2003)

2.3.3 Maturité des usages d'un S.I.

1 Apprentissage et confiance

L ’approche systémique cherche à « penser » le S.I. comme un tout. Cependant,

malgré des efforts de convergence des sciences de l’information, de
l’ingénierie, de la productique, mais aussi des sciences humaines et sociales, les
préoccupations des différents acteurs conduisent à mobiliser des outils adaptés aux
différents « points de vue » existants. Le constat général partagé par les pratriciens
des S.I. en entreprise est que ces systèmes intègrent une part des connaissances que
les acteurs cristallisent sous forme de données, il ne peut être transformé sans
prendre en compte les pratiques collaboratives des acteurs, les réticences, conflits,
erreurs, motivations... qui conditionnent l'efficacité de l'interaction entre les acteurs
et le système. Toutes les études montrent qu'une part essentielle de l'efficacité
potentielle du S.I. se perd dans les pratiques réelles que portent les utilisateurs.
« Quant à l’appropriation du système par l’utilisateur, seul un quart des
entreprises la qualifie de forte, et plus d’un tiers de faible » (Labruyere et al.,
2002).
Pour comprendre pourquoi une part parfois importante des utilisateurs
potentiels d’un ERP ne s’en sert pas et trouve des procédures de contournement, des
facteurs d’utilité de l’outil sont étudiés pour mesurer ce qui contribue à une
satisfaction de l’utilisateur. L’utilité perçue et la facilité d’apprentissage sont des
facteurs déterminants de satisfaction de l’utilisateur. Si l’outil est donc bien sûr un

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 110
 Etat de l’art industriel et académique / Systèmes d’information et usages

facteur important de l’usage, il ne suffit pas à créer l’usage qui suppose des
utilisateurs percevant la faisabilité et l’utilité de l’effort demandé (Calisir et Calisir
2004). Le « facteur humain » est ainsi déterminant dans les conditions de réalisation
des projets comme dans les conditions d’efficacité des usages. Les études
confirment les leçons de l’expérience en soulignant que la « confiance » des acteurs
dans les technologies est variable, et notamment en fonction des positions dans un
projet entre décideurs, équipe projet, utilisateurs, prestataires (Lander et al. 2004).
Cela rend d’autant plus nécessaire d’agir pour construire une telle confiance
nécessaire à l’appropriation par l’utilisateur. Cela nécessite selon Landa de
considérer des mécanismes et stratégies diverses, qui peuvent se jouer dans les
premiers contacts du projet et se construire ou se défaire même après la mise en
exploitation : la réputation, l’intégrité, l’engagement, la prédictibilité, le souci des
autres, le partage du contrôle, la disponibilité… On ne peut donc parler de système
d'information sans étudier la « maturité » acquise par l'organisation et les acteurs
dans l'usage de ce système.

2 Modèles de maturité

L a maturité des aptitudes d'une organisation a fait l'objet d'efforts de

normalisation pour proposer des « modèles » de maturité. Les premiers efforts
ont portés sur les démarches de projet avec les normes ISO 9001 (ISO 9001 2000).
Un des plus en vogue pour les projets informatique est le modèle « CMMI » qui se
définit comme une collection de « bonnes pratiques », un cadre d'organisation et de
priorisation des activités, un support pour la coordination d'activités pluri-
disciplinaires, un moyen de souligner l'alignement des objectifs d'amélioration de
processus avec les objectifs d'amélioration des affaires (CMMI 2007). Centré sur les
activités de projet et de maintenance des systèmes d'information, il est très proche
de la norme ISO 9001 qui concerne plus largement toutes les activités de
l'entreprise (Mutafelija et Stromberf 2003). Le modèle CMMI propose cinq niveaux
de maturité :
1. initial : processus imprévisibles, mal controlés et réactifs
2. processus gérés : un processus par projet, gestion parfois réactive
3. processus définis : processus standardisés, gestion proactive
4. processus maîtrisés : processus sous controles
5. optimisation : amélioration continue des processus

Un niveau de maturité est caractérisé par des « domaines de processus »

décrits par des « objectifs » qui peuvent être atteints par des « pratiques ».
Objectifs et pratiques peuvent être spécifiques à un domaine de processus ou

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 111
 Etat de l’art industriel et académique / Systèmes d’information et usages

génériques. Les objectifs d'un domaine doivent être atteints pour considérer le
domaine sous contrôle et donc évaluer le niveau de maturité correspondant. Une
pratique est mesurée par des livrables dont l'existence est la première étape de
l'évaluation CMMI. Ce contrôle des livrables est clairement issu de l'ingénierie de
projet et du contexte de développement ou maintenance d'un système. Il ne permet
pas d'évaluer la maturité des activités opérationnelles d'une organisation. Une
relecture du modèle CMMI est proposé par ses promoteurs pour l'évaluation des
opérations à partir de la recherche des analogies entre démarche de projet et
démarche d'amélioration (Gallagher 2002). Cependant, l'évaluation des services
apportés à une entreprise par un système d'information repose sur des processus
différents et complémentaires (Niessink et Vliet 2000) qui doit prendre en compte
l'exploitation de ce système et ses résultats en terme d'information mise à
disposition et des différents usages que le système en permet.
Le modèle ITIL (Information Technology Infrastructure Library) édité par
l'Office Public Britannique du Commerce23 est lui basé sur les processus de soutien
et de réalisation des « services » informatiques qui peuvent être apportés à une
organisation, autant dans un contexte de prestataires externes qu'internes. Il se
présente comme un ensemble de « bonnes pratiques » regroupées en 9 « livres »
dont les premiers portent sur les processus de support au service, la livraison des
services, le management et la relation client, le support logiciel, les opérations
systèmes, les réseaux. La version 3 introduit un « cycle de vie » pour faire le lien
entre les pratiques de gestion de projet et les pratiques de gestion de services. Mais
le modèle décrit une organisation « idéale » d'une organisation de services
informatiques sans proposer de démarche de mise en œuvre tenant compte de la
« maturité » de cette organisation.
Le modèle « IT Service CMM » s'inspire du modèle CMMI pour une
organisation de services informatique en identifiant les processus nécessaires pour
répondre aux dysfonctionnements identifiés dans des organisations de service ayant
mis en œuvre une évaluation des niveaux de service et même une démarche ITIL
(Ni e s s i n k e t Vli et 1 9 9 8). Les dysfonctionnements étudiés portent notamment sur
l'évaluation qualitative des informations portés dans un processus et dont la faible
valeur peut mettre en cause l'efficacité du processus pourtant respecté. C'est une
démarche proche que nous proposons avec un modèle de maturité des systèmes de
type ERP.

23 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 112
 Etat de l’art industriel et académique / Systèmes d’information et usages

3 Matrice de maturité d'usage d'un système ERP

L e constat évoqué au chapitre 1.1 des difficultés de la maîtrise des systèmes

ERP dans tout leur cycle de vie conduit à rechercher les conditions
particulières d'efficience des usages. A partir d'enquêtes quantitatives et qualitatives
sur des entreprises utilisatrices de systèmes ERP, les dysfonctionnements constatés
et les actions correctrices conduites sont synthétisées pour une classification mettant
en lumière des « niveaux de maturité » (Botta-Genoulaz et Millet 2005). La Figure
2.19 présente cette classification reposant sur deux axes de maîtrise des S.I., eux-
mêmes décomposés en trois niveaux : Le premier axe intitulé « Maturité de l’outil »
relèvant de la bonne utilisation des systèmes du point de vue de leur efficience
propre, se décompose en Maîtrise de l’outil, Amélioration, Évolution. Le deuxième,
intitulé « Support de la stratégie », relevant de la contribution du S.I. à la
performance de l’entreprise, de son efficience, se décompose en Maîtrise des
données de base, Maîtrise des processus, Accompagnement stratégique.

Figure 2.19: Matrice de maturité outil/processus

Nous proposons sur cette matrice une vision synthétique d’une démarche
d’optimisation. Elle souligne la contrainte de cohérence entre les deux axes, le
système d’information ne pouvant apporter à la stratégie d’entreprise sans être
maîtrisé en tant qu’outil, certaines situations sont impossibles (maîtriser les
processus sans maîtrise de l’outil).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 113
 Etat de l’art industriel et académique / Systèmes d’information et usages

Chaque niveau a été défini par les critères d’alertes permettant de le

reconnaître et par les actions d’amélioration caractéristiques à mettre en œuvre à ce
niveau. Nous pouvons ainsi dégager une stratégie de meilleure utilisation du S.I. en
deux grandes étapes qui aboutissent à la situation d’un système d’information
considéré comme contribuant à la stratégie de l’entreprise. Ces étapes sont
représentées par des niveaux d’optimisation et permettent de distinguer trois
situations :
Pour atteindre la situation 1 : optimisation opérationnelle centrée sur la bonne
utilisation de ce qui existe (Maîtriser les outils pour maîtriser les données) ; le
système d’information est considéré comme un outil de production et diffusion de
données.
Pour atteindre la situation 2 : optimisation tactique centrée sur la meilleure
intégration de ce qui existe afin de permettre une utilisation plus efficace
(améliorer les usages pour mieux maîtriser les processus) ; le système
d’information est ici considéré comme un outil d’aide au pilotage des processus
opérationnels de l’entreprise.
Pour une utilisation maximale des systèmes d’information : optimisation
stratégique conduisant à modifier le positionnement de l’ERP existant dans la
stratégie du système d’information : il est alors un véritable élément au service de
la stratégie de l’entreprise.
Des audits réalisés dans plusieurs entreprises sur l’utilisation des modules
de planification (MRP) au sein des ERP permettent de valider cette proposition de
classification des démarches d’optimisation.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 114
 Etat de l’art industriel et académique / Systèmes d’information et usages

Un système d'information est un ensemble structuré de ressources

informatiques et humaines pour capturer, traiter et distribuer de
l'information. Dans une approche systémique, il développe la capacité
du système de pilotage à agir sur le système opérant. Il est intiment
lié à l'organisation, aux interactions entre les acteurs, entre les acteurs
et l'organisation, entre l'acteur et le système. Son efficacité est
d'abord celle des usages par les acteurs.

L'ingénierie des systèmes d'information prend en compte cette

dimension organisationnelle de la capacité d'un système à répondre
aux besoins, identifiant des points de vue divers à prendre en compte,
proposant donc une multiplicité de représentations pertinentes pour
formaliser le besoin et le système. Elle cherche à construire
l'alignement du S.I. à la stratégie d'entreprise.

Des approches ont été développées et sont utilisées dans le contexte

de développement de S.I. spécifiques et proposent donc des
démarches relativement séquentielles « traduisant » par étape le
besoin en solution. Des approches récentes complètent les cadres
existants pour prendre en compte la place des progiciels, proposant
des démarches itératives de prototypage dans lesquelles la décision
humaine reste nécessaire pour trouver le compromis efficace entre
contraintes d'organisation et systèmes d'information, pratiques
existantes et conduite du changement ...

Au delà du projet de construction d'un S.I., la place de l'acteur dans

l'efficience de ce système conduit à évaluer la maturité acquise par
l'organisation. Des modèles de maturité formalisent les bonnes
pratiques et peuvent être adaptés à l'analyse des retours d'expérience
des projets ERP. Cela conduit, à coté des concepts de processus,
fonctions, ressources que la modélisation d'entreprise et l'ingénierie
des systèmes formalisent, à insister sur la notion de pratiques pour
caractériser et évaluer les comportements humains et
organisationnelles qui sont les seuls facteurs de performance d'un S.I.
tout en le conditionnant lui-même.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.3
Institut National des Sciences Appliquées de Lyon 115
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

Chapitre 2.4
Intégration
organisationnelle et
informationnelle

Comme nous l'avons vu en caractérisant les projets ERP, l'intégration

est un enjeu essentiel des systèmes d'information. L'intégration est
pour les gestionnaires une réponse à la nécessité de la coordination
dans une entreprise. Nous étudierons donc tout d'abord cette
intégration organisationnelle. Nous verrons ensuite qu'elle suppose et
repose sur une intégration informationnelle qui est au cœur de la place
prise par les systèmes d'information. Cette dimension informationnelle
de l'intégration nous conduit à étudier les dépendances comme
élément de couplage entre des entités, des acteurs, des entreprises.

Nous verrons que cette notion de couplage « fort » ou « faible » est

au cœur de représentations multidisciplinaire de l'organisation, avec
les efforts de partitionnement (« clustering ») qui ont mobilisés
gestionnaires, informaticiens, économistes, logisticiens... Nous
étudierons ensuite les techniques de partitionnement avant de
conclure ce chapitre en précisant comment cette intégration
informationnelle est portée dans les systèmes ERP et dans la
modélisation d'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 117
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

2.4.1 Intégration et organisation

1 Intégration et coordination

T oute organisation est caractérisée par une structure de liens hiérarchiques et

fonctionnels qui assurent la stabilité, la cohésion et la dynamique du système.
Elle permet de maîtriser la complexité du système en répartissant les fonctions et en
assurant les liens nécessaires entre elles. Les formes de répartition et la nature des
liens existant entre les sous-ensembles de la structure peuvent être variées et
correspondre à des finalités différentes. Cette décomposition d'un système conduit
généralement à une vision hiérarchique de la structure en trois niveaux :
stratégiques, tactiques et opérationnels (Anthony 1964). Mais toute décomposition
conduit à interroger le niveau d'autonomie de décision de chaque sous-système, leur
« intégration » dans une logique commune de coopération et des moyens divers de
contrôle, la rationalité et la conflictualité des acteurs qui vont « coopérer ». La
division des tâches ne constitue ainsi qu'un des fondements de l'organisation et
renforce le problème des dépendances entre les tâches. Pour réduire ce problème,
(Thompson 1967) proposa une démarche de simplification des problèmes de
coordination par modification de l'organisation. Il classa les problèmes de
coordination en trois classes de difficulté croissante et proposa un mode de
coordination plus particulièrement adapté à chacune de ces classes :
La coordination par règle à l'intérieur d'une même structure permet de réguler ce
qu'il appelle la « pooled interdependence » (dépendance au sein d'un même
groupe par la production ou l'usage d'une ressource commune).
La coordination par planification traite le problème de la coordination d'activités
se déroulant séquentiellement, un résultat de la première venant conditionner la
suivante (« sequential interdependence »).
La coordination par ajustement mutuel permet enfin de répondre aux
interdépendances mutuelles, cas le plus difficile à son avis de coordination
(« reciprocal interdependence »).
Cette vision sera complétée par les travaux de Lawrence et Lorsch (1969)
qui identifient deux manières de résoudre ces problèmes de coordination :
En les réduisant, par modification de la structure, ou par introduction de jeux
(« slack »).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 118
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

En augmentant les capacités d'intégration de l'organisation, par le développement

de systèmes d'information verticaux ou latéraux.
Leurs travaux ont montré les limites du pilotage hiérarchisé dans un
environnement diversifié, situation dans laquelle l'adaptation à l'environnement
passe par une décentralisation des décisions. Mais le risque de la « non
observabilité » des activités décentralisées renforce l'importance des capacités
d'intégration qui doivent pourtant autoriser une forte flexibilité de l’organisation. La
décentralisation ne supprime pas la nécessité de l’intégration à mettre en place pour
rendre cohérent l’ensemble des décisions de l’entreprise.
Une théorie de la coordination a été proposée par Malone et Crowston
(1994) qui caractérisent les dépendances entre tâches comme liées aux ressources
partagées ou échangées entre elles, proposant une classification de ces dépendances
par ressources partagées, relations client-fournisseur, simultanéité et dépendances
entre tâches et sous-tâches. Cette intégration outil de maîtrise de la coordination que
rend nécessaire la dépendance entre activités peut se réaliser de deux manières
(Daihani 1994) :
L’intégration physique en regroupant les différentes parties ou même en les
fusionnant pour n’en faire qu’une seule (exemple : intégrer un sous-traitant). Il
s'agit de réduire le nombre des éléments à gérer, d'obtenir une interdépendance
étroite qui tend donc à rigidifier le système par suppression des découplages
(Everaere 1994).
L’intégration fonctionnelle qui relie deux ou plusieurs parties en partageant des
ressources communes informationnelles ou matérielles. Chaque élément garde
son autonomie et l’intégration harmonise la collaboration ou l’enchaînement des
tâches entre les différentes parties dans le but d’atteindre des objectifs communs.
On peut alors définir la coordination comme la recherche de cohérence dans les
interactions (Everaere 1994).
L’histoire de l’intégration des systèmes d’information permet d’identifier
quatre niveaux d’intégration des systèmes, des applications, des affaires, et enfin
des entreprises.
« L'intégration peut être définie comme un effort d’amélioration de
l'efficacité globale en liant les éléments au moyen de réseaux de communication
pour obtenir une meilleure réactivité et efficacité du système global comparé avec
les opérations isolées de ses composants » (Kosanke et al., 1999).
L’intégration est ainsi l'effort d'une organisation pour des relations
interindividuelles, inter-fonctionnelles et inter-entreprises plus étroites (Geffroy-
Maronnat et al., 2004). Elle se fonde sur une coordination plus étroite des tâches,
sur la coopération et sur le partage des informations et des prises de décision. La

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 119
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

gestion de cette interdépendance organisationnelle au niveau intra ou inter

entreprise devient ainsi une intégration « informationnelle ».
Cet enjeu s'est étendu aux relations inter-entreprises notamment pour le
pilotage des chaînes logistiques et plus généralement dans les collaborations qui
s’établissent dans les « entreprises virtuelles » ou « étendues ». Différents modes de
coordination sont nécessaires aux partenaires d'une chaîne logistique. Il leur faut
ajuster ou combiner correctement des moyens, des actions, des objectifs, des
décisions, des informations et même des connaissances pour assurer un
fonctionnement efficace de la chaîne. Un mode spécifique de coordination est
nécessaire selon les caractéristiques de la dépendance qui doit être controlée. Il peut
être analysé sur deux dimensions :
le degré de mutualisation de la coordination qui augmente depuis la simple
complémentarité des acteurs, puis dans la recherche de cohérence pour la
compréhension de leur dépendance et enfin dans une vision commune des
objectifs,
l'objet « focus » de la coordination qui peut porter uniquement sur les liens
opérationnels ou sur la coordination des processus support de la dépendance pour
devenir de véritables processus collaboratifs, ou encore impliquer plus
globalement une dépendance organisationnelle conduisant à un partage de la
connaissance sur la demande finale et les ressources de la chaîne pour supporter
les processus de décision (Tableau 2.9).
Mutualisation de la coordination
Complémentarité des processus de la compréhension
Focus de la Liens Synchronisation logistique Partage
coordination opérationnels (objet produits/services et d’informations
processus logistiques) (objet : information)

Liens Motivation d’alignement Apprentissage

Organisationnels (objet : bénéfices et collectif
risques) (objet : connaissances
et capacités)

Tableau 2.9 : Les deux dimensions de la coordination ((Simatupang et al., 2002)

Le support de la coordination, dans tous les modes identifiés, est ainsi

fortement informationnel, depuis les données opérationnelles qui accompagnent les
flux physiques (synchronisation) jusqu'au partage d'informations construites par les
acteurs dans les activités tactiques ou stratégiques (apprentissage). Les mécanismes
d'intégration dans une organisation reposent ainsi fortement sur le système de
décision et le système d'information (Daihani 1994). Les sciences sociales peuvent
utiliser une représentation de cette intégration sous forme de graphe. Ainsi Yu et
Mylopouloos (1997) propose un modèle de dépendances stratégique sous forme d'un

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 120
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

graphe reliant les acteurs par des relations de ressources, activités, buts et « buts
indirects » (softgoal), dépendances qualifiées par le niveau de vulnérabilité qu'elles
représentent, et un modèle de rationalité stratégique qui relie les ressources,
activités et buts dans un arbre au moyen d'une relation de causalité entre une
activité et son résultat (means-ends) et d'une relation de décomposition d'une
activité en activités et objectifs « indirects » (softgoal). Nous considérons cette
représentation sous forme de graphe, comme un outil commun aux informaticiens et
aux gestionnaires pour représenter la complexité des dépendances qui constituent
ensemble l'intégration d'un « système entreprise ».

2 Intégration informationnelle

L ’interdépendance croissante des systèmes d’information est ainsi non seulement

la conséquence de l’informatisation croissante des fonctions de l’entreprise et
des échanges eux-mêmes en croissance, mais aussi le support d’une réponse à
l’intégration organisationnelle. Cette intégration informationnelle s’est construite
autour de différentes approches :
L’enrichissement des bases de données cherchant à intégrer les logiques
applicatives à partir de règles évènementielles, de structures de données évoluées
(graphes, arbres…), et d’interaction supportées par les données (triggers…).
Le développement d’applications d’entreprise complète (ERP) intégrant et
standardisant de nombreux domaines fonctionnels.
La standardisation de protocoles et normes d’échanges réduisant le coût des
transactions entre applications (EAI, CORBA, DCOM, J2EE…).
L’urbanisation du système d’information autour de cartographie modélisant les
organisations et leurs processus, le système d’information et les applications et
outils le supportant.
L’intégration par les EAI (Enterprise Application Integration) a montré la
complexité des différents niveaux de cohérence nécessaires depuis les plateformes
techniques (Broker, accès distant, publication…), les données (extraction,
transformation, métadonnées…), les composants (transaction, services web…), les
applications (connecteurs, API…), les processus (modélisation et workflow….), et
même les relations d’affaires (EDI, place d’affaires…) (Gold-Bernstein et Ruh
2004).
Ce besoin d'intégration informationnelle est au coeur du développement
des ERP qui se sont présentés dans un premier temps comme la solution à la
difficile maintenance d'un système éclaté en multiples îlots informatiques
nécessitant de nombreuses interfaces. En proposant l’interconnexion fonctionnelle,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 121
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

l’homogénéisation inter-fonctionnelle et l’ouverture évolutive, les ERP permettent

de converger vers “ le vieux rêve d’un référentiel unique du système d’information
de l’entreprise ” (Rowe 1999). Ils sont apparus comme une réponse au problème de
la fragmentation des informations dans des organisations de grande taille promettant
une intégration complète de toutes les informations circulant dans une société, de
toutes les fonctions et processus (Sarkis et Gunasekaran 2003).
Cette intégration informationnelle s'est étendue aux relations inter-
entreprises avec les applications du SCM (Supply Chain Management) qui cherche
notamment à coordonner la prise de commande par un client le plus directement
possible dans le système d'information du fournisseur. Une étude des scénarios
d’intégration de ce processus de commande conduit à identifier quatre techniques
d’intégration (Werner et Vetter 2003) :
une intégration « visuelle » par l’interface utilisateur autorisant des appels à des
outils externes ;
une intégration « fonctionnelle » par les interfaces de programmation applicatives
(API) ;
une intégration « données » par l’échange et la transformation de données ;
une intégration « orientée message » avec le routage (EAI), les workflow traitant
des flux de données avec gestion de statuts.
L'intégration informationnelle repose ainsi sur une intégration
informatique qui se réalise à la fois par la standardisation des normes d'échanges et
par la standardisation des applications. L'intégration peut être très forte, notamment
à l'intérieur d'une organisation où les entités seront considérées d'abord comme
« fortement couplée ». Elle peut être au contraire « lâche », notament dans les
échanges inter-entreprise. On parlera alors d'interopérabilité, comme mode
« faiblement couplée » de l'intégration (Vernadat 2007) .

3 Intégration, dépendance et couplage

L’intégration s’exprime donc sous des formes diverses mais dont une
représentation simple et générique peut être de caractériser les diverses formes de
« dépendances » entre les différents types « d'objets » ; entités, ressources,
décisions, informations, systèmes impliqués dans cette intégration. Ces dépendances
sont au cœur des préoccupations des sciences de gestion qui cherchent à identifier
leurs caractéristiques économiques (identifier, imputer, analyser des coûts et des
revenus entre entités), à organiser leur pilotage en proposant des structures limitant
ce couplage (externalisation) ou au contraire en facilitant le contrôle (intégration).
Une des premières théories générales des systèmes intègre ainsi dans son glossaire
le concept de « coupling » défini comme un ensemble de variables communes à

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 122
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

deux éléments du système ou un élément du système et son environnement. Ce

« couplage » est caractérisé par un degré d'intensité (réel, hypothétique ou dirigé)
selon son domaine de validité (Klir 1969). Bien avant la problématique des ERP, ce
concept permet d'étudier la contradiction entre le besoin d'autonomie nécessaire à la
créativité et la flexibilité et le besoin de cohérence nécessaire au contrôle. Une
structure de management « faiblement couplée » est ainsi proposée dans un modèle
reposant sur « deux noyaux », l'un technologique, l'autre administratif (Daft 1978).
La même approche (Tableau 2.10) est proposée comme cadre d'étude du compromis
entre intégration et réactivité locale dans les modes de coordination et de
configuration d'une structure multinationale (Spender et Grevesen, 1999).
Prolongeant les travaux sur la capacité d'une organisation a construire des
convictions internes tout en réagissant a des incertitudes externes, cette « théorie du
couplage faible » cherche à concilier réactivité globale et différenciation locale
(Orton et Weick 1990). Ce modèle a été fréquemment évoqué pour caractériser les
universités (Fusarelli 2002) , (Avila de Lima 2007) ou les organismes de santé
(Pinelle et Gutwin 2005). L'étude des conditions d'efficacité d'organisations
faiblement couplées conduit à caractériser ce qui maintient les entités diverses d'une
organisation dans leurs transformations et notamment le rôle des dirigeants et les
pratiques des acteurs (Spender et Grinyer 1995). C'est une des caractéristiques des
entreprises de taille moyenne dont les structures organisationnelles sont souvent
évolutives et constamment interprétées par des acteurs dominés par les contraintes
opérationnelles (Huin 2004).

Réactivité locale Réactivité locale

faible forte

Firme globale Transnationale

Réactivité globale
(système fortement (système faiblement
forte
couplé) couplé)

Multinationale
Réactivité globale
Non structuré (système non
faible
couplé)

Tableau 2.10: Couplage et matrice intégration/réactivité

La place prise par les S.I. dans les relations entre acteurs les place au cœur
de ce qui construit ce couplage plus ou moins fort dans une organisation,
notamment par l'échange d'information. On peut ainsi caractériser l'intégration entre
deux organisations par la mesure de l'intensité de leur « couplage » informationnel

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 123
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

qui peut dépendre de la nature des informations échangées et le nombre

d'intermédiaires impliqués dans l'échange. Une telle classification dans le cas d'une
chaîne logistique permet ainsi de définir un niveau d'intensité de ce « couplage
logistique » (Barut et al., 2002). Ce couplage des partenaires d'une chaîne logistique
n'est pas limité à l'échange d'information mais peut reposer sur une dépendance
forte des processus eux-mêmes pouvant conduire à la notion d'entreprise virtuelle.
(Themistocleous et al., 2004)
Ce concept de « mesure » de l'intégration est étudié par plusieurs auteurs à
partir notamment de la représentation des dépendances dans la modélisation
d'entreprise. On peut considérer qu'une dépendance doit être modélisée comme une
relation entre deux objets (Giachetti et al. 2005). On peut la compléter par la
dépendance organisationnelle induite par la position des objets dans une hiérarchie
(Ganesan et al., 2003). La dépendance peut donc être directe, par exemple entre
deux processus dont l'un déclenche l'autre, entre deux données avec une contrainte
d'intégrité de base de donnée. Elle peut être indirecte, par exemple entre deux
processus qui utilisent une même ressource, sont pilotés par le même acteur, ou
influencent le même indicateur de performance. Une telle approche est prise en
compte dans une méthodologie d'analyse et ré-ingénierie des processus reposant sur
la mesure de « couplage » entre deux activités à partir de la proximité des
informations en entrée ou en sortie de ces activités ((Castano et al., 1999). Ces
dépendances représentent à la fois la structure d'une organisation, ce qui la rend
pérenne et lui permet d'accumuler des compétences, et en même temps les
contraintes qui freinent son adaptation. Cela conduit à ne pas se limiter à une
évaluation quantitative d'un niveau de couplage global, mais à caractériser et étudier
des dépendances cruciales notamment en termes de conduite du changement, donc
au niveau des processus d'entreprises (Chapron 2006). Cet auteur propose une
classification des dépendances de processus en types de dépendances élémentaires
qui peuvent être ensuite agrégées :
dépendance d'acteurs (partage d'acteurs, dépendance structurelle liées à la
dépendance hiérarchique des acteurs, dépendance de rôle commun),
dépendances par les ressources (partage d'applications, dépendance d'un flux de
donnée) ,
dépendances informationnelles (partage d'objet métier, dépendance
évènementielle) .
La dépendance peut aussi être enrichie de l'importance des objets et de la
dépendance elle-même. On peut caractériser cette dernière représentée dans un
modèle de processus en l'annotant d'informations de fréquence, d'importance et de
délai pour obtenir ainsi une matrice d'évaluation de la dépendance entre tâches qui
peut ensuite être traduite au niveau organisationnel (Giachetti 2006).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 124
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

On trouve encore une approche similaire dans la classification des modes

de partage de connaissance dans un processus de conception. La dépendance que
représente ce partage peut se réaliser à différents niveaux, le processus
informatique, le système ou l'équipe sous forme d'une matrice des dépendances
processus/équipe, système/processus... (Prasad 1999). On peut alors rechercher
comment « simplifier » la matrice résultante afin d'obtenir une dépendance plus
faible représentant une organisation « faiblement couplée ».
Il est important de ne pas limiter le concept de dépendance à
l'interopérabilité informationnelle. On constate en effet l'absence de corrélation
évidente entre interdépendance et standardisation des échanges ce qui semble
indiquer que le couplage peut être géré autrement qu'au niveau de l'échange
informationnel (Wybo et Goodhue 1995) .

4 Intégration et partitionnement

C ette problématique de couplage entre différents types d'élément d'un système a

conduit à la notion de « clusters », regroupements pertinents d'objets
fortement dépendants. C'est notamment le cas dans la conception de logiciel pour
aider à la recherche de la « bonne » modularité des applications dans la relation
entre architecture applicative et organisation (Winter et Robert 2003), dans la suite
de la méthode IBM « Business System Planning Method » (BSP) de clusterisation
entre données et processus et de la méthode « Systems and Technology Planning
(STP) » de clusterisation entre entités organisationnelles et applications (Figure
2.20). Cette analyse doit prendre en compte des facteurs contradictoires :
complexité, couplage, coût d'infrastructure, coût de réalisation et coût de
maintenance qui sont liés de manière contradictoire. Un couplage fort sur
l'ensemble des fonctionnalités d'un système conduit à augmenter fortement la
complexité donc le coût de réalisation, mais réduit le coût de l'architecture support
(Schwinn et Winter 2005).
L'identification des clusters dans ces modèles repose sur 2 dimensions que
Winter propose de généraliser en un modèle à 3 dimensions : fonctionnalités,
informations et organisations/activités. De plus, la reconnaissance de cluster repose
sur le tri des données par axe de la matrice, dans un ordre lié au flux dans le cas
BSP et sur l'affectation de fonctions aux entités dans la méthode STP. Les
problèmes posés par les très larges applications existantes conduisent à chercher des
solutions s'appuyant plus fortement sur la connaissance des diverses dépendances
entre entités, qui ne peuvent se limiter à une matrice à deux dimensions. Il faut
souvent considérer le graphe complet des dépendances dont les caractéristiques ne

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 125
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

peuvent être prédéterminées indépendamment des organisations et des applications

et dont la structuration en dimensions doit pouvoir être considérée comme
partiellement « émergente ».

Architecture IBM BSP (1984) Architecture STP (St-Gallen) (2000)

Figure 2.20: Clusterisation comparée d'architectures (Winter, 2003)

Le problème peut être défini comme l'étude des dépendances concrétisant

l'intégration organisationnelle et informationnelle afin de définir des « sous-
domaines » cohérents qui soient à la fois pertinents par leur intégration interne
justifiant un projet et faiblement dépendants de domaines externes afin de limiter
les perturbations. Ce problème rencontré dans des domaines variés est désigné sous
l'expression de « clustering ». Il fait l'objet d'études en physique (Newman 2004),
en sciences humaines (Ferre et Jouve 2002), conduit à des approches génériques
multi-domaines (Palla et al. 2005) et à de nombreuses recherches d'algorithme
performant (Wang et al., 2007; Yang et al., 2006). Il peut être vu comme un
problème d'optimisation ce qui souligne la nécessité d'identifier les objectifs et les
contraintes du partitionnement (Vinod 1969).
Une première approche propose un algorithme reposant sur une analogie
mécanique de forces liant les nœuds du graphe et les repoussant. Chaque arc
représente une force reliant ses sommets et une force générale repousse les sommets
entre eux, à l'image d'une gravité inverse. On peut ainsi calculer un équilibre
dynamique qui place les sommets de manière à équilibrer les forces opposées,
calculant ainsi une distance entre sommets (Eades 1984), (Di Battista et al., 1994).
Un résultat visible est de faire apparaître des « partitions » du graphe en zones
relativement denses faiblement reliées. Sans être un algorithme de partitionnement

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 126
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

pouvant optimiser des critères, il est une solution simple et permettant de faire
apparaître des structures pour des graphes quelconques. Il peut être utilisé sur un
graphe déjà partitionné, afin de représenter le « super-graphe » reliant les clusters
existants de manière pertinente, puis de naviguer dans ces clusters (Eades et al.,
2000).
Une taxinomie des approches de solution du problème de clustering lui
même est proposée par Jain présentée dans la Figure 2.21.
Clustering
Hierarchical Partitionnal

Single Complete Square Graph Mixture Mode

link link error Theoretic Resolving seeking

Expectation
k-means Maximization

Figure 2.21: Une taxinomie des approches de clustering (Jain, 1999)

La première étape est toujours d'identifier et de caractériser les éléments à

regrouper, puis de définir une similarité entre ces éléments. Cette similarité n'est pas
une notion triviale dans la mesure ou les caractéristiques sont le plus souvent
hétérogènes. Les méthodes de résolution dite « hiérarchiques » produisent une
hiérarchie de cluster avec un niveau de similarité à chaque niveau de hiérarchie, le
premier niveau regroupant l'ensemble des objets.(Jain et al., 1999). On peut ainsi
« choisir » le niveau de regroupement pertinent en fonction du niveau de similarité
constaté à ce niveau. Les méthodes hiérarchiques sont rapidement très couteuses en
temps pour des volumes de données importants.
Les méthodes de résolution par partitionnement produisent un ensemble de
clusters dont le nombre recherché est un des paramètres essentiels. Ils cherchent à
optimiser une fonction locale à un sous-ensemble d'objets ou globale sur l'ensemble
des objets. La méthode la plus répandue repose sur le critère des moindres carrés et
identifie correctement les clusters « fortement corrélés ». L'algorithme le plus
répandu est appelé « k-means » ou k est le nombre de cluster recherché. Jain (1999)
identifie quatre méthodes :
ascendante avec une règle de regroupement ou descendante avec un critère de
séparation et dans les deux cas un critère d'arrêt,
déterministe ou stochastique notamment pour de grand volume de données,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 127
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

incrémentale pour permettre l'ajout progressif de donnée dans le graphe ou non

(traitement global du graphe),
net pour une appartenance univoque à un cluster ou flou qui associera à un objet
un « degré d'appartenance » à un cluster.
Il souligne l'importance de « l'effet de chaîne » qui complique la séparation
de deux groupes fortement corrélés liés entre eux par une suite de dépendances
faibles. C'est un critère important de choix des algorithmes. Cependant, dans tous
les cas, l'approche k-means est de très loin la plus rapide et fournira une bonne
solution. La prise en compte de contraintes spécifiques au domaine venant
compléter la méthode choisie est souvent un élément essentiel de l'efficacité d'une
méthode.
Cette démarche est utilisée fréquemment pour comprendre la complexité
des systèmes d'information et des entreprises. On trouve ainsi un complément multi-
agent à un système ERP pour la construction de clusters de ressources (fournisseurs,
stock, client...) (Symeonidis et al., 2003) Il repose sur approche d'extraction de
connaissances en utilisant le langage PPML du datamining group (DMG 2007).
Cette démarche est aussi utilisée pour identifier des groupes homogènes d'acteurs
d'une chaîne logistique (Srinivasan et Moon 1999). Elle est utilisée fortement dans
une approche complète d'urbanisation du système d'information pour la gestion de
l'évolution de l'entreprise, approche centrée sur les processus comme construit
essentiel de l'ingénierie d'entreprise. L'objectif est de délimiter des zones de
processus cohérentes vis-à-vis de la gestion de l'évolution (Chapron 2006). Cette
démarche repose sur la constitution d'un graphe de dépendances entre processus
prenant en compte les dépendances d'acteurs, d'information et de ressources. Une
caractérisation précise d'une dépendance par une mesure opérationnelle semble
difficile car elle nécessiterait une analyse par entretien. Le graphe est donc quantifié
par le nombre de dépendances entre deux processus qui sont considérées comme
symétriques (le graphe n'est donc pas orienté). La formulation d'un problème non
flou, déterministe et non incrémental conduit l'auteur à une méthode de
classification hiérarchique. Les différents types de dépendance sont traités
séparément pour produire ainsi trois « cartes de cluster » (Figure 2.22). L'étude de
ces cartes est la base d'une démarche de diagnostic portant sur la qualité des cartes
obtenues, la mesure de l'effort à fournir pour transformer une situation identifiée
vers un état cible, enfin sur la cohérence des différents points de vue que
représentent les cartes, notament en rapprochant l'urbanisation applicative de la
clusterisation des processus pour mesurer l'alignement du S.I. aux processus.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 128
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

Figure 2.22: Cartes de Cluster (Chapron, 2006)

Ce diagnostic permet d'engager ensuite une étude des processus eux-

mêmes, de leur maturité et de leur contribution stratégique. Dans les deux cas, il
s'agit d'éclairer les démarches existantes de mesure de maturité ou de contribution
stratégique d'un processus en considérant leur cohérence dans un cluster, et en
l'agrégeant pour en éclairer plus fortement la pertinence dans les projets d'évolution
d'entreprise.

2.4.2 Intégration et standardisation

1 Intégration et ERP

L ’intégration est le plus souvent présentée comme un facteur de performance et

donc comme un enjeu important des projets de S.I. L'intégration peut être un
vecteur de maîtrise des enjeux de pouvoir amont et aval pour une entreprise
cherchant dans un projet S.I. à réduire sa vulnérabilité provenant de la dépendance
et des coûts de transaction. (Humphreys et al., 2001).
Elle peut être au contraire un risque dans des organisations dont
l'intégration est toujours une construction historique et contingente. Un projet ERP
dans une entreprise « non intégrée », et dont certaines entités peuvent être au
contraire marginalisée dans les relations sociales internes conduit à reproduire cette
« dés-intégration » dans le S.I. (Elbanna 2007). De même, l’intégration « imposée »
par un ERP peut être une contrainte face aux besoins de flexibilité. Une

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 129
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

classification de l’intégration sur deux axes permet d’identifier quatre types

d’organisation et leur infrastructure de système d’information (Evgeniou 2002). Un
axe vertical mesure la « visibilité » permise par des vues multiples (global/local, par
produit, par canal…). Un axe horizontal mesurant la “flexibilité” face au besoin de
changement. Le quadrant “visibilité faible/flexibilité forte” intitulé “entreprise
décentralisée” s’appuie sur une infrastructure non intégrée de système
d’information, alors que le quadrant visibilité forte/flexibilité faible s’appuie sur
l’intégration autour d’un ERP. On peut même considérer qu'une certaine
« ambiguïté structurelle » dans la définition des rôles permet un couplage plus
faible des différentes parties d'une organisation lui conférant une certaine souplesse
(Ravasi et Verona 2001). En tout état de cause, la perception de l'intégration dans
l'entreprise n'est pas figée et peut se transformer dans le temps :
« SAP was first allied with top management, playing the role as a
powerful change agent. Later on, SAP was allied with local managers
and users, helping them bringing the change process under their
influence and to the speed they preferred. Currently, SAP is changing its
role as it is installed and integrated into a larger corporate
infrastructure. As such, it becomes everybody’s enemy by resisting all
organizational change » (Hanseth et Braa 1998).
De fait, le modèle d'organisation est « codé » dans les applications qui
définissent les entités organisationnelles, les classifications de comptabilité, de
statistiques... les regroupements qui conditionnent les processus de décision.
L'alignement entre ce modèle d'organisation de l'application et l'organisation réelle
peut être très difficile. (Kovacs et Paganelli 2003). La cohérence entre les modes
d'intégration organisationnels et informationnels est donc un facteur de succès de la
conduite du changement nécessaire. C'est ce que perçoive les dirigeants d'entreprise
qui identifient comme condition de réussite des projets ERP l'adéquation entre les
éléments de stratégie d'entreprise et les mécanismes d’intégration portés par l’ERP :
« An organization is more likely to perceive system value, beyond their
expectations, when there is a fit between its strategy and integrating
mechanism. ERP systems standardize processes, integrate information and
centralize control; organizations that find this consistent with their own
strategies, characteristics and integrating mechanism are more likely to realize
higher system value from their ERP. » (Somers et Nelson 2003).

L 'ERP est un exemple significatif de système « fortement couplé » qui répond

bien aux besoins d'organisation fortement intégrée et formalisée, mais dont la
flexibilité intrinsèque est limitée. Mais l'intégration totale ne peut être atteinte et on
ne peut parler que d'un effort d'intégration qu'il faut savoir caractériser et mesurer

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 130
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

(Dechow et Mouritsen 2005). Cet effort ne peut reposer que sur les connaissances et
capacités d'apprentissage ou de changement de l'organisation. Pour exprimer
l'efficacité d'un système fortement intégré en conservant la flexibilité et réactivité
de l'organisation, il faut que les compétences, relations et ressources soient
mobilisées pour assurer la cohérence de l'alignement recherché.(Lengnick-Hall et
al., 2004). La difficulté est de prendre en compte les dépendances et les
différenciations entre les entités de l'organisation. Les dépendances bénéficient de
l'intégration de l'ERP et les différenciations sont sources de risques et de coûts.
(Gattiker et Goodhue 2004).
Cependant, l’ERP masque la complexité de son intégration interne dans le
packaging produit et sa standardisation. C’est justement ce qui est « enfermé » dans
l’ERP qui est pertinent pour comprendre comment assurer la cohérence entre
l’intégration organisationnelle et informationnelle. De plus, l'ERP est un système de
très grande taille comportant des dizaines de milliers d'objets (25000 transactions
pour le plus étendu leader du marché SAP, mais déjà 132 modules constitués de
2413 tables et 4901 scripts dans 7527 sessions dans la solution BAAN5 considéré
comme représentatif du deuxième segment de marché. Or si l’ERP peut proposer
des « connecteurs » assurant l’ouverture aux différentes approches de l’intégration
informatique, s’il doit proposer des modèles externes des objets à échanger, il ne
peut ouvrir sa logique d’intégration interne sans mettre en cause l’actif immatériel
qu’il représente et donc les droits de l’éditeur.

2 Intégration et modélisation d’entreprise

L e rapport entre intégration et modélisation d’entreprise est clairement identifié

dans les études sur les architectures d’entreprises comme le montre les
définitions CIMOSA qui caractérise l'intégration par la mise à disposition de la
bonne information au bon endroit et la modélisation par la capacité à bien identifier
l'information et sa localisation (Kosanke et al., 1999). L’intégration entre les
processus, l’organisation et l’information est donc essentielle et suppose des outils
adaptés, principe au cœur de l'outil ARIS (Scheer 2002). Mais l’intégration
représente aussi une difficulté dans les efforts de modélisation d’entreprise compte
tenu de l'importance des processus transverses des organisations. La définition
hiérarchique d’un domaine de modélisation dans une démarche descendante risque
donc de ne pouvoir tenir compte des dépendances que l’infrastructure crée entre les
domaines.
Ainsi, l’exemple illustrant les premières publications d’utilisation de
CIMOSA (Geerbox production) montre bien la nécessité dans toute démarche de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 131
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

modélisation de définir un périmètre, donc ce qui est externe au périmètre et les

interactions entre le domaine étudié et les autres domaines (Zelm et al., 1995). Les
interactions sont identifiées et affectés au niveau inférieur de la modélisation (les
Domain Process). Mais si les domaines modélisés et non modélisés partagent une
infrastructure basée sur un progiciel standard comme un ERP, il n’est plus possible
de définir ainsi les domaines non modélisés comme « externe » au modèle.
Le domaine modélisé peut correspondre au domaine couvert par l'ERP,
mais sa décomposition hiérarchique doit dès les premières étapes prendre en compte
les conséquences de l’intégration qui feront des interactions entre domaines toujours
plus nombreuses et complexes. Cela rend difficile l’assemblage de modèle par
composition de parties pouvant provenir de concepteurs différents. Si la définition
des processus doit prendre en compte des détails de mise en œuvre de l’intégration
dans les applications informatiques, leur assemblage nécessitera une étude de
cohérence de l’intégration entre les composants applicatifs impliqués.
La modélisation d'entreprise propose une architecture et des concepts qui
sont un support de la standardisation (Kosanke et Nell 1999). Mais cet objectif de
standardisation pour permettre une « architecture d’entreprise par composant » rend
nécessaire d'expliciter dans la modélisation les dépendances de tous niveaux et entre
tout type d'objet. La connaissance de ces dépendances pour des systèmes standard
de grande taille comme les ERP est donc un enjeu important.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 132
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

Le concept d’intégration est largement utilisé en informatique

comme en productique depuis les années 1980 avec le CIM
(Computer Integrated Manufacturing) présenté comme un réseau
unifié de systèmes informatiques assurant et/ou contrôlant la
totalité des fonctions intégrées de l’entreprise. Cette approche était
centrée sur l’outil de production et son automatisation. Mais
l’intégration dans l’entreprise immergée dans une chaîne
logistique, en constante transformation pour répondre aux objectifs
de performance qui lui sont fixés ne peut se réduire à une forme
d’automatisation. Au contraire, les processus de prise de décision,
d’apprentissage et de résolution de conflit font de l’intégration un
enjeu organisationnel. Cette dimension explique le caractère
pluridisciplinaire des réponses possibles, devant prendre en compte
des ressources hétérogènes.

L’intégration est ainsi une réponse organisationnelle au besoin de

coordination dans un contexte de transformation continue de
l'entreprise et de son environnement. Elle se réalise dans des
situations de « couplage faible » où dominent les interactions entre
organisations; on parle alors d'interopérabilité. Elle peut conduire à
un « couplage fort » dans lequel les objectifs, les processus, les
stratégies des acteurs doivent être en cohérence.

L'accélération des cycles de conception, de production, de

distribution et la multiplication des acteurs et des marchés tend à
rendre de plus en plus complexe et dynamique ce « couplage »
entre une multiplicité de points de vue et d'intervenants.

Dans tous les cas, l'intégration est organisationnelle et

informationnelle et se traduit par un ensemble de dépendances
entre les différentes entités, ressources, informations, systèmes,
acteurs. Elle porte ainsi la complexité d'une organisation dans son
contexte, ses relations à ses parties-prenantes, et doit être évaluée
et caractérisée pour accompagner l'alignement des différents
systèmes d'une organisation. Des techniques de partitionnement
ou de clusterisation peuvent aider à identifier des structures
faiblement couplées à partir d'un système existant.

Nous retenons de cet état de l'art l'enjeu de l'intégration dans une

approche pluridisciplinaire au cœur de l'alignement entre les points
de vue des gestionnaires, des praticiens des différents métiers de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 133
 Etat de l’art industriel et académique / Intégration organisationnelle et informationnelle

l'entreprise, des informaticiens, des ingénieurs de l'organisation...

Cette intégration n'est jamais totale ni aboutie. La flexibilité ou la
réactivité conduisent toujours des acteurs à innover et transformer
l'organisation. Elle doit donc être une démarche supportée par le
cadre méthodologique de l'ingénierie d'entreprise, et notamment
par la modélisation d'entreprise.

Nous proposons dans la troisième partie une démarche d'ingénierie

orientée par et pour l'intégration, démarche reposant sur une
représentation de l'intégration comme ensemble de dépendances
pouvant être utilisée à différentes échelles d'étude, depuis les
dépendances techniques et humaines d'une équipe de travail, de
ses compétences, ses ressources et ses tiers, jusqu'à un secteur
économique où interagissent des chaînes logistiques, des centres
de financement, des centres de compétences et de formation, des
supports réglementaires.

Cette démarche d'ingénierie sera le cadre où assurer la maitrise

des systèmes d'information, des projets associés jusqu'à la
maturité de leur « bon usage » au service de la performance de
l'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 2 / Chapitre 2.4
Institut National des Sciences Appliquées de Lyon 134
Partie 3

Démarche d'ingénierie

orientée intégration
 Démarche d'ingénierie orientée intégration / Démarche d'ingénierie orientée intégration

Chapitre 3.1
Cadre et méta-modèle de l'intégration...........................139
3.1.1 Cadre de modélisation de l'intégration...............................................140
3.1.2 Méta-modèle de l'intégration............................................................145
1 Modèle de construit 19440......................................................................145
2 Comparaison du modèle 19440 et du modèle SCOR..................................151
3 Comparaison du modèle 19440 et d'un modèle ERP..................................154
4 Méta-modèle de l'intégration...................................................................157
3.1.3 Référentiels métiers pour les modèles d'entreprise.............................159
1 Informations échangées dans le modèle SCOR.........................................160
2 Briques applicatives................................................................................166
3 Processus et briques applicatives.............................................................172

Chapitre 3.2
Graphe d'intégration du modèle d'entreprise...................181
3.2.1 Graphe des dépendances..................................................................182
3.2.2 Sous-graphes d'intégration...............................................................189
3.2.3 Définition de mesures de l'intégration................................................197
3.2.4 Partitionnement d'un graphe d'intégration.........................................201
3.2.5 Couplage et voisinage d'intégration...................................................203
3.2.6 Complexité des algorithmes..............................................................207
3.2.7 Dépendances et maturité des usages des S.I.....................................208

Chapitre 3.3
Ingénierie d'entreprise orientée intégration ...................213
3.3.1 Démarche d'alignement....................................................................215
3.3.2 Démarche d'ingénierie .....................................................................217
3.3.3 Démarche d'alignement et graphe d'intégration.................................223

Chapitre 3.4
Illustration sur des cas académiques et réels..................233
3.4.1 Illustration sur un cas académique....................................................234
3.4.2 Illustration sur le cas BAAN..............................................................245
1 Etude de l'intégration de l' ERP BAAN.......................................................245

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Partie 3
Institut National des Sciences Appliquées de Lyon 136
 Démarche d'ingénierie orientée intégration / Démarche d'ingénierie orientée intégration

2 Etude des distances sur un graphe BAAN partiel.......................................248

3.4.3 Illustration sur le cas SCOR..............................................................252

L'état de l'art de la partie 2 nous permet de reformuler la

problématique « ERP » de manière synthétique à partir d'une relecture
du sigle lui même comme une rencontre entre les différents points de
vue de l'ingénierie d'entreprise et du système d'information :

● Enterprise Resource : le point de vue managérial qui se

préoccupe de performance économique, c'est à dire de la
meilleure utilisation des ressources disponibles pour le résultat
financier de l'entreprise, cherchant à concilier intégration et
flexibilité. Il porte la nécessité de la standardisation là où le coût
est jugé essentiel, de la différenciation dans les processus
critiques de la création de valeur. Il cherche comment
contribuer à la stratégie d'entreprise à coût minimum, faisant
pression vers l'industrialisation des services et l'externalisation.

● Ressource Planning : le point de vue de l'ingénierie qui

cherche l'utilisation optimale des ressources industrielles et
logistiques, leur positionnement efficace dans la chaîne de la
demande, modélise les processus d'approvisionnement,
production et distribution pour les simuler, les optimiser, et
même quand c'est possible les piloter directement.

● Enterprise Ressource Planning : La réponse des

informaticiens à cette recherche d'intégration et de pilotage,
s'appuyant sur l'industrialisation du logiciel et des services,
condition de la réduction des coûts de conception et de
possession, sur des architectures facilitant la flexibilité de mise
en œuvre et de pilotage, cherchant à supporter les efforts de
modélisation pour la conduite du changement nécessaire au
management, pour le pilotage des processus métiers.

Cette relecture du sigle ERP identifie ainsi notre problématique comme

la rencontre de différents points de vue sur la contribution des
systèmes d'information à la performance des organisations : celui des
exigences managériales de l'intégration flexible, celui de l'ingénierie
d'entreprise dirigée par les modèles, celui de la maîtrise de la maturité

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Partie 3
Institut National des Sciences Appliquées de Lyon 137
 Démarche d'ingénierie orientée intégration / Démarche d'ingénierie orientée intégration

des systèmes d'information. Cette relecture s'appuie ainsi sur les trois
domaines étudiés dans l'état de l'art : modélisation d'entreprise,
intégration organisationnelle et informationnelle, usages de systèmes
d'information. Elle illustre fortement le caractère pluridisciplinaire des
enjeux de l'alignement du S.I. aux besoins économiques du pilotage
des affaires, et plus généralement des activités d'une organisation.

Pour y répondre, nous proposons un cadre d'étude pour une

ingénierie d'entreprise tenant compte des contraintes d'intégration
dont sont porteurs les modèles des différents points de vue. Ce cadre
d'étude de l'intégration repose sur

● un cadre de modélisation d'entreprise et un méta-modèle

largement issus des normes récentes que nous allons
interpréter et compléter pour prendre en compte des
référentiels métiers issus de notre expérience ERP,

● des graphes de dépendances permettant l'analyse des

problématiques d'alignement des processus, de l'organisation,
des systèmes d'information, de l'infrastructure, vues comme la
maîtrise des dépendances entre les acteurs, composants et
objets de l'entreprise,

● une caractérisation dans le méta-modèle et les graphes de

dépendances de la maturité des usages pour prendre en compte
l'acteur humain dans l'ingénierie afin d'accompagner les projets
et les actions contribuant à la contribution des systèmes
d'information à la performance de l'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Partie 3
Institut National des Sciences Appliquées de Lyon 138
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Chapitre 3.1
Cadre et méta-modèle de
l'intégration

Les différents points de vue de la modélisation d'entreprise, du

système d'information, de l'intégration organisationnelle s'appuient sur
des modèles normalisés ou en cours de normalisation. Ils sont
nécessaires à la maîtrise de la contribution des S.I. à la performance
d'une organisation, c'est à dire à la maîtrise des nécessités de
standardisation et d'intégration dans un contexte de flexibilité et de
concurrence. Nous allons donc croiser ces trois points de vue pour
définir un modèle de l'intégration et proposer un cadre de pilotage de
cette intégration dans les démarches d'ingénierie d'entreprise au
service de projets d'entreprise dont les dimensions organisationnelles
et informationnelles sont toujours plus étroitement liées.

Dans la première section, nous proposons un cadre de modélisation

issu des normes ISO 19439 et 19440 de modélisation d'entreprise que
nous confrontons dans la deuxième section à des référentiels métiers
pour proposer un méta-modèle d'intégration étendu. Nous proposons
dans la troisième section une étude détaillée de construits
représentatifs à partir de référentiels métiers qui en donnent une
définition extensive et illustrent l'enjeu de la standardisation des
connaissances métiers mobilisables dans la modélisation d'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 139
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

3.1.1 Cadre de modélisation de l'intégration

L e projet UEML (Chapitre 2.2) avait identifié deux cadres de référence

principaux, l'un issu de la modélisation d'entreprise, la méthode GERAM qui
influencera fortement la norme récente ISO 19439 présentée dans le chapitre 2.2 de
l'état de l'art, l'autre issu de l'ingénierie des S.I. présentée dans le chapitre 2.3
(Zachman, 1997). Une comparaison de ces deux cadres de référence est proposé par
Martin et Robertson (2002) soulignant certaines correspondances en termes de
structure mais une différence principale. L'approche Zachman utilise la notion de
rôle qui représente un point de vue présent en permanence dans tout le cycle de vie
du système, alors que le cadre ISO19439 s'appuie sur deux axes de généricité et de
modélisation qui sont intimement liés aux étapes de ce cycle de vie. Elle n'est pas
réellement un cadre de modélisation mais plutôt un support d'interrogation de
l'existant identifiant les acteurs et les questions pertinentes. Elle peut être utilisée
dans toutes les étapes de l'axe de modélisation, par exemple pour structurer la vue
des fonctions à l'étape des concepts de la norme 19439. Mais elle n'identifie pas
l'enjeu de la standardisation et donc n'éclaire pas les conditions d'usage de concepts
génériques dans les interrogations proposées aux différents acteurs. Elle ne facilite
pas la prise en compte d'une approche d'alignement cherchant à comparer le modèle
implicite d'un COTS avec le besoin exprimé, du type de celle proposée par Soffer
(Soffer, Golany, et Dori 2003).
D'autre part, le cadre Zachman doit être complété d'un cycle de vie, ce que
propose la méthode USDP (chapitre 2.3) qui identifie des « métiers » proches des
rôles de Zachman en les situant dans une démarche de projet structurée en phases.
Ces phases peuvent se recouvrir partiellement mais sont fondamentalement
séquentielles, à partir de l'expression des besoins pour spécifier puis réaliser un
système dont il faut enfin vérifier la conformité aux exigences. On peut alors
proposer la correspondance suivante :
Cadre de cycle de vie du S.I. points de vue Généricité
référence
ISO 19439 Axe des phases de Axe des points de vue Axe de généricité
modélisation
Zachman + Phases USDP Rôles Zachman = Non formalisé
USDP métiers USDP

Tableau 3.1.: Comparaison des cadres ISO 19439 et Zachman+USDP

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 140
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Dans les deux cas, le caractère itératif de la démarche et la pratique de

prototypage comme outil de comparaison de modèles parfois implicites n'est que
difficilement représentable. Le cadre 19439 paraît plus proche de la problématique
des solutions standard car il éclaire fortement la dimension de généricité. Celle-ci
n'est pas différencié dans l'approche USDP des phases de projet. Comme dans les
approches traditionnelles (MERISE, SA...), bien qu'en introduisant une plus grande
souplesse par le recouvrement possible des phases, USDP progresse de l'analyse de
l'existant au conceptuel, puis à sa traduction logique et enfin physique. Si l'axe des
phases de modélisation 19439 semblent très proche des phases USDP, il est par
contre orthogonal à l'axe de généricité. Ainsi, le prototypage d'une solution standard
pour éclairer les concepts en phase amont d'un projet peut être considéré comme
une activité support de l'étape de formalisation des concepts au stade générique. Ce
prototypage après validation d'un périmètre de projet et de l'architecture cible peut
être une activité de l'étape de définition des besoins par écart avec la solution, tout
comme il devient une activité de réalisation en permettant le paramétrage du
système particulier mis en œuvre. C'est pourquoi le cadre 19439 nous semble plus
adapté à la prise en compte de solutions standard de type COTS. C'est le sens de la
proposition de Darras (2004) positionnant le modèle de référence, le modèle cible,
le progiciel standard et la solution mise en œuvre dans les deux axes de généricité
de d'instanciation de GERAM.
De plus, les problématiques d'intégration se révèlent toujours dans des
projets d'entreprise. Mais cela concerne autant des projets d'ingénierie que des
projets de « ré-ingénierie », des projets à dominante managériale que technologique,
de grands projets d'investissements sur de nouvelles ressources ou au contraire
d'accompagnement pour une meilleure efficience de ressources existantes. Nous
parlerons de « projets » au sens le plus général d'actions de transformations
partielles d'une organisation, actions qui mettent toujours en relation des points de
vues divers pour atteindre des objectifs. C'est d'ailleurs pourquoi l'importance des
pratiques des acteurs et de l'impact d'un projet sur ces pratiques rend nécessaire la
prise en compte les compétences et les connaissances des acteurs dans l'ingénierie
de projet. Cela devrait conduire à identifier les acteurs du projet dans le cadre de
référence pour prendre en compte les différences de point de vues sur le même objet
comme source de clarification des besoins, de solidité des validations et aussi
d'identification des tâches de la conduite de changement. Le cadre de référence
19439 nous semble porter insuffisamment cette problématique. Nous proposerons
dans le chapitre 3.2 de les prendre en compte en caractérisant leur niveau de
maturité dans les construits de modélisation.
Ces remarques nous conduisent à une interprétation du cadre 19439 sur
trois aspects essentiels à notre démarche :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 141
Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

L'axe des phases de modélisation n'est pas un axe de réalisation qui viendrait
ainsi séquentiellement « traduire » l'expression d'un besoin en spécification, puis
en solution. Nous nous plaçons résolument dans un contexte de « ré-ingénierie »
dans lequel le système existant est modélisé à différents niveaux, concepts,
spécification, réalisation, usage que tout projet d'entreprise doit réutiliser en les
transformant pour atteindre des objectifs. Etendant le principe du chevauchement
des phases USDP, nous considérons un cycle itératif dans lequel par exemple la
connaissance de spécifications de solutions standard ou l'analyse des conditions
de mise en œuvre de ces solutions peut influer sur l'expression du besoin, ou les
conditions de transition peuvent influer sur la définition d'un périmètre de projet.
Si l'axe des phases reste le cycle naturel de validation du projet, nous ne le
considérons pas comme un axe ordonné d'activités séquentielles. Nous l'utilisons
comme une liste de types de modèles qui sont interdépendants mais qui peuvent
être étudiés dans différents ordres selon la nature du projet : ingénierie dans un
contexte de création d'activité, ré-ingénierie d'amélioration pour la recherche
d'une meilleure performance par l'analyse critique des dysfonctionnements, ré-
ingénierie radicale de type BPR, mise en œuvre rapide de solutions standard,
séparation ou fusions d'activités...
Les axes de modélisation et de généricité ne sont pas à considérer comme (devant
être) synchronisés dans la durée d'un projet. Ainsi, dans la phase de formalisation
des concepts, le prototypage d'une solution existante (ERP « acheté » en
démonstration) ou même d'analyse d'un système en fonctionnement chez un
partenaire (ERP « comparé ») peut aider à clarifier les concepts génériques
utilisés. La même activité peut jouer un rôle important dans l'expression des
besoins identifiés par écart avec un fonctionnement de solution progicielle (ERP
« configuré »). Elle pourra encore être utilisée pour la réalisation d'un système
particulier pour permettre le paramétrage de la solution standard.
Les différents types de modèles qui peuvent être utilisés, autant en termes de
langages que de construits de base ou de modèles de référence ne sont pas
destinés à être unifiés dans un méta-modèle global traitant toutes les phases et
tous les points de vue de l'ingénierie d'entreprise. La définition des construits
19440 introduit justement des descriptions générales et d'autres spécialisées pour
chaque phase de modélisation. C'est indispensable car les objectifs des différents
acteurs de l'ingénierie peuvent être radicalement différents. Le modèle métier
cherche à identifier les enjeux de la différenciation qui portera la performance de
l'entreprise tout en réutilisant les bonnes pratiques qui lui garantissent son
efficience. Il s'appuiera donc sur des pratiques standard adaptées à sa typologie,
c'est à dire déjà « particulière », et concevra des processus différenciateurs
« spécialisés » à ce qu'il perçoit comme la source de sa performance. Le modèle
de logiciel standard cherchera au contraire la « généricité » qui lui garantira

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 142
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

l'ouverture au plus grand marché possible. L'enjeu est bien de faciliter la mise en
correspondance de modèles qui peuvent être hétérogènes, notamment des
modèles à dominante métiers utilisés dans les phases amont (périmètre, concept,
besoins) et des modèles à dominante technique dans les phases aval
(spécification, réalisation, mise en œuvre).
Ces remarques nous permettent alors de placer dans le cadre 19439 les
« statuts » de l'ERP définis précédemment (Figure 3.1), ainsi que des exemples de
référentiels portant une connaissance métier.. L'ingénierie de projet d'entreprise
dans ce cadre 19439 s'organise ainsi dans un travail de mise en correspondance de
différents modèles, dans un « va et vient » entre modèles génériques porteurs de
bonnes pratiques et modèles particuliers déjà traduits en solutions standard ou
même en solution déjà mises en œuvre, modèles métiers et modèles logiciels,
modèle du système existant et modèle cible. Dans ce rapprochement, l'ingénierie
d'entreprise a besoin d'un couplage faible entre ces modèles, pour permettre
l'intervention des acteurs dans la nécessaire réactivité et l'incertitude qui
caractérisent l'entreprise. C'est ce que préconise de nombreuses études de

CMMI

ERP Acheté

OAGIS

SCOR

ERP Acheté ERP Comparé

ERP Installé

ERP Configuré

ERP Adapté

ERP Utilisé

ERP migré

Figure 3.1: L'ERP dans les différentes phases du cadre 19439

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 143
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

management de l'innovation, parfois bien avant la croissance continue des

technologies de l'information comme dans le modèle dit à « double cœur »
administratif et technique de Daft (1978).
Dans un tel cadre de représentation des différents modèles utilisés, la
cohérence ne peut être traduite par un alignement détaillé entre modèles métier et
modèle S.I., ou entre modèle stratégique et modèle opérationnel, alignement qui
exigerait une correspondance complète au niveau le plus détaillé possible. Nous
considérons ce « couplage lâche » nécessaire entre les différents points de vue
comme un ensemble de dépendances entre les construits des modèles portant des
contraintes plus ou moins fortes sur la modélisation aux différentes étapes et points
de vue de l'ingénierie d'entreprise. Ces dépendances peuvent être exprimées à
différents niveaux de granularité. Les contraintes qu'elles portent ne seront le plus
souvent pas de nature à permettre une « transformation automatique de modèle »
allant jusqu'à la génération du logiciel ou de son paramétrage. Une représentation
sous forme de « graphe de dépendances » viendra compléter la démarche
d'ingénierie reposant sur la modélisation d'entreprise en enrichissant
l'environnement de modélisation, et le modèle lui même de différents « points de
vue » de l'intégration.
Notre cadre d'étude de l'intégration (Figure 3.2) repose ainsi sur un
ensemble de modèles dans les trois axes de la norme 19439 et un ensemble de
dépendances entre les construits de ces modèles, dépendances internes à un modèle
et illustrant la cohérence du point de vue que ce modèle porte, et dépendances entre
modèles illustrant la cohérence ou « l'alignement » entre les différents points de vue

A3
P1
Métiers Pratiques
P2
P3
Indicateurs
Applications

Données
Processus

Transactions

Figure 3.2: Un cadre d'étude de l'intégration

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 144
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

ou étapes d'un projet de transformation d'une organisation. L'ensemble des

dépendances représente un « graphe d'étude de l'intégration », qui permet
notamment de caractériser le plus ou moins fort couplage entre les composants du
système, de structurer la navigation dans l'ensemble des modèles utilisés et leur
utilisation cohérente dans les différentes phases d'un projet d'entreprise.
Dans le paragraphe suivant, nous présentons le méta-modèle de construits
à partir de la norme 19440 comparée à des exemples de référentiels illustrant
certains des construits notamment pour leur rôle dans les dépendances d'alignement
entre processus métier et système d'information.

3.1.2 Méta-modèle de l'intégration

L e méta-modèle 19440 concentre de nombreux travaux et représente un « état de

l'art » en termes de construits de modélisation d'entreprise. C'est pourquoi nous
utilisons ce modèle en cours de normalisation en l'interprétant de ce qui nous paraît
significatif dans notre problématique. Cependant, comme nous l'avons vu dans la
section 2.2.4 sur les modèles de références et les taxonomies, il est utile de
comparer ou compléter un tel méta-modèle à partir de référentiels existants afin d'en
consolider la pertinence pour permettre de construire un modèle par composition de
construits d'un référentiel standard. C'est pourquoi nous compléterons le méta-
modèle 19440 à partir de sa comparaison avec des référentiels métiers issus de notre
expérience de projets ERP.

1 Modèle de construit 19440

Le modèle des construits associés au cadre 19439 est en cours de normalisation
(ISO 19440). Nous utilisons la description disponible dans la version provisoire
(prEN ISO 19440:2004 (E)) et dans les livrables UEML2.1 du projet INTEROP. Les
construits sont identifiés par une structure commune composée d'un entête (header)
identifiant le construit et d'un corps (body) composé de descriptions formalisées en
XML ou EXPRESS et de relations entre construits. Leurs principales relations ont
été présentées dans la en page . Nous précisons ci-dessous notre interprétation de
chacun de ces construits pour notre problématique d'étude de l'intégration :
Domain (DM, vue fonctionnelle) : pour définir un périmètre de projet vu comme
un domaine de gestion ou d'activité d'une entreprise détaillé en processus et
interactions externes (event et object view).
Dans les projets de type ERP, l'identification d'un périmètre ne peut se faire
dans une démarche hiérarchique basée sur l'organisation existante, mais au

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 145
Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

contraire, dans l'identification des dépendances entre processus nécessaires aux

objectifs du projet. Ces dépendances peuvent être liées à l'organisation
existante, aux flux physiques ou au contraire liées à telle ou telle solution ERP
pré-sélectionnée dans le projet. Le domaine est donc pour nous le résultat des
premières analyses de processus et sera souvent transverse à l'organisation. Il
est donc plus un outil de « reporting » permettant une vue de synthèse des
processus et non pas un outil de structuration de l'analyse dans une démarche
descendante.
Business Process (BP, vue fonctionnelle) : une suite d'activités destinées à
produire un résultat. C'est le construit principal qui porte un double point de vue
des objectifs à travers la finalité du processus, ses indicateurs de performance, et
des moyens, à travers les activités qu'il enchaîne et les ressources qu'elles
utiliseront.
Il est essentiel pour nous à la cohérence entre les représentations métiers et
techniques du système cible, à la comparaison de modèles prédéfinis de
solutions au besoin formalisé de l'entreprise.
Il utilise une relation d'agrégation (business process décomposé en sous-
processus) qui permet une représentation hiérarchique du modèle.
Enterprise Activity (EA, vue fonctionnelle) : Une activité ou une étape d'un
processus transformant un objet d'entreprise, utilisant des ressources et
interagissant par des événements en entrée et sortie.
C'est ce construit qui pour notre problématique porte les dépendances
principales entre la vue des processus et le système d'information.
Event (Ev, vue fonctionnelle) : un changement dans l'état d'un objet d'entreprise,
ou du système en général.
Ce construit qui permet de modéliser une vue fonctionnelle dynamique
renforce la relation entre processus et système d'information, à travers les
données qui portent ou sont portées par les évènements, mettant donc en
relation la vue fonctionnelle avec la base de données qui représente l'état du
système à tout instant.
Resource (Re, vue ressource) : un objet d'entreprise (une machine, un système,
un acteur) qui intervient dans une activité. Il est plus ou moins autonome et
possède des aptitudes (capability).
Dans notre problématique, la différenciation des ressources informatiques est
nécessaire pour supporter plus clairement l'analyse de l'alignement des S.I. à
l'organisation et aux processus. ajoutons donc une spécialisation de l'objet
ressources pour caractériser une « Ressource-IT » au sens d'applications, ou de
services de type SOA. Nous reviendrons sur ce point dans la comparaison avec
un méta-modèle d'ERP dans la section 3.1.3 de la partie 3 pour caractériser les

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 146
Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

dépendances informatiques que ce construit permet d'identifier dans le méta-

modèle.
Functional Entity (FE, vue ressource) : un ensemble de ressource pouvant
assurer certaines fonctions. Ce construit permet une représentation hiérarchique
du modèle et repose sur une relation d'agrégation des ressources.
Ce construit utilisé dans les vues ressource et fonction, porte les rôles
opérationnels des acteurs et est sous le contrôle d'une unité organisationnelle.
La séparation des points de vue ingénierie (ressources) et management
(organisation) nécessite de gérer la cohérence entre ces points de vue. Ainsi,
les centres de charges dans un système d'information peuvent être à la fois des
ressources et des entités organisationnelles, et l'intégration plus large des ERP
actuels suppose de gérer cette double identité. Le modèle 19440 le permet par
la relation «Functional entity – organisational unit », qui va donc être un des
supports de l'alignement.
Ces entités peuvent être des systèmes, des personnes ou des applications
informatiques. Comme pour les ressources, la spécialisation des entités
correspondants à des systèmes informatiques nous paraît nécessaire. Cela nous
conduit à créer une entité « Package » qui représente un regroupement de
« ressources-IT ». C'est à ce niveau que la décomposition de la structure
technique des ressources informatiques en composants logiciels paraît
pertinente. Tout montre en effet que la structuration des briques applicatives en
composants relève de considérations techniques internes à ces applications et
non pas de la structuration des processus qu'elles supportent. Cette
indépendance des points de vue interne et externe est un cas de ce « couplage
lâche » que nous recherchons dans les dépendances entre points de vue.
Capability (Ca, vue organisation) : une aptitude ou compétence portée par une
ressource et nécessaire à la réalisation d'une activité.
La comparaison avec SCOR nous conduira à renforcer cette gestion des
compétences en introduisant un construit supplémentaire recouvrant la notion
de « pratiques » en relation avec les aptitudes.
Enterprise Object (EO, vue information) : Ce construit est une représentation de
tout objet de l'entreprise dont les caractéristiques sont nécessaires à la
modélisation. Il porte un point de vue informationnel sur l'objet physique dont les
caractéristiques de ressources seront portées par le construit ressource. Il fait
donc partie du système d'information.
Object View (OV, vue information) : Une vue partielle d'un objet d'entreprise.
C'est l'interface naturelle entre la vue informationnelle et les autres vues
notamment la vue fonctionnelle. Dans notre problématique, il représente par
exemple la vue des connaissances nécessaire à un acteur dans une activité de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 147
Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

processus, et cette relation pourra être comparée avec les données que les
ressources informatiques mettent à disposition de cette activité.
Product (Pr, vue information) : c'est un objet d'entreprise particulier qui est
spécialisé par les caractéristiques matérielles nécessaires à la modélisation des
flux physiques.
La séparation entre flux physique et flux informationnel que permet la
spécialisation du construit product par rapport à l'objet d'entreprise est
pertinente malgré la tendance à leur synchronisation toujours plus étroite par
les technologies d'acquisition (RFID, code à barre...) car les flux physiques
sont porteurs d'enjeux spécifiques. Cependant, elle ne porte pas dans le méta-
modèle de dépendances particulières au construit « product »
Order (Or, vue information) : c'est un objet d'entreprise particulier qui est
spécialisé par les caractéristiques d'une décision prise par une autorité pour
l'action d'une autre autorité.
Elle est donc souvent en relation avec un évènement ce qui est représenté par
une relation d'association dans le projet de norme. L'évènement est de ce point
de vue la vue « fonctionnelle » d'une information liée à un objet de gestion de
l'entreprise. La dépendance entre événement et ordre sera un élément de
support de la relation entre système d'information et système d'entreprise
complémentaire à la relation entre activité et ressources informatiques. Elle
permet notamment d'interroger la cohérence des processus de décisions décrits
dans la vue fonctionnelle avec les objets supports de ces processus de décision
dans les applications.
Organizational Unit (OU, vue organisationnelle) : une unité organisationnelle
élémentaire qui regroupe des capacités et compétences dans une certaine structure
hiérarchique. Elle est affectée à un centre de décision et est responsable de
certains objets d'entreprise, processus, évènements ou capacités...
Le modèle 19440 différencie deux types de relations entre organisation et les
autres construits du modèle, la responsabilité et l'autorité. Ces deux relations
ne sont pas décrites plus précisément, et elles sont systématiquement définies
pour tous les construits du modèle. Du point de vue de l'analyse des
dépendances, elles n'introduisent donc pas deux problématiques différentes et
nous les considérerons comme une seule relation.
Dans notre approche, nous identifions des « rôles organisationnels » autant
pour représenter les acteurs dans un projet d'entreprise que pour représenter les
utilisateurs dans la définition des impacts d'un projet et de la conduite du
changement nécessaire. Nous cherchons à travers ces rôles à relier
l'organisation au système d'information de manière cohérente avec les
processus. La norme 19440 propose de différencier le rôle en tant que « rôle
organisationnel » à travers le construit « organisational unit » et le « rôle

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 148
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

opérationnel » porté par le construit « Functional entity ». qui regroupe les

aptitudes nécessaires à la réalisation de l'activité. Cela conduit à considérer la
relation « responsable de » entre l'unité organisationnelle et les objets
fonctionnels et informationnels comme la base de l'alignement entre
organisation, processus et système d'information. Au niveau élémentaire
l'unité organisationnelle représente donc un « rôle » au sens utilisé dans
plusieurs outils de modélisation liées à un ERP comme le module DEM de
BAAN.
Organizational Cell (OC, vue organisationnelle) : Une cellule organisationnelle
regroupe des unités organisationnelles. Ce construit permet une représentation
hiérarchique du modèle et il repose sur une relation d'agrégation.
Decision Center (DC, vue organisationnelle) : C'est une abstraction particulière
permettant d'associer une grille de décision (grille GRAI).
ce construit doit être représenté comme objet informationnel pour être supporté
par le S.I. ce qui nous conduit à le considérer aussi comme un objet
d'entreprise qui peut être en relation avec les objectifs ou variables du modèle.

N ous définissons donc un modèle dénommé « méta-modèle d'intégration »

issu du modèle 19440 en l'interprétant de manière à rendre plus lisible les
enjeux d'alignement de l'organisation, des processus et du système d'information. La
structure du modèle permet d'interroger l'alignement entre les vues proposées, à
travers les relations qui lient les construits :
la vue informationnelle autour de l'objet porte la représentation des données du
S.I. Tout objet du modèle dont une représentation est nécessaire dans le S.I. doit
être un objet d'entreprise dans la vue informationnelle, y compris les construits
organisationnels et fonctionnels.
la vue organisationnelle porte la stratégie d'entreprise, le point de vue managérial
de la conduite du changement dans l'alignement.
la vue fonctionnelle porte l'alignement des processus pour construire de manière
souple le lien entre S.I. et organisation, à travers les différentes dépendances
identifiées dans le méta-modèle.
La vue des ressources pourrait introduire une notion utile d'alignement
entre la vue stratégique de l'organisation et sa vue opérationnelle. Cet enjeu relève
des sciences de gestion et ne sera pas prise en compte dans notre modèle. Par
contre, les ressources informatiques support du système d'information sont un enjeu
essentiel de sa définition et représente pour nous le « système informatique ». Nous
le détaillerons après la comparaison avec un méta-modèle ERP dans la section 3.1.2
de la partie 3.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 149
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Nous utilisons tous les construits du méta-modèle, mais celui-ci utilise

aussi des « concepts complémentaires » aux construits qui viennent caractériser un
modèle et peuvent enrichir les dépendances possibles. C'est notamment le cas du
concept « d'objectifs » qui joue un rôle fondamental pour guider les projets
d'ingénierie et que nous considérons donc comme un construit supplémentaire. Le
méta-modèle définit aussi des « contraintes » dans tous les points de vue à
l'exception des construits organisationnels et des « règles d'intégrité » qui
s'appliquent aux objets informationnels. Ces deux concepts permettent de
contraindre les dépendances techniques liées au système d'information. Des
contraintes peuvent être regroupées en « règles déclaratives » qui permettent de
suivre les résultats de processus en comparaison à des « objectifs » associés aux
différents niveaux des vues organisationnelles ou fonctionnelles. Ces concepts sont
importants pour formuler notamment dans la phase d'expression des besoins des
conditions ou contraintes. Cependant, ils ne viennent que conditionner la
modélisation, donc la production d'instances de construits et de leurs relations. Ils
ne portent pas par eux-mêmes des dépendances nouvelles, mais viennent
conditionner ou interroger des relations déjà identifiées entre d'autres construits.
Dans notre objectif centré sur l'identification des dépendances portant l'intégration,
nous ne les retiendrons donc pas dans notre méta-modèle.
Le construit « d'activité » peut être aussi décomposé en « fonctionnalité
opérationnelle » élémentaire ou tâches qui seront associées aux entités
fonctionnelles, de même que le construit « capacités » peut être décomposé en
capacités élémentaires associées aux mêmes entités fonctionnelles. Ces relations
permettent d'enrichir la description statique des capacités et fonctionnements
possibles, mais elles n'apportent pas de dépendances différentes et nous ne les
retiendrons donc pas dans notre modèle. Enfin, les processus peuvent être associés à
des « règles de comportements » qui permettent de formaliser des règles de pilotage
et de rendre ainsi deux processus dépendants d'une règle commune. C'est pourquoi
nous retenons ce concept comme un construit dans notre modèle.

2 Comparaison du modèle 19440 et du modèle SCOR

L a comparaison d'un référentiel textuel comme le modèle de référence SCOR

avec un méta-modèle comme celui du projet de norme 19440 suppose
d'identifier le méta-modèle propre du référentiel et de mettre en correspondance les
deux méta-modèles soit par un recouvrement direct entre construits considérés
comme équivalents, soit par l'identification d'une relation entre deux construits

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 150
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

différents mais dépendants. Pour cela, nous avons proposé un méta-modèle de

SCOR (Millet et Botta-Genoulaz 2006) qui repose sur les construits suivants :
Entity : entité organisationnelle impliquée dans une chaîne logistique.
Processus : au coeur du modèle de référence SCOR qui représente la brique de
base de construction du pilotage d'une chaîne logistique.
Informations : échangées entre processus en entrée et sortie.
Practices : bonnes pratiques identifiées par les auteurs du référentiel pour
atteindre des performances concurrentielles sur chaque processus.
Features : fonctionnalités du S.I. nécessaires à la mise en œuvre des pratiques,
souvent associés à des progiciels standard (COTS).
Metrics : Indicateurs qui permettent de mesurer la performance atteinte, de
construire des tableaux de bord et de comparaison.
La Figure 3.3 présente ces construits et leurs dépendances dans un
diagramme de classe UML.

Figure 3.3: les construits du méta-modèle SCOR (Millet et Botta 2006)

Un modèle de chaîne logistique construit à partir de SCOR devient dans ce

méta-modèle une liste d'affectations de processus à des entités. Il permet ainsi
d'obtenir par parcours des dépendances, la liste des informations utiles à la mise en
œuvre d'une pratique ou d'une application.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 151
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

La correspondance entre les modèles 19440 et SCOR est illustrée dans la

Tableau 3.2 qui présente en ligne les construits 19440 et en colonne les construits
SCOR.
19440 \ SCOR Entity Process Practice Feature Inform. Metric
Domain Scope
Business Process Niveau 2
Enterprise Activity Niveau 3
Event In / Out
Ressource COTS
Functionnal Entity
Capability (Aptitude) Skills IT Cap.
Enteprise Object In / Out
Object View
Product In / Out
Order In / Out
Organizationnal Unit
Organizationnel Cell Macro Struct.
Decision Centre objective

Tableau 3.2 : Correspondance 19440 / SCOR

La correspondance est forte pour les processus, activités et objets

informationnels (en vert) et nous semble incomplète pour les features, metrics et
practices (en bleu clair). Les « features » sont à la fois des ressources comme
applications informatiques support et des aptitudes à réaliser en terme de mise en
œuvre. Nous les considérons comme un construit complémentaire en relation avec
les pratiques reconnues nécessaires aux processus et avec les ressources
informatiques qui en permettent la mise en œuvre. Le construit « features » est ainsi
une définition « utilisateur » des services que le S.I. peut offrir aux processus, un
point de vue « externe » sur le S.I. et jouera un rôle clef dans l'alignement de la vue
fonctionnelle et informatique d'un point de vue managérial. Il est indispensable au
niveau générique de la modélisation, pour laquelle aucune application informatique
n'est parfois définie ou choisie, mais où un référentiel de fonctionnalités
« standard » est un outil classique de la définition de besoin.
Les « practices » contribuent aux aptitudes d'une organisation, mais elle
sont aussi souvent des facteurs d'organisations par elles-mêmes. Ainsi la mise en
œuvre d'un Plan Industriel et commercial (PIC) relève d'une organisation périodique

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 152
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

de révision du plan entre entités commerciales et industrielles. Leur réduction à une

aptitude nous semble insuffisante pour en caractériser toutes les dépendances avec
d'autres construits.
Le concept de pratiques dont nous avons noté l'importance dans la maturité
des usages doit être identifié en tant que tel dans un méta-modèle pour porter la
dimension organisationnelle et humaine des compétences nécessaire au pilotage
d'entreprise. Le modèle SCOR en propose une structure qui se détaille en :
description;
contexte de pertinence, qui précise les conditions au sens d'indicateurs qui
rendent cette pratique pertinente. Il s'agit donc d'une relation avec les indicateurs;
impacts sur la performance, qui est une relation avec les indicateurs de
performances du modèle;
facteurs de succès à prendre en compte pour la mise en œuvre de la pratique;
ressources, au sens de références bibliographiques pertinentes pour définir la
pratique.
Le construit de « Domain » n'a pas de correspondance dans SCOR.
Cependant son rôle de définition d'un périmètre de projet comme un ensemble de
processus peut être joué dans une modélisation de chaîne logistique par le périmètre
logistique qui fait l'objet de l'étude. L'ensemble des entités logistiques identifiées
dans la chaîne conduira en effet à une liste de processus. Dans le cas de SCOR, le
périmètre est d'abord un périmètre physique qui conduit à identifier un ensemble de
processus. Dans la pratique d'ingénierie qui sous-tend le modèle 19440, le
« Domain » permet de délimiter un périmètre fonctionnel de projet en phase
d'initialisation. Cependant les projets ERP conduisent souvent à réviser le périmètre
initial pour tenir compte des contraintes d'alignement des processus et de
l'organisation. Le couplage entre processus et organisation nous semble donc plus
pertinent que la notion de domaine comme base de définition d'un périmètre de
projet, le « Domain » pouvant être considéré comme une agrégation de processus à
des fins de reporting.
Les « metrics » ont évidemment à voir avec le concept complémentaire
19440 d'objectifs reliés aux centres de décisions et aux construits fonctionnels.
Cependant la définition SCOR repose sur des indicateurs dont les formules de calcul
précises et hiérarchisées en font des objets informationnels. Les objectifs 19440
sont des textes qui sont traduits par des « indicateurs de performances » gérés
comme attribut des construits fonctionnels. La description détaillée des construits
« Domaine », « Business Process » et « Enterprise Activity » inclue cependant des
attributs dénommés « Performance Indicators » qui correspondent bien au concept
de Metrics du modèle SCOR. Nous proposons donc d'étendre notre modèle avec les
construits « Objectives » et « Metrics ». L'ajout de ces construits peut d'ailleurs

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 153
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

conduire à ajouter une vue « décisionnelle » en complément de la vue

organisationnelle.
En conclusion de cette comparaison, nous intégrons dans notre méta-
modèle issu de la norme 19440 trois construits nécessaires à la représentation du
modèle de référencec SCOR
les « practices » (Pr) dans la vue organisationnelle, en tant que méthode mettant
en jeu des aptitudes dans des organisations, conditionnant des objectifs
d'entreprise et représentant ce qui est nécessaire pour la maîtrise de certains
processus ;
les « features » (Fe) dans la vue fonctionnelle, fonctionnalités du système
d'information nécessaire à la mise en œuvre des pratiques et supportées par des
composants d'applications informatiques ;
les « metrics » (Me) dans la vue informationnelle, représentant les indicateurs
pertinents pour évaluer la situation de l'entreprise du point de vue de ses
objectifs. Considérés comme des « objets d'entreprise », ils sont aussi traduits en
« données » informatiques.

3 Comparaison du modèle 19440 et d'un modèle ERP

A près l'extension du modèle 19440 pour prendre en compte le référentiel

SCOR, nous avons vérifié la capacité des construits de la modélisation
d'entreprise à représenter un ERP autant dans sa structure technique qui conditionne
l'organisation de projet que dans sa relation aux processus que l'organisation
cherche à améliorer. A partir de notre connaissance détaillée d'un ERP particulier
(BAAN), nous avons modélisé les objets organisationnels et informationnels utilisés
dans un projet ERP. L'intérêt de l'ERP BAAN (désormais INFOR ERP LN 24) est
d'inclure une application dédiée de modélisation des processus permettant de lier
directement les transactions de l'application informatique et l'organisation des
activités décrites dans les processus. A partir de ce cas particulier, nous proposons
un « méta-modèle ERP » (Figure 3.4) qui repose sur l'identification d'objets
« organisationnels » permettant de modéliser les processus, les rôles et
l'organisation, et d'objets « informationnels » représentant l'architecture applicative
à un niveau permettant de modéliser les dépendances entre l'organisation et le S.I.
(Millet 2005).

24 Http://[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 154
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Nous croisons ce méta-modèle ERP avec le méta-modèle 19440 pour

caractériser la capacité de la modélisation d'entreprise à outiller les projets ERP
(Tableau 3.3). La partie « organisationnelle » de ce méta-modèle (processus, rôle et
information...) correspond sans difficulté aux construits 19440 processus,
organizational unit et object view.

Figure 3.4: Méta-modèle des objets d'un ERP

Les objets informationnels représentant le S.I. ne peuvent être considérés

dans l'approche 19440 que comme des « ressources » que nous avons décidé de
spécialiser comme « IT Resoruce » pour modéliser plus précisément la dimension
informatique. Ces ressources sont :
les « données » du système échangées ou stockées qui sont le support des
« objects view ». Il est donc nécessaire de différencier un point de vue
« informationnel » qui est celui de la vue correspondante 19440 et un point de
vue « informatique » qui en est la traduction dans les ressources informatiques.
Le construit « object view » porte les informations au sens de l'usage des données
par les acteurs pour construire des connaissances nécessaires pour agir, alors que

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 155
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

le construit «Data » porte le point de vue informatique du stockage et du

traitement des données correspondantes.
les « transactions » élémentaires des applications logicielles sont identifiées dans
le modèle ERP comme la décomposition la plus fine du progiciel nécessaire à la
définition des activités de processus. Dans le modèle 19440, ce sont les
ressources mobilisées dans les activités de processus, et la relation de support
identifiée dans le modèle ERP correspond à celle entre ressource et activité du
modèle 19440.

DM BP EA Ev Re FE Ca EO OV Pr Or OU OC DC

Organization X

Process X X

Actor X

rôle X

information X X

Transaction X

data X

IT Object
orders ? ?

ressources X

parameter
Structure
IT dependences constraints

Support R R

Tableau 3.3 : Correspondance modèle ERP et 19440

Les dépendances informatiques du modèle ERP peuvent être traitées en

19440 comme des contraintes entre ressources informationnelles. Il faut donc
compléter le modèle 19440 par la spécialisation du construit ressource déjà
présentée, en s'inspirant du modèle ERP évoqué plus haut afin de différencier :
Les ressources « données (data) » (Da)et leurs contraintes d'intégrité.
Les ressources « interactions » (Int), outils applicatifs élémentaires utilisables
dans une activité (transaction, état, page web interactive....).
Les ressources « programmes (logic) » (Log) internes aux applications et qui
portent de nombreuses dépendances entre « data » et « interactions » car elles
codent les mécanismes d'intégration informationnelle de l'ERP.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 156
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Une telle extension correspond au modèle de système d'information

proposé par Morley séparant le système informatique du système de traitement de
l'information (section 2.3.1). Ces construits pourraient conduire à considérer une
vue dédiée à la représentation du système informatique indépendamment de la vue
générale des ressources. Mais l'objectif de notre cadre de modélisation n'est pas
l'ingénierie du logiciel. L'extension de ce cadre à un point de vue « informatique »
nécessiterait un travail plus approfondi de cohérence avec les modèles de logiciels
existants qui ne nous paraît pas pertinent dans notre problématique centrée sur
l'alignement entre les différents points de vue. Ce que nous demandons aux
construits des différentes ressources informatiques, c'est seulement d'identifier les
contraintes liées aux dépendances entre leurs composants. La spécialisation en
données, traitements et interfaces est suffisante pour prendre en compte la totalité
des contraintes d'intégrité (dépendances entre données) des contraintes logiques
(dépendances entre programmes, et entre programmes et données) et les contraintes
d'utilisation (dépendances entre interfaces et programmes).

4 Méta-modèle de l'intégration

A partir des différents construits étudiés dans les paragraphes précédent, nous
obtenons le méta-modèle utilisé dans notre cadre d'étude de l'intégration
(Figure 3.5). Ce méta-modèle, que nous appellerons « méta-modèle d'intégration de
l'entreprise » utilise les construits de la norme 19440 dans l'interprétation que nous
avons présenté dans le début de ce chapitre, complété des concepts de cette norme
que nous avons considérés nécessaires à l'identification de dépendances, des
construits « pratices », « features » et « metrics » issus du modèle SCOR et des
construits spécialisant les « Ressources Informatiques » issus du modèle ERP afin
de prendre en compte les contraintes issues des dépendances informatiques.
Ce méta-modèle conserve la structure en quatre points de vue, chaque
construit étant de manière dominante centré sur un point de vue, mais souvent en
relation avec d'autres. Il est destiné à identifier et caractériser les différentes
dépendances entre ces construits, dépendances qui portent les contraintes et les
opportunités de l'intégration que nous allons étudier dans la section suivante.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 157
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Pierre-Alain MILLET Partie 3 / Chapitre 3.1

Figure 3.5. Le méta-modèle d'étude de l'intégration
Thèse en informatique/ 2008 158
Institut national des sciences appliquées de Lyon
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

3.1.3 Référentiels métiers pour les modèles

d'entreprise

C omme nous l'avons vu dans l'état de l'art sur les ontologies dans la
modélisation d'entreprise (section 2.2.4), un méta-modèle a pour vocation de
permettre une modélisation cohérente sur l'ensemble des domaines étudiés, par la
comparaison de points de vue multiples, de points de vue des différents acteurs d'un
projet d'entreprise. Le modèle d'entreprise ne peut être réparti entre domaines
comme la finance, la logistique ou l'ingénierie de manière indépendante. Au
contraire, l'insuffisance de compétences transverses dans des projets ERP répartis en
sous-projets par grand domaine fonctionnel est souvent cité comme une difficulté
des projets d'intégration. De fait, les points de vue multiples portés par les acteurs
sont essentiels à la compréhension de ce qui fonde le niveau d'intégration existant
ou souhaité, donc des dépendances qui existeront entre les construits de ces
différents domaines. Cependant, chaque métier va utiliser ses propres connaissances
pour représenter les processus qui le concerne, y compris les processus transverses.
C'est pourquoi la connaissance d'ontologies métiers et leur insertion dans le cadre
du méta-modèle d'entreprise utilisé est essentielle pour garantir l'efficacité de la
modélisation par les acteurs, et sa cohérence transverse. Des référentiels divers
existent, beaucoup portant sur les échanges entre entreprises, dans le prolongement
des outils EDI comme le standard OAGIS proposé par les principaux éditeurs de
progiciels d'entreprise25. Nous étudions dans cette section un référentiel métier
permettant d'illustrer certains des construits de notre méta-modèle. Nous avons
choisi de nous concentrer sur le modèle de référence SCOR car d'une part, il donne
une vue relativement détaillé des processus logistiques sans être trop lourd pour être
utilisable dans notre contexte de projet, d'autre part, nous avons étudié son
adéquation avec le méta-modèle 19440 pour construire notre méta-modèle. Nous
avons concentré notre travail sur les construits encore faiblement normalisé dans le
modèle SCOR, les informations et fonctionnalités (« features »). Pour les processus,
pratiques et indicateurs qui sont au cœur du modèle SCOR et déjà fortement
normalisé, nous avons confirmé la correspondance en termes de méta-modèle dans
les paragraphes précédents. C'est pourquoi nous étudierons successivement les
informations échangées puis les fonctionnalités (« features) en cherchant à
contribuer à la normalisation de ces construits qui ne sont proposés que sous forme
de texte dans le modèle SCOR et en identifiant les enjeux d'intégration dont ils sont

25 [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 159
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

porteurs. Nous proposerons ainsi une liste de « briques applicatives » pour

formaliser les fonctionnalités évoquées dans les processus SCOR en étudiant leur
contribution aux processus qui se traduira dans le modèle d'entreprise par les
dépendances entre les construits correspondants. Ces « briques » sont à la fois des
« IT ressources de notre méta-modèle » puisqu'elles se définissent en relation avec
les progiciels du marché, mais aussi des fonctionnalités au sens des services que ces
applications apportent aux processus et qui sont étudiées à travers les « features »
de SCOR.

1 Informations échangées dans le modèle SCOR.

D e nombreux points de vue sont possibles pour construire une classification des
informations échangées entre les processus. Les informations sont des
données de gestion (valeurs, volumes, prix, ratios…), liées aux flux ou aux
processus de décision. Ce sont le plus souvent des données informatiques qui
peuvent être statiques (pour des données de contexte d'une collaboration),
dynamiques (pour les données quantitatives liées aux échanges) ou historiques (pour
les données de collaboration dans la décision). Le point de vue le plus pertinent
pour identifier leur contribution à l’alignement des S.I. aux processus est de
considérer la place de ces informations dans les relations entre acteurs, depuis les
informations échangées systématiquement (les informations de flux logistiques ou
financiers notamment), jusqu’aux informations critiques échangées dans le cas de
collaboration voire d’intégration forte (organisation, indicateurs, risques,
valorisations...). Nous pouvons donc identifier plusieurs critères de classification et
évaluer comment les appliquer à partir du contenu des informations décrites dans le
modèle SCOR.
Nous nous appuyons sur les travaux réalisés dans le cadre du projet
COPILOTES (Copilotes, 2005) portant sur la caractérisation des échanges
d'information dans une chaîne logistique. A partir d’une étude bibliographique des
modèles mesurant la valeur de l’échange d’informations, et notamment d'une
mesure de l'intensité de relations portant sur quatre informations agrégées
(demande, capacité, planning, stocks) proposée par Barut (Barut, Faisst, et Kanet
2002), un des groupes de travail du projet a proposé une classification selon la
valeur de l’échange entre partenaires d’une chaîne logistique (Tableau 3.4).
Cette classification représente un critère de « nature » de l'information
dans la relation de collaboration et représente dans notre travail un point de départ
dans la recherche d'une « taxonomie » des informations du modèle SCOR. A partir

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 160
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

de cette première liste, nous avons recherché des critères de classification

facilement instanciable pour les 342 informations identifiées dans le modèle SCOR.

Produit / Structure du produit

Production Coût de production (+ var.)
Taille des lots de fabrication
Coûts logistiques
Ressources Capacités de production (+ var.)
Flexibilité de la capacité
Répartition de la capacité/produits ou clients
Stocks Niveaux de stocks/inventaires
Paramètres politiques de gestion des stocks
Encours de production et/ou de livraison
Coûts de stockage et de rupture
Contraintes d'approvisionnement amont
Délais Délais de production (+ var.)
Délais de livraison (+ var.)
Délais de commande (+ var.)
Demande Caractéristiques de la demande finale
Ventes réalisées et /ou historique de ventes
Niveau des reports de la demande
Prévisions de ventes
Campagnes promotion sur le marché finale
Planification Programme de production (+ var.)
Paramètres planification appros
Suivi des commandes et des ruptures
Règles priorité appliquées aux commandes

Tableau 3.4 Informations échangées

Nous avons vérifié la pertinence de ces critères en classant ces

informations dans le modèle de données de l'ERP BAAN afin d'en obtenir une
classification « technique » par les modules structurant la base de donnée de cet
ERP. Ce travail a conduit à un tableau des informations que nous avons rapproché
de notre méta-modèle d'intégration. Celui-ci organise la vue informationnelle autour
de la notion d'objet d'entreprise qui peut être spécialisée en produit, ordre ou
ressource. Les évènements sont représentés dans la vue informationnelle par une
vue d'objet. Nous avons de plus proposé l'ajout d'un construit informationnel
« metrics » issu du modèle SCOR. Enfin, nous avons considéré que les construits
organisationnels devait être « représentés » dans le S.I. car la définition d'une entité
organisationnelle est aussi une information qui va être gérée par des données
utilisées pour le paramétrage, la modélisation, la mesure de performance. Nous
avons donc les classes d'informations suivantes issues du méta-modèle : produit,
ordre, indicateur, ressource, évènement, entité organisationnelle.
La classification des informations SCOR sur les construits informationnels
et la classification COPILOTES a conduit à étendre ce modèle informationnel pour

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 161
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

plusieurs types d'informations présentes dans le modèle SCOR et difficilement

rattachable de manière globale à un construit du méta-modèle. C'est le cas :
des informations de planification qui regroupent les deux classes « demande » et
« planification » de la classification COPILOTES. Nous ne pouvons les
considérer comme des « order » 19440. Si ce construit « order » est défini dans la
norme comme représentant les informations de planification et de contrôle, il est
effectivement défini dans son template dans le sens d'un ordre donné à une entité
pour réaliser une opération (commande client, ordre de fabrication). Or si une
commande client est une information naturellement échangée car elle conditionne
l'échange, le plan directeur est une information d'une autre nature, rarement
échangée entre entreprises et qui relève de processus décisionnel et non pas de
processus opérationnel. Il nous semble de manière générale nécessaire de
différencier les informations selon leur niveau décisionnel, opérationnel, tactique
ou stratégique. Ce sera un des critères de classification des informations et cela
nous conduit à différencier les informations de type « plan » des informations de
type « order » (qui représentent une décision.
de nombreuses informations du modèle SCOR portent sur les « conditions » de
l'échange entre partenaires. De même, la classification COPILOTES étudie
séparément les informations de délai comme des « paramètres » qui peuvent être
par eux-mêmes des informations échangeables au niveau d'une collaboration
tactique ou stratégique. Dans un ERP , de nombreuses données liées aux
relations commerciales (conditions de livraison, de facturation, de paiement, de
gestion de crédit, de gestion des relances...) ou à l'organisation interne de
l'entreprise (type d'ordre, causes d'erreurs, de retards...) ou sur le contexte externe
à l'entreprise (taux de devises, conditions d'export...) sont gérées, échangées. Ces
données peuvent être liées à des tiers, à des ordres, à des entités
organisationnelles... Elles existent par elles-mêmes et jouent un grand rôle dans
les échanges entre entreprises et donc dans les systèmes d'entreprise. Elles
conditionnent les ordres et les évènements mais ne peuvent être considérés
uniquement comme des attributs de ces construits. Nous proposons donc deux
classes d'information qui les représentent, les CONDITIONS qui relèvent d'une
relation entre l'entreprise et ses partenaires ou son environnement, et les REGLES
qui conditionnent les processus de décision de l'entreprise.
Les évènements liés aux flux physiques et informationnels sont bien entendu
largement présents dans le modèle SCOR et sont couverts par le construit
« event » du modèle 19440. Mais la journalisation de ces évènements créent pour
les processus de décision une information de type nouveau, qui n'est plus lié à la
dynamique des processus opérationnels, mais devient une source de donnée pour
le processus de décision. Nous proposons donc d'ajouter une classe

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 162
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

« JOURNAL » qui représente l'ensemble de la mémoire des flux, et des

modifications de données qui sont utiles pour un processus de décision.
Enfin, de nombreuses informations portent sur les partenaires eux-mêmes de
l'entreprise. Le modèle 19440 propose une représentation de l'entreprise, sans
réellement prendre en compte la représentation de ses échanges, alors que le
modèle SCOR est au contraire centré sur la chaîne logistique, donc sur les
relations clients-fournisseurs. Nous proposons l'ajout d'une classe « ACTOR »
qui peut être considérée comme une spécialisation d'une entité organisationnelle
(dans de nombreux cas, des relations client-fournisseur peuvent exister à
l'intérieur d'une entreprise et sont donc naturellement des relations entre
construits organisationnels)
Le résultat est un ensemble de 10 classes d’information, formulées en
anglais par cohérence avec le modèle SCOR lui-même et sans chercher à reprendre
la terminologie 19440 :
Actor : Les caractéristiques, identification ou localisation d’une entité
organisationnelle, d’une ressource vue comme acteur dans une relation (rôles, tiers,
entité légale, sites). Le partage d’information sur les acteurs représente une
« transparence » de l’entité sur son organisation interne ou son réseau de partenaire,
marque d’une collaboration forte.
Rules : Les règles et conditions du pilotage de l’activité. Elles traduisent
les choix stratégiques et tactiques : règles de pilotage, système
d’approvisionnement, modes de valorisation. Les règles sont rarement échangées
dans une relation. Leur partage est significatif d’une collaboration portant sur le
pilotage de la chaîne.
Plan : Prévisions, planning et programmes qui déterminent un cadre
de décision (PDP, prévisions de demande, …). Données généralement réparties dans
un calendrier par période ou date. L’échange de données de ce type est
caractéristique d’une collaboration plus étendue que la simple relation commerciale.
Object : Définition et caractérisation des produits, ressources,
moyens, procédés et services conçus, réalisés et livrés. Données « techniques »
considérées souvent comme statiques. Documents décrivant ces objets, plans,
guides, instructions. Le partage d’informations sur les objets, au-delà des
informations échangées sur les objets dans les flux, relève d’une collaboration dans
la conception des produits ou le pilotage des ressources.
Ressource : Point de vue « capacitaire » des objets définis (stock,
capacité, localisation, disponibilité…). Donnée en général variable dans le temps et
dont on gère un profil temporel. Le partage d’information sur les ressources est

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 163
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

associé à des pratiques collaboratives (GPA, Stock déporté…) et encadré par ces
pratiques.
Condition : Les règles et conditions du pilotage des relations (tarifs,
conditions, règles…). Elles peuvent être légales : règles de pilotage, tarifs,
conditions de livraisons, de facturation, contraintes légales,… Les conditions sont
le plus souvent échangées dans une relation, mais le jeu commercial conduit
souvent à en masquer une partie.
Decision : Information caractérisant une décision proposée, confirmée
ou en cours de réalisation et impliquant des flux physiques ou financiers. Cela
inclus les demandes, propositions, ordres, contrats, factures… les décisions sont les
données principales échangées entre acteurs, les normes EDI représentent une bonne
vue des informations associées.
Flow : Flux et évènements liés aux relations (flux physiques, temps passés,
anomalies, réceptions, livraisons…). Données dynamiques associées à la date de
l’évènement et faisant souvent l’objet de moyens d’acquisition. Elles font partie des
données échangées de manière classique dans toute relation.
Journal : Données historiques, traces, listes d’évènements datés et qui ne
sont plus modifiées. Le partage d’information de ce type n’a de pertinence que dans
la recherche d’une base de connaissance partagée, donc d’une collaboration forte.
Metric : Données représentatives de l’activité, bilans financiers,
indicateurs d’aide à la décision opérationnels (volumes, charge, ratios…), tactiques
(indicateurs de performance, niveau de service…), ou stratégiques (fidélité client,
rentabilité…). Données parfois réglementées, dépendantes des flux, historisées et
souvent détaillées en tableau multidimensionnel.
Ces différents types d’information sont présentées dans la Figure 3.6 dans
leur position relative à la relation entre acteurs économiques. Toutes les
informations de flux et d’ordres ne sont pas nécessairement échangées, mais elles
sont liées naturellement à un échange. Au contraire, le partage d’informations sur
des ressources, un plan ou des règles relève d’une décision de collaboration
particulière. Ces 10 classes ont permis de caractériser les informations définies dans
SCOR. Elles constituent ainsi le niveau 1 de modélisation des informations
échangées dans la chaîne logistique. On peut alors analyser leur rôle dans les
processus logistiques, et caractériser ainsi la nature informationnelle de la
collaboration proposée dans le modèle SCOR.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 164
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

metric

rules
condition

Entité focale plan

(actor) decision

Tiers en relation
(actor)
resource Object

journal flow

Figure 3.6: Classes d'information échangées dans le modèle SCOR

Le Tableau 3.5 présente le nombre d’occurrences par famille de processus

de chaque classe d’informations. Il représente ainsi au niveau 1 de modélisation une
vue orientée information de l’alignement des S.I. aux processus. Il classe en lignes
les processus en différenciant les processus de support (Enable noté E), les
processus opérationnels (Source, Make, Deliver, Return, notés S, M, D et R) et les
processus de planification stratégique (S).
Type N1 actor conditiondecision flow journal metric object plan resource rules Total
S P 15 15 5 3 5 8 37 14 8 110
O D 2 6 52 32 1 8 3 16 28 1 149
M 6 7 24 2 12 5 56
R 11 35 43 5 9 17 21 141
S 3 4 24 21 2 8 9 71
E D 4 10 6 5 2 8 4 1 2 8 50
M 7 8 8 1 9 9 7 5 54
P 5 5 1 3 7 7 7 2 37
R 3 5 2 4 4 11 13 42
S 14 2 6 8 1 3 2 2 8 6 52
Total 23 69 158 152 15 31 37 105 108 64 762

Tableau 3.5: Classes d'information par processus SCOR de niveau 1

On peut étudier ainsi la complétude du modèle en notant par exemple

qu’aucune information de type «metric » n’est identifiée pour les processus

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 165
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

opérationnels de production ou de support à la production. Les processus

d’évaluation de performance permettant d’obtenir les indicateurs définis dans le
modèle ne sont donc pas inclus. On illustre ainsi qu'un méta-modèle ne peut
contenir la totalité d'une sémantique, que toute construction d'un discours métier
nécessitant une formalisation plus détaillée du vocabulaire utile, conduit à enrichir
chaque construit. Un méta-modèle ne peut que proposer une structure générale des
concepts nécessaires à la modélisation. Il doit être complété par une formalisation
des connaissances métiers, c'est à dire une ontologie. Son rôle modèle est de
proposer un contexte pour positionner les ontologies métiers entre elles et faciliter
leur mise en cohérence. L'enjeu de l'alignement d'ontologies métier hétérogène dans
un cadre de modélisation est une perspective de recherche que nous évoquerons
dans la partie 4.

2 Briques applicatives

L a conception d'un S.I. d'entreprise et notamment de son architecture doit

pouvoir s'appuyer sur un référentiel des types d'applications existantes,
indépendamment des environnements technologiques. Nous avons vu qu'un S.I. est
dans la pratique toujours construit à partir de telles applications. La définition des
différents sigles utilisés varient d’un acteur à l’autre. Le périmètre d’une offre
évolue dans le temps. Mais les progiciels standard du marché sont bien les
« briques » à partir desquelles une entreprise constitue son architecture applicative.
Des référentiels partiels existent dans des glossaires industriels ou des études de
marché, le dictionnaire de l’Apics (APICS 2005). ou du Gartner Group (GARTNER
2003). Les sigles répandus sont une réalité commerciale et financière parfois
identifiée par un indicateur boursier (ITtoolbox 2005). Une étude de référence
([Link]) sur le positionnement des offres sur le marché
s’appuie sur une classification d’applications regroupées par familles pour
lesquelles sont proposées des outils d’évaluation : ERP, SCM, CRM, BI... Dans ces
glossaires se retrouvent des sigles de nature différentes : des méthodes industrielles
ou logistiques, des technologies informatiques et des applications ou
fonctionnalités. Une cartographie de composants applicatifs centrée sur le pilotage
d’une chaîne logistique du fournisseur au client fait état de trois composants
applicatifs, ERP, WMS et TMS correspondant à trois rôles différents dans la chaîne,
le producteur, le distributeur, le transporteur et d'un composant nécessaire à
l’intégration dans la chaîne logistique : le SCE. (Verwijmeren 2004). On voit ainsi
une dépendance possible entre briques et processus de l'entreprise.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 166
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Une définition de briques applicatives peut s’appuyer sur une base

théorique avec les « modules » de la méthode de modélisation d’entreprise GERAM
(Bernus et Nemes 1997). GERAM propose des « Generic Enteprise Module » qui
sont des produits qui peuvent être configurés et intégrés dans un S.I. d’une
entreprise particulière. Dans l’esprit de GERAM les « modules » doivent
correspondre à des « modèles » d’entreprise pour faciliter le choix d’un module
selon le cas d'entreprise étudié. Cette notion de « modules » ou de « briques » ne
correspond pas nécessairement à la notion de « composant » utilisée en génie
logiciel dans les « architectures à base de composants ». Comme le note Wallnau
((1999) dans un état des lieux technique de ces architectures de composants
réutilisables :
« Advocates of software reuse equate components to anything that can be
reused; practitioners using COTS software equate components to COTS
products; software methodologists equate components with units of project and
configuration management; and soft-ware architects equate components with
design abstractions. »
C’est d’ailleurs dans une évolution de l’architecture proposée par cet
auteur, qu’apparaît la notion de « Components On The Shelf (COTS) » parfois
dénommé aussi « Commercial off the shelf » pour répondre aux besoins du
département de la défense des USA dont un règlement défini la notion de « produit
commercial » dans le contexte des logiciels. Cette définition de « COTS » est
clairement commerciale quels que soit le contenu et la technologie utilisée (Albert
et Brownsword 2002). C'est un composant qui est
vendu, loué ou licencié au public
proposé par un vendeur qui cherche à en tirer un profit
supporté et amélioré par le fournisseur qui en garde la propriété intellectuelle
disponible en multiples copies sans modifications internes
Ces applications existantes sur le marché sont identifiées dans le modèle
SCOR comme support de fonctionnalités (« features ») et sont utilisées pour décrire
le S.I. support des processus d'une chaîne logistique. Le modèle propose ainsi les
fonctionnalités nécessaires aux « bonnes pratiques » identifiées sur chaque
processus, faisant ainsi référence aux ERP, APS… Ce choix de relier applications et
processus à travers les pratiques illustre l'enjeu d'une définition de ces briques
indépendante des offres pour l'ingénierie des projets d'intégration. La version 8.0 du
modèle SCOR constate cependant la difficulté d'une définition « neutre » de ces
fonctionnalités et ne propose plus de l'inclure dans le modèle. La question de
l'alignement des fonctionnalités applicatives aux pratiques identifiées est donc non
couverte par le modèle SCOR dans sa dernière version.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 167
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Au croisement des « Generic Models » de GERAM, des COTS et des

features de SCOR, nous proposons donc une définition de briques applicatives
comme progiciel du marché support d'un modèle générique partiel
d'entreprise, et supportant des processus d'affaires particuliers. Nous en
proposons une définition extensive. Cette-ci ne peut se faire à partir d’un
partitionnement technique de l’ensemble des applications existantes, compte tenu de
l’hétérogénéité des offres, de recouvrements entre applications, et de définitions
redondantes. Plus le niveau d’intégration est élevé, plus l’architecture applicative
sera l’image de choix d’organisation et non pas de la répartition des données ou
fonctionnalités. La classification de ces briques doit donc faciliter l’analyse des
processus et de leurs fonctionnalités support.
Cette classification est nécessairement évolutive. Une innovation technique
peut conduire à redéfinir la frontière entre deux briques apparemment clairement
identifiées. Ainsi, si le MES et l’ERP relèvent de marchés nettement séparés, leur
définition relative peut se transformer comme le montre une architecture agent :
« In PABADIS the MES layer is dissolved and its functionality divided into a
centralized part that can be attached to an ERP system and a decentralized
part, implemented by mobile software agents, that can be connected to the
production equipment » (Klostermeyer et Klemm 2003).
Notre classification (Figure 3.7) s'appuie sur un axe lié au flux d'activité
permettant une différentiation entre les applications tournées vers l’extérieur de
l’entreprise de celles centrées sur l’entreprise elle-même. Nous définissons ainsi les
briques tournées vers le pilotage et l’intégration des tiers (SRM - Supplier
Relationship Management, CRM - Customer Relationship Management) et les
briques assurant le pilotage et l’intégration des fonctions internes telles que les ERP.
A coté de cette dimension du « flux » sur lequel positionner les briques,
F BI
O C
U SCP APS
R L
N PDM PLM I
I
S SRM ERP CRM E
S N
E SCEM
U T
R SCE (TMS, WMS) MES SCE (TMS, WMS)

Figure 3.7: Briques applicatives

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 168
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

avant la résolution de problèmes complexes, multi-critères. On peut identifier

d’autre part un niveau décisionnel, très présent autour des CRM et des SCP et qui
s’appuie sur des applications décisionnelles (« Business Intelligence : BI »).
Cette cartographie étend la première proposition centrée sur les système
d’information logistiques (Millet et Botta-Genoulaz, 2007). Le Tableau 5.4 en
annexe présente nos définitions. Il est conforté par la fréquence d’usage de ces
sigles dans la structuration des offres éditeurs et leur présence dans les principaux
dictionnaires métiers comme celui de l’APICS ou du GARTNER Group dont les
définitions sont mises en relation dans le tableau.

C ette définition de briques est en quelque sorte un point de vue externe, sur
l'architecture nécessaire du S.I. Dans les premières phases d'étude
d'opportunité d'un projet évaluant les processus critiques, elle peut contribuer à
l'identification des briques nécessaires dont la sélection caractérise ainsi un projet
comme étant un projet « ERP » ou « CRM », (ou « ERPII » comme évoqué dans
l'état de l'art) car il utilise plusieurs briques. Cependant, pour être opérationnel, ces
définitions doivent pouvoir être détaillées en « modules » ou « fonctionnalité » plus
précises qui aident à définir le périmètre du projet et donc le périmètre de mise en
œuvre des briques choisies. Mais les différences entre les solutions standard au
niveau détaillé sont plus importantes. Elles peuvent provenir de différences
historiques. Un module a été créé de manière autonome chez un éditeur, et intégré
dans une autre fonctionnalité chez un autre, cette structuration survit aux évolutions
des deux solutions bien que les fonctionnalités se rapprochent avec les différentes
versions. Elles peuvent aussi provenir de positionnement différent sur le marché. La
présence très forte de SAP sur les grands groupes le conduit à prendre en compte
dans l’ERP même les fonctions de consolidation financière. Dans le cas de BAAN,
le positionnement moins orienté grand compte conduit à proposer une application
dédiée finance grand compte en complément à l’ERP.
Il existe des listes de fonctionnalités destinées à la sélection de solutions
(comme celles du cxp26 ou du site technologyevaluation27). De telles listes de
questions permettent en principe de vérifier si les fonctions proposées par une
solution répondent à tel ou tel besoin d’une entreprise particulière. Mais ces listes
sont souvent redondantes, regroupent des questions de niveau de modélisation très
différent. Un travail de généricité et de modélisation des questions serait nécessaire
pour produire un référentiel académique permettant une définition extensive des
briques applicatives. Un tel travail de normalisation des briques et de leur

26 Http://[Link]
27 Http://[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 169
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

définitions représente une vue « applicative » d'un modèle de référence générique,

qui doit pouvoir être spécialisé selon les solutions du marché retenues.
Une esquisse de structuration de la brique ERP facilement traduisible sur
plusieurs ERP existants est proposée ci-dessous :
EP « Enterprise Planning » : Planification de l’entreprise, (PIC, Plan Industriel et
Commercial, planification de la demande et de la production (PDP, Plan Directeur
de Production), planification des besoins matières (MRP), gestion de la charge
(CRP, Capacity Requirement Planning), planification de la distribution (DRP,
Distribution Requirement Planning), des projets (PRP, Project Requirement
Planning);
PD « Product Data » : Gestion des données techniques, intégrant la gestion des
nomenclatures d’étude, des indices et procédures de révisions, des ordres de
modifications techniques ;
MC « Manufacturing Contro » : Gestion de la production, intégrant
l’approvisionnement, la gestion de l’atelier (SFC, Shop Floor Control), parfois
l’ordonnancement, la gestion des opérations, la gestion en flux tiré, la gestion de
campagnes répétitives…
PU « Purchase Control » : Gestion des Achats, intégrant la gestion des
fournisseurs, des tarifs, des contrats, des programmes cadencés, des appels
d’offres, des demandes d’achats, l’évaluation fournisseur…
WH « Warehouse control » :Gestion des stocks, intégrant la gestion des entrepôts
(trans-stockeurs, magasins dynamiques, optimisation de rangement…), la gestion
de l’inventaire (cyclique, sur évènement…), la gestion des lots (traçabilité,
caractéristiques techniques, fractionnement), le paramétrage des
approvisionnements sur stock (point de commande, stock de sécurité, niveau de
service…) ;
SM « Service Management » : Gestion des services de maintenance, intégrant la
gestion des parcs matériels, des contrats de services, des interventions, des pièces
de rechanges, des retours, de la maintenance préventive…
QM « Quality Management » : Gestion de la qualité, intégrant la gestion des
laboratoires, des échantillons, des ordres de contrôle sur stock ou sur flux, la
gestion des classes de produits, des certifications ;
PM « Project Management » : Gestion de projets, intégrant la planification
d’activités, la gestion et le suivi de budgets, l’ingénierie de projet, le suivi et
l’avancement de projet, la gestion des encours et résultats de projets ;
SD « Sales and Distribution » : Gestion des ventes et de la distribution, intégrant
la gestion des clients, des tarifs, des contrats, des programmes cadencés, des
devis, des ordres de ventes, des livraisons, des facturations, l’évaluation du taux
de service…

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 170
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

TM « Transport Management » : Gestion des transports, tarification,

planification, trajets et regroupements, traçabilité, facturation des transporteurs,
intégration aux achats et ventes ;
FI « Finance » : Gestion financière, intégrant la comptabilité générale, les
comptabilités auxiliaires (fournisseurs, clients…), la comptabilité analytique, la
gestion budgétaire, la production des états fiscaux ;
CM « Cash Management » : Gestion de la trésorerie, intégrant la gestion des
règlements, des échanges bancaires, des effets ;
CO « Controling » : Contrôle de gestion, intégrant la gestion des prix de revient,
la valorisation des stocks et des flux, le suivi des indicateurs financiers
d’activité ;
AM « Asset Management » : Gestion des actifs, investissements
(immobilisations, amortissements et provisions), de leur maintenance (préventive,
curative), des consommations associées ;
HR « Human Resource » : La planification et gestion des ressources humaines,
intégrant la paie, la gestion des temps, la gestion des compétences, des
formations.
La comparaison de cette liste de « briques applicatives » à des
architectures applicatives existantes sur le marché, comme celle de ERP LN
(anciennement BAAN) ou celle proposée dans l'offre prépackagée de SAP (All In
One) montre que la diversité des architectures du marché représentatives est autant
une diversité d'architecture interne des offres que de positionnement marketing des
éditeurs. L'offre pré-packagée SAP repose justement sur une liste de «building
blocks » (Tableau 5.3 en annexe) qui sont des ensembles de paramétrages et de
données de base couvrant un ensemble de processus standard supportés par l'ERP.
Cette architecture à base de « blocs » de mise en œuvre facilite la
configuration d'un système par assemblage. Un « bloc » n'est pas seulement un
ensemble de composants applicatifs, mais aussi un ensemble d'outils de mise en
œuvre : processus standard décrits et documentés, scripts de paramétrage
correspondants, données de base dont la codification est adaptable. Il s'agit d'un
« bloc » de construction du projet ERP lui-même. Leur définition prend en compte
pour une part des typologies d'activité (sur stock, à la commande...) afin de mieux
adapter les blocs à des contextes métiers particuliers. Cela confirme que la
décomposition des briques applicatives en blocs n'est pas seulement la
décomposition technique issue des structures informatiques des applications, mais
doit être conçue pour faciliter la mise en œuvre de tels « blocs » dans les projets.
Leur structuration peut être rapprochée de la structuration des messages échangés
entre applications. Il s'agit de croiser un point de vue « fonctionnel » sur les
ressources informatiques et un point de vue « informationnel » sur les échanges.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 171
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

C'est ce que permet le standard proposé par les principaux éditeurs d'applications et
l'organisation « Open Application Group » (Rowell 2002).
Cette diversité des référentiels existant rend nécessaire une méthode souple
de normalisation des objets du modèle SCOR permettant d’instancier facilement un
modèle selon une architecture de briques du marché, en quelque sorte de pouvoir
passer d’une version académique du modèle à une version adaptée à un éditeur
(SAP, SSA…). Les définitions peuvent se recouvrir selon les typologies métiers ou
les objectifs. Ainsi, l'ordonnancement se retrouve dans les solutions de type APS,
ERP, MES... Un modèle académique sur les deux premiers niveaux est cependant
possible et conduirait à définir des briques applicatives composées de modules. La
décomposition des modules en fonctions élémentaires pouvant être utilisées dans
des listes d’évaluation de périmètre reste difficile compte tenu de la diversité des
offres à ce niveau détaillé de représentation. Une mise en adéquation d'une
définition académique de fonctionnalités avec les modules des offres du marché
restera toujours nécessaire. Cette liste de briques peut être un support a cette mise
en adéquation des fonctions aux solutions métiers existantes.

3 Processus et briques applicatives

L es briques applicatives identifiées dans la section précédente doivent aider la

construction d'un système d'information en reliant le point de vue applicatif
aux autres points de vue de la modélisation. Pour cela, une étude de leur
contribution aux processus d'entreprise est nécessaire. Notre cadre d'étude de
l'intégration repose sur la formalisation de la connaissance liée à la standardisation
à travers les relations dans un modèle entre ses différents construits. Cette
contribution des briques aux processus est ainsi un élément d'ontologie détaillant la
relation entre les construits « ressources IT » et « Processus » ou « Enterprise
Activity » du méta-modèle. Ces ontologies seront de fait la base de construction
d'un graphe de dépendances détaillé au niveau générique de la modélisation. Les
dépendances au niveau conceptuel de méta-modèle ne donne en effet qu'une
connaissance conceptuelle des dépendances possibles à ce niveau. Elles sont
insuffisantes pour fournir une cartographie détaillée des dépendances au niveau des
différents métiers de l'entreprise. Pour construire une telle connaissance de cette
relation, nous l'étudions à travers deux référentiels contenant une expertise sur cette
contribution des applications aux processus d'entreprise, le modèle SCOR et le
modèle de Lambert (Lambert et Cooper 2000).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 172
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Processus et briques dans le modèle SCOR

C omme nous l'avons vu dans l'état de l'art, SCOR ne propose pas de

modélisation des systèmes d’information support de la chaîne logistique, mais
identifie pour chaque processus des « bonnes pratiques » et des fonctionnalités
associées. Ces fonctionnalités font souvent référence à des noms d’applications de
type progiciel connues (ERP, SCM,…), mais aussi à certaines fonctionnalités
précises de ces applications (inventaire cyclique, contrôle des coûts par activité),
parfois à des pratiques rendues possibles par ces applications (sélection à base de
règles d’un transporteur en expédition), ou encore à des technologies (code à barre,
RFID…).
A partir de ces descriptions de fonctionnalités, nous avons associé a
chaque processus la brique applicative principale supportant ces fonctionnalités
(Millet et Botta-Genoulaz 2006). Ce croisement permet d'illustrer comment le
modèle SCOR « utilise » les briques applicatives. Le Tableau 3.6 montre ainsi en
ligne les briques applicatives identifiées et en colonne les processus de niveau 2 du
modèle SCOR. Le nombre d'occurences de ces briques dans les fonctionnalités
support des processus est représenté en cellule et coloré afin de caractériser
visuellement le niveau de contribution de chaque brique. Les informations n'ont pu
être différenciées entre PLM et PDM et entre SCE et SCEM. Concernant le PLM,
on peut penser que le modèle SCOR est insuffisamment développé sur les
collaborations en conception, et concernant le SCEM que cette brique est encore
mal identifiée en tant que telle. D'autre part, ce travail a été réalisé sur la version 7
de SCOR pour laquelle les processus RETURN n'avaient pas encoré été suffisament
détaillé pour être pris en compte.
N1 P S M D
N2 EP P1 P2 P3 P4 P5 ES S1 S2 S3 EM M1 M2 M3 D1 D2 D3 D4 ED 0
PDM 3 3
BI 1 1 1 1 1 5
APS 4 23 1 1 3 2 4 3 2 1 1 45
SCP 1 7 1 1 1 1 12
CRM 4 1 5
SRM 1 1 6 1 9
ERP 1 9 2 1 9 6 21 8 8 7 22 14 13 11 19 15 9 9 9 193
MES 9 18 23 17 67
SCE 1 1 2 6 10 10 10 5 1 14 13 12 6 21 112
7 45 3 3 12 11 34 18 18 17 43 39 41 30 34 29 21 15 31 451

Tableau 3.6 : Briques applicatives référencées par processus SCOR

On obtient ainsi une représentation standard du système d’information

selon les processus d’un modèle classique de chaîne logistique. Une vue plus

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 173
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

synthétique permet de situer rapidement les principales briques applicatives dans les
4 processus principaux Plan (P), Source (S), Make (M), Deliver (D) présentés en
colonnes dans la matrice résumée du Tableau 3.7.
COTS P S M D
PDM 3 3
BI 2 1 2 5
APS 32 11 2 45
SCP 9 3 12
CRM 4 1 5
SRM 2 6 1 9
ERP 28 44 60 61 193
MES 67 67
SCE 4 36 6 66 112
81 87 153 130 451
Tableau 3.7 : Matrice de synthèse par processus SCOR de niveau 1

On constate que ce modèle est tourné vers le pilotage d’une chaîne

logistique et non sur sa conception ou sur l’activité commerciale qui permet de la
faire vivre. Ainsi la brique CRM ne se retrouve cité que 4 fois pour la planification
de la demande et le support de la saisie de commande en ligne par le client. Ce
tableau permet de mettre en évidence le rôle transversal de l’ERP support de
pratiquement tous les processus SCOR. De même, il souligne la vocation de
certaines briques à supporter précisément certains processus, comme les MES
tournés vers les processus de production. On constate cependant que la partition des
processus ne recouvre pas celle des briques applicatives montrant ainsi l’enjeu de
l’intégration des systèmes d’information support des processus logistiques. L'étude
confirme la pertinence de la classification en niveau opérationnel, de pilotage et de
décision, différenciant les briques « transversales » qui sont en fait centrées sur
l’entreprise (ERP) et les briques opérationnelles assurant les fonctions d’exécution
qui sont proches d’un processus opérationnel. Ainsi le MES est centré sur la
production (Make) et en détaillant la brique SCE, on trouve les WMS et TMS
centrés sur l’expédition (Deliver), et la brique purement SCE restante est le plus
souvent orientée vers l’approvisionnement (Source).
Le référentiel SCOR représente ainsi une formalisation des connaissances
permettant d'identifier quelles briques applicatives peuvent contribuer aux différents
processus d'entreprises. Une telle connaissance formalisée sous forme d'ontologie
exploitable dans un cadre de modélisation d'entreprise peut jour un rôle essentiel.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 174
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Processus et Fonctions dans la matrice de Lambert

C e travail réalisé sur un référentiel métier centré sur la logistique doit être
élargi à une mise en correspondance plus systématique entre les fonctions
décrivant une organisation et les processus décrivant ses modes de réponses aux
relations avec ses clients et partenaires dans la chaîne logistique. Lambert propose
une telle classification sous forme d’un croisement des processus d’affaires aux
fonctions de l'entreprise (Lambert et Cooper 2000). Si le modèle SCOR est destiné à
la construction d’indicateurs de performance dans une chaîne logistique, le modèle
de Lambert est destiné à étudier la chaîne logistique comme intégration transverse
dans l’entreprise afin de la différencier de la fonction logistique dans l’entreprise.
Cela conduit à identifier les relations entre trois dimensions caractérisant le pilotage
de la chaîne logistique : les processus d'affaires, les fonctions nécessaires au
système de management et la structure de la chaîne elle-même.

L es processus utilisés sont les suivants :

Customer Relationship Management (Gestion de la relation client)
Customer Service Management (Gestion des services au client)
Demand Management (Gestion de la demande)
Fullfilment (Réalisation des ventes)
Manufacturing Flow Management (Gestion des flux de production)
Supplier Relationship Management (Gestion de la relation fournisseur)
Product Development and commercialization (Développement et
commercialisation produit)
Returns (Gestion des retours)
Contrairement au modèle SCOR, cette approche des processus d’affaires
met l’accent sur les relations collaboratives dans la chaîne logistique plutôt que sur
les processus internes à l’entreprise. Elle éclaire le rôle des fonctions analysées
comme des silos dans l’organisation : « Marketing », « Research & Development »,
« Logistics », « Production », « Purchase », « Finance & Accounting ». Le modèle
proposé permet ainsi de répondre à trois questions sur l'intégration de la chaîne
logistique :
Quels sont les acteurs qui doivent être reliés dans la chaîne logistique ?
Quels processus doivent être reliés entre ces différents acteurs ?
Quel niveau d'intégration et de pilotage est nécessaire pour ces processus ?
L’apport de chaque processus aux fonctions est analysé en termes
d’activité contribuant à la création de valeur pour le processus. Cette approche met
en valeur fortement le caractère transverse des processus identifiés et permet de
repérer des activités connexes au cœur des fonctions et qui contribuent pourtant
significativement au support de la performance, comme l’illustre la Figure 3.8 sous

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 175
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

forme d'une matrice processus/fonctions. Le processus de gestion de la relation

client s’appuie sur la gestion des clients (fonction marketing), la définition des
besoins produits (fonction recherche & développement), la définition des besoins
logistiques (fonction logistique), la stratégie industrielle (fonction production), la
stratégie d’approvisionnement (fonction achat), la profitabilité des clients (fonction
finance).
Fonction Sales & Research & Logistics Production Purchase Finance &
Processus……. Marketing Development Accounting
Customer Relationship Account Requirements Requirements Manufacturing Sourcing Customer
Management Management Definition Definition Strategy Strategy Profitability
Customer Service Account Technical Performances Coordinated Priority Cost To
Management Administration Services Specifications execution Assesment Serve
Demand Management Demand Process Capability TradeOff
Planning Requirments Forecasting Planning Sourcing analysis
Fullfilment Environnemental Network Selected Distribution
Special Orders Requirments Planning Plant Direct Suppliers Costs
Manufacturing Flow Packaging Priorization Production Integrated Manufacturin
Management Specifications Process Stability Criteria Planning Supply g Costs
Supplier Relationship Order Material Inbound Integrated Supplier
Management Booking Specifications Flow Planning Management Material Costs
Product Development Movement Process Material
and comercialisation Business Plan Product Design Requirments Specifications Specifications R&D Costs
Returns Product Life Return Re Material Revenue &
Cycle Product Design Logistics manufacturing Specifications Costs
Information Architecture, Database Strategy, Information Visibility

Figure [Link] de Lambert : croisement processus / fonctions

Nous avons placé dans cette matrice les briques applicatives proposées
précédemment pour obtenir une « cartographie » des briques applicatives selon la
matrice de Lambert (Figure 3.9). Ces cartographies représentent à la fois
l'alignement des briques aux processus et fonctions d'entreprise et précisent ainsi en
retour la définition de ces briques. Nous proposons dans ce mémoire celles
concernant l'ERP et les applications SCM.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 176
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Fonction Sales & Marketing Research & Logistics Production Purchase Finance &
Processus……. Development Accounting
Customer Relationship Account Requirements Requirements Manufacturing Customer
Management Management Definition Definition Strategy Sourcing Strategy Profitability
Customer Service Account Performances Coordinated
Management Administration Technical Services Specifications execution Priority Assesment Cost To Serve
Demand Management Process Capability
Demand Planning Requirments Forecasting Planning Sourcing TradeOff analysis
Fullfilment Environnemental
Special Orders Requirments Network Planning Plant Direct Selected Suppliers Distribution Costs
Manufacturing Flow Packaging Priorization Production Manufacturing
Management Specifications Process Stability Criteria Planning Integrated Supply Costs
Supplier Relationship Material Integrated Supplier
Management Order Booking Specifications Inbound Flow Planning Management Material Costs
Product Development Movement Process Material
and comercialisation Business Plan Product Design Requirments Specifications Specifications R&D Costs
Returns Material
Product Life Cycle Product Design Return Logistics Re manufacturing Specifications Revenue & Costs
Information Architecture, Database Strategy, Information Visibility

Figure 3.9. Positionnement des ERP dans la matrice de Lambert

La cartographie est représentée par un marquage coloré de la matrice selon

l’apport (partiel ou complet) de la brique étudiée à l’activité repérée dans le
croisement processus/fonction.
Ainsi l’ERP est un support complet de la coordination des activités de
réalisation des ventes (apport de la fonction production au processus Customer
Service Management), et un support partiel de la planification de la demande
(apport de la fonction Marketing au processus de gestion de la demande). Ces
cartographies confirment le caractère transverse de l’ERP qui couvrent une grande
partie de la matrice, du caractère transverse centré sur la logistique des solutions
SCM (Figure 3.10), et du caractère ciblé des solutions CRM qui ne contribuent qu’à
trois activités sur les 48 définies, les solutions MES étant quant à elles centrées sur
4 autres activités.
Pour obtenir une approche plus détaillée, il est nécessaire de s’appuyer sur
une définition générique des processus d’affaires, des fonctions d’entreprises et des
fonctionnalités détaillées des briques applicatives. Les processus logistiques et les
organisations font l’objet de modèles existants (SCOR par exemple) qui peuvent
être utilisés comme référentiel. Un approfondissement du référentiel de briques
applicatives est donc nécessaire. Il faut noter de plus que ces matrices de
positionnement des briques applicatives sont établies à partir des définitions
construites sur les fonctions existantes des différentes briques. On sait cependant
qu’il existe une différence parfois notable entre les fonctions existantes et les

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 177
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

fonctions utilisées selon les typologies d’entreprise, les niveaux d’informatisation et

les types d’intégration organisationnelles et informationnelles dans les entreprises.

Fonction Sales & Research & Logistics Production Purchase Finance &
Processus……. Marketing Development Accounting
Customer Relationship
Management Account Requirements Requirements Manufacturing Sourcing Customer
Management Definition Definition Strategy Strategy Profitability
Customer Service
Management Account Technical Performances Coordinated Priority Cost To
Administration Services Specifications execution Assesment Serve
Demand Management Demand Process Capability TradeOff
Planning Requirments Forecasting Planning Sourcing analysis
Fullfilment Environnemental Network Selected Distribution
Special Orders Requirments Planning Plant Direct Suppliers Costs
Manufacturing Flow Packaging Priorization Production Integrated Manufacturin
Management Specifications Process Stability Criteria Planning Supply g Costs
Supplier Relationship Order Material Inbound Integrated Supplier
Management Booking Specifications Flow Planning Management Material Costs
Product Development
and comercialisation Movement Process Material
Business Plan Product Design Requirments Specifications Specifications R&D Costs

Figure 3.10. positionnement des briques SCM dans la matrice de Lambert

C'est l'enjeu de la prise en compte de la maturité des organisations dans

l'identification des usages des systèmes qui conditionnent la réalité des dépendances
potentielles entre processsus et applications.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 178
 Démarche d'ingénierie orientée intégration / Cadre et méta-modèle de l'intégration

Nous proposons une interprétation du cadre de modélisation ISO

19439 orientée vers une ingénierie de systèmes d'information à base
de progiciels du marché dans laquelle nous définissons un méta-
modèle orienté vers l'étude de l'intégration organisationnelle et
informationnelle. Ce méta-modèle est issu d'une confrontation entre la
norme ISO 19440, le modèle de référence SCOR et un méta-modèle
ERP issu de nos précédents travaux.

L'étude de référentiels métiers, de la connaissance qu'ils contiennent

sur les concepts et leurs relations illustre la nécessité de compléter le
méta-modèle d'entreprise qui représente un point de vue
« architectural » du système d'entreprise par des ontologies
définissant les connaissances utilisées et les dépendances possibles
entre-elles et portant ainsi une définition par « extension » du
système. Nous avons proposé une liste de « briques applicatives » qui
peut être la base d'une ontologie détaillant le construit « IT resource »
de notre méta-modèle et une classification des informations issues du
référentiel SCOR qui est une étape vers une ontologie détaillant le
construit « Object View » de ce méta-modèle. Dans cette approche, on
retrouve la pertinence des « points de vue » de modélisation portés
par la norme 19439 et que des référentiels métiers peuvent
concrétiser :

Le point de vue informationnel qui modélise les données, informations

qui circulent dans une organisation inter ou intra entreprise ;

Le point de vue fonctionnel qui décrit les processus et activités en les

reliant aux ressources mises en œuvre ;

Le point de vue organisationnel qui décrit les entités, les acteurs et

leurs pratiques ;

Le point de vue des ressources qui permet notamment de décrire les

applications support des activités informatisées.

La construction de référentiels métiers permettant d'enrichir le cadre

de modélisation au niveau générique pour les différents construits est
un enjeu de leur mise en cohérence, de leur utilisabilité dans des
modèles d'entreprise et dans des projets d'ingénierie.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.1
Institut National des Sciences Appliquées de Lyon 179
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Chapitre 3.2
Graphe d'intégration du
modèle d'entreprise

Comme nous l'avons vu dans le chapitre 3.1, l'intégration peut être

caractérisée par la notion de dépendances entre objets, acteurs,
processus. L'identification et la caractérisation de ces dépendances est
un enjeu de la modélisation d'entreprise pour supporter les stratégies
organisationnelles.

Nous présentons dans la première section le graphe d'intégration que

représente l'ensemble des dépendances et sa pertinence pour étudier
tous les aspects d'un projet : informationnels, organisationnels,
techniques. Nous proposons ensuite la notion de « sous-graphe
d'intégration » pour étudier les dépendances directes et indirectes d'un
construit et leur pertinence par rapport à des problématiques connues
des projets de type ERP.

Nous définissons ensuite une « distance » entre construits dans le

graphe qui nous permet de proposer des « partitions » dans le graphe.
Nous définissons de même un « couplage » qui nous permet de
proposer des « voisinages » dans le graphe. Partitions et voisinages
sont deux outils d'analyse du graphe.

Nous étudions la complexité des algorithmes nécessaires aux calculs

des distances et couplages.

Nous étudions enfin comment prendre en compte la nature technique

ou organisationnelle des dépendances de même que la maturité des
usages et leur influence sur le graphe.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 181
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

3.2.1 Graphe des dépendances

N ous étudions les dépendances issues du méta-modèle en nous inspirant des

études de dépendances identifiées dans l'état de l'art. La classification de
Chapron (2006) repose sur la nature de l'objet créant la dépendance entre
processus : acteurs, ressources ou informations. Dans le même esprit, la
classification des modes de collaboration de Simatupang (2002) repose sur l'objet
focus : produits et services, information, connaissances et capacités, bénéfices et
risques. Winter (2003) compare les dépendances entre processus et données et entre
fonctions et centres de profits. Dans le modèle ERP évoqué précédemment, nous
prenons en compte les dépendances entre objets informatiques et les dépendances
entre processus et transactions de l'application. Les dépendances sont donc diverses
et peuvent être identifiées entre plusieurs catégories d'objets.
Nous étudions de manière systématique l'existence de dépendances
potentielles entre chaque couple de construits de notre méta-modèle. Une
dépendance doit pouvoir être caractérisée par ses conséquences opérationnelles, et
notamment dans notre problématique par son importance dans l'efficience des
projets et des usages d'ERP. Elle doit alors être représentée comme une relation
dans le méta-modèle utilisé. Si deux processus sont dépendants parce qu'ils utilisent
une même ressource, ou influent sur la même information, nous devons avoir dans
le modèle une relation processus-ressource ou processus-information. A l'inverse, si
notre méta-modèle propose une relation entre les construits process et évènements,
c'est qu'une dépendance existe entre un processus déclencheur d'un événement et cet
événement, et réciproquement dans ce cas. On peut identifier plusieurs natures de
dépendance, fortement liées aux points de vue de la modélisation :
Des dépendances « fonctionnelles » liant les construits décrivant le
fonctionnement de l'entreprise et ses ressources. Le construit « Enterprise
Activity » porte la relation essentielle de ce point de vue.
Des dépendances « organisationnelles » fortement transverses au reste du modèle
et liant les construits organisationnels aux autres représentations par la relation
« controls » sur tous les construits.
Des dépendances « informationnelles » liant les construits informationnels entre
eux et avec les ressources qui sont représentées dans le point de vue
informationnel. C'est dans ce cas le construit « object view » qui porte la relation
entre information et ressources.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 182
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

C'est d'ailleurs la représentation courante des construits 19440 sous forme

d'une carte répartissant les objets selon les points de vue que nous reprenons dans la
Figure 3.5 du méta-modèle d'intégration. Cette analyse est confortée par la
comparaison avec la classification des dépendances de processus proposée par
Chapron (2006) pour qui les dépendances de processus peuvent être de type
« acteurs », « informations » et « ressources ». Elle rejoint ainsi les trois types de
relations possible entre le point de vue fonctionnel que portent les processus et les
autres points de vue, ce qui se représente facilement dans notre méta-modèle
d'intégration. La Figure 3.11 présente ce méta-modèle en surlignant les différentes
dépendances possibles dont celles identifiées par Chapron (en jaune) autour des
processus en relation avec les autres points de vue. Elle permet aussi d'identifier les

Figure 3.11: Classification des dépendances de processus de Chapron et 19440

autres dépendances internes à un point de vue ou reliant les points de vue en

illustrant la richesse du modèle pour étudier les diverses sources d'alignement. Les
dépendances qui portent une hiérarchisation du modèle sont surlignées en rouge et
les autres en bleu.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 183
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Les relations d'agrégation permettent de considérer une structure

hiérarchique permettant d'analyser les dépendances à divers niveaux de granularité
de la modélisation. Ce ne sont pas des dépendances porteuses de contraintes pour
l'ingénierie d'entreprise mais permettant de passer d'un point de vue macro à un
point de vue détaillé ou l'inverse. Ces relations d'agrégation permettent de
différencier les dépendances au niveau d'instances du modèle et leur agrégation a un
niveau d'abstraction plus élevé. On pourrait ainsi représenter entre un business
process et une unité organisationnelle, l'ensemble des dépendances entre les sous-
business process et les sous-unités organisationnelles. On peut alors utiliser un
graphe hiérarchisé proche de la proposition de Eades, évoquée dans l'état de l'art
(2000), associant à un graphe, un arbre de hiérarchisation prédéfini à partir de
partitionnement connu du graphe. La Figure 3.12 présente les relations d'agrégation
du méta-modèle. Pour notre travail, nous considérerons ces relations d'agrégation
comme complémentaires aux autres dépendances. Elles concernent des ressources
regroupées en entité fonctionnelle, des unités organisationnelles regroupées en

Figure 3.12. Hiérarchisation du modèle d'intégration

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 184
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

cellule/ilot, des objets d'entreprises décomposés en sous-objets, des processus

décomposés en sous-processus, des aptitudes décomposées en aptitudes, des
ressources IT regroupées en applications (package).

L es dépendances peuvent aussi être étudiées à partir de la classification des

dépendances de coordination de Malone et Crowstown (1991) qui caractérise
les dépendances entre buts, activités et acteurs en quatre classes :
Dépendances de ressources (« Shared ressources »). Cette dépendance concerne
la relation fonctions/ressources et nécessite un processus d'allocation qui doit
avoir un responsable. Elle est couverte dans le modèle 19440 par une dépendance
indirecte entre activité (EA) à travers la relation avec les ressources (RE) du type
EA1 → RE 1 et EA 2 → RE1.
Dépendance séquentielle « Producer/consumer » : pour des échanges physiques
mais aussi informationnels. On retrouve notamment la question des connaissances
produites par une entité et utilisées par une autre. Cette dépendance est couverte
dans le modèle 19440 par la relation input/output au niveau activité ou processus
et qui peut porter sur tout objet d'entreprise ou sur des évènements (EA → EO →
EA).
Dépendance temporelle « Simultaneity constraints » : Ce type de contrainte
temporelle est couverte dans le modèle 19440 par les relations Input/Output des
évènements. (Ev → EA) ou (EA → Ev) sous forme d'une dépendance indirecte
EA1 → Ev et EA2 → Ev.
Dépendance d'objectif « Task / subtask » : ce type de dépendance nécessité
l'identification du but commun à un ensemble de tâches qui n'implique pas de
contraintes directes en termes de ressources ou d'évènements, mais suppose un
processus d'affectation des tâches garantissant leur cohérence. Cette dépendance
est couverte dans le modèle par la relation objectifs (Ob) /activité (EA) etune
dépendance indirecte EA1 → Ob 1, EA2 → Ob 2.
Ces dépendances étudiées par Malone pour répondre aux besoins de
coordination confirment la nécessité de prendre en compte les chaînes de
dépendances entre construits, que nous aborderons dans la suite de ce chapitre. Le
méta-modèle permet ainsi de repérer les dépendances étudiées par Chapron et
Malone, et d'autres dépendances potentielles. La Figure 3.13 les présente en les
identifiant par le construit source et destination des relations.

Nous pouvons donc considérer les dépendances suivantes en complément

de celles étudiées par Chapron et Malone :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 185
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Ev-Ov : Dépendance entre les évènements de la vue fonctionnelle et les vues

d'objet de la vue informationnelle. Elle est un des critères de l'alignement entre

Figure 3.13: Dépendances identifiées et potentielles du méta-modèle

les vues informationnelle et fonctionnelle.

OV-Da : Dépendance entre les vues d'objet de la vue informationnelle et les
données gérées dans le S.I. Elle est un des critères de l'alignement entre la vue
informationnelle et le système informatique.
Me-Ob : Dépendance entre les Objectifs de la vue organisationnelle et les
indicateurs définis dans la vue informationnelle. Elle est un des critères
d'alignement entre une vue décisionnelle et la vue informationnelle.
RIT-RIT : Dépendances techniques entre les objets informatiques, dont les
relations d'intégrité entre données, de cas d'emploi de programme ou données,
d'enchaînement entre transactions. Elle sera une contrainte importante pour tenir
compte dans le modèle d'intégration des différentes dépendances techniques
imposées ou permises par le système informatique.
RIT-Fea : Dépendance entre les vues informatique et fonctionnelle qui identifie la
contribution potentielle des ressources informatiques aux « fonctionnalités » ou
« services » attendus par les acteurs de l'entreprise et nécessaires à la définition

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 186
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

de la vue fonctionnelle. Elle est un des outils de l'alignement entre la vue

fonctionnelle du modèle et le système informatique.
M-OU : Dépendance entre les unités organisationnelles portant notamment les
rôles de l'entreprise avec l'ensemble des objets du modèle (pour l'ensemble des
vues). Cette affectation d'un « responsable » organisationnel à tout objet est une
dépendance essentielle à la structuration d'une action ou d'un projet d'ingénierie.
Elle porte l'alignement entre l'organisation et les autres points de vue. Cette
notion de responsabilité est essentielle aux construits qui portent l'alignement du
point de vue informationnel (EO, Da, Re, BP, EA, Ob).
Ca-Re : Dépendance entre les aptitudes utilisées pour caractériser d'un point de
vue organisationnel les besoins des processus et activités avec l'affectation de
ressources à ces mêmes processus et activités. Cette dépendance porte
directement la coéhérence entre organisation (gestion des capacités) et processus
du point de vue des ressources.
Ca-Fe : Dépendance entre les éléments d'aptitudes et les entités fonctionnelles
aggrégeant des ressources. Cette dépendance permet d'identifier les besoins de
compétences des ressources. Elle concerne l'alignement entre ressources et
aptitudes nécessaires de l'organisation.
PR-Ob : Dépendances entre les pratiques standard définies pour construire les
processus et les objectifs de l'entreprise. Cette dépendance est définie au niveau
générique et représente un élément de « bonne pratique ». Elle porte sur la
cohérence des bonnes pratiques et de leurs efficacité en regard des objectifs
qu'elles se proposent d'atteindre. Elle concerne donc l'alignement entre une vue
organisationnelle et une vue décisionnelle.
Compte tenu de la diversité des dépendances identifiées à ce niveau
générique et de la nécessité de les étudier plus précisément dans leurs instanciations
possibles selon les référentiels utilisés, nous approfondirons la suite de nos travaux
sur un méta-modèle simplifié limité aux dépendances qui interviennent dans
l'alignement entre système informatique, système d'information et organisation, qui
portent la cohérence entre intégration informationnelle et organisationnelle ( Figure
3.14).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 187
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Figure 3.14. Dépendances prises en compte pour l'alignement du S.I.

Nous considérons les dépendances internes à la vue organisationnelle entre

aptitude et rôles comme relevant du management. L'alignement entre ces construits
n'est pas une problématique d'alignement entre points de vue mais un objectif
propre du point de vue organisationnel.
De plus, nous ne considérons pas les relations d'agrégation comme un
élément de dépendance mais un enjeu opérationnel pour construire des vues
synthétiques d'un problème d'alignement et d'assurer la cohérence entre vue
« macro » et vue détaillée. De telles vues agrégées ne peuvent être construite qu'une
fois la problématique de l'alignement formalisée à un niveau de granularité donné.
Le traitement de graphe de dépendances hiérarchisé ne peut être étudié sans avoir
proposé une représentation de graphe mononiveau. De même, nous ne considérerons
pas des processus hiérarchisé, bien que la pratique de modélisation conduise le plus
souvent à considérer des « macro-processus » et des processus détaillé. Cette
facilité de modélisation est elle-même un outil de l'analyse descendante, et de la
cohérence des vues agrégées et détaillées. Nous considérons donc que les
dépendances peuvent être définies au niveau le plus détaillé, et que l'agrégation
permettra de reconstruire ces dépendances d'un point de vue macro. Cela nous

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 188
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

conduit à ne pas considérer les relations d'agrégation entre « Business Process » et

de spécialisation d'une « Enterprise Activity » en « Business Process ».
Par contre, les relations entre « Data », « Logic » et « Ressource IT » qui
représentent la structuration technique interne des applications ne peuvent être
considérées comme les relations d'agrégation précédente. Nous les conservons dans
le modèle car elles portent potentiellement les contraintes d'intégrité ou de
workflow des progiciels.
Il reste une dépendance particulière qui relie le même construit et n'est pas
une agrégation, la relation entre « Enterprise Objects ». Elle représente de
nombreuses relations qui traduisent la cohérence de la vue informationnelle et qui
permet aux acteurs la « navigation » dans cette vue informationnelle. Une
commande client peut par exemple être liée à un devis, puis à une facture. Un
produit est lié à ses composants, une opération de gamme à la ressource qu'elle
utilise. L'ensemble de ces relations représente dans la vue informationnelle des
relations entre les données dans le construit « Data ». Ainsi, dans notre méta-modèle
simplifié pour l'étude des dépendances, celles-ci peuvent être considérées de même
« niveau » de modélisation, avec la même granularité de construits.
Le méta-modèle partiel ainsi défini sera celui que nous utiliserons dans
l'étude du graphe d'intégration dans la suite de ce chapitre. Il nous faut toutefois
dans un premier temps identifier la notion de « chaines de dépendances » qui tient
compte de la transitivité des dépendances.

3.2.2 Sous-graphes d'intégration

L es dépendances issues du méta-modèle peuvent être considérées comme

« structurelles » en ce qu'elles existent dans tout modèle d'entreprise. Mais
elles induisent de fait d'autres dépendances indirectement, parce que des
dépendances successives créent des dépendances entre des construits qui ne sont pas
liés par une relation, et parce que deux construits étant dépendants du même tiers
deviennent de fait dépendant. C'est pourquoi nous allons étudier les « chaînes de
dépendances » et les dépendances « indirectes » de notre méta-modèle afin de
caractériser le « graphe d'intégration ».
Les dépendances peuvent donc être déduites des relations du méta-modèle
par une « chaîne » du graphe de dépendance. Une dépendance entre un processus
BP et un objectif Ob, lui même dépendant d'un indicateur Me, lui même associé à
une ressource Re constitue une « chaîne de dépendances » qui au final représente
une dépendance entre le processus BP et la ressource Re. Cette transitivité des
dépendances correspond à l'expérience de l'intégration comme contrainte pour les

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 189
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

acteurs d'un projet ERP. Un exemple représentatif est celui des conflits possibles
dans l'usage par différents acteurs d'un projet d'une même donnée à codifier et à
gérer dans le système d'information. C'est le cas des données de base du système,
données organisationnelles, de classification, de valorisation... qui peuvent être
utilisées par de nombreuses fonctions du système et donc par de nombreux acteurs
différents. Les règles de gestion d'une telle donnée « multi-usage » doivent être
validées par ces acteurs d'une manière cohérente. Une telle dépendance est tout à
fait représentative de l'impact de l'intégration informationnelle sur les dépendances
organisationnelles.
Nous considérons donc l'ensemble des construits (C) et de leur relation (R)
comme un graphe des dépendances D(C,R) dans lequel les construits sont les nœuds
et les relations des arcs. Nous l'appellerons le « graphe d'intégration » du modèle.
Les relations sont « orientées » à l'exception de l'association entre « Enterprise
Objects » qui peut cependant être considérée comme orientée avec un objet source
de la relation comme pour une relation « composée de » qui correspondra à une
relation inverse « est composée de ». Cependant, une relation « orientée »
représente une dépendance aussi bien dans le sens « orienté » que dans le sens
inverse. Nous pouvons donc considérer le graphe de dépendances comme un graphe
non orienté ou considérer le graphe orienté dans le sens des relations et le graphe
inverse. Nous verrons que l'existence structurelle de cycles dans le graphe orienté
nous conduit à privilégier le graphe non orienté.
Les caractéristiques du graphe non orienté sont représentatives de la
complexité de l'intégration. La diamètre, défini comme le plus long des plus court
chemins entre deux sommets est représentatf du couplage global du modèle. Le
degré du graphe, défini comme le plus grand degré de ces sommets, permet
d'identifier l'homogénéité de l'intégration ou au contraire l'existence de points
particulièrement structurant.
Le graphe de dépendances peut être étudié au niveau conceptuel à partir
des relations possibles entre construits de notre méta-modèle. Mais il prend une
autre dimension comme graphe de dépendance des instances d'un modèle
d'entreprise donné. Nous considérons cependant que l'étude du graphe conceptuel
est une première étape pour permettre l'étude opérationnelle d'un graphe réel. En
effet, un cycle au niveau des instances correspond nécessairement à un cycle au
niveau conceptuel. De même, on peut noter qu'un tel graphe ne sera pas planaire. Le
théorème d'Euler qui relie le nombre de sommets, d'arêtes et de faces d'un graphe
définit un nombre d'arêtes maximum pour un graphe planaire. Si n est le nombre de
sommets, a, le nombre d'arêtes alors si (3 x n – 6 > a), les graphes que nous avons
étudié ne sont jamais planaires. On peut vérifier que c'est le cas pour notre graphe
au niveau du méta-modèle. Cette caractéristique vient confirmer la nécessité des

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 190
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

points de vue de modélisation qui permettent de donner des vues partielles plus
facilement représentable.
Dans la suite, nous désignons par C,D,E... un construit quelconque quand
il n'est pas nécessaire d'utiliser la codification du méta-modèle pour évoquer un
construit particulier. Nous notons d'autres part C i une instance quelconque du
construit C (BP i une instance de « Business Process », autrement dit un Business
Process particulier).
L'exemple déjà cité des dépendances aux données de base conduit à
s'intéresser aux « chaînes » reliant le construit « Organizational Unit » au construit
« Data ». Une chaîne entre ces deux construits peut suivre les dépendances Da→OV,
qui relient données de la base de donnée et vue d'objet, puis OV→EA, qui identifie
les activités concernés, puis EA→BP qui trouve les processus impliqués et enfin
BP→OU pour rejoindre le « rôle » organisationnel concerné. Une telle chaîne
repose principalement sur la vue « fonctionnelle » comme lien entre la vue
organisationnelle et informationnelle. Mais il existe d'autres chaînes possibles, par
exemple en utilisant le construit « Event » qui analyse la même dépendance à partir
de la dynamique de la vue fonctionnelle. Elle peut aussi être étudiée à partir du lien
de support des ressources aux activités d'entreprise en identifiant les « Ressources
IT » concernées, y compris en tenant compte des contraintes informatiques (Data-
Logic-Ressource IT) puis la relation RIT→EA, et enfin EA→OU. Cette dépendance
apporte une vue plus opérationnelle utilisant le construit définissant les activités
comme support de la dépendance entre les données et les rôles. La Figure 3.15
présente les différentes chaînes entre ces deux construits.
Cependant, il s'agit des chemins « utiles », car de nombreux chemins plus
long existent. En considérant le graphe non orienté et tenant compte que le graphe
est connexe, on peut joindre tout sommet en parcourant tout le graphe. Il nous faut
donc caractériser les chemins « utiles » et tenir compte des « cycles » possibles du
graphe orienté.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 191
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Figure 3.15. les chaînes de dépendances entre Data et Organizational Unit

Pour étudier les cycles, nous prenons la matrice d'adjacences du graphe.

Pour un graphe D(C,R), cette matrice est la matrice M i,j ou i et j sont des sommets
du graphe et Mi,j = 1 si une arête existe entre i et j. Cette matrice permet en étudiant
ses puissances de connaître le nombre de chaînes possibles entre deux sommets du
graphe. Plus précisément, pour une matrice d'adjacence M(D) du graphe D(C,R), si
on note M ni,j la position de ligne i et de colonne j de la matrice M à la puissance n,
Mni,j est le nombre de chemins de longueur n reliant les sommets i et j. Pour un
graphe orienté sans cycle de longueur n, la matrice d'adjacence à la puissance n a
une diagonale nulle (Mni,i =0, pour tout i, n). La matrice du graphe orienté
conceptuel de la Figure 3.14 est présentée dans le Tableau 3.8 avec en ligne et
colonne les construits du méta-modèle d'intégration.
La coloration permet de noter des caractéristiques particulières :
La colonne (resp ligne) « somme » contient le nombre de sommet aval (resp
amont). Le total est le degré d'un sommet. Ainsi, le construit OV a 4 dépendances
dont il est l'origine et 5 dont il est destination, son degré en tant que sommet du
graphe est de 9.
Une relation réflexive sur un seul construit est notée en rouge. Elle représente un
cycle structurel de l'intégration. Les cellules des relations hiérarchiques qui ne
sont pas prises en en compte dans le modèle simplifié sont surlignées en orange.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 192
Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Les autres cycles directs correspondent à des symétries et sont notées en bleu
clair. Ils reposent principalement sur les relations des construits « Event » et
« Object View » qui relève d'une logique temporelle. Un événement déclenche
une activité qui génère un autre événement. Un objet est consommé par une
activité qui en produit un autre. Ces cycles n'existent pas au niveau opérationnel
où les activités sont alors successives. La dépendance au niveau opérationnel
intervient bien de manière chronologique comme toutes les activités humaines.
D'autres cycles que ceux portés par les dépendances temporelles existent, liés
notamment aux relations réflexives de la vue informationnelle sur les construits
« Enterprise Object », « Data » et « Logic » . Ils sont aussi liés aux construits
issus du rapprochement avec le modèle SCOR, rapprochement qui porte
justement une intégration plus forte et complémentaire au méta-modèle 19440.
Enfin, certains construits n'interviennent pas dans l'existence de cycles car ils ne
portent que des relations entrantes ou sortantes. Ils sont pour toute chaîne un
début ou une fin. Dans un graphe, ils constituent des sources, notées en vert dans
Ent. Activity
Bus. Process

Object View

ITResource
Ent. Object
Capability
Ressource

Objective
Org. Unit

Interface
Pratices
Product

Somme
Metrics
Feature
Event

Logic
Order

Data
Event 1 1 1 3
Bus. Process 1 1 1 1 1 5
Ent. Activity 1 1 1 1 4
Ressource 1 1 1 3
Capability P
Ent. Object 1 1
Object View 1 1 1 1 4
Product 1 1
Order 1 1
Org. Unit 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17
Objective 1 1
Metrics 1 1
Feature 1 1
Pratices 1 1 2 4
Data 1 1 1 3
ITResource 1 1
Logic 1 1 2
Interface 1 1 2
Somme 3 3 5 2 4 5 5 1 1S 4 4 1 2 4 6 3 1
Degré 6 8 9 5 4 6 9 2 2 17 5 5 2 6 7 7 5 3 17

Tableau 3.8: Matrice d'adjacence du graphe de dépendances

le tableau (Organizational Unit) et des puits notés en bleu dans le tableau

(Capability, Objective).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 193
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Ces caractéristiques du graphe du méta-modèle ne permettent pas

d'identifier toutes celles d'un graphe au niveau des instances d'un modèle particulier.
L'existence de cycles au niveau du méta-modèle n'implique pas nécessairement leur
existence au niveau du modèle d'entreprise. Mais c'est le cas par exemple du cycle
« BP i→Prj→Obk →BPi ». En effet, dans un modèle cohérent, les pratiques
conseillées d'un processus sont efficaces pour des objectifs auxquels le processus
doit contribuer. Le cycle apparent au niveau conceptuel sera bien traduit par des
cycles au niveau instancié. De nombreux cycles sont ainsi dus à la cohérence
nécessaire de l'intégration entre les différents points de vue. Par exemple, deux
activités liées par un événement utilisent des ressources informatiques qui
s'appuient souvent sur la même application qui transforme l'objet informationnel
dont le changement de statut traduit l'évènement. Les transactions applicatives
correspondantes aux deux activités sont le plus souvent dépendantes par les données
communes qu'elles manipulent. Ainsi la structure en parallèle « EAi →Evj→EAj »
au niveau fonctionnel et «ITR k→Da l→ITR m » au niveau informatique crée
naturellement un cycle puisque les ressources informatiques supportent les activités.
On a une chaîne «ITRm→EAi →Evj→EAi →ITRk →Dal →ITRm ».
C'est pourquoi l'utilisation de graphe orienté ne produit pas aisément une
mesure de l'intégration. Plutôt qu'une approche cherchant à mesurer un « flux »
d'intégration dans un graphe orienté, nous chercherons donc plutôt une « structure »
liée aux chaînes possibles dans le graphe en cherchant à identifier des sous-graphes
particuliers pertinents pour l'étude de l'intégration en tenant compte des
problématiques ERP connues. La dimension de ces sous-graphes ne pouvant être
borné à priori, il faut pouvoir les « limiter » de manière réaliste en considérant que
la contrainte d'intégration ne se propage pas indéfiniment. Nous proposons de
considérer que la dépendance « s'affaiblit » par transitivité. Cela correspond à une
réalité par exemple dans une relation « client-fournisseur ». S'il est vrai qu'un acteur
est dépendant de son fournisseur, donc du fournisseur de son fournisseur, le but de
toute organisation est de gérer les conséquences d'un aléa. Plus cet aléa est « loin »
dans la chaîne logistique, plus son impact sera déjà pris en compte par les acteurs
intermédiaires. De même, il est clair qu'un paramètre de stock d'un composant de
bas niveau est une donnée qui pèse indirectement sur l'activité de vente d'un produit
fini, dans la mesure ou ce paramètre influe sur la disponibilité du composant qui
peut être un critère de disponibilité du produit fini. Cependant, si plusieurs étapes
de production sont nécessaires, l'impact sera naturellement limité par les stocks
intermédiaires, marges, délais. Traduit dans le graphe de dépendances de notre
modèle, il est clair que le chemin de dépendances qui mène du paramètre de stock
du composant au processus de vente d'un produit fini est d'autant plus long que la

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 194
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

structure technique du produit produira de nombreux intermédiaires entre le

composant et le produit fini.
Nous appelons « sous-graphe d'intégration de longueur n » des instances
de construits C i et D j l'ensemble des chaînes existantes de longueur inférieure à n
entre ces deux instances, et nous le noterons GIn(C i,Dj). Nous utilisons aussi des
sous-graphes liant une instance C i et l'ensemble des instances d'un construit D et
nous le noterons GI(Ci →D). Dans l'exemple des relations entre données et rôles
organisationnels, le sous-graphe GI(DAi →OU) liste l'ensemble des rôles
organisationnels concernés par une même donnée du système.
La longueur maximum d'un sous-graphe d'intégration devient un paramètre
du cadre d'étude de l'intégration. Nous savons qu'un graphe se caractérise par un
diamètre qui est la longueur maximum du plus court chemin entre deux sommets.
Ce diamètre nous indique ainsi une borne pertinente pour considérer une chaîne.
Nous verrons dans l'étude précise que c'est le rayon du graphe, plus grand des plus
court chemins issus d'un centre du graphe qui constitue le paramètre le plus
discriminant pour nous. Chaque sous-graphe représente un point de vue de
l'intégration et décrit un ensemble de contraintes sur l'objet C i du point de vue du
construit D. Il permet de définir pour D une comparaison entre les instances D j selon
leur proximité avec l'objet Ci.

L es exemples ci-dessous éclairent comment des sous-graphes d'intégration

illlustrent des problématiques connues des projets de type ERP. Les chemins
listés sont les chemins les plus utiles, mais bien entendu, d'autres chemins,
notamment avec boucles, peuvent exister. Nous notons entre parenthèse des étapes
optionnelles d'un chemin pour en limiter le nombre.
GIn (Dai,OU) : Quels sont les acteurs concernés par une même donnée DA i du
système ? Ce sous-graphe correspond à différents chemins possibles (voir Figure
3.15) :
Da→(Lo→)→ITR→Fea→Pr→OU,
Da→(Lo→)→ITR→Re→EA→OU,
Da→(Lo→)→ITR→Re→Ca→OU,
Da→OV→BP→OU,
Da→OV→Ev→BP→OU,
GIn (DA,OU i) : Quelles sont les données pertinentes à la maîtrise du contexte
d'une activité Eaj par un acteur OU i ? Cette problématique de l'intégration dans un
projet conduit à rechercher toutes les données qui interviennent dans des
composants informatiques qui sont mobilisés par des activités amont de l'activité
étudiée. Elle est en quelque sorte un graphe « symétrique » du précédent qui fixe

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 195
Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

le point de vue organisationnel. Les dépendances possibles sont les mêmes que
pour le sous-graphe GI(Dai ,OU).
GIn (RITi , Ob) : Quels sont les objectifs de l'entreprise qui peuvent aider à une
prise de décision dans le paramétrage d'un composant logiciel ? Cette
problématique classique de la mise en œuvre d'un ERP correspond aux différentes
chaînes entre une « Ressource IT » et un « Objective » :
RIT→Re→EA→Ob,
RIT→Re→EA→BP→Ob,
RIT→Fea→PR→Ob,
RIT→Da→OV→Me→Ob (chemin permettant de prendre en compte
d'éventuelles dépendances informatiques non modélisées dans les activités et
processus) .
GIn (OV, Cai ) : Quels sont les connaissances informationnelles nécessaires à la
maîtrise d'une aptitude ? Ce sous-graphe contient les chemins suivants :
OV→EA(→BP→EA)→Ca,
OV→EA→Re→Ca,
OV→Ev→EA→Re→CA,
OV→Da→ITR→Fea→Pr→Ca,
GIn (RIT, BPi ) : Quelle contribution des applications informatiques aux processus
d'entreprise ? Ce sous-graphe semble relativement simple puisqu'il repose
presque directement sur les relations de support qui lient ressources et activités
d'un processus. Il est cependant utile pour montrer que les différents chemins
possibles d'un sous-graphe illustrent différents aspects d'une dépendance :
RIT→Re→EA(→BP→EA)→BP, (chemin « naturel » du modèle)
RIT→Re→EA→Re→BP, (permet de s'interroger sur une contribution
indirecte du S.I. qui vient paramétrer dans une activité une ressource utilisée
par un autre processus.
RIT→Ev→EA→Re→Ca, (intègre une dépendance temporelle, une application
supporte une transaction, mais elle est aussi dépendante de ce qui se passe en
amont et en aval)
RIT→(Da→RIT)→EA(→BP→EA), l'application est liée par des données à
d'autres applications qui elles-mêmes interviennent dans des activités support
d'autres processus. La dépendance temporelle est sans doute devenue une
dépendance à travers des interfaces
RIT→Fea→Pr→BP, indépendamment de la définition réelle des processus en
activité, l'application est associée à des fonctionnalités qui représentent les
services qu'elle peut rendre et qui sont associés à des pratiques elles-mêmes
conseillées pour certains processus. Cette dépendance est donc celle des
« bonnes pratiques » qu'on peut comparer aux dépendances réelles passant par
les activités.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 196
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Cette liste de sous-graphes d'intégration n'est pas exhaustive. Elle

représente cependant une traduction dans le modèle d'intégration des principales
problématiques rencontrées dans les projets ERP. Elle constitue une approche de la
notion « d'alignement » dont nous proposerons une définition dans le chapitre 3.3.
Ainsi, si le modèle contient une relation de « responsabilité » des « Organizational
Unit » sur les autres objets, les sous-graphes liant ces mêmes OU permettent de
juger de la « transversalité » de cette responsabilité. Si une OU est fortement
dépendante d'un grand nombre d'objets sur lesquels, elle n'exerce pas de
responsabilité, on pourra considérer que l'alignement stratégique entre les différents
points de vue et l'organisation est mis en cause.

3.2.3 Définition de mesures de l'intégration

L es dépendances et chaînes de dépendances permettent d'obtenir un premier

ensemble de dépendances portées par des relations du modèle. Cependant elles
ne suffisent pas à expliciter l'ensemble des contraintes que représente l'intégration.
C'est ce que ressentent les acteurs d'un projet ERP confrontés au constat que des
décisions jugées à priori indépendantes se retrouvent de fait dépendantes,
notamment parce qu'elles concernent une donnée de base du système ERP qui
n'avait pas été identifié comme significative dans chacun des processus, alors
qu'elle les impacte de fait, notamment en cas de non gestion de cette donnée. L'ERP
« masque » sa complexité derrière des transactions que l'ergonomie cherche à
simplifier pour l'utilisateur et derrière des processus qui se concentrent sur l'ajout de
valeur en considérant que les fonctions de support sont maîtrisées et cohérentes
dans l'ensemble de l'entreprise. En quelque sorte l'acteur est supposé concentré sur
l'étape du processus dans lequel il agit sans que l'efficience et la qualité des actions
amont ne puissent interférer dans sa propre efficacité.
Ainsi une dépendance directe entre un processus BP 1 et un événement Ev 1,
créent une dépendance indirecte entre les processus BP 1 et BP 2 s'il déclenche le
même événement Ev 1. Une telle dépendance traduit une contrainte potentielle de
coopération entre les deux processus. Les sous-graphes d'intégration permettent de
prendre en compte ces dépendances indirectes entre construits qui jouent un rôle
important. Reprenons l'exemple de la chaîne de dépendance reposant sur l'usage
d'une donnée par des activités d'entreprise. De fait, l'utilisateur, une fois formé à
l'utilisation des transactions support des activités dont il a la charge, peut
relativement facilement connaître les données qui lui sont nécessaires. Mais il ne
voit pas naturellement par qui d'autres ces mêmes données sont utilisées.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 197
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

L'exemple de la Figure 3.16 illustre cet enjeu des dépendances indirectes à

partir de trois types de construits (P pouvant être un processus, R pouvant être une
ressource de type transaction informatique, et D pouvant être une donnée). La partie
gauche du schéma permet de constater que si on en reste à la dépendance processus/
ressource, les processus P1 et P4 sont indépendants.

R1
d1 P1 d1
R2 P1
d2 P2
d2 P2
R3
d3 P3
d3 P3
R4
P4
d4 d4 P4
R5
d5 d5
R6

Figure 3.16: Dépendances Indirectes

Cependant, si la qualité et la connaissance des données amont est cruciale

pour ces processus, alors on peut constater que la relation indirecte
données/processus fait au contraire des processus P1 et P4 les processus les plus
dépendants par le nombre de données amont qui leur sont nécessaires ou qu'ils ont
en commun.
Il nous faut donc définir plus précisément comment deux objets sont
dépendants indirectement, car ils sont en relation avec les mêmes objets à travers le
graphe alors qu'aucune relation directe ne les lient. Pour cela, nous allons
considérer les sous-graphes d'intégration qui relient ces construits au reste du
graphe en considérant les différents points de vue de modélisation. Ces sous-
graphes représentent le contenu de l'intégration qui concerne ce construit. Nous
considérons que deux construits C i et Cj sont proches si les sous-graphes
d'intégration vers Ci et C j sont proches, c'est à dire relient beaucoup d'objets
identiques. Plus précisément, nous désignons comme graphe d'intégration d'un
objet Ci l'union des sous-graphes d'intégration GI n(X,C i) pour tout construit X. Nous
notons GI n(Ci ) le graphe complet qui contient la totalité des contraintes d'intégration
pertinentes portant sur l'objet C i. Nous pouvons alors comparer les construits C i et
Cj en comparant leur graphe d'intégration. La Figure 3.17 montre deux graphes
d'intégration GI(s1) et GI(s2) dans un graphe global. Nous considérerons
l'intersection des deux sous-graphes que nous appellerons le « couplage » des deux
objets, leur différence au sens ensembliste que nous appellerons la

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 198
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

« dissimilarité », et enfin le poids relatif de la dissimilarité dans la taille cumulée

des deux graphes qui mesure de manière plus précise une mesure normée. Cette
« dissimilarité relative » mesure la proximité entre les sommets quelque soit leur
degré. Dans le cas de deux sous-graphes d'intégration disjoint, le couplage est nul,
et la dissimilarité relative sera alors toujours égale à 1 quelque soit la taille des
sous-graphes.

GI(s1) GI(s2)

Figure 3.17 couplage et dissimilarité de graphes d'intégration

Plus précisément, nous définissons le couplage cn (Ci , Cj ) par :

cn(Ci , Cj ) = | GIn (Ci) ∩ GI n(Cj) |
et la dissimilarité dn(Ci , Cj ) par :
dn(Ci , Cj ) = | GIn (Ci) - GIn(Cj) | + | GIn (Cj) - GIn(Ci) |
Ces mesures de couplage et dissimilarité « absolue » peuvent être normées
en les rapportant à la taille du graphe d'intégration avec le couplage relatif (inversé
pour être une dissimilarité) :
cr n (Ci , Cj ) = 1 - cn(Ci , Cj ) / (cn(Ci , Cj ) + dn (Ci , Cj ))
et la dissimilarité relative par :
dr n (Ci , Cj ) = dn (Ci , Cj ) / (cn (Ci , Cj ) + dn(Ci , Cj ))
La dissimilarité est une distance au sens mathématique et on peut vérifier
les relations suivantes :
dn ( dn ( Ci , Ck ) <= dn(Ci , Cj ) + dn (Cj , Ck )

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 199
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

dn (Ci , Ci ) = 0
dn (Ci , Cj ) = dn(Cj , Ci )
Les autres mesures proposées sont des métriques pour lesquelles des cas de
non vérification de l'inégalité triangulaire sont faciles à construire. Il faut noter que
cette définition peut être généralisée à deux objets quelconque. On peut donc parler
de dn(Ci , D j ) et dr n(Ci , D j ) quelque soit le type de construit de C et D. Nous
présentons les algorithmes de calcul dans la sectin 3.4.

C es définitions sont sensibles au paramètre de longueur maximum utilisé. Pour

une valeur très faible, les graphes d'intégration sont de petite taille et la
plupart des objets seront relativement éloignés. A l'inverse, si la valeur est proche
du diamètre du graphe, les graphes d'intégration seront de grande taille et se
recouvreront fortement. A l'extrême, avec une valeur égale au diamètre, tout graphe
d'intégration est égal au graphe total et les dissimilarités sont alors nulles. La Figure
3.18 présente ainsi l'efficacité relative des dissimilarités selon la longueur max dans
des matrices de dissimilarité d'un graphe exemple de 15 sommets et de diamètre 5
que nous notons E15 et qui est présenté dans la Figure 3.19 du chapitre 3.4.
0 5 5 5 5 9 6 6 5 4 6 6 6 6 5 0 9 9 13 14 14 13 11 4 3 9 13 17 18 17 0 2 11 14 13 3 4 6 6 3 4 6 9 9 9 0 0 3 12 7 0 0 0 3 1 1 2 2 2 2
5 0 4 6 6 10 5 5 6 7 9 7 7 7 6 9 0 6 8 7 17 8 4 13 12 16 18 18 17 16 2 0 9 12 11 5 4 4 8 5 6 8 11 11 11 0 0 3 12 7 0 0 0 3 1 1 2 2 2 2
5 4 0 2 4 8 5 5 4 5 7 5 5 5 4 9 6 0 4 5 19 10 4 13 12 18 18 16 15 14 11 9 0 3 2 14 11 5 17 14 15 17 18 18 18 3 3 0 9 4 3 3 3 6 4 4 5 5 5 5
5 6 2 0 2 8 5 5 4 5 7 5 5 5 4 13 8 4 0 3 19 12 6 11 12 18 16 14 13 12 14 12 3 0 1 17 14 8 20 17 18 20 19 19 19 12 12 9 0 5 12 12 12 15 13 13 14 14 14 14
5 6 4 2 0 8 5 3 4 5 7 5 5 5 4 14 7 5 3 0 18 11 5 12 13 19 17 15 14 13 13 11 2 1 0 16 13 7 19 16 17 19 18 18 18 7 7 4 5 0 7 7 7 10 8 8 9 9 9 9
9 10 8 8 8 0 7 9 8 9 9 7 7 7 6 14 17 19 19 18 0 11 17 12 13 7 3 5 6 7 3 5 14 17 16 0 3 9 7 4 1 3 6 6 6 0 0 3 12 7 0 0 0 3 1 1 2 2 2 2
6 5 5 5 5 7 0 4 5 6 8 6 6 6 5 13 8 10 12 11 11 0 6 17 16 12 12 10 9 8 4 4 11 14 13 3 0 6 10 7 4 6 7 7 7 0 0 3 12 7 0 0 0 3 1 1 2 2 2 2
6 5 5 5 3 9 4 0 5 6 8 6 6 6 5 11 4 4 6 5 17 6 0 15 14 18 18 16 15 14 6 4 5 8 7 9 6 0 12 9 10 12 13 13 13 0 0 3 12 7 0 0 0 3 1 1 2 2 2 2
5 6 4 4 4 8 5 5 0 3 5 5 5 5 4 4 13 13 11 12 12 17 15 0 1 7 9 13 14 13 6 8 17 20 19 7 10 12 0 3 6 4 7 7 7 3 3 6 15 10 3 3 3 0 2 2 1 1 1 1
4 7 5 5 5 9 6 6 3 0 6 6 6 6 5 3 12 12 12 13 13 16 14 1 0 6 10 14 15 14 3 5 14 17 16 4 7 9 3 0 3 5 8 8 8 1 1 4 13 8 1 1 1 2 0 0 1 1 1 1
6 9 7 7 7 9 8 8 5 6 0 6 8 8 7 9 16 18 18 19 7 12 18 7 6 0 4 8 9 10 4 6 15 18 17 1 4 10 6 3 0 2 5 5 5 1 1 4 13 8 1 1 1 2 0 0 1 1 1 1
6 7 5 5 5 7 6 6 5 6 6 0 4 6 5 13 18 18 16 17 3 12 18 9 10 4 0 4 5 6 6 8 17 20 19 3 6 12 4 5 2 0 3 3 3 2 2 5 14 9 2 2 2 1 1 1 0 0 0 0
6 7 5 5 5 7 6 6 5 6 8 4 0 4 5 17 18 16 14 15 5 10 16 13 14 8 4 0 1 2 9 11 18 19 18 6 7 13 7 8 5 3 0 0 0 2 2 5 14 9 2 2 2 1 1 1 0 0 0 0
6 7 5 5 5 7 6 6 5 6 8 6 4 0 3 18 17 15 13 14 6 9 15 14 15 9 5 1 0 1 9 11 18 19 18 6 7 13 7 8 5 3 0 0 0 2 2 5 14 9 2 2 2 1 1 1 0 0 0 0
5 6 4 4 4 6 5 5 4 5 7 5 5 3 0 17 16 14 12 13 7 8 14 13 14 10 6 2 1 0 9 11 18 19 18 6 7 13 7 8 5 3 0 0 0 2 2 5 14 9 2 2 2 1 1 1 0 0 0 0

Figure 3.18 matrice des dissimilarités selon la longueur d'intégration

Les couleurs différencient les objets proches (en clair), ou lointains (en
orange foncé ou gris foncé). Les données sont résumées dans le Tableau 3.9. Les
longueurs 2 et 3 sont les plus pertinentes, ce qui correspond au rayon du graphe.
Dissimilarité Max = 1 Max = 2 Max = 3 Max = 4
proches 51 41 65 163
neutres 174 124 116 60
lointains 0 60 44 2

Tableau 3.9 : répartition des dissimilarités selon la longueur d'intégration

Nous avons comparé les différentes mesures possibles (couplage,

dissimilarité, couplage relatif, dissimilarité relative) du point de vue des

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 200
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

conséquences sur les lites ordonnées de construit qu'elles permettent de réaliser. La

position des objets dans une liste ordonnée par les différentes mesures est
relativement stable (moins de 10% de la taille du graphe dans les cas étudiés).
Cependant les écarts sont dépendants de la position de l'objet dans le graphe. L'objet
centre est par exemple très homogène dans toutes les mesures car son graphe
d'intégration recouvre le graphe total, alors que des objets faiblement couplé sont
positionnées différemment par le couplage et la dissimilarité. On peut cependant
considérer ces mesures comme équivalentes. Nous utiliserons le couplage comme
mesure de similarité et la dissimilarité relative que nous appellerons par la
suite par commodité « distance », tenant compte que les analyses suivantes restent
valables avec d'autres définitions de distance comme le classique « plus court
chemin » dans le graphe. Nous étudierons la complexité du calcul correspondant
dans le chapitre 3.4 afin de proposer une démarche capable de traiter des modèles
de taille réelle. Cette distance d'intégration dans un modèle d'entreprise va devenir
un outil d'analyse dont nous allons proposer des utilisations possibles, le
« partitionnement » d'un ensemble de construit, et le « voisinage d'intégration » d'un
construit que nous allons étudier dans les sections suivantes.

3.2.4 Partitionnement d'un graphe d'intégration

M uni de la distance ainsi définie, nous pouvons utiliser les techniques de

partitionnement évoquées dans l'état de l'art pour proposer des « partitions »
de construits donnant un autre point de vue sur l'intégration, révélant des
conséquences structurelles, notamment sur l'organisation. Des objets du modèle
fortement dépendants devraient être « associés » dans les unités organisationnelles
qui en assument la responsabilité. La possibilité de visualiser la proximité de deux
processus, deux objets d'entreprise, deux ressources, du point de vue de
l'intégration, doit donc être outillée dans notre cadre d'étude. Ce sera le but des
« partitions de construits ». Une partition de construits est une carte qui
présente les objets d'un construit donné en les regroupant de manière à faire
apparaître une « partition » de l'ensemble de ces objets à partir de la distance
calculée entre eux. Cette carte est construite pour que le positionnement relatif de
chaque construit par rapport aux autres soit significatif de sa distance aux autres.
Pour illustrer ces partitions de construits et leur pertinence pour comparer
l'intégration avec les structures hiérarchiques définies indépendamment, nous
prenons l'exemple d'un graphe liant 15 instances de construits regroupés dans 4
structures (par exemple des domaines métiers). Il s'agit du cas E15 présentés dans le
chapitre 3.4.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 201
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

La Figure 3.19 présente en haut le graphe avec les objets classés en

groupes prédéfinis et les dépendances entre ces objets. La partie basse présente une
structuration possible obtenue par un algorithme de force qui repositionne les objets
à partir de leur distance et fait apparaître une partition potentielle différente. Pour
vérifier la réalité de ce partitionnement, nous prenons des graphes de longueur 2
comme graphes d'intégration pour définir la distance entre construits et nous
utilisons un algorithme de classification ascendante hiérarchique.

Figure 3.19. modèle conçu et modèle placé avec partitions de construits

Les distances présentées dans le Tableau 3.11 permettent d'appliquer à

l'ensemble des 15 construits un partitionnement par analyse ascendante
hiérarchique. Le résultat identifie 3 classes et confirme la pertinence du

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 202
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

partitionnement rendu visible par l'algorithme de force. Les classes sont rendues
visibles dans la Figure 3.19 par les traits en tirets.
la classe 1 contient les objets C1,C2,A1
la classe 2 les objets A2,A3,A4,B2,B3
la classe 3 les objets B1,C3,D1,D2,D3,D4.
Les caractéristiques du partitionnement sont notées dans le Tableau 3.10 :
Classe 1 2 3
Variance intra-classe 51,000 130,767 116,400
Distance minimale au barycentre 2,828 5,904 6,583
Distance moyenne au barycentre 5,444 9,575 9,387
Distance maximale au barycentre 7,937 18,552 15,470
Tableau 3.10 : Classification ascendante hiérarchique (variance totale: 487, 933)

A1 A2 A3 A4 A5 B1 B2 B3 C1 C2 C3 D1 D2 D3 D4
A1 0 9 9 13 14 14 13 11 4 3 9 13 17 18 17
A2 9 0 6 8 7 17 8 4 13 12 16 18 18 17 16
A3 9 6 0 4 5 19 10 4 13 12 18 18 16 15 14
A4 13 8 4 0 3 19 12 6 11 12 18 16 14 13 12
A5 14 7 5 3 0 18 11 5 12 13 19 17 15 14 13
B1 14 17 19 19 18 0 11 17 12 13 7 3 5 6 7
B2 13 8 10 12 11 11 0 6 17 16 12 12 10 9 8
B3 11 4 4 6 5 17 6 0 15 14 18 18 16 15 14
C1 4 13 13 11 12 12 17 15 0 1 7 9 13 14 13
C2 3 12 12 12 13 13 16 14 1 0 6 10 14 15 14
C3 9 16 18 18 19 7 12 18 7 6 0 4 8 9 10
D1 13 18 18 16 17 3 12 18 9 10 4 0 4 5 6
D2 17 18 16 14 15 5 10 16 13 14 8 4 0 1 2
D3 18 17 15 13 14 6 9 15 14 15 9 5 1 0 1
D4 17 16 14 12 13 7 8 14 13 14 10 6 2 1 0
Tableau 3.11: dissimilarité de longueur d'intégration 2 pour le graphe E15

Dans cet exemple simple, la classification avec la dissimilarité et la

dissimilarité relative donne le même résultat.

3.2.5 Couplage et voisinage d'intégration

L a notion de couplage qui est complémentaire à la dissimilarité nous paraît très

pertinente dans un contexte où un modèle d'entreprise existe déjà et ou le
travail de modélisation doit tenir compte des contraintes d'intégration qui ne sont
pas directement visibles dans les relations. Ainsi, un acteur de projet travaillant sur

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 203
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

un modèle organisationnel aura du mal à tenir compte d'un point de vue

informationnel qui n'apparait pas directement dans son modèle. De manière
générale, le travail de modélisation est toujours un travail partiel, ou le modélisateur
se concentre sur un point de vue et un périmètre particulier. L'architecture générale
du modèle, le passage du générique au particulier et sa connaissance générale du
domaine l'aide à garantir la cohérence de son travail avec les autres acteurs.
Cependant, la complexité de l'intégration rend difficile la connaissance et la prise en
compte de l'ensemble des contraintes qui pèsent sur un objet d'un modèle,
contraintes qui sont justement hétérogènes en termes de métiers, de techniques, qui
peuvent être des contraintes indirectes traduites par des chaînes d'une longueur qui
interdit de les représenter dans un graphe visible au modélisateur.
Nous proposons donc de représenter de manière synthétique l'ensemble de
ces contraintes d'intégration en les hiérarchisant à partir de cette notion de couplage
pour représenter une liste des voisinages par point de vue, quelque soit la position
des objets concernés dans le modèle global. Plus précisément, pour un objet Ci nous
définissons un voisinage d'intégration de couplage n pour un point de vue donné
comme l'ensemble des objets de ce point de vue dont le couplage avec l'objet est
supérieur à n. Ainsi, nous définissons un voisinage informationnel noté VI n (Ci), un
voisinage fonctionnel noté VFn (Ci), un voisinage ressources noté VR n(Ci ) et un
voisinage organisationnel noté VO n(Ci ). On peut écrire :
V In(Ci ) = { Cj , C j informationnel, couplage(C i,Cj )>=n}
V Fn(Ci ) = { Cj , C j fonctionnel, couplage(Ci,Cj )>=n}
V R n(Ci) = { C j , Cj ressources, couplage(Ci ,Cj)>=n}
V O n(Ci) = { C j , Cj organisationnel, couplage(C i,Cj )>=n}
Par extension, nous parlerons du voisinage d'un objet comme la réunion
des voisinages par point de vue :
V n(Ci ) = { Cj , couplage(Ci,Cj )>=n}
Comme pour la longueur d'intégration, le paramètre n est borné, dans ce
cas par le diamètre du graphe. Cependant, contrairement à la longueur d'intégration
pour laquelle une valeur proche du rayon du graphe semble pertinente, il n'existe
pas à priori pas de longueur générale particulière qui permettrait de figer cette
notion de voisinage. En effet un objet fortement utilisé comme l'application ERP en
relation avec de très nombreux processus et données, ou une donnée de base du
système comme un magasin, pourra être très fortement couplé à de nombreux autres
objets. Un couplage de longueur faible conduira à considérer dans le voisinage de
cet objet la presque totalité du graphe. A l'opposé, pour un objet faiblement
connecté, ce sera l'inverse. Nous considérons donc que c'est l'acteur de la
modélisation qui choisit d'interroger cette notion de couplage selon l'objet considéré

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 204
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

et l'objectif recherché avec une « profondeur » de voisinage adaptée au contexte et

au construit étudié. C'est pourquoi nous proposons une représentation de ce
voisinage intégrant une variable destinée à représenter et agir sur ce paramètre du
voisinage d'intégration.
Cette notion de voisinage peut être illustrée dans l'exemple du graphe E15
présenté précédemment avec un couplage défini cette fois pour une longueur
d'intégration de 3. A partir des couplages, on obtient comme premier voisinage du
construit A1, a une longueur de couplage supérieur à 18 les objets A2, B1, B2 et C3.
On peut représenter un tableau des voisinages de A1 pour différentes longueurs
discriminantes dans ce cas (18,15 et 9) qui répartissent le graphe en trois voisinages
successifs, présentés par couplages décroissants :
Construit A1 Couplage > 18 Couplage > 13 Couplage > 9
Voisins de type A A2 A3
Voisins de type B B1,B2 B3
Voisins de type C C3 C1,C2
Voisins de type D D1 D2,D3,D4
Tableau 3.12 : Voisinages dans le cas E15

La matrice des couplages, calculée pour une longueur d'intégration de 3,

permettant de construire ces voisinages est est présentée dans le Tableau 3.13.
Un acteur de modélisation peut avec ce type de représentation de voisinage
par point de vue, prioriser son travail d'étude, de comparaison, afin de mieux tenir
compte de l'ensemble de la sémantique existante dans le modèle. La Figure 3.20
illustre la pertinence de cette notion de voisinage basé sur le couplage entre graphes
d'intégration, en présentant graphiquement les voisinages successifs décrits dans le
Tableau 3.12. Le premier voisinage de l'objet A1 contient les objets B1,B2 qui ont
un plus court chemin vers A1 de 2, mais ne contient pas l'objet C1 qui est pourtant
directement relié à A1. On voit ainsi que l'intégration mesurée à travers la notion de
couplage est différente de ce que les relations directes et la notion de plus court
chemin peuvent illustrer dans un modèle.
Ce concept de voisinage est une aide à la modélisation en permettant de
représenter graphiquement le « contexte d'intégration » d'un objet du modèle
quelque soit sa position précise dans le modèle. Il est donc un outil au service de
l'alignement entre point de vues en aidant à agir sur ce qui est porteur des plus
fortes contraintes.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 205
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

couplage A1 A2 A3 A4 A5 B1 B2 B3 C1 C2 C3 D1 D2 D3 D4
A1 11 6 4 1 1 6 5 4 7 8 8 5 2 1 1
A2 6 10 5 3 4 4 7 7 2 3 4 2 1 1 1
A3 4 5 6 3 3 1 4 5 0 1 1 0 0 0 0
A4 1 3 3 4 3 0 2 3 0 0 0 0 0 0 0
A5 1 4 3 3 5 1 3 4 0 0 0 0 0 0 0
B1 6 4 1 0 1 15 8 3 5 5 11 12 10 9 8
B2 5 7 4 2 3 8 12 7 1 2 7 6 6 6 6
B3 4 7 5 3 4 3 7 8 0 1 2 1 1 1 1
C1 7 2 0 0 0 5 1 0 7 7 7 5 2 1 1
C2 8 3 1 0 0 5 2 1 7 8 8 5 2 1 1
C3 8 4 1 0 0 11 7 2 7 8 14 11 8 7 6
D1 5 2 0 0 0 12 6 1 5 5 11 12 9 8 7
D2 2 1 0 0 0 10 6 1 2 2 8 9 10 9 8
D3 1 1 0 0 0 9 6 1 1 1 7 8 9 9 8
D4 1 1 0 0 0 8 6 1 1 1 6 7 8 8 8
Tableau 3.13 : matrice des couplages du graphe E15

Figure 3.20 voisinages successifs de l'objet A1 dans le graphe E15

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 206
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

3.2.6 Complexité des algorithmes

L a capacité à calculer effectivement les voisinages et les partitions nécessite

d'étudier la complexité des algorithmes nécessaires. Nous proposons une
démarche en 3 étapes de complexité différente (les algorithmes utilisés sont fournis
en annexe) :
La construction des voisins à la longueur d'intégration est possible avec un
algorithme reposant sur une définition récursive (les voisins à une longueur n,
sont les voisins à une longueur n-1 des voisins directs). Sa complexité dépendante
du degré moyen du graphe (d) et de son rayon (r) est égale à (n*d*r). Degré et
rayon n'augmentent pas linéairement avec la taille du graphe mais sont
représentatives de sa complexité. Le degré étant le nombre de relations possibles
sur un objet, nous considérons pour des raisons de lisibilité qu'il est borné (en
général inférieur à 10). Le rayon du graphe est d'autant plus bas que le système
est fortement intégré. Nous pouvons aussi le considérer comme borné. La
complexité est alors o(n) pour la construction des voisins.
A partir des voisins, les distances peuvent être calculées dans un algorithme de
complexité (d*n2). Là encore, le fait de considérer le degré du graphe comme
borné permet de considérer une complexité o(n2) correspondant à la taille des
matrices. Cela nous a permis de traiter rapidement des graphes de 1000 ou 2000
sommets. Dans un système de très grande taille comme un ERP, il sera cependant
difficile d'effectuer la totalité du calcul de manière transactionnelle. Mais compte
tenu qu'au delà d'une longueur de chemin supérieure au rayon du graphe, les
distances seront rapidement toutes égales au maximum, il est possible de limiter
le calcul à un sous-graphe pertinent à un point de vue et pour une sélection
limitée de nombre d'objets, il est alors possible de calculer la sous-matrice de leur
distance. Nous reprendrons ce point dans les perspectives .
Enfin, la construction des sous-graphes d'intégration relève d'un algorithme de
complexité o(nl) où l est la longueur d'intégration. Nous avons pu exécuter sans
difficulté ces algorithmes pour des graphes de 1000 sommets et de rayon 5. A
partir de 2000 sommets, nous avons rencontré des limitations de taille mémoire.
Les sous-graphes ne pourront être construits globalement pour un graphe de très
grande taille dont le rayon peut être de l'ordre de 10. Il faudra donc trouverque de
manière interactive pour un sous-graphe sélectionné et non pour l'ensemble du
graphe.
Si les algorithmes de base sont d'une complexité acceptable pour une
utilisation opérationnelle, la taille d'un graphe d'intégration complet d'un modèle
d'entreprise de type ERP qui peut être estimé à 10 5 objets pose évidemment

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 207
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

problème en terme de taille mémoire pour gérer des matrices qui devraient donc être
de dimension double 10 10 . Nous évoquerons ce défi dans la partie 4 sur les
perspectives académiques (4.1.3) et industrielles 4.2.

3.2.7 Dépendances et maturité des usages des S.I.

E n redéfinissant la problématique de l'alignement comme celle de la cohérence

entre plusieurs points de vue d'un modèle d'entreprise, cohérence explicitable
par l'ensemble des dépendances entre ces points de vue, nous devons étudier la
dimension essentielle de la « maturité » des usages des systèmes d'information pour
prendre en compte dans la caractérisation des dépendances les aspects humains et
sociaux, portés dans les construits organisationnels, qui sont générateurs
d'incertitude, de non défini, de flou. Nous avons déjà noté l'importance d'étendre le
modèle aux construits d'objectifs avec indicateurs, de pratiques organisant les
aptitudes et leur mise en œuvre en relation avec les activités. Mais ce sont les
dépendances qui doivent être qualifiées pour prendre en compte des contraintes qui
ne sont pas absolues au sens d'une contrainte d'intégrité dans une base de donnée.
En fait, si certaines dépendances peuvent être traduites dans un système
d'information par des relations techniques « dures », « obligatoires » si elles sont
activées, de nombreuses dépendances notamment concernant les construits
organisationnels doivent être considérées comme « molles », parfois non
permanentes, soumises à interprétation dynamique par les acteurs et susceptibles
d'être non respectées selon le contexte, ou la décision particulière d'un acteur. C'est
bien entendu le cas de la notion de « responsabilité » qui relie tout modèle
(fonctionnel, informationnel ou de ressource) à une unité organisationnelle. Il est
bien connu qu'un acteur est responsable de quelque chose, sauf si son propre chef
décide de confier la chose en question à un autre acteur... C'est ce que nous avons
étudié en évoquant la notion de « couplage faible » dans la recherche de
l'intégration (chapitre 2.4). Nous devons donc qualifier les dépendances par leur
nature plus ou moins « structurante » notamment pour différencier les dépendances
qui seront considérées comme relevant de l'architecture du modèle, devant toujours
être prises en compte et les dépendances relevant du pilotage par les acteurs et
pouvant être « levées » selon le contexte par les acteurs. Pour cela, nous nous
inspirons des travaux présentés dans l'état de l'art (chapitre 2.4) sur le niveau de
couplage en théorie des systèmes en qualifiant les dépendances en « réelle »,
« hypothétique » et « dirigée »

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 208
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Une dépendance « réelle » est considérée comme existante en permanence et

correspondant à une intégration technique ou physique. C'est le cas des
dépendances liant les objets techniques ou informationnels entre eux.
Une dépendance « hypothétique » est soumise au contexte et peut être active ou
non selon certaines hypothèses. Ce peut être le cas des dépendances entre
fonctions et ressources, dont la réalité peut dépendre de « paramètres » du
système d'information. Ainsi, un contrôle qualité créant une dépendance entre une
fonction réception et une ressource de contrôle peut être inactif dans une
première phase de mise en œuvre d'un projet, puis activé dans le cadre d'une
action d'amélioration du même système.
Une dépendance « dirigée » n'est effective que par la volonté d'un acteur qui la
rend opérationnelle au moyen de processus, règles, indicateurs. De manière
générale, c'est le cas des dépendances liant les construits organisationnels.
Les sous-graphes d'intégration évoqués précédemment prendront donc une
qualification que nous désignons comme une « force » qui sera naturellement le
minimum au sens de l'ordre naturel : (« dirigé » < « hypothétique » < «réel »). On
pourra par la suite pondérer les relations avec cette force pour en tenir compte dans
la notion de « longueur » de chaîne, une suite de relations « hypothétiques »
représentant certainement une contrainte d'intégration plus faible qu'une suite de
relations « réelles ».

E n complément de cette caractéristique de « force », le modèle doit tenir

compte d'une autre caractéristique essentielle d'un système d'information
opérationnel, la maturité des acteurs dans ses différents points de vue. L'étude des
modèles de maturité dans la section 2.3.3 conduit à identifier plusieurs « points de
vue » de la maturité, comme la maturité « organisationnelle » et « informatique »
étudiée dans le modèle de maturité portant sur la contribution des S.I. à la
performance de l'entreprise (Botta-Genoulaz et Millet 2005). le modèle CMMI
propose lui cinq niveaux de maturité que nous utiliserons pour évaluer la maturité
d'une unité organisationnelle sur tout autre construit du méta-modèle. Cette maturité
devient un attribut de la dépendance de contrôle des unités organisationnelles.
initial : processus imprévisibles, mal contrôlés et réactifs
processus gérés : un processus par projet, gestion parfois réactive
processus définis : processus standardisés, gestion proactive
processus maîtrisés : processus sous controles
optimisation : amélioration continue des processus
Nous considérons que tout élément du modèle d'entreprise doit être
qualifié par un niveau de maturité mesuré dans l'organisation, ce niveau de maturité
étant naturellement un attribut de la relation de contrôle des unités

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 209
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

organisationnelles sur tous les éléments du modèle (si le modèle autorise un même
objet à être sous la responsabilité de plusieurs unités organisationnelles, on
considérera que la maturité de l'objet est la maturité minimum de ses responsables).
Une telle approche permet de prendre en compte une maturité acquise hétérogène
dans l'organisation, et dans sa nature. Le croisement de la maturité dans la relation
« Organizational Unit » et « Processus » avec la maturité de la relation
« Organizational Unit » et «IT Resource » représente ainsi la matrice de maturité
proposée section 2.3.3.
On peut ainsi mesurer la maturité de l'alignement entre plusieurs points de
vue, et plus généralement de toute dépendance entre construits du modèle. Une
dépendance est qualifiée par la maturité des construits qui sont liés par cette
dépendance à travers la maturité des unités organisationnelles qui les contrôlent. On
peut ainsi obtenir une classification des situations de maturité pour deux construits
C1 et C2 sous contrôle d'unité organisationnelle U1 et U2 selon :
la nature de la relation organisationnelle entre U1 et U2 (hiérarchique U1 > U2 ou
U2 > U1, parallèle notée U1 // U2 , indépendante notée U1 <> U2)
les niveaux de maturité constatés des unités U1 et U2 sur les construits qu'elles
controlent, U1(C1) plus mature que U2(C2) noté U1(C1) >> U2(C2), ou de
maturité équivalent noté U1(C1) ~U2(C2).
Le Tableau 3.14 présente les différentes situations possibles et illustre
l'importance de cette notion de maturité pour orienter les décisions dans la
modélisation et le plan d'action dans un projet utilisant le modèle. Cette définition
de la maturité conduit à compléter les relations avec les construits organisationnels
du méta-modèle d'intégration par un attribut de « maturité » pouvant prendre les
cinq valeurs standard proposé par le modèle CMMI que nous renommerons (initial,
géré, défini, maîtrisé, aligné). Cette maturité se propageant aux construits peut être
analysée dans tout chemin du graphe qui devient ainsi enrichi d'une deuxième
caractéristique en complément de la « force » mesurant la nature technique ou
humaine de la dépendance. Bien qu'elle puisse s'appliquer à l'ensemble des
construits, ce n'est toutefois ni possible ni utile. Ce sont principalement les
construits sur lesquels une action d'évaluation, de correction, de formation est
possible et donc principalement les construits BP et EA pour la vue fonctionnelle,
OV pour la vue informationnelle, Da et RIT pour la vue des ressources
(informatiques) et Ca pour la vue organisationnelle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 210
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Dépendance Maturité Maturité faible Maturité

C1 vers C2 U1(C1) << U2(C2) U1(C1) ~ U2(C2) U1(C1) >> U2(C2)
U1 > U2 Fort risque, car le Besoin d'amélioration Faible risque car le
décideur ne maîtrise sous la responsabilité décideur a autorité et
sans doute pas. de U1 compétence.
U2 > U1 Faible risque car le Besoin d'amélioration Fort risque, car le
décideur a autorité sous la responsabilité décideur ne maîtrise
et compétence. de U2 sans doute pas.
U1 // U2 Risque devant être Besoin d'amélioration Risque devant être
soumis à sous la responsabilité soumise à l'organisation
l'organisation de l'organisation supérieure
supérieure supérieure
U1 <> U2 Fort risque exigeant Risque exigeant une Fort risque exigeant une
une réingénierie réingénierie pour réingénierie pour
pour identifier la identifier la identifier la
responsabilité responsabilité responsabilité

Tableau 3.14.: caractérisation des dépendances par la maturité

Pour caractériser une dépendance par une mesure de maturité, nous

considérons une codification numérique de la maturité (Initial = 0,2, géré = 0,4,
défini = 0,5, maîtrisé = 0,8, aligné = 1). La maturité d'une dépendance peut alors
être évaluée en tenant compte de deux aspects contradictoires :
l'effet « solidaire » d'une organisation qui permet à un acteur de compenser par
l'expérience une maturité faible d'un autre acteur. Un maillon faible ne condamne
pas nécessairement totalement la chaîne totale.
l'effet au contraire cumulatif des erreurs. Il est bien connu que les aléas ont un
caractère multiplicateur qui fait qu'un taux de service de 90% est jugé comme très
faible dès qu'il s'applique à un ensemble d'activité
Une étude fine de ces effets contradictoires supposent de tenir compte de
l'orientation des dépendances, puisque l'effet cumulatif d'une erreur se propage
nécessairement chronologiquement. Dans un premier temps, nous nous limitons
cependant à définir la maturité d'une dépendance dans le graphe non orienté comme
la moyenne des maturités des construits. Ainsi la chaîne :
RIT(0,8)→Da(0,4)→RIT(0,8)→EA(1)→BP(0,6) aura comme maturité 0,6 ce qui
veut dire que la maturité « gérée » de la gestion des données ne suffit pas à
perturber la chaîne au point que les différents construits pourraient ne plus être
défini. Les conséquences de ces caractéristiques qualitatives des dépendances, force
et maturité, supposent de considérer un graphe valué. Nous l'évoquerons dans les
perspectives académiques de la partie 4.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 211
 Démarche d'ingénierie orientée intégration / Graphe d'intégration du modèle d'entreprise

Nous avons ainsi situé dans le cadre de modélisation de la norme

19439 les construits nécessaires à la modélisation d'entreprise en
prenant en compte l'existence de référentiels ou standards autant pour
les pratiques et la définition fonctionnelle du système d'entreprise que
pour les applications informatiques support de ces pratiques. Ce méta-
modèle d'intégration contient les relations entre construits qui
permettent la construction d'un modèle d'entreprise et portent les
différentes formes de dépendances internes au système d'entreprise.

Nous construisons ainsi un « graphe d'intégration » correspondant au

modèle que nous pouvons analyser. Ce graphe peut être étudié
localement pour caractériser des « chaînes d'intégration » entre deux
objets. Il permet plus globalement de définir un couplage et une
distance entre objets à partir de la connexité comparée des graphes
d'intégration. Il permet de propager la maturité évaluée des entités
organisationnelles pour colorer le graphe par cette maturité.

Le couplage entre objets permet de définir le voisinage d'un objet qui

représente un « contexte d'intégration » dont le modélisateur doit
tenir compte.

La distance entre objets permet de définir une partition significative

des conséquences de l'intégration sur la structuration du modèle.

Nous avons ainsi un cadre d'étude, un méta-modèle de construits, des

graphes d'intégration permettant de construire des voisinages et des
partitions qui constituent les outils de base de notre étude de
l'intégration organisationnelle et informationnelle.

Nous allons étudier plus précisément comment les construits

deviennent, à travers des référentiels métiers, des « ontologies »
permettant la modélisation non seulement en respectant l'architecture
que porte le méta-modèle, mais aussi la connaissance métier et sa
structuration que portent les standard.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.2
Institut National des Sciences Appliquées de Lyon 212
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Chapitre 3.3
Ingénierie d'entreprise
orientée intégration

Le cadre de modélisation, le méta-modèle et le graphe d'intégration

nous permettent de proposer une démarche d'ingénierie doublement
caractérisée par la place de la modélisation au cœur des efforts
d'alignement entre des points de vue multiples, et la place de
l'intégration comme critère d'évaluation de la pertinence d'une vue du
modèle d'entreprise.

Nous commençons par proposer une définition générale de

l'alignement, autant pour ses dimensions managériales que pour
l'alignement entre besoins et solutions standard, ou même entre
système défini et système en usage.

Nous proposons ensuite une démarche d'ingénierie dans le cadre de

modélisation utilisé s'appuyant sur les vues partielles du méta-modèle
adaptées à des situations de projet variées.

Enfin, nous caractérisons des situations d'alignement dans les

différentes étapes de notre démarche d'ingénierie en listant les
construits au cœur de la modélisation à ces différentes étapes.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 213
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

N ous avons défini un méta-modèle de l'intégration construit par extension du

méta-modèle de la norme 19440 pour notre problématique de l'intégration et
nous l'avons détaillé sur quelques construits en étudiant la structure de référentiels
métiers. Nous avons étudié le graphe d'intégration correspondant à un modèle
d'entreprise utilisant ce méta-modèle et nous avons défini dans ce graphe un
couplage et une distance permettant de construire des outils d'analyse du modèle
d'entreprise. Nous pouvons alors proposer une ingénierie d'entreprise dirigée par
les modèles orientée vers la prise en compte de l'intégration qui s'appuie sur :
le cadre de modélisation issu de la norme 19439 dans l'interprétation que nous
avons proposé à la section 3.1.1, page 140.
le méta-modèle d'intégration proposé dans la section 3.1.2, page 145 et issu de la
confrontation du méta-modèle 19440 avec le référentiel SCOR et un méta-modèle
ERP.
la prise en compte de connaissances métiers standardisés sous forme de
référentiels à travers des ontologies qui enrichissent le langage de modélisation,
telles que celles étudiées dans la section 3.1.3, page 159.
les dépendances entre objets du modèle d'entreprise que nous appelons le
« graphe d'intégration » et dont nous pouvons proposer des sous-graphes
d'intégration représentant autant de « points de vue » sur l'intégration présentées
dans la section 3.2.2, page 189. Ces graphes permettent de définir deux mesures
de l'intégration, le couplage qui traduit la connectivité entre deux objets et la
distance basée sur la dissimilarité des graphes d'intégration et qui illustre si les
objets sont proches du point de vue de leur contraintes d'intégration.
des voisinages d'intégration d'un objet dans le modèle présentés dans la section
3.2.5, page 203, voisinages fondées sur la notion de couplage et qui hiérarchisent
les contraintes d'intégration existantes pour chaque point de vue afin d'outiller
une modélisation tenant compte en permanence de l'intégration,
des partitions présentées dans la section 3.2.4, page 201, représentant un point de
vue sur la structuration possible d'un construit, issues de la distance définie par le
graphe d'intégration et qui peut être comparé avec les structures hiérarchiques
préexistantes dans un modèle standard ou l'organisation de l'entreprise.
des niveaux de maturité de l'organisation dans ses dépendances aux construits qui
permettent d'interroger les sous-graphe d'intégration et partitionnements en les
colorant par la maturité présentés dans la section 3.2.7 de la partie 3, page 208.
Dans cette approche, le graphe d'intégration joue un rôle central dans la mesure où
il porte les contraintes et les objectifs d'intégration qui sont la clef de la réussite de
l'ingénierie d'entreprise. Nous allons montrer qu'il permet d'outiller les démarches
d'alignement qui sont caractéristiques de l'ingénierie des systèmes d'information,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 214
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

alignement entre les différents points de vue qui reposent sur les dépendances entre
objets du modèle d'entreprise, donc sur le graphe d'intégration.

3.3.1 Démarche d'alignement

N otre démarche d'étude de l'intégration s'appuie sur la modélisation à la fois

dans le cadre de l'ingénierie des systèmes d'information et dans celui du
management des systèmes d'entreprise. Il faut donc éclairer comment nous
cherchons à prendre en compte les deux approches de la modélisation qui nous sont
nécessaires. A partir du positionnement des techniques de modélisation proposée par
Katzy (2003) et du modèle d'alignement stratégique de Henderson et Venkatraman
(1993) vu dans l'état de l'art, nous situons le rôle des modèles comme support de
l'alignement nécessaire entre les points de vue du management, qui porte en premier
lieu la capacité de compréhension du modèle pour les acteurs humains et le point de
vue de l'ingénierie des systèmes d'information qui porte la capacité à mettre en
œuvre et utiliser les systèmes (Figure 3.21). Le mot « enactment » traduit cette
concrétisation d'une potentialité que représente la promulgation d'une loi, la
représentation d'un rôle dans dans une pièce de théâtre. C'est bien ce lien entre la
volonté des acteurs et la réalité des pratiques et des résultats que nous cherchons à
maîtriser en étudiant l'ensemble des dépendances qui conditionnent, contraignent ou
freinent ce « passage à l'acte ».
Le point de vue des systèmes (en bas à gauche de la figure) est bien
entendu appuyé sur le système informatique et a comme premier objectif
l'utilisation opérationnelle et informatisée des modèles. Le point de vue managérial
(en haut à droite de la figure) est à l'opposé supporté par les acteurs humains et a
comme premier objectif la compréhension des modèles. Le rapprochement entre ces
deux points de vue est au cœur de l'alignement nécessaire entre stratégie et
opérations. Nous enrichissons ce double point de vue du management et des
systèmes en positionnant les vues issues de la modélisation d'entreprise afin
d'illustrer notre interprétation prenant en compte non seulement les aspects
techniques, informatisables, mais aussi les aspects humains qui nécessitent une
représentation plus qualitative de la « compréhension » par les acteurs. Les vues
standard de la norme 19439 représentent aussi différentes vues de la problématique
de l'alignement comme nous l'avons noté à la section 3.1.1, introduisant une lecture
en « couches » de la Figure 3.21 où les ressources informatiques s'alignent sur les
processus d'entreprise de la vue fonctionnelle à travers la vue informationnelle, et
ou la vue fonctionnelle sert de support à l'alignement entre la vue organisationnelle
et la vue informationnelle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 215
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Figure 3.21. démarche d'alignement dirigée par les modèles

L'alignement porte autant sur les conditions d'efficacité des projets

d'ingénierie de S.I. que sur la maturité des usages dont sont porteurs à la fois
l'organisation et les acteurs individuels. C'est pourquoi nous ne limitons pas
l'alignement à une relation entre stratégie et technique ou même comme dans le
modèle de Henderson et Venkatraman aux relations entre stratégie d'entreprise,
opérations, stratégie informatique et système d'information. Notre objectif est bien
de mettre en relation les différents modèles utilisés aux étapes successives d'un
projet d'ingénierie d'entreprise afin de faciliter un alignement qui concerne
l'ensemble des acteurs intervenant dans l'ensemble des phases d'ingénierie
d'entreprise, de la conception aux usages. Nous nous inspirons fortement des
objectifs et des premiers résultats du projet de recherche Easy-dim du groupement
de recherche MACS du CNRS28
L'alignement doit alors être étudié sur chaque dépendance entre des
construits du modèle d'entreprise. Il peut être interne à un point de vue, par exemple
l'alignement entre aptitudes définies dans le modèle et organisation hiérarchique des
métiers, ou aligner des points de vue différents comme l'alignement entre ressources
informatiques et activités de l'entreprise qui est au cœur des projets d'ingénierie des
S.I. Nous allons chercher à caractériser les différentes situations d'ingénierie afin de

28 //[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 216
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

repérer les situations d'alignement entre construits les plus pertinentes pour
construire une démarche d'ingénierie guidée par l'intégration.

3.3.2 Démarche d'ingénierie

N otre démarche d'ingénierie d'entreprise est guidée par les modèles nécessaires
et l'étude de l'intégration dont ils sont porteurs. Notre interprétation non
séquentielle du cadre 19439 d'ingénierie d'entreprise peut éclairer le rôle des
différents modèles utilisés. Il est pour cela nécessaire de préciser comment le cadre
de modélisation répond aux différentes situations de projets d'entreprise. Nous
plaçons pour cela dans le cadre 19439 différents « cycles de projet » correspondant
à des typologies de projet connues.
Des projets de type BPR toujours déclenchés par une volonté d'une direction
générale et qui chercheront d'abord à reconvevoir l'entreprise avant de traduire le
modèle cible retenu en système d'information nécessitant des solutions
informatiques.
Des projets de type ERP « IT » déclenchés par une opportunité ou une contrainte
et nécessitant la mise en œuvre rapide d'une solution standard, projets souvent
portés par une direction informatique et qui par choix méthodologique ou par
contrainte de temps peuvent être limités aux tâches informatiques sans effort de
modélisation orientée processus.
Des projets de type ERP « BP » souvent déclenchés par une recherche
d'amélioration de performance, une demande de réorganisation pour laquelle le
système d'information est vu par la direction générale comme une opportunité et
qui tout en s'appuyant sur une solution standard vont intégrer la nécessité d'un
effort de modélisation et de re-conception partielle du modèle d'entreprise.
D'autres situations de projet existent, « montée de version », « migration »,
« déploiement » qui s'appuient sur un modèle existant et se limite à déployer une
solution dans un périmètre. Souvent portés par une direction informatique, ils
peuvent être des projets à dominante technique mais dont les impacts opérationnels
sur les pratiques des acteurs peuvent être significatifs et exiger une démarche de
conduite de changement.
Nous étudierons dans la suite les trois premiers types de projets en les
situant dans les phases de modélisation du cadre 19439 rappelées ci-dessous et
décrites dans le Figure 2.6, page 74 :
Identification du domaine (« Domain Identification » ) ;
Définition des concepts (« Concept Definition ») ;
Défintion des besoins (« Requirements Definition ») ;

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 217
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Spécification de conception (« Design Specification ») ;

Description de la mise en oeuvre (« Implementation Description ») ;
Opérations (« Domain Operation »)
Définition de décommission (« Decommission Definition »).
Les figures suivantes représentent chaque type de projet par un
enchaînement de phases de modélisation dans le cadre 19439 pour lesquelles nous
précisons les construits « cœur de phase » qui portent la connaissance essentielle à
cette étape et dont la validation en constitue le livrable principal. Chaque figure
présente dans le cadre de modélisation 19439, une séquence type de projet (flèche
parcourant les phases de projet à travers les niveaux de généricité) en précisant les
construits typiques de cette phase pour chaque point de vue. Si cette liste de
construits par phase, pertinente pour une typologie de projet d'intégration, n'est pas
exhaustive, elle caractérise une démarche d'ingénierie dans le cadre 19439 et ses
principaux enjeux d'alignement dans cette typologie de projet.
La Figure 3.22 présente les projets de type BPR en utilisant la codification
définie des construits (Tableau 5.2 en annexe). Ces projets débutent par la définition
d'objectifs qui sont spécifiques à l'entreprise concernée. Ces objectifs conduisent
des consultants à chercher des « bonnes pratiques » qui seront issues des
connaissances génériques portées par des référentiels métiers et le plus souvent
traduites en processus d'affaires. Il s'agit d'éclairer la connaissance des acteurs en
termes de « concepts » pour leur permettre de définir ensuite leur besoin.

Généricité Vues

Projets de type BPR Gen. Part. Spec. Func. Inf. Ress. Org.

Domain Identification Ob

Concept Definition BP PR

Requirements Definition Fea EO Ca

Da
Ev
Design Specification EA Me Re
Implementation Description OV OU

Domain Operation Me

Decommission Definition

Figure 3.22. cadre 19439 et projets de type BPR

Pour cela, les processus porteurs de bonnes pratiques seront traduits en

fonctionnalités attendues du système, fonctionnalités qui peuvent être génériques,

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 218
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

mais seront le plus souvent adaptés au métier. Ces fonctionnalités conduiront à la

fois à spécifier les objets d'entreprise qui doivent être gérés et les besoins
correspondants en termes de données, tout en définissant les aptitudes nécessaires
de l'organisation. Sur la base de ces besoins, la conception du système cible portera
sur les indicateurs de performance traduisant les objectifs par rapport aux objets
d'entreprise définis et sur les ressources applicatives nécessaires.
Le choix de solutions de type COTS interviendra à ce niveau. Les
conditions de mise en œuvre seront décrites à la fois dans les vues d'objets qui
permettront de détailler les diverses représentations des informations du système
(états, écrans...) et la définition des rôles de la nouvelle organisation correspondant
aux processus et aux aptitudes définies.
Enfin, le nouveau système d'entreprise mis en œuvre sera suivi par les
indicateurs définis qui constituent les différents tableaux de bord des opérations.
Bien entendu, d'autres construits peuvent être utilisés aux différentes étapes, mais la
séquence « objectifs » (Ob), « pratiques » (Pr), « processus » (BP), « fonctionnalités
attenudes » (Fe), « indicateurs définis » (Me), « données » (Da), « aptitudes
nécessaires » (Ca), « indicateurs définis » (Me), ressources nécessaires (Re),
« organisation » (OU), «indicateurs suivis » (Me) est tout à fait représentative de la
nature d'un projet de ré-ingénierie qui conçoit l'organisation dans une approche
processus afin de servir des objectifs.
La Figure 3.23 présente les étapes d'un projet de type ERP « IT », projet
qui n'implique que faiblement les directions générales et les directions métiers.
Dans ce contexte piloté par la direction informatique, c'est très souvent la
simulation directe sur l'ERP standard installé qui va guider la rédaction de
procédures d'utilisation en parallèle aux décisions de paramétrages. Il n'y a pas
réellement de spécifications du système cible, en dehors des spécifications de
quelques développements ou interfaces nécessaires.
De tels projets peuvent être précédés ou débutés par des approches
orientées maîtrise d'ouvrage de rédaction de cahier des charges représentant les
« besoins », voire intégrant des débuts de modélisation des processus métiers. Mais
sans implication des compétences métiers qui nécessiteraient l'engagement de la
direction générale, l'expérience montre que ces ébauches n'ont que peu d'impacts sur
le déroulement du projet qui sera centré sur le choix d'une solution pour laquelle les
motivations de la direction informatique seront prédominantes (maintien d'un
environnement connu tel que AS400, ou choix du leader incontestable pour des
raisons de « prestige » informatique, au contraire, refus des leaders et recherche de
solutions « libres »...).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 219
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Généricité Vues

Projets de type ERP « IT » Gen. Part. Spec. Func. Inf. Ress. Org.

Domain Identification

Concept Definition

Requirements Definition

Design Specification

Implementation Description Ev EA PR OU

Domain Operation Da Re

Decommission Definition

Figure 3.23. le cadre 19439 et les projets de type ERP « IT »

Le projet commence réellement avec ce choix de solution qui se situe au

niveau opérationnel du cadre 19439, puisqu'il ne s'agit pas de modélisation, mais
bien d'installation et de simulation d'un système standard (simulation au sens de
saisie de données pour réaliser des transactions simulées et évaluer les résultats
notamment en termes de documents produits). Ce sont directement les construits
représentants le système informatique qui sont mobilisés dans le projet (Da, Re).
L'installation et la première configuration des solutions standard représente un
passage du niveau générique à un niveau partiel qui préfigure le système spécifique
et à partir duquel les procédures de travail seront définies. Ces procédures ne sont le
plus souvent pas issues d'une approche processus, au sens d'une réflexion
organisationnelle sur la contribution de ces processus à une finalité, mais
simplement d'une définition évènementielle des activités nécessaires. Les pratiques
et les rôles dans l'entreprise sont définis à travers ces procédures qui peuvent être
regroupées en « manuel utilisateur » représentant les « pratiques » de l'entreprise et
support des formations nécessaires.
Dans un tel projet, la maîtrise de l'intégration est évidemment très difficile
et ne peut être portée par les outils de modélisation qui peuvent être totalement
absents. C'est pourquoi ces projets généreront souvent un très grand nombre de
développements spécifiques pour adapter le système aux habitudes de l'organisation
existante, pour « défaire » des contraintes d'intégration que la solution standard
porte, ou au contraire prendre en compte une contrainte d'intégration de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 220
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

l'organisation existante dont la traduction dans la solution standard n'a pas été
trouvée par un mapping au niveau des activités opérationnelles.
La Figure 3.24 présente un projet de type ERP « BP », projet qui intègre
une volonté de changement de l'entreprise, marqué à la fois par une dimension de
ré-ingénierie forte, libérant des ressources métiers pour contribuer à une réflexion
sur l'organisation, les processus, les rôles à redéfinir, et dans le même temps par la
recherche d'une solution standard, limitant les développements spécifiques en
cherchant à obtenir le plus fort alignement possible entre le standard et les besoins
métiers.

Généricité Vues

Projets de type ERP « BP » Gen. Part. Spec. Func. Inf. Ress. Org.

Domain Identification Ob

Concept Definition BP PR

Fea
Requirements Definition EO Ca

Ev
Design Specification BP EA
Me Da OU

Ev
Implementation Description BP EA
OV Da PR Ca

Ev Da
Domain Operation Me Re OU
BP EA

Decommission Definition

Figure 3.24. le cadre 19439 et les projets de type ERP « BP »

L'entreprise dans ce type de projet accepte le coût de la conduite de

changement nécessaire afin d'obtenir une situation permettant la recherche d'une
contribution forte des S.I. à sa performance. De tels projets ont donc une double
origine et s'organisent le plus souvent autour de deux démarches parallèles de
formalisation du besoin et de prototypage du standard. La première origine conduit
comme dans un projet de type BPR à une réflexion sur les objectifs spécifiques à
l'entreprise et les bonnes pratiques susceptibles d'aider à les atteindre qui sont
recherchées dans des référentiels formels ou informels (Construits Ob, PR, BP en
phase d'identification de domaine et de définition de concept). L'objectif plus
directement opérationnel de ces projets par rapport aux projets BPR conduira à
rechercher des référentiels proches des métiers de l'entreprise, de sa typologie et
nous les considérons donc plutôt comme des modèles partiels dans l'axe de
généricité du cadre 19439. Ces référentiels permettront de s'appuyer sur une

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 221
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

définition générique des processus, dont il faut ensuite organiser le rapprochement

avec des solutions possibles (Construits BP, Fea, Ev, EA, Me, OU...) dans l'itération
entre les phases de définition de besoin et de spécification de conception). Ces
solutions sont étudiées en parallèle à partir des progiciels standard existants, dont le
choix peut s'appuyer sur les modèles partiels de processus qui constituent alors une
forme nouvelle de cahier des charges de consultation (Explicitation des contraintes
de la phase de spécification à partir des simulations faites sur l'ERP en plateforme
de test, en phase d'opération au niveau générique). Loin de la liste détaillée des
fonctionnalités qui souvent est une agrégation de toutes les fonctionnalités
existantes de l'offre, de tels cahiers des charges se concentrent sur les processus
porteurs des objectifs du projet dont les contraintes d'intégration et la qualité des
solutions support doivent être étudiées en détail en limitant l'effort sur les processus
jugés « standard » pour lesquelles une démarche de mise en œuvre rapide est
possible. On est alors au cœur de la « boucle » d'alignement proposée par Soffer
comparant le modèle de solution au modèle de besoin. Il s'agit d'une démarche
itérative basée sur le prototypage de solutions standard, et nécessitant la
codification de données, le paramétrage de ressources, en cohérence avec la
définition de processus, d'objets d'entreprise et en anticipant sur la définition des
compétences nécessaires aux rôles impliqués dans les processus. L'efficacité repose
alors sur la cohérence des différents modèles utilisés, la capacité à en vérifier
l'alignement de manière dynamique selon les décisions prises, les modifications
liées aux résultats des simulations...
La maîtrise de ce type de projet d'ingénierie qui aligne standard et cas
spécifique, spécification du besoin et configuration de la solution, paramétrage du
système et définition des compétences nécessaires des acteurs, rend fortement
nécessaire une approche d'ingénierie d'entreprise « dirigée par les modèles » pour
permettre un alignement dynamique au fur et à mesure du prototypage du système.
Cela nécessite d'être capable de rapprocher des référentiels métiers entre eux dans le
cadre d'un modèle d'entreprise. Ce sera le but de l'intégration d'ontologies dans la
modélisation. Il est aussi nécessaire de représenter le modèle implicité d'une
solution standard en en concevant une vue « fonctionnelle » orientée processus.
Certains ERP le proposent et de nombreux outils de modélisation existants font le
lien avec des ERP et permettent de construire un tel modèle à partir de l'expérience
et d'en vérifier la cohérence avec l'ERP.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 222
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

3.3.3 Démarche d'alignement et graphe d'intégration

D ès que la modélisation intervient, donc à l'exception des projets de type ERP

« IT », elle est le support essentiel des différentes formes d'alignement
recherchées. Elle permet de les représenter comme un alignement entre des points
de vue partiels du modèle que l'alignement met en relation. Nous considérons
l'alignement comme une qualité du graphe d'intégration lié au modèle
d'entreprise. Mais ce graphe est une construction progressive dans la démarche
d'ingénierie. Dans le cas d'un projet de type ERP « BP », la démarche met en
relation une approche descendante qui détaille progressivement objectifs en
pratiques puis en processus et une démarche ascendante qui part des applications, de
leurs données et des processus opérationnels pour construire l'alignement avec le
besoin. La granularité de la modélisation dans ces deux démarches est donc
différente et cela rend nécessaire de garantir la cohérence des passages entre
différents niveaux de granularité dans la modélisation. Ainsi, on passe du concept
au besoin en spécialisant des construits génériques à partir des ontologies métiers
disponibles. Un processus de vente se spécialise par exemple en processus de vente
de matières dangereuses, dont une ontologie métier peut définir les caractéristiques
dans l'industrie chimique soumise à des normes strictes. S'il existe une dépendance
générique entre processus de vente de marchandises et documents d'expéditions, il
existe une dépendance particulière entre un processus de vente de matières
dangereuses et la déclaration de transport de matières dangereuses. Le graphe
d'intégration se construit donc par morceaux que l'alignement entre deux modèles va
relier et à différents niveaux de granularité qu'il faudra « coudre » parfois en
instanciant une relation du modèle qui n'est pas nécessairement pré-définie dans un
des modèles génériques ou partiels utilisés.
Mais les projets qui nous intéressent peuvent être de nature très différente,
des projets « de conception » tels que les projets ERP « BP » évoqués
précédemment. Ils peuvent être des projets de ré-ingénierie, de changement de
version d'un ERP, ou de maintenance d'un système en exploitation (évaluation des
usages d'un système ERP). Dans tous les cas, les acteurs vont chercher à modéliser
l'existant et la cible de différents points de vue en confrontant des expériences
métiers diverses. La démarche de modélisation ne sera donc que rarement une
démarche ex nihilo dans laquelle les acteurs peuvent construire progressivement un
modèle en assurant la cohérence complète par la qualité propre de la conception. Le
plus souvent, elle sera confrontée à une représentation partielle de systèmes
existants, à des normes ou standards dont l'utilisation est imposée ou considérée
comme nécessaire, à des solutions standard qui apportent leurs propres contraintes.
De fait, la modélisation dans tous les types de projet va nécessiter de « mettre en

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 223
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

relation » différents modèles. C'est ainsi au cœur de la modélisation que peut se

définir de manière précise la notion d'alignement. A chaque phase de modélisation,
des modèles partiels d'origine différente sont rapprochés afin d'en assurer la
cohérence. Cette cohérence est portée par l'ensemble des dépendances entre ces
modèles, et aussi par l'insertion de ces modèles dans le modèle global. L'alignement
est donc une qualité du « graphe d'intégration ». La modélisation ne peut se limiter
à une vue locale des dépendances dans une vue partielle du modèle. L'alignement
doit se construire avec le graphe d'intégration pour tenir compte des contraintes non
locales, pour aider à situer un modèle partiel dans son contexte d'intégration. On
peut donc caractériser les situations d'alignement en référence aux différentes
positions possibles dans la démarche d'ingénierie présentée dans la section
précédente. Le Tableau 3.15 et la Figure 3.25 présentent ces différentes situations
d'alignement possibles en les situant dans une phase de modélisation du cadre
19439 et un niveau de spécialisation de l'axe de généricité. La Figure 3.25 place les
différents modèles possibles dans le cadre de modélisation. Les différents types
d'alignement possibles sont représentés par une flèche dont le numéro renvoie au
Tableau 3.15. Chaque alignement est ainsi défini comme une relation entre deux
modèles, caractérisés par leur niveau de généricité et la phase de modélisation où ils
sont pertinents. On peut alors construire pour chaque alignement un méta-modèle
particulier reprenant les construits concernés et surtout les dépendances qui
conditionnent cet alignement.
La qualité de l'alignement peut alors être étudié comme une caractéristique
de cette relation extraite du graphe d'intégration. Le « bon alignement » est celui qui
« conserve » les structures de chacun des modèles dans la relation. Les construits du
modèle A qui sont « proches » doivent être liés à des construits du modèle B qui
sont proches. Les structures hiérarchiques des construits du modèle A doivent être
dépendantes de structures hiérarchiques du modèle B. On peutt proposer une
définition formalisée de l'alignement. Deux modèles sont alignés si les dépendances
qui les lient représentent une relation monotone pour la distance d'intégration. Notre
approche de partitionnement présenté en page 201 est alors un outil d'identification
de « mauvais alignement », quand une partition calculée ne correspond pas à une
structure hiérarchique existante.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 224
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Généricité

Phases Gen. Part. Spec.

Domain 3
Identification
DI 1
Concept
CD
Definition
Requirements
5
RD
Definition
2 4 8
Design
DS
Specification
Implementation 6 7
ID
Description
Domain
DO
Operation
Decommission
De
9
Definition 6

Figure 3.25 Alignement entre modèles dans le cadre d'intégration

Modèle A Modèle B
Type d'alignement entre les modèles
N Phase Génér. Phase Génér.
1 CD - RD Génér. - CD - RD Génér. - Alignement de Référentiels (Ontologies)
Pariel Partiel
2 CD - RD Génér. - DO Génér. - Mapping COTS sur Référentiel
Partiel Partiel
3 DI - CD Spéc. CD Partiel Conception d'un périmètre projet à partir de
référentiels
4 CD - RD Génér. - RD - DS Partiel Adaptation d'un référentiel a un contexte
Partiel métier (ontologies)
5 RD - DS Partiel RD - DS Spéc. Mapping modèle métier / modèle standard
6 DO Génér. - ID Spéc. Simulations/Paramétrage d'un COTS pour
Partiel définir des procédures de mise en œuvre.
7 RD - DS Partiel DS Spéc. Conception du système cible à partir de
modèle standard
8 DS Spéc. ID Spéc. Conception de la mise en œuvre
9 ID Spéc. DO Spéc. Alignement des usages sur les bonnes
pratiques décrites.

Tableau 3.15 : Typologie d'alignement de modèles dans la démarche

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 225
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Le positionnement entre partiel et spécifique est bien entendu utile pour

souligner la pertinence de modèles partiels, plus facilement alignable avec un
besoin spécifique. Cependant, dans une démarche d'ingénierie, le modèle de projet
évolue constamment et se retrouve de fait dans une situation mixte entre partiel et
spécifique.
Cette représentation souligne l'importance de travaux sur l'alignement au
niveau générique des différents référentiels possibles (SCOR et OAGIS par
exemple), mais aussi de l'alignement entre ces référentiels métiers et les
applications standards.
L'alignement entre deux modèles peut se traduire par différentes activités
de modélisation :
Les modèles peuvent être en partie complémentaires et l'alignement consiste à
ajouter des dépendances qui explicitent cette complémentarité.
Les modèles peuvent se recouvrir, et l'alignement nécessitera de fusionner des
objets en consolidant leurs définitions et dépendances.
Un modèle peut être construit comme une spécialisation d'un autre. L'alignement
consiste alors à construire le premier par instanciation du deuxième. L'enjeu de la
démarche de modélisation est alors de conserver la traçabilité de ce travail, pour
permettre à tout moment de « remonter » à l'objet générique pour étendre son
implémentation en s'appuyant sur les dépendances existantes au niveau
générique.

La Figure 3.26 présente un exemple de cadre de modélisation dans lequel

différents modèles utilisés dans un projet d'ingénierie sont mis en relation :
RFP : le modèle d'expression des besoins par l'entreprise
SCOR, OAGIS : des référentiels métiers utilisés comme base de connaissances
OWL : des ontologies métiers complémentaires aux référentiels
ERP : le modèle de l'ERP dans ses différentes instanciations au fil du projet.
Le graphe d'intégration et ses caractéristiques restent au cœur des
dépendances entre ces différents modèles.
Les exemples suivants correspondants à la figure illustrent certaines de ces
situations typiques d'une construction progressive du modèle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 226
Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Généricité

Phases Gen. Part. Spec.

Domain
DI
Identification RFP
Concept
CD
Definition
SCOR
Requirements OWL
Definition
RD Graphe BPM
rayon, degré
Design
DS OAGIS couplage ERP
Specification distanceconfiguré
longueur ERP
Implementation
ID EDI
Description adapté
Domain
DO
ERP ERP ERP
Operation démo installé utilisé
Decommission
De
Definition

Figure 3.26 exemples d'alignement entre modèles

La correspondance entre deux ontologies qui se recouvrent dans la définition de
certains objets métiers. Ainsi, le référentiel SCOR définit des informations
échangées entre processus que normalisent aussi le référentiel OAGIS. S'il
n'existe pas de correspondance prédéfinie, un modèle d'entreprise utilisant les
deux référentiels devra « mapper » les objets d'entreprise correspondants. Dans ce
cas, il s'agit d'éviter une redondance du modèle en considérant que deux
définitions portées par des référentiels recouvrent le même objet du modèle. Cette
correspondance peut être une fusion de deux objets du niveau générique en un
objet du modèle partiel ou spécifique. Les dépendances existantes de ces deux
objets génériques sont alors cumulées sur le nouvel objet qui sera de fait plus
connecté que chacun des deux objets précédents et donc dont les distances avec
d'autres seront transformées. La comparaison des voisinages des objets au niveau
générique et des voisinages après fusion au niveau spécifique peut être un atout
dans la compréhension des conséquences de cette fusion.
Les contraintes d'intégrité informatique sont « activables » par paramètres qui
sont définis progressivement dans le projet. Une dépendance peut donc exister
« en principe » au niveau générique et être « désactivée » par une décision de
modélisation traduite dans le paramétrage de l'ERP. Le graphe d'intégration se
spécialise donc au fil de la spécialisation d'objets du modèle en se simplifiant des
contraintes génériques qui n'existent plus à un niveau particulier ou spécifique.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 227
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

On doit pouvoir caractériser le modèle en cours de travail par les conséquences

d'une (des)activation d'un paramètre.
La faisabilité d'une solution est dépendante de la capacité à dimensionner les
tâches de conduite de changement nécessaires. Pour cela, la capacité à relier le
système existant au modèle en cours d'ingénierie est essentielle, notamment à
« affecter » les objets du système aux acteurs de l'organisation pour éclairer le
« qui fait quoi », autant dans le système cible que pour le projet. Il faut pouvoir
lister les connaissances nécessaires aux différents acteurs, vérifier comment le
futur système produit les indicateurs existants ou redéfinis. On va donc chercher à
caractériser les conséquences du projet sur un modèle organisationnel existant et
transformé.

D ans ces différentes situations d'alignement, le modélisateur est toujours dans

une représentation partielle du système, à la fois en termes de vues et de
périmètre. La totalité du modèle et donc de ses contraintes d'intégration, ne peut
être rendue visible. Nous avons montré dans la section 3.2.2 que les dépendances
directes, correspondantes aux relations existantes du modèle ne sont pas suffisantes
pour expliciter l'ensemble de ces contraintes. Le graphe d'intégration et les outils
associés, (voisinages et partitions) sont indispensables pour aider le modélisateur à
prendre des décisions « localement efficace pour la vue partielle du modèle sur
laquelle il travaille, mais globalement cohérente avec les contraintes
d'intégration impactant les objets de sa vue partielle par transitivité ».
Cette cohérence entre le local et le global d'un système est une
caractéristique bien connue de la complexité. Notre proposition fondamentale est
bien d'outiller une démarche d'ingénierie par la prise en compte du graphe
d'intégration dans la modélisation afin de faciliter l'alignement entre des modèles
partiels. Cela suppose un environnement de modélisation adapté, capable de
représenter les voisinages d'un objet au sens du couplage dans le graphe, les
partitions calculées à partir de la distance d'intégration, de caractériser les vues
partielles du modèle par des indicateurs de structure du sous-graphe comparée aux
caractéristiques globales du graphe total :
Le diamètre indique l'étendue du modèle au sens de l'intégration.
Le rayon représente une bonne mesure du niveau d'intégration du modèle. Dans
un modèle à faible rayon, tout objet est relativement proche de tout autre, et donc
relativement dépendant, alors qu'à l'inverse, dans un graphe de rayon élevé, des
objets sont relativement distants et donc faiblement couplés.
La dispersion des degrés de sommets dans le graphe indique l'homogénéité plus
ou moins forte de l'intégration. Des objets à fort degré sont des objets saillants de
l'intégration, comme l'ERP dans le cas académique présenté en section 3.4.1. Ces

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 228
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

objets sont les points principaux de l'intégration et sont donc à la fois critiques et
centraux dans les projets d'ingénierie.
De même, l'alignement n'est jamais une situation parfaite qui pourrait être
définie théoriquement dans le modèle puis traduite dans le système. Il ne peut être
qu'un processus toujours en cours pour obtenir un « meilleur alignement », un
« réalignement » dans un contexte évolutif, avec par exemple, une nouvelle
application, une nouvelle situation du marché, de nouvelles ressources, de nouveaux
objectifs... L'alignement doit donc tenir compte de la nature socio-technique de tout
système d'entreprise que nous avons traduit par les caractéristiques de force et de
maturité des dépendances présentées en section 3.2.7. Une dépendance
« technique » sur des construits pilotés avec une faible maturité sera un point de
faiblesse de l'alignement. La « qualité » d'alignement d'un modèle suppose donc un
niveau de maturité des dépendances qui portent cette maturité.
Afin d'illustrer cette démarche d'ingénierie dirigée par l'intégration, nous
proposons une représentation imagée d'un atelier de modélisation intégrant les
fonctionnalités listées ci-dessus. La Figure 3.27 représente une esquisse d'un tel
atelier dans lequel un modèle partiel en cours d'édition est « contextualisé » par
différentes vues du contexte d'intégration :
Les voisinages d'un objet sélectionné, pour les différents points de vue (flèches
ordonnant des objets dans un cadre à haut à droite).
Une partition correspondant à l'ensemble des objets utilisés dans le modèle et
leurs voisins proches (cercles groupant des objets en bas à droite). Cette partition
peut faire apparaître des structures d'intégration qui peuvent être une aide pour
décider d'une structuration du modèle.
Des mesures caractéristiques des graphes correspondants au modèle partiel en
cours d'édition, au modèle global, à la partition affichée... (taille, degré,
diamètre...) (légende en haut à gauche). La partition peut être caractérisée par le
nombre de parties, la variance interclasse représentant l'efficacité de la partition.
Des filtres permettant de prendre en compte uniquement les dépendances
« fortes » du modèle, à caractère technique, ou de tenir compte de l'ensemble des
dépendances, éventuellement d'une maturité minimum ou au contraire maximum
pour étudier un graphe représentatif des points de faiblesse de l'organisation
(encart en bas).
Des informations détaillées associées à un objet ( fenêtre associée à une
dépendance au milieu du cadre présentant la vue encours du modèle), permettant
de connaître la force et la maturité d'une dépendance.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 229
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Figure 3.27 Environnement de modélisation dirigé par l'intégration et les modèles

On utilise ainsi dans un environnement de modélisation d'entreprise les

modèles de référence porteurs des métiers, des bonnes pratiques, des solutions
standard,... et les caractéristiques du graphe d'intégration outillé pour caractériser un
modèle et une vue partielle. L'ensemble de cet environnement permet ainsi de
« modéliser localement en concevant globalement » afin d'aider à la prise en compte
de l'ensemble des contraintes d'intégration dans une vue partielle d'un modèle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 230
 Démarche d'ingénierie orientée intégration / Ingénierie d'entreprise orientée intégration

Nous avons étudié dans le cadre de notre méta-modèle d'intégration

les relations entre les construits nécessaires à un modèle d'entreprise
et qui portent les différentes formes de dépendances internes au
système d'entreprise. Les dépendances informatiques issues des
contraintes des logiciels sont en général précises et calculables à partir
de la connaissance détaillée des applications. Elles sont souvent
« paramétrables » ce qui permet de les activer ou les désactiver selon
les besoins d'une entreprise. Les dépendances organisationnelles sont
plus difficiles à identifier et à caractériser. La difficulté fréquente à
publier un organigramme à jour d'une entreprise est révélateur du fait
qu'une organisation repose largement sur de l'informel, du compromis
qui donne « du mou », donc de la flexibilité aux décideurs.

Nous ne proposons pas une structuration à priori de ces dépendances,

mais une représentation permettant de découvrir les structures que
ces dépendances imposent ou révèlent sur le modèle d'entreprise.
C'est pourquoi nous considérons l'ensemble des dépendances comme
un « graphe d'intégration » à partir duquel nous cherchons à
construire des « représentations » du modèle afin de révéler l'enjeu
des contraintes d'intégration pour les différents points de vue. La mise
en œuvre de telles « représentations de l'intégration » à partir de
l'étude des dépendances peut aider à constater l'incohérence de sous-
modèles, à prendre une décision sur un des points de vue dans
l'objectif de progresser dans la modélisation en ajoutant ou levant une
contrainte.

Nous étudions ce « graphe d'intégration » localement pour caractériser

des « chaînes d'intégration » entre deux objets, qui permettent de
définir une distance et un couplage entre objets à partir de leur
connexité comparée.

Le couplage entre objets permet de définir le voisinage d'un objet qui

représente un « contexte d'intégration » dont le modélisateur doit
tenir compte.

La distance entre objets permet de définir une partition significative

des conséquences de l'intégration sur la structuration du modèle.

Enfin, nous proposons de propager la maturité évaluée des entités

organisationnelles pour colorer le graphe par cette maturité.

Nous avons ainsi un cadre d'étude, un méta-modèle de construits, des

graphes d'intégration permettant de construire des voisinages et des
partitions qui constituent les outils de base de notre étude de
l'intégration organisationnelle et informationnelle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.3
Institut National des Sciences Appliquées de Lyon 231
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Chapitre 3.4
Illustration sur des cas
académiques et réels

Nous allons illustrer le cadre de modélisation et son graphe

d'intégration sur un cas académique, construit à partir de notre
expérience métier et défini sous forme d'un modèle d'entreprise. Nous
avons réalisé les calculs de distance, de couplage et évalué la
pertinence des outils proposé de voisinage et de partitionnement.

Nous étudions ensuite deux cas issus d'applications réelles. Le premier

concerne l'ERP BAAN déjà cité, autant pour l'étude de sa structure
technique que pour le mapping fonctionnel des processus aux
fonctions support de l'ERP. Le deuxième concerne le référentiel de la
chaine logistique SCOR dont nous étudions l'alignement entre vue
métier et vue système d'information.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 233
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

3.4.1 Illustration sur un cas académique

P our illustrer notre cadre

d'entreprise simplifié pour
pouvant faire l'objet de manière
d'étude de l'intégration, nous utilisons un cas
obtenir un graphe d'intégration de taille limitée et
aisée d'une représentation sous forme de graphe et
de matrice d'adjacence. Nous l'appellerons E104 car le graphe correspondant
contient 104 objets.
Il s'agit d'une entreprise industrielle transformant des matières en produits
finis en une seule étape de production, avec un processus de vente, un processus
d'approvisionnement et un processus de production. Son organisation est limitée aux
services de base (achat, production, planification, ventes, comptabilité). Nous avons
simplifié légèrement le méta-modèle en fusionnant les construits EO et OV,
considérant que chaque objet était utilisé dans toutes les fonctions avec la même
vue. Nous considérons que la gestion de la demande est hors périmètre, que la
traçabilité de planification n'est pas assurée... Les objets du modèle sont présentés
dans les tableaux suivants regroupés par points de vue (Tableau 3.16, Tableau 3.17,
Tableau 3.18).
Pratices Capability Objectives Organizational Unit
Pr-InvCyc CA-Manage Ob-Top10F OU-Purchase
Pr-MRPII CA-Make Ob-TS>99 OU-Sales
Pr-FullDel CA-Source Ob-TimeCycle OU-Shop-Floor
Pr-NotFou Ob-ATP> OU-Warehouse
Pr-FlowSync Ob-CashCycle OU-Accounting
Pr-RelTiers OU-Planning
Tableau 3.16 : liste des objets organisationnels du modèle E104

Les relations entre ces objets ne sont pas listées compte tenu de leur
nombre (234) mais sont représentées dans le graphe de la Figure 3.28 . Dans cette
figure, les objets sont regroupés par construits avec une coloration correspondant
aux points de vue. Les groupes « Data, Features, Practices et Objectives » sont
détaillés, les autres groupes sont condensés sur un objet graphique ce qui permet de
faire ressortir la structure générale au niveau des construits. Cette représentation est
un exemple de la hiérarchisation nécessaire du graphe pour en permettre des
représentations utilisables. Même sur ce modèle simplifié, la structure du méta-
modèle ne permet pas de représenter de manière pertinente l'intégration. En effet, de
nombreuses dépendances traversent cette structuration et nous allons montrer sur
cet exemple simple, la pertinence des différents outils proposés dans notre démarche
d'ingénierie dirigée par l'intégration.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 234
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Features Event Enterprise Activity Business Process

Fea-Selling Ev-CusReq EA-Release BP-Plan
Fea-Shipping Ev-OrdConf EA-SelectSupplier BP-Source
Fea-Invoicing Ev-SOP valid EA-PurORder BP-Make
Fea-Forecasting Ev-OrdPro EA-PurReceipt BP-Deliver
Fea-Planning Ev-OrdTrans EA-Forecast BP-Account
Fea-Scheduling Ev-Shortage EA-SOP
Fea-Purchasing Ev-ProdDecl EA-MRP
Fea-Warehousing Ev-Receipt EA-Produce
Fea-Accounting Ev-Shipment EA-Schedule
Fea-Producing Ev-SupInv EA-Sale
Ev-InvoiceCleared EA-Deliver
Ev-Paiement EA-Invoice
Ev-Forecast updated EA-Clearing
Ev-OrdAvailable EA-Closing
Ev-Period EA-Controling
Ev-SalInv EA-Budget
EA-Paying
Tableau 3.17 : Liste des objets de la vue fonctionnelle du modèle E104

Data Enterprise Object Resources

Da-PlanOrd EO-SalesO Re-Machine
Da-MObom EO-PurchaseO Re-Stocks
Da-SO EO-ManufactO Re-Truck
Da-PO EO-EntPlan Re-Expert
Da-Manuf-Order EO-RawMat Re-ERP
Da-Item EO-SalesI Re-APS
Da-SI EO-PurchaseI Re-SRM
Da-PI EO-WorkCenter
Da-WC EO-Customer
Da-Customer EO-Supplier
Da-SUP EO-Warehouse
Da-WH EO-Forecast
Da-MPS EO-MPS
Da-Gen-Ledger EO-PlanOrd
EO-GenLedger
Tableau 3.18 : liste des objets informationnels et ressource du cas E104

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 235
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Figure 3.28. graphe d'intégration du cas d'entreprise E104

La complexité est visible dans la Figure 3.29 qui présente le graphe après
positionnement des sommets par un algorithme de force et « routage » des arêtes
autour des sommets pour en faciliter la lecture.
Dans cette nouvelle figure, on visualise bien le rôle central de l'ERP, qui se
retrouve au centre du graphe compte tenu qu'il est le sommet de plus fort degré du
graphe, et naturellement son centre, mais on mesure aussi la nécessité de construire
des points de vue « utilisables », nécessairement partiels compte tenu de la
complexité du graphe, mais qui ne peuvent être simplement issus du méta-modèle
d'entreprise dont la structure en classes d'objets est une vue illustrative d'une
architecture sans éclairer l'intégration transverse a cette structure.
C'est ce que les outils issus du graphe d'intégration que nous proposons
permettent de construire. Pour cela, nous représentons le graphe E104 dans un outil
de calcul 29 avec lequel nous avons développé des outils d'analyse des graphes
d'intégration. Le graphe est représenté par une structure listant les sommets origine
et destination de chaque arête. Un premier algorithme construit une matrice des
voisins de chaque sommet, puis un deuxième algorithme utilise cette structure pour
calculer les matrices de couplage et de distance. Un troisième algorithme calcule un
partitionnement par un algorithme spécifique de type classification hiérarchique
ascendante, reposant sur un critère de sélection adapté des centres de classification.
Un autre outil de classification basé sur Excel a été utilisé pour diversifier les

29 Scila, outil de calcul numérique développé par l'INRIA [Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 236
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

critères de classification et comparer les résultats à des méthodes de type k-means.

Enfin un algorithme de positionnement du graphe par équilibre de force a été réalisé
en complément du logiciel utilisé pour obtenir des visualisations utilisables de
graphes. Ces outils ont été utilisés pour le cas académique et les cas réels présentés
dans les sections suivantes.

Figure 3.29. graphe d'intégration du cas E104 avec algorithme de force

Les temps de calculs pour la construction des chemins confirme la

complexité évoquée dans la section 3.2.6. Le calcul des voisins pour le cas E104 ne
prend que 15s sur un portable DELL630 (INTEL Core CPU 2Ghz, 2Go RAM) 30, et
se confirme comme un outil capable de passer à l'échelle d'un graphe correspondant
à un projet ERP qui peut être estimé à 10 5objets. Le Tableau 3.19 donne les temps
de construction des graphes permettant le calcul des distances en fonction du
paramètre de longueur d'intégration, ainsi que le nombre de chemins
correspondants.
Longueur Temps (s) Nb chemins
2 30 788
3 92 4855
4 796 25862
5 23455 134578
Tableau 3.19 : temps de construction des graphes d'intégration (cas E104)

30 L'ensemble des calculs décrits dans ce document ont été effectués sur cette machine

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 237
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

La pertinence du rayon du graphe comme paramètre de longueur

d'intégration est confirmée dans ce cas. Le Tableau 3.20 montre que c'est la
longueur 3 qui permet de discriminer le mieux les couplages entre objets du cas
E104. Il présente pour chaque longueur en colonne, le nombre de couples de
sommets dont le couplage est compris dans la dizaine correspondante de la ligne.
On voit que la longueur d'intégration 1 ou à l'inverse proche du diamètre ne mesure
pas de distance significative puisque tous les sommets sont équivalents. La valeur
optimale est bien 3 ce qui correspond au rayon du graphe E104. Nous utilisons donc
cette valeur pour choisir les matrices de couplage, et distance dans la suite des
calculs.
Couplage max Longueur=1 Longueur=2 Longueur=3 Longueur=4 Longueur=5
10 10811 8388 520 0 0
20 4 726 640 0 0
30 0 86 591 0 0
40 1 12 499 0 0
50 0 1446 1245 18 0
60 0 129 1172 16 0
70 0 23 1328 102 0
80 0 4 1097 217 0
90 0 1 883 211 0
100 0 0 674 206 0
110 0 0 338 281 0
120 0 0 157 547 0
130 0 0 45 410 0
140 0 0 24 192 0
150 0 0 0 199 0
160 0 1 1151 400 0
170 0 0 305 598 14
180 0 0 101 945 193
190 0 0 36 886 4
200 0 0 9 1570 26
210 0 0 0 1316 581
220 0 0 0 940 613
230 0 0 1 1762 9385
total 10816 10816 10816 10816 10816
Tableau 3.20 : Couplages répartis par dizaine selon la longueur d'intégration

Dans un premier temps, nous utilisons la matrice de couplage pour établir

des voisinages. Nous prenons un exemple centré sur l'objet « EO-EntPlan » dans un
modèle en cours de construction centré sur le processus de planification. Des objets
de différents types sont placés dans le modèle. Le processus « P » de planification
est décrit par l'objectif « ATP » avec les activités d'entreprise « Forecast », « SOP »

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 238
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

et « MRP » qui sont déclenchés par les évènements « Forecast update » et « SOP
validated ». Deux objets d'entreprise sont concernés, le « plan MPS » et les « ordres
planifiés ». Le modèle utilise les données « Ordre planifié », « MPS » et les
applications « APS » et « ERP ». L'objet «EntPlan » est positionné dans le modèle
et le modélisateur cherche à connaître le contexte d'intégration de cet objet. Les
calculs de couplage permettent d'identifier les objets qui lui sont liés fortement dans
l'ordre décroissant de leur couplage. Le Tableau 3.21 présente les couplages pour
cet objet présenté par ordre décroissant et pour chaque point de vue en colonne. Une
valeur limite est proposée pour identifier les « voisins » de chaque point de vue qui
sont colorés. La structure du graphe fait que cette limite est variable selon le point
de vue, sachant que le couplage maximal dans ce graphe est de 233.
Fonctionnelle Informationnelle Organisationnelle Ressources
Ev-Period 133 EO-PurchaseI 115 OU-Compta 121 Re-APS 80
EA-Produce 133 EO-PurchaseO 98 Ob-TS>99 116 Da-WC 70
Fea-Producing 117 EO-RawMat 95 Pr-FullDel 111 Da-WH 67
Fea-Purchasing 114 EO-Customer 86 Pr-FlowSync 111 Re-Stocks 62
Fea-Warehousi 113 EO-MPS 82 OU-Magasin 111 Re-Camion 58
Fea-Selling 112 EO-PlanOrd 76 OU-Achat 106 Re-SRM 55
Ev-Shortage 110 EO-Warehouse 75 Pr-MRPII 105 Re-Expert 52
Ev-ProdDecl 109 EO-Supplier 75 Ob-Top10F 105 Re-Machine 50
Fea-Scheduling 108 EO-SalesI 70 OU-Planning 102 Da-SUP 40
Ev-Paiement 108 EO-WorkCente 61 Pr-InvCyc 97 Re-ERP 39
BP-Account 107 EO-SalesO 60 Ob-ATP> 95 Da-SI 28
Fea-Shipping 106 EO-EntPlan 55 CA-Manage 93 Da-Manuf-Orde 21
EA-Paying 104 EO-ManufactO 45 Ob-TimeCycle 92 Da-Gen-Ledger 21
Ev-SOP valid 102 EO-GenLedger 45 Ob-CashCycle 92 Da-Item 17
Fea-Planning 101 EO-Forecast 43 CA-Source 92 Da-PlanOrd 13
Fea-Forecastin 101 OU-atelier 64 Da-MObom 13
Fea-Accounting 99 Pr-NotFou 60 Da-Customer 12
EA-Invoice 97 CA-Make 60 Da-PO 11
EA-Forecast 97 Pr-RelTiers 40 Da-MPS 10

Tableau 3.21: Couplages dans le graphe E104 pour l'objet EA-Produce

On peut représenter pour l'utilisateur cette priorité de couplage dans une

interface graphique de modélisation en présentant sous forme de bloc par point de
vue, les objets dans l'ordre décroissant de leur couplage. Cette vue qui intègre le
couplage dans un environnement de modélisation est présentée dans la Figure 3.30
où les voisinages reprennent la couleur des points de vue correspondants. Dans cette
figure, chaque « voisinage » place les objets concernés dans l'ordre de couplage
décroissant de gauche à droite.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 239
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Figure 3.30 modèle partiel et voisinages par point de vue de l'objet EP.

Enfin, nous utilisons la distance pour construire un partitionnement du

graphe E104. Comme pour le couplage, on constate que la longueur d'intégration
qui donne la mesure la plus discriminante comme distance correspond au rayon du
graphe. Le Tableau 3.22 présente la répartition des dissimilarités calculées par
dizaine et par longueur d'intégration. Les distances pour la longueur 1 (colonne 2)
comme celle pour la longueur 5 (dernière colonne) ne permettent pas de construire
une distance efficace pour discriminer les sommets du graphe puisque les distances
sont faiblement distribuées et donc que les sommets sont le plus souvent presque
équidistants. Nous retenons encore la longueur d'intégration 3 pour la suite des
calculs de partitionnement et nous utilisons la distance (dissimilarité relative)
comme mesure pour la classification.
Nous savons qu'il n'existe pas de classification « absolue » pour tous les
usages possibles. Les méthodes de classification hiérarchique proposent un nombre
de classes non pré-determiné au contraire des méthodes d'allocation autour de
centres mobiles (k-means). La pertinence d'une classification peut être évaluée par
la variance des distances inter-classes comparée à la variance totale. Ce critère
mesure le pouvoir de « séparation » entre les classes. On peut aussi chercher à
évaluer la « densité » des classes constituées. Nous avons privilégié pour des
raisons pratiques la mesure de variance, et nous avons surtout évalué la pertinence
métier des classes à partir de notre connaissance du modèle E104.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 240
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Dissimilarité max Longueur=1 Longueur=2 Longueur=3 Longueur=4 Longueur=5

10 7330 164 194 1772 8492
20 3280 478 304 720 1152
30 0 1510 452 1794 766
40 0 1640 540 1518 198
50 204 1202 456 1094 8
60 2 1362 270 828 186
70 0 1836 398 462 14
80 0 1340 622 368 0
90 0 800 778 332 0
100 0 240 1028 202 0
110 0 68 1558 492 0
120 0 48 1512 474 0
130 0 4 940 338 0
140 0 4 658 156 0
150 0 44 462 54 0
160 0 72 322 200 0
170 0 4 206 12 0
180 0 0 76 0 0
190 0 0 28 0 0
200 0 0 2 0 0
210 0 0 8 0 0
220 0 0 2 0 0
230 0 0 0 0 0

Tableau 3.22 : Dissimilarité du graphe E104 selon la longueur d'intégration

Nous avons donc comparé les résultats obtenu par une classification
hiérarchique utilisant différentes distances (simple, moyenne, distance de Ward) et
une classification de centre mobiles (k-mean) en tenant compte du nombre de
classes et de la répartition de la variance inter/intra classes. La comparaison des
méthodes de classification hiérarchique (Tableau 3.23) montre surtout l'importance
du choix de la règle d'agrégation qui sera utilisée. Le nombre de classes obtenues
sur le graphe E104 varie fortement pour des variances interclasses proches.
variance interclasse nombre de classes
Méthode d'agrégation : Méthode de Ward 62% 3
Méthode d'agrégation : Lien proportionnel 84% 12
Méthode d'agrégation : Lien simple 93% 42
Méthode d'agrégation : Lien complet 81% 13
Méthode d'agrégation : Méthode de Ward 62% 3
Méthode d'agrégation : Lien moyen 57% 9

Tableau 3.23 : Comparaison méthode de classification hiérarchique ascendante

La méthode de Ward donne quelque soit la distance un nombre de classes

faible avec une variance intraclasse qui reste forte (près de 40%). La classification

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 241
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

est dans ce cas peu efficace. La méthode du lien simple éclate le graphe en un très
grand nombre de classes (42 pour 104 objets). C'est la méthode du lien
proportionnel qui propose une classification significative en nombre de classes et en
séparation des classes. Cependant, 4 classes générées ont 1 ou 2 objets seulement.
L'utilisation d'une méthode de partitionnement k-means permet de
comparer les partitionnements en fonction du nombre de classes demandé. Dans
tous les cas, la classification fournit des partitions inégales, une classe regroupant
un grand nombre de sommets et d'autres de plus petite taille. Le Tableau 3.24
présente les résultats :

Nb de groupes 5 6 7 8 9 10 11 12 13 14 15
variance interclasses 81% 83% 85% 85% 86% 86% 87% 87% 88% 88% 89%
taille moyenne 20,8 17,3 14,9 13,0 11,6 10,4 9,5 8,7 8,0 7,8 6,9
taille maximum 40 40 40 40 40 40 40 40 24 21 22
taille minimum 6 6 6 4 2 3 2 3 1 2 1

Tableau 3.24 : Comparaison partitionnement selon nombre de groupes

Le choix du nombre de classes nécessite d'étudier leur contenu. La classe

de grande taille regroupe dans plusieurs cas l'essentiel des Data, Features, et
Enterprise Activity. Le partitionnement a donc partiellement reconstruit la
classification des construits. Mais d'autres classes prennent une signification métier.
Ainsi on voit apparaître dans plusieurs cas une classe contenant les objets BP-A
(processus comptable), EO-GL (Grand Livre), EO-PI (facture fournisseur), EO-SUP
(fournisseur), Ev-InvoiceCleared (facture rapprochée), Ev-Paiement (paiement), Ev-
Period (période), Ev-SalInv (facture client), Ev-SupInv (facture fournisseur), Pr-
RelTiers (relance fournisseur).
L'analyse des classes peut conduire à s'interroger sur le modèle. Ainsi
dans l'exemple ci-dessus, si la classe semble regrouper les informations à caractère
financier, elle peut sembler incomplète. L'objet d'entreprise SI « facture client» n'est
pas regroupé dans la même classe, alors que c'est le cas pour l'évènement
correspondant (Ev-SalInv). On peut donc s'interroger sur les relations autour de cet
objet. La différence entre EO-SalesInv et EO-PurchaseInv du point de vue de
l'intégration repose en fait sur la présence de l'objet SRM qui n'a pas son équivalent
du coté commercial dans le cadre de ce modèle simplifié.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 242
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Figure 3.31 graphe interclasses après partitionnement 8-means.

On peut aussi utiliser le partitionnement pour donner une vue agrégée du

graphe. La Figure 3.31 présente ainsi les 8 classes générées par un partitionnement
k-means et leurs relations dans le modèle. Malgré la simplification due au
partitionnement, le graphe est fortement corrélé. Une classe fait exception car elle
semble être faiblement lié au graphe dans son ensemble et pouvoir être facilement
rattaché à une autre classe. Cette classe isolée contient les objets suivants : Fea-
Forecasting, EA-Forecast, Ob-Cycle, Ob-ATP, OU-atelier, OU-Planning. Ces objets
sont cohérents et centrés autour de la maîtrise du disponible. Le super-graphe reliant
les classes nous confirme que l'intégration est forte. En dehors d'une classe
faiblement dépendante, le degré des sommets est élevé ((4+3+4+4+3+4+6) avec une
moyenne de 4). La réalité de l'intégration apparaît dans ce graphe qui est proche du
graphe complet. Certaines classes présentent un point de vue particulièrement
significatif. Les classes C6 et C7 sont centrées sur la planification. Dans la Figure
3.32 les objets de ces deux classes ont été positionnés automatiquement par un
algorithme de force.
Cette vue permet de s'interroger sur l'évènement « SOP Validation » non
lié aux activités de planification dans cette vue mais qui, étant présent dans cette
partition est proche des autres objets. Le graphe d'intégration peut ainsi à la fois être
un outil d'explicitation de l'intégration masquée dans le modèle et qu'il est
nécessaire de révéler au modélisateur, ou au contraire être un outil d'interrogation
du modèle par le modélisateur dont l'expérience le conduit à critiquer la
représentation de l'intégration que porte le graphe.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 243
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Figure 3.32 Classes C6,C7 du partitionnement K8 du graphe E104

D'autres dispositions, notamment hiérarchiques sont possibles et

permettent de générer des « points de vue » particuliers de l'intégration, regroupant
des objets proches qui sont ou ne sont pas liés dans le modèle. Le partitionnement
peut aussi être utilisé sur un sous-graphe, notamment sur un des construits afin
d'aider à la structuration du modèle. Cette démarche est robuste sur ce cas E104. Le
construit « Enterprise Activity » a un classement quasi constant par toute les
méthodes utilisées. Le Tableau 3.25 montre ce classement dans le cas d'un
partitionnement k-means avec 4 groupes.
EA-Release EA-SelectSupplier EA-Forecast EA-Clearing
EA-PurORder EA-SOP EA-Schedule EA-Closing
EA-PurReceipt EA-Sale EA-Controling
EA-MRP EA-Deliver EA-Budget
EA-Produce EA-Invoice EA-Paying
Tableau 3.25 : Classement des "Enterprise Activity" partitionnement 4-means

Ce cas académique que nous avons utilisé comme cas expérimental pour
mettre au point les outils de calcul permet de vérifier la pertinence et la faisabilité
de l'étude de l'intégration à travers le graphe des dépendances du modèle
d'entreprise. Le couplage et les voisinages, la distance et les partitions peuvent
donner des représentations originales et pertinentes sur le modèle d'entreprise afin
d'aider les acteurs à tenir compte des contraintes globales qui conditionnent leurs
actions sur le modèle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 244
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

3.4.2 Illustration sur le cas BAAN

1 Etude de l'intégration de l' ERP BAAN

B AAN a été un ERP parmil les leaders des années 1990, et un des premiers
éditeurs d'ERP qui a inclus un module de modélisation de processus dans
l'application. Ce module (DEM for Dynamic Enterprise Modelling) permet de
définir des modèles de référence standard selon des typologies d'entreprise,
représentant les « meilleurs pratiques » d'usage de cet ERP. Cet ERP, qui représente
toujours une base installée parmi les plus importantes, s'appelle, après plusieurs
rachats successifs « INFOR ERP LN ». Il conserve cette originalité d'un module
intégré de modélisation de processus et d'un référentiel qui permet d'analyser un
modèle générique de processus déjà aligné sur les fonctionnalités applicatives. La
structure technique de l'ERP est classiquement celle d'une application 3-tiers, autour
d'une base de données relationnelle, d'un serveur applicatif qui assure la logique des
traitements et des calculs par un ensemble de librairies qui sont activées par des
interactions utilisateurs principalement sous forme transactionnelle. Ces interactions
sont structurées en « sessions » qui représentent l'entité élémentaire d'un menu et
l'objet informatique que repère l'utilisateur et qui représente « l'outil » à
sélectionner selon la tâche à réaliser. Une session correspond à la notion de
« transaction » de SAP et peut comporter plusieurs écrans ou états. Les sessions,
écrans, états, tables, champs, librairies... sont classifiés dans une arborescence
technique et codifiés d'une manière pertinente pour cette classification. Cette
classification organise l'ERP en « applications » (packages) qui représentent un
domaine fonctionnel comme la production, les services ou la finance, lui-même
décomposé en modules qui correspondent à des ensembles d'objets développés par
une équipe pour répondre à un besoin fonctionnel et sont donc supposés être
« fortement intégrés » et faiblement dépendants des autres modules.
Le module DEM propose une démarche d'analyse centrée sur des
« modèles de contrôle (business control model) » et des « cas d'entreprises (business
cases) » qui décrivent à la fois une structuration du domaine et sa dynamique. Il
existe quelques modèles de contrôle standard pour les principales typologies
d'entreprise (MTS, ATO, MTO...) mais la démarche de modélisation consiste en
général à créer des modèles spécifiques représentant le « cadre » d'expression du
projet. Ces modèles de contrôle identifient les « déclencheurs » ou évènements
internes ou externes qui activent des « fonctions ». Une fonction est décrite sous
forme de un ou plusieurs « processus » qui peuvent être spécialisés selon la
typologie d'activité ou d'évènements déclencheurs. Ce module propose une

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 245
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

décomposition hiérarchique des fonctions et des processus facilitant l'analyse

descendante. Un processus est décrit sous une forme de type « réseau de petri » ou
les places traduisent les évènements et déclencheurs sous forme de statuts d'objets
et les transitions représentent les activités informatiques ou manuelles qui sont
déclenchées par un événement et en génère d'autres.
L’intégration de cet ERP peut être mesurée par le nombre de dépendances
entre ces différents objets. On compte dans la version 6 de cet ERP 2413 tables,
4901 scripts et 7527 sessions. Les dépendances entre ces objets peuvent être
extraites des références croisées que l'outil technique peut fournir. Elles sont
présentées dans le Tableau 3.26 en séparant les dépendances « intra-modules » entre
deux objets du même module technique (par exemple entre la fiche magasin et les
ordres d’inventaire), et les dépendances « inter-modules » entre des objets de
modules différents (par exemple entre la fiche magasin et les ordres de ventes). Plus
la part de dépendances interne est élevée, plus la structure technique de
l’application est pertinente pour présenter les contraintes d’intégration.

Objects Dependences Intra-module Inter-modules

Tables 2431 6898 2593 4305
Tables+sessions+scripts 14841 22308 11541 14260

Tableau 3.26 : dépendances techniques inter et intra modules BAAN

On constate que la moitié des dépendances sont inter-modules ce qui

souligne en première approche que l'intégration est fortement transverse à la
structure technique de l'application et qu'il n'est pas possible de considérer un ERP
et donc pas non plus un projet ERP, comme un ensemble de modules faiblement
couplés. La même analyse peut être faite sur les dépendances entre les objets
organisationnels portés par le référentiel DEM (fonctions, rôles et processus) et les
objets informationnels des applications. Le Tableau 3.27 présente présente la
répartition en pourcentage de la contribution d'une application (colonne) aux
fonctions métiers (ligne) à partir du couplage entre les objets correspondants,
cumulés au niveau des fonctions principales DEM (premier niveau de
décomposition de la vue fonctionnelle) et des applications de l'ERP (premier niveau
de décomposition de l'arborescence technique).
La profondeur de l'intégration apparait encore avec des applications,
cohérentes et modulaires d'un point de vue technique interne, mais qui contribuent à
plusieurs fonctions métiers, notamment les applications centrales de l'ERP
(distribution, finance, production, planification, service, magasin) qui contribuent à
plus de 4 fonctions métiers chacune. On constate des cas particuliers, l'application
“project” qui a été intégré dans cet ERP après avoir été une application autonome

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 246
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

orientée sur un marché particulière (génie civil) et l'application “freight

management”, application récente que les modèles de processus de cet éditeur n'ont
pris en compte que tardivement et en complément aux processus existants.
On peut s'interroger sur l'absence de prise en compte de cette application
dans le processus de planification par exemple, alors que les délais de transport et
même les contraintes de groupage à l'export peuvent être prises en compte dans le
calcul des délais des processus de planification. Là encore, notre approche peut être
le support de démarches de vérification ou validation de modèles standard en en
interrogeant la cohérence de l'intégration entre les différents points de vue.

Docum e nt M gt

Warehousing
Distribution
Commun

Invoicing

Planning
Industry

Services
Finance

Fre igth

Project

People

Total
proc
Account M gt 8% 11% 21% 4%
Account Payable Invoice s 14% 3%
Account Rec. Invoices 2% 8% 83% 3%
Call/Order M gt 22% 2%
Cas h M gt 3% 20% 4% 5%
Cost Accounting 20% 6% 5%
Dem and M gt 21% 1%
Enginee ring 24% 4% 27% 10% 7%
Enterprise Planning 8% 5% 75% 14% 6%
Fin. Planning and Budg. 1% 3% 1%
Fixed Ass ets 10% 2%
Fre ight M gt 3% 3% 100% 2% 6%
Hum an Res ource M gt 5% 55% 2%
Inve ntory M gt 3% 1% 53% 5%
M aster Data 1% 7% %
Object Data M gt 1% 96% 2%
Posting & Auditing 1% 19% 1% 9% 5%
Product As sortm ent M gt 6% 2% 2% 1% 1%
Production 7% 3% 40% 3% 5% 16% 8%
Project M gt 6% 19% 96% 11% 12%
Purchas e 18% 3% 2% 3%
Purchas e & Sales Sched. 21% 1% 1% 3%
Quality M gt 6% %
Re porting & Analyzing 18% 6% 4% 3%
RM A/ De pot Re pair Control 8% 1%
Sales 27% 7% 4%
Se rvice Execution Control 1% 12% 11% 1%
Supplier M gt 4% 11% 2%
Ware hous ing % 33% 3%
Total 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100%

Tableau 3.27: Contribution des applications aux fonctions métiers (BAAN)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 247
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

2 Etude des distances sur un graphe BAAN partiel

L a mise en œuvre de notre approche sur un cas complet BAAN nécessite une
infrastructure et des travaux complémentaires compte tenu de la taille du
modèle et du graphe résultant. La taille estimée du graphe BAAN est de 30000
objets et 100000 dépendances. La première difficulté est d'obtenir l'ensemble des
objets « utiles ». En effet, l'extraction automatique par les outils fournit des objets
(34982) dont certains sont des outils connexes de tests, vérifications, reprises en cas
d'erreur techniques. Il faut donc d'abord filtrer ces listes à partir d'une connaissance
détaillée de l'ERP considéré. Sur la base des algorithmes utilisés, la taille du graphe
rend nécessaire des architectures adaptées en termes de taille mémoire notamment.
Les algorithmes utilisent une pile dont la paramétrage maximum sur notre portable
était de 10 9 octets (pour une mémoire de 2Go de RAM). Elle permettait de traiter
des graphes de l'ordre de 2000 objets.
De plus, les approches de partitionnement étudiées dans la section 3.2.4 ne
reposent pas sur des techniques donnant une solution optimale, mais suppose
d'étudier la pertinence de chacune des méthodes et notamment le choix du nombre
de partitions recherchées. Dans un modèle de grande taille, il est indispensable
d'automatiser des chaînes de tests permettant de vérifier la pertinence de telle ou
telle approche.
Pour toutes ces raisons, nous avons travaillé sur des vues partielles de ce
cas à partir d'un graphe réduit aux objets dépendants de l'application
« Warehousing » de l'ERP. A partir de ce cas, nous avons construit deux graphes
dénommé BAAN-TT et BAAN-WH. BAAN-TT a pour objectif d'étudier comment
notre approche permet d'interroger la structure technique de la base de données de
l'ERP. BAAN-WH a pour objectif d'étudier comment notre approche permet de
mieux rendre compte des relations entre points de vue technique et fonctionnel dans
le modèle.
Cas BAAN-TT-568
Ce cas est limité aux objets techniques « tables » de l'ERP en lien avec la
gestion de production, (gestion d'atelier, données de base, données
organisationnelles, gestion de magasin). Il représente 568 objets et 1714
dépendances après filtrage de quelques éléments non connexes. Le graphe de rayon
6 a été traité pour une longueur d'intégration de 5 31 pour le calcul des voisinages en
368 s et pour le calcul des matrices de distances en 1620 s avec une pile mémoire
maximum de 7571565 mots.

31 Pour des raisons de limitations de taille mémoire

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 248
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Des partitionnements ont été étudiés sur ce cas pour les tables des
applications “production” pour vérifier des résultats précédents montrant l'existence
de partitionnements plus efficace que la structure technique existante. L'utilisation
de la distance d'intégration donne une vue du modèle clairement transverse à sa
structure hiérarchique technique.
Nous avons d'abord effectué une classification hiérarchique pour obtenir
un nombre de classes objectif. Puis nous avons utilisé un traitement k-means qui a
donner une séparation des classes plus forte. Cette classification est plus
intéressante car les classes sont “faiblement couplées entre elles tout en étant
“relativement denses”. Or, ces classes ne correspondent pas du tout à la structure
technique existante. Le Tableau 3.28 montre ainsi la classification obtenue avec des
classes (en ligne) très fortement transverses à la structure technique (en colonne).
Le tableau présente pour une ligne et une colonne le nombre d'objets, donc de tables
concernés. Les modules pris en compte sont dans l'ordre des colonnes: bom
(nomenclatures), cpr (prix de revient), cst (coûts constatés), edm (nomenclatures
d'études), grt (classification de groupe), ipd (données articles de production), mfc
(données fabrication), pcf (configurateur de produit), rou (gammes de production),
rtp (gammes répétitives), sfc (gestion d'atelier), trp (gestion d'outillages).
Classe bom cpr cst edm grt ipd mfc pcf pcs rou rpt sfc trp Total
1 2 2 4
2 1 2 1 2 4 313
3 6 2 614
4 2 1 2 1 1 7
5 1 1 2 1 5
6 1 1 1 3
7 1 10 1 1 7 1 1 22
8 2 4 2 5 10 23
9 1 2 3 2 8
10 3 4 1 4 1 13
11 3 2 2 1 8
12 1 4 1 1 7
13 2 1 1 4
14 5 1 6
15 2 1 1 1 3 8
16 1 1 2 4
17 3 3 6
18 6 6
19 2 1 3
20 3 1 4
21 12 12
22 6 6
23 7 7
24 3 3
25 5 5
Total 4 33 12 14 31 2 2 23 23 21 3 19 14 201
Tableau 3.28 : Partitionnement tables TI du cas BAAN-TT-568

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 249
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

On constate ainsi que la classe 8 proposée par le partitionnement regroupe

des tables provenant de 5 modules différents de l'ERP. C'est bien l'objet gamme qui
est au cœur de ce regroupement et qui est effectivement transverse à ces modules.
Nous avons ici un exemple potentiel de « réingénierie » du progiciel dont
la structure est historique et dépendante de considérations de comptabilité
ascendante, de compétences des équipes de développement. Une autre organisataion
technique des objets de l'ERP est sans doute possible.

Cas BAAN-WH-336

C e cas repose sur un sous-graphe construit sur l'objet organisationnel “Business

Function”, et les objets informatiques “sessions” et “tables” pour lesquels des
dépendances existent avec l'application “warehousing” de BAAN. Ces objets
correspondent aux construits BP, ITR et Da de notre méta-modèle. Le cas contient
336 objets et 1211 dépendances. Le graphe de rayon 4 a été traité pour le calcul des
voisinages en 266 s et pour le calcul des matrices de distances en 459 s avec une
pile mémoire maximum de 2484334 mots. Les matrices résultantes ont été analysées
pour étudier le partitionnement possible des “business fonctions” tenant compte des
dépendances avec les tables et les sessions. Un premier résultat est obtenu avec une
classification hiérarchique ascendante sur la matrice de dissimilarité entre
“business functions”. Le dendogramme est présenté dans la Figure 3.33 et le calcul
propose 5 classes.

Dendrogramme

1,2

0,8
Dissimilarité

0,6

0,4

0,2

Figure 3.33: dendogramme classification hiérarchique cas BAAN-WH-BF

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 250
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Deux classes sont particulièrement intéressantes car elles illustrent un

regroupement des fonctions par la richesse fonctionnelle du besoin de gestion de
magasin.
Les processus de stockage, réception, expédition, inventaire proposés par
le modèle de processus de BAAN sont en effet différenciés en processus “de base”
et processus “avancés”. C'est justement la séparation des classes 4 et 5 résultantes
de la classification hiérarchique comme le montre le Tableau 3.29. Dans cet
exemple partiel, le partitionnement permet de représenter une structure qui n'était
apparente que dans le libellé des fonctions. Les fonctions dites “advanced” dans le
référentiel sont regroupées par la classification, permettant de faire apparaitre une
structure implicite par l'étude de l'intégration d'un modèle.

Classe 4 Paramètres et description Classe 5 Paramètres et description

fonctions classe 4 fonctions classe 5
12 Objets 8
12 Somme des poids 8
0,009 Variance intra-classe 0,004
0,062 Distance minimale au barycentre 0,034
0,088 Distance moyenne au barycentre 0,054
0,124 Distance maximale au barycentre 0,090
MIM01 Inventory Monitoring MIM02a Inventory Analysis - Advanced
MIM02b Inventory Analysis - Basic MMN02f Assembly: Execution
MIM03 Sourcing MWH01a Receiving - Advanced
MIM04 Planning/ VAS Control MWH04a Picking - Advanced
MIM05 Warehouse Layout Management MWH04c Picking - Over-the-counter Sales
MIM06 Lot & Serial Number Control MWH05a Stock Management
MIM08 Inventory Blocking MWH06 Packing
MPS12 Process Purchase Schedules MWH07a Shipping - Advanced
MPU01 Purchase Order Entry
MWH02 Inspection
MWH03 Store Goods
MWH08 Cycle Counting

Tableau 3.29 : Usages "de base" et "avancés" des processus WH de BAAN

Le cas BAAN permet ainsi d'illustrer deux situations ou l'approche du

graphe d'intégration apporte un éclairage utile sur un modèle établi et connu.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 251
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

3.4.3 Illustration sur le cas SCOR

L e modèle de référence SCOR a été présenté dans la section 2.2.4. Nous

utilisons pour son étude précise la version 7 dont nous avons transformé le
document de référence (tel que présenté dans la Figure 2.12 en page 93) en tableaux
des objets selon le méta-modèle proposé dans la Figure 3.3 en page 151.
L'identification des objets suppose un travail de clarification et normalisation
notamment des objets de type « informations » et « features ». En effet, leur
description uniquement textuelle fait apparaître des redondances sémantiques (deux
objets identifiés par des textes différents mais qui peuvent être considérés comme
identiques). Ce travail présenté en section 3.1.3 conduit à un graphe de 1846 objets
reliés par 2642 aretes. Si le temps de calcul estimé est réaliste (2h sur un portable),
le besoin en taille mémoire important (estimé entre 4 et 6Go) compte tenu que
l'outil de calcul utilisé ne peut fonctionner que dans la limite de la mémoire
disponible, supposerait un travail d'optimisation de l'utilisation mémoire ou
d'utilisation de ressources de calcul plus spécialisées.
Mais une difficulté plus importante est apparue sur ce cas qui rend
nécessaire un travail de fond sur le référentiel lui même. En effet, nous avons fait le
choix de considérer le graphe d'intégration au niveau le plus détaillé, sans tenir
compte des structures hiérarchiques existantes, l'objectif étant justement de
rechercher des structures émergentes. Or le graphe d'intégration du référentiel
SCOR au niveau 3, donc sans la structure hiérarchique de processus comporte 18
composantes connexes. Par exemple les processus D1.1 et D2.1 échangent deux
informations entre eux mais sont isolés du reste du modèle sans la structure
hiérarchique du processus D qui contient les processus D1 et D2. Le Tableau 3.30
présente la totalité des dépendances concernant ces deux processus de niveau 3.

(Customer) Inquiry I007 D1.1 Process Inquiry & Quote (Stocked Product)
(Customer) Inquiry I007 D2.1 Process Inquiry & Quote (MTO Product)
Order Quote (Customer) I168 D1.1 Process Inquiry & Quote (Stocked Product)
Order Quote (Customer) I168 D2.1 Process Inquiry & Quote (MTO Product)

Tableau 3.30 : dépendances des processus SCOR D1.1 et D1.2

La cohérence du référentiel SCOR est donc partiellement implicite. Des

dépendances entre processus ne sont pas explicitées par une dépendance
d'information échangée, de bonnes pratiques préconisées, ou d'applications support.
Le référentiel ne peut donc être utilisé sans une analyse complémentaire qui
suppose une étude de sa structure et notamment des relations existantes
implicitement entre processus et qui sont utilisées pour construire un modèle de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 252
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

chaîne logistique basé sur SCOR. Ainsi, le processus D1 est considéré comme
devant être alimenté par un processus M1, alors que le processus D2 est alimenté
par un processus M2. Mais ces dépendances ne sont pas présentes comme
informations échangée entre ces processus. On peut s'interroger sur la complétude
du modèle de ce point de vue et notre approche de graphe d'intégration peut
contribuer à un outil de vérification de la cohérence du référentiel.
Nous avons étudié un cas limité à la composante connexe principale du
graphe réduit aux seuls processus et informations du référentiel SCOR mais incluant
les relations hiérarchiques entre processus. Ce graphe contient 525 objets et 966
arêtes. Le graphe est alors connexe et le résultat fait ressortir la structure
hiérarchique existante. Le calcul des voisins a été effectué en 435 secondes et le
calcul des matrices en 923 secondes avec une taille de pile mémoire de 4830488
mots.
Une classification des processus SCOR à partir de la distance d'intégration
calculée est donc très fortement marquée par la structuration hiérarchique des
processus. Le Tableau 3.31 présente une classification k-means à 13 classes avec en
tête de colonne le nom du processus barycentre de la classe et en colonnes les
processus appartenant à cette classe (la liste détaillée des codes process de SCOR
est disponible dans la documentation SCOR, la première lettre étant significative du
process principal: P pour Plan, S pour Source, D pour Deliver, M pour Make, E pour
Enable, R pour Return). La classe 1 centrée sur le processus EP de support à la
planification contient l'essentiel des processus de planification, la classe 3 centrée
sur le processus M3.3 contient l'essentiel des processsus de manufacturing, la classe
4 centrée sur le processus D2.6 contient l'essentiel des processus de distribution...
Cet exemple illustre l'enjeu de modéliser les dépendances en considérant
l'intégration comme une caractéristique transverse. En effet, si la structure
arborescente du modèle est dominante dans la modélisation, le graphe sera le plus
souvent non connexe, ce qui de notre point de vue, traduit une représentation
insuffisante de l'intégration. L'alignement stratégique de l'entreprise avec son
système d'information se concrétise ici dans la cohérence entre une structure qui
peut être plus ou moins fortement couplée et la réalité des dépendances
informationnelles, fonctionnelles ou de ressources qui constituent les contraintes de
modélisation et qui traduisent un couplage plus ou moins fort dans le modèle. On
peut avoir deux entités ou domaines dont la stratégie suppose une indépendance au
plan organisationnel, mais dont l'interopérabilité nécessaire va créer une intégration
informationnelle ou de ressources qui conduira à une « proximité d'intégration » qui
doit être prise en compte dans un modèle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 253
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

EP ER.8 M3.4 D2.6 ER S1.5 ED.4 EM.2 D1.10 S3.6 D3.12 M1.1 P2.4
P S M D R S1 ED EM D1.1 D1.3 D2.9 D3.2 DR1.3
P1 ES M1 D1 SR1 S2 DR3.4 EM.1 D1.10 D1.8 D3.1 ED.8 DR2.3
P2 ER.8 M2 D2 DR1 S3 ED.1 EM.2 D1.11 D1.9 D3.10 ES.9 DR3.2
P3 ES.1 M3 D3 SR2 D4 ED.2 EM.3 D1.12 D2.3 D3.11 M1.1 P1.2
P4 ES.2 M1.3 D2.1 DR2 D3.9 ED.3 EM.4 D1.13 D2.7 D3.12 M1.5 P2.1
P5 ES.4 M1.4 D2.10 SR3 D4.2 ED.4 EM.5 D1.14 D2.8 D3.13 M2.1 P2.4
EP ES.5 M1.6 D2.11 DR3 D4.3 ED.5 EM.6 D1.15 D3.7 D3.14 M2.5 P4.2
EM.8 ES.6 M2.3 D2.12 ER D4.4 ED.6 EM.7 D1.2 D3.8 D3.15 M3.2 P5.2
EP.1 ES.7 M2.4 D2.13 D4.7 D4.5 ED.7 D1.4 D4.1 D3.3 M3.6 S1.1
EP.2 ES.8 M2.6 D2.14 DR3.3 D4.6 D1.5 ER.3 D3.4 P3.4 S2.1
EP.3 M3.1 D2.15 DR1.1 S1.2 D1.6 ES.3 D3.5 S3.1
EP.4 M3.4 D2.2 DR1.2 S1.3 D1.7 M1.2 D3.6 S3.3
EP.5 M3.5 D2.4 DR1.4 S1.5 M2.2
EP.6 M3.7 D2.5 DR2.1 S2.2 M3.3
EP.7 D2.6 DR2.2 S2.3 P2.2
EP.8 DR2.4 S2.5 P3.2
P1.1 DR3.1 S3.2 S1.4
P1.3 EP.9 S3.4 S2.4
P1.4 ER.1 S3.5 S3.6
P2.3 ER.2 S3.7 SR1.2
P3.1 ER.4 SR1.3
P3.3 ER.5 SR1.4
P4.1 ER.6 SR1.5
P4.3 ER.7 SR2.2
P4.4 P5.1 SR2.3
P5.3 P5.4 SR2.4
SR1.1 SR2.5
SR2.1 SR3.2
SR3.1 SR3.3
SR3.4
SR3.5

Tableau 3.31 : Classification Hiérarchique ascendante des processus SCOR

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 254
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

La démarche présentée dans les chapitres précédents a eté illustrée

dans ce chapitre à travers un cas académique, de taille réduite pour en
faciliter l'étude et la présentation dans la première section. Il fait suite
à de précédents travaux portant sur BAAN, notamment sur la
cohérence de l'intégration interne par les données et la structure
technique des modules de l'ERP et sur l'alignement des fonctions aux
processus des modèles de référence portés par le module DEM de cet
ERP (Millet et al, 2005; Millet, 2005).

Cette démarche résulte aussi de l'étude du référentiel SCOR, autant

pour le compléter par une normalisation des informations identifiées
dans les échanges entre processus que pour étudier l'alignement de ce
référentiel a des briques applicatives (Millet et al, 2007), (Millet 2006).

Ces deux cas métiers ont été repris avec la définition de distance
proposée pour réévaluer les matrices et partitionnements possibles.
Mais dans le cadre de cette thèse, l'étude ne peut porter que sur des
cas partiels issus de ces environnements. En effet, la taille des
graphes d'intégration nécessite une infrastructure technique adaptée
et une plateforme automatisant l'enchaînement des tâches pour
permettre des études plus systématiques d'un cas de grande taille.
Nous évoquerons dans les perspectives industrielles de la partie 4,
l'opportunité d'un projet de plateforme d'ingénierie ERP industrialisant
les outils proposés.

L'étude de ces cas réels partiels donnent des résultats significatifs sur
la pertinence et la faisabilité de l'approche proposée. Ils permettent de
confirmer la pertinence du rayon du graphe comme longueur
d'intégration. Ils mettent en avant la nécessité de critères de sélection
des partitions possibles, notamment en terme de nombre, de
séparabilité ou d'homogénéité.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 255
 Démarche d'ingénierie orientée intégration / Illustration sur des cas académiques et réels

Dans cette troisième partie, nous avons proposé une démarche

d'ingénierie dirigée par les modèles orientée vers l'intégration comme
caractéristique première d'un système d'entreprise et de son système
d'information. Cette démarche repose sur une interprétation itérative
du cadre de modélisation de la norme 19439 permettant la recherche
de l'alignement entre solutions standard et besoin spécifique à partir
de référentiels et normes.

Un méta-modèle d'intégration a été proposé pour structurer les

construits de modélisation nécessaires à partir de la norme 19440 en
l'enrichissant d'une étude de modèles métiers existants. Cette étude
confirme l'importance du méta-modèle pour faciliter la mise en
cohérence d'ontologies métiers diverses qui seront mobilisés dans un
projet d'entreprise.

Le modèle d'entreprise fondée avec ce méta-modèle est caractérisé

par son « graphe d'intégration » dont l'étude nous a conduit à
proposer des outils d'analyse de l'intégration basés sur une
« distance » et un « couplage » d'intégration. Nous proposons ainsi de
construire des voisinages et des partitions qui éclairent l'intégration
diffuse du modèle.

Le cadre de modélisation, le méta-modèle et le graphe d'intégration

sont mobilisés dans cette démarche d'ingénierie qui supporte la
recherche d'alignement entre modèles partiels. Différentes situations
d'alignement sont étudiées illustrant des problématiques classiques
rencontrées lors de projets ERP.

Les outils proposés sont illustrés sur un cas académique et des cas
réels issus de modèles de référence ou solutions du marché. Nous
avons conclu cette partie en esquissant la possibilité d'un atelier
d'ingénierie dirigé par la modélisation qui s'appuie sur les outils
proposés du graphe d'intégration pour en faire un des critères et un
des résultats de la modélisation.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 3 / Chapitre 3.4
Institut National des Sciences Appliquées de Lyon 256
Partie 4

Conclusions et Perspectives
 Conclusions et Perspectives / Conclusions et Perspectives

Chapitre 4.1
Conclusions et perspectives académiques.......................259
4.1.1 Conclusion au détour du terrain........................................................260
4.1.2 Perspectives pour le cadre de modélisation........................................265
1 Prise en compte des relations d'agrégation dans la modélisation...............265
2 Etude systématique de l'alignement.........................................................266
3 Extension du modèle vers le pilotage.......................................................266
4.1.3 Perspectives pour le graphe d'intégration...........................................267
1 Vers un graphe orienté, valué et hiérarchisé.............................................267
2 Analyse locale et dynamique du graphe...................................................269

Chapitre 4.2
Perspectives d'applications industrielles..........................271
4.2.1 Navigation non hiérarchique dans un ERP .........................................272
4.2.2 Re-conception architecture applicative ERP .......................................273
4.2.3 Vers un configurateur de projet ERP..................................................274

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Partie 4
Institut National des Sciences Appliquées de Lyon 258
 Conclusions et Perspectives / Conclusions et perspectives académiques

Chapitre 4.1
Conclusions et
perspectives académiques

Nous présenterons cette conclusion en revenant à travers trois cas

d'entreprise issus de notre expérience de chef de projet ERP sur les
enjeux qui ont motivés notre recherche. Chaque cas mettra en
exergue un des aspects de l'intégration dans un système socio-
technique. Nous pourrons alors conclure sur l'enjeu de notre
proposition d'un cadre d'ingénierie orienté intégration, du graphe
d'intégration et de ses outils associés, pour permettre des démarches
d'ingénierie adaptées aux projets de type ERP.

Notre contribution est un pas limité vers une ingénierie d'entrepris et

de système d'information pilotée par les modèles et orientée vers
l'intégration. Nous décrivons des perspectives de recherche autour
de deux grands domaines. L'enrichissement du cadre de modélisation
puis l'enrichissement du graphe d'intégration lui-même.

Nous terminerons par la présentation de perspectives industrielles

autant pour les éditeurs de progiciels que pour les prestataires chargés
de leur mise en œuvre. Nous présenterons notamment un projet en
cours de préparation pour le prototypage d'un configurateur de projet
de type ERP.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 259
 Conclusions et Perspectives / Conclusions et perspectives académiques

4.1.1 Conclusion au détour du terrain...

N otre expérience de consultant dans des projets de mise en œuvre de solutions

ERP constitue le terrain d'où sont issues les interrogations fondamentales de
cette thèse : le rapport entre intégration organisationnelle et informationnelle, la
capacité de la modélisation d'entreprise à supporter la conception et le pilotage de
ces différents formes d'intégration, la contradiction entre des systèmes à long délai
de mise en œuvre et un contexte toujours instable et partiellement incertain. Il n'est
pas inutile de revenir avant de tirer les conclusions de notre travail sur des cas réels
emblématiques de ces questionnements :
Le premier cas concerne une PME de taille moyenne qui avait décidé en
1996 d'un projet de grande ampleur en pleine irruption de l'ERP sur le marché, et
l'avait accompagné d'un effort qui paraissait gigantesque de formation. Près de la
moitié du personnel, ouvriers compris, avait participé à des cycles de formation à la
gestion industrielle en amont du projet. L'accompagnement semblait correctement
dimensionné et expérimenté, l'engagement de la direction générale était réel. La
prise en compte des spécificités du processus, notamment son aval orienté vers des
chantiers de taille très variée a été difficile, mais possible. Cependant, l'acceptation
par l'organisation, dans la réalité de directions relativement autonomes dans leurs
priorités, a été très douloureuse. La phase de stabilisation a été longue et coûteuse,
l'entreprise ne retrouvant son niveau de chiffre d'affaire qu'au 4ème mois de
fonctionnement. Les risques du démarrage avait été évalués par l'ensemble des
acteurs, mais il ne paraissait plus possible de le reporter et un support spécifique
avait été organisé. Cette difficulté à se projeter dans des pratiques nouvelles a
généré un compromis entre habitudes et nouvel outil qui a renforcer durablement les
ressources de gestion nécessaires. Ce cas est révélateur de situations où le projet
génère un surcoût de fonctionnement qui conduira l'entreprise à rechercher des
réorganisations plus fortes, touchant à l'organisation industrielle elle-même. La
capacité à « aligner » les attentes des différents services, les objectifs du projet et
les capacités de l'ERP s'est révélée nettement insuffisante. Il manquait des outils et
méthodes pour définir, valider et promouvoir des pratiques claires et cohérentes
entre-elles, dimensionner les tâches de pilotage du nouveau système, notamment de
réglage des nombreux paramètres qui conditionnent son fonctionnement. La
modélisation des processus opérationnels ne donne pas par elle-même une vue
globale permettant à la direction générale de contrôler la cohérence des décisions
des directions de différents services. Elle ne donne pas non plus une vue

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 260
 Conclusions et Perspectives / Conclusions et perspectives académiques

opérationnelle du poste de travail, ce dernier étant réduit aux transactions

nécessaires sans identifier les indicateurs et listes de contrôle nécessaires, sans
permettre aux acteurs de s'approprier les paramètres et données de base dont la
gestion influe sur les transactions du poste. Dans un tel contexte, la méfiance
domine les comportements humains avant, pendant et après le démarrage. Avant le
démarrage, la direction industrielle encourage le sur-stockage préventif, les
commerciaux tentent de faire livrer en urgence leurs commandes dans le système en
remplacement... Après le démarrage, de nombreux acteurs suspendent le processus
en cas de doute, mais trouvent le moyen de continuer les opérations
correspondantes, créant un « encours de transactions en retard »... les pratiques de
contrôle prévues sont peu mises en œuvre, les alertes du système ne sont pas traitées
par méfiance sur leur pertinence, la surcharge perçue de travail pousse aux solutions
de contournement, sans utiliser les anomalies réelles pour régler les paramètres et
données de base. Au total, c'est l'incapacité de l'organisation à assumer
collectivement le fort niveau d'intégration du système et la cohérence qu'il suppose
qui est le facteur essentiel de dysfonctionnement. Après stabilisation, la maîtrise des
données de base et de la cohérence du S.I. restent une tâche « technique » sous
estimée. Le projet n'a pas transformé la relation entre S.I. et métiers, les projets
suivants ont reconstruit une cartographie applicative hétérogène, avec un ERP
centré sur la gestion de production, faiblement couplé au marketing et à la relation
client, et dont les fonctionnalités financières analytiques sont faiblement utilisées.
La contribution du S.I. à la performance de l'entreprise reste faible.
Le deuxième cas est à l'opposé celui d'une entreprise ne faisant pas le
choix d'un projet « Big Bang », mais décidant successivement au fil des ans des
mises en œuvre partielles d'un ERP, considéré principalement comme un progiciel
de gestion de production. Le périmètre de mise en œuvre est à chaque projet partiel,
et correspondant à une réalité organisationnelle et de processus. Les projets sont
maîtrisés en coût et leur impact est jugé positif par les acteurs de la gestion de
production. Les projets accompagnent une évolution depuis une organisation de
production en série, avec des effets importants sur les premières étapes de
production, vers une organisation plus tournée vers la demande, en petite série,
minimisant les regroupements possibles et voyant exploser la combinatoire des
variantes possibles. Cependant, le S.I. reste à l'image de l'organisation réparti en un
grand nombre de systèmes dont les techniques, les fournisseurs, les responsables
sont différents. Au fil du temps, le besoin d'intégration augmente sous la pression
notamment des flux logistiques, et de la nécessité de mieux suivre dans l'ensemble
du système la relation client. Des actions sont entamées mais l'organisation reste
fortement segmentée et la partie spécifique du S.I. est un obstacle à une plus forte
intégration. Plusieurs études sont réalisées pour identifier le système cible et

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 261
 Conclusions et Perspectives / Conclusions et perspectives académiques

orienter les actions possibles, mais la direction ne souhaite pas de « grands projets »
d'intégration et les décisions privilégient toujours des adaptations locales. Si le S.I.
est jugé efficace et est devenu une ressource critique des processus de production et
distribution, il s'est développé dans le cadre d'une organisation faiblement intégrée
qui domine les décisions. Le S.I. est un élément d'une stratégie et le responsable
informatique ne peut être le décideur de l'évolution de ce S.I. qui n'est pas un
élément de la stratégie d'entreprise.
Le troisième cas est celui d'une usine d'une grande entreprise mondiale de
fabrication de système en ingénierie à l'affaire pour laquelle le projet ERP est une
première informatisation de certains fonctions. L'informatisation existante est
centrée sur les études, alors que la gestion de production et la gestion de stock
restant largement manuelles. Le projet est porté par une équipe forte et proche de la
direction générale, clairement structuré par processus dans un objectif d'intégration.
Les gains opérationnels sont repérés principalement en gestion de stock et obtenus
assez rapidement. L'enjeu principal de l'intégration des études et de la production
est maîtrisé par une standardisation forte des structures techniques des affaires.
C'est cette structure technique qui devient le référentiel commun des différents
acteurs et qui devient un « outil de projet » faisant le lien entre les métiers existants
et les nouveaux processus proposés par le projet ERP. L'appropriation par les
acteurs est portée par cet «alignement » maîtrisé entre métier et organisation de
l'ERP, alignement qui se concrétise de manière très concrète dans une pratique
métier connue et dont l'évolution est jugée par les acteurs critiques comme positive.
Ces cas, comme de nombreux autres nous conduisent à rechercher ce qui
peut aider à la cohérence dans l'ensemble du cycle de vie du S.I. entre les objectifs
des différents niveaux de décisions de l'entreprise, les possibilités offertes par les
solutions standard, et la capacité des acteurs à redéfinir leurs pratiques en
s'appuyant sur ces solutions standard. Les contraintes propres à l'organisation et à
ses choix de faible ou forte intégration organisationnelle, les contraintes propres aux
applications et à leur plus ou moins forte intégration informationnelle, enfin les
contraintes liées aux capacités des acteurs en termes de disponibilité et de
compétences expliquent la complexité de tels projets. Ces contraintes sont toujours
exprimables en termes de « dépendances » entre des objectifs, des ressources, des
acteurs, des données... C'est pourquoi si la modélisation est une étape indispensable
pour identifier, caractériser, décider, valider les processus et pratiques du système
cible, la capacité de cette modélisation à éclairer les contraintes que les acteurs
doivent prendre en compte est essentielle.
Dans le cas 1, ce sont les pratiques qui sont faiblement modélisés et donc
les contraintes qui leur sont imposées qui sont mal évaluées, empêchant une
appropriation confiante par les acteurs.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 262
 Conclusions et Perspectives / Conclusions et perspectives académiques

Dans le cas 2, c'est l'incapacité à supporter le choix d'une organisation

répartie d'entités fortement autonomes tout en accompagnant la nécessaire
intégration informationnelle qui conduit à un S.I. fortement hétérogène et dont le
coût de maintenance est élevé.
Dans le cas 3, c'est au contraire la maîtrise d'un outil de projet faisant le
lien entre le métier et le S.I. qui permet l'appropriation par les acteurs des
contraintes de l'intégration organisationnelle et informationnelle.

C e terrain d'expérience nous a conduit à rechercher comment représenter de

manière systématique ces contraintes d'intégration et comment outiller un
cadre d'ingénierie pour des projets de type ERP. La première étape est bien entendu
de choisir un cadre d'ingénierie porteur des dimensions de standardisation qui sont
caractéristiques de ces projets, tout en assumant la multiplicité des points de vue des
acteurs rencontrés dans ces projets, directeurs, informaticiens, responsables
d'activités, commerciaux, ingénieurs... Le cadre proposé par la norme ISO 19439
répond à ces objectifs tout en capitalisant sur l'histoire des différents cadres de
modélisation d'entreprise. Dans ce cadre d'ingénierie, un méta-modèle capable de
porter des points de vue organisationnel et informationnel est nécessaire. Nous
enrichissons le méta-modèle de la norme ISO 19440 à partir de l'étude du modèle de
référence SCOR et de notre propre expérience de modélisation dans un
environnement ERP pour proposer un méta-modèle d'intégration, portant les
dépendances entre processus, pratiques, organisations, fonctions, objets, objectifs...
dépendances qui sont toutes pour nous des éléments « d'alignement » entre
différents points de vue. Nous considérons alors cet ensemble de dépendances
comme un graphe d'intégration et nous définissons des distances entre éléments
d'un modèle d'entreprise pour en construire des partitions, et un couplage entre
éléments mesurant leur connexité pour étudier le voisinage d'un objet au sens de
l'intégration dont le modèle est porteur. Nous enrichissons enfin ces dépendances en
les qualifiant par une force représentant leurs caractéristiques socio-techniques pour
différencier les contraintes « dures » qui s'imposent à l'organisation sociale, aux
responsabilités individuelles, et les contraintes « faibles » que l'organisation, le
contexte où la décision individuelle peuvent limiter ou lever. Nous qualifions aussi
ces dépendances par l'impact de la maturité de l'organisation sur les éléments du
modèle, en propageant cette maturité liée au point de vue organisationnel dans
l'ensemble du graphe.
Le cadre d'ingénierie, le méta-modèle d'intégration et le graphe
d'intégration constituent la base d'une démarche d'ingénierie dirigée par les modèles
et orientée intégration, démarche adaptée aux enjeux des projets de type ERP dans
leurs dimensions organisationnelles et informationnelles. Nous proposons d'outiller

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 263
 Conclusions et Perspectives / Conclusions et perspectives académiques

cette démarche en enrichissant une plateforme de modélisation d'entreprise par la

gestion des voisinages d'intégration d'un élément, voisinages qui présentent à
l'acteur chargé de modéliser un point de vue partiel, le « contexte d'intégration » de
chaque élément pour aider à identifier et comprendre les contraintes qui
conditionnent l'usage de cet élément, au delà des dépendances directes que le
modèle contient sur cet élément. Nous proposons de plus d'utiliser les techniques de
partitionnement pour rechercher des structurations pertinentes du modèle, éclairant
pour les acteurs de l'ingénierie, les contraintes d'intégration en proposant des
classifications des éléments du modèle. Ces classifications peuvent être globales
pour rechercher une séparation du modèle en plusieurs parties faiblement couplés
du point de vue de l'intégration. Elles peuvent être partielles et concerner un point
de vue, ou une vue spécifique du modèle, pour aider à sa structuration. Une telle
classification du point de vue organisationnel peut être ainsi le support des
démarches de ré-ingénierie organisationnelle, permettant d'évaluer la pertinence
d'une organisation par rapport aux contraintes d'intégration. De la même manière,
une telle classification du point de vue informatique peut être le support de
démarche de ré-ingénierie des structures techniques ou d'analyse critique de
l'urbanisation du système d'information.
Ce cadre d'étude de l'intégration permet de définir dans l'ingénierie
d'entreprise la problématique de l'alignement stratégique utilisée par les
gestionnaires comme la recherche de cohérence entre deux points de vue, voire deux
construits d'un modèle d'entreprise. Cette cohérence se mesure à la fois par la
définition des voisinages d'intégration et par l'étude de partitionnements possibles
des différents points de vue. Le bon alignement entre processus métiers et
fonctionnalités du système d'information peut ainsi être vérifié si des processus
« proches » s'appuient sur des fonctionnalités « proches ». Une représentation des
processus fondée sur leur distance, par exemple par un algorithme de force, sera
assez « ressemblante » à une représentation des fonctions support de ces processus
fondée aussi sur leur distance propre.
Dans notre cadre d'ingénierie d'entreprise dirigé par la modélisation
d'entreprise, le graphe d'intégration est une part de la sémantique que porte
l'intégration et que nous représentons ainsi dans la modélisation. Cette approche
demande de nombreux travaux afin de préciser et consolider les concepts et outils
proposés. Cela concerne autant le cadre d'ingénierie lui-même que l'utilisation du
graphe d'intégration et encore plus la prise en compte des usages et de l'incertitude
caractéristique des systèmes socio-techniques. Nous allons dans les sections
suivantes identifier les principales perspectives de recherche sur cette
problématique.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 264
 Conclusions et Perspectives / Conclusions et perspectives académiques

4.1.2 Perspectives pour le cadre de modélisation

1 Prise en compte des relations d'agrégation dans la modélisation

N ous avons montré la pertinence de notre méta-modèle d'intégration, mais nous

avons construit le graphe correspondant en considérant un modèle
mononiveau sans utiliser les relations d'agrégation qui sont pourtant représentatives
des structures hiérarchisées que sont les organisations humaines ou les systèmes
techniques. Nous avons constaté dans le cas du modèle SCOR que cela influait
fortement sur les référentiels. De manière générale, de nombreux modèles peuvent
être étudiés dans le cadre d'une hiérarchisation existante ou implicite, et le graphe
d'intégration correspondant se trouvera ainsi « dominé » par la hiérarchisation. Il
nous faut donc enrichir le cadre en étudiant comment assurer la cohérence des
représentations de l'intégration dans l'agrégation et la désagrégation des modèles,
comment consolider un ensemble de relations entre objets élémentaires en relations
entre groupes d'objets. L'enjeu est d'étudier comment « valider » une organisation
hiérarchique par sa pertinence du point de vue du couplage plus ou moins fort entre
ses composantes. Comme nous l'avons évoqué dans la section 3.2.5 de la partie 3
sur la prise en compte des usages dans les dépendances du modèle, deux entités
indépendantes dans la hiérarchie car n'étant relié qu'au plus haut niveau
organisationnel, devraient être faiblement couplée par rapport à deux entités
appartenant à la même direction. Cette comparaison entre une hiérarchisation
« émergente » de l'intégration et la hiérarchisation organisationnelle existante peut
être un atout décisif pour outiller les démarches de réingénierie organisationnelle.
La même analyse peut être faite sur la structure technique des applications,
qui sont souvent le résultat d'une histoire pendant laquelle des équipes techniques
ont développé cette application, parfois chez des éditeurs successifs. Il peut être
nécessaire de « re-concevoir » l'architecture applicative de manière à rendre plus
efficace son partitionnement, du point de vue du couplage technique entre ces
composantes. On peut utiliser notre cadre d'ingénierie comme outil de conception
d'une architecture distribuée faiblement couplée. Les premiers cas d'étude sur le
dictionnaire des données BAAN (chapitre 3.4) sont illustratifs de la possibilité d'une
démarche d'ingénierie inverse, prenant en compte le modèle d'entreprise
globalement.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 265
 Conclusions et Perspectives / Conclusions et perspectives académiques

2 Etude systématique de l'alignement

N ous avons redéfini la problématique de l'alignement des S.I. comme l'étude de

la cohérence de différents points de vue dans l'ingénierie d'entreprise.
L'alignement devient ainsi celui des construits et de leurs structures, porté par ou les
dépendances qui forment une relation plus ou moins complexe entre des points de
vue ou des structures.
On peut ainsi considérer des formes d'alignement variées pour chaque
couple de points de vue, voire pour chaque couple de construits. Ainsi, on peut
évaluer l'alignement d'une solution progicielle standard à une description de besoin
en étudiant la dépendance « Features » sur « IT Resource ». On peut aussi étudier
l'alignement organisationnel entre les aptitudes des entités organisationnelles et les
fonctions assurées par les ressources pour servir les processus. On peut encore
étudier l'alignement entre les structures de données portées par les applications et
les vues informationnelles des évènements et objets d'entreprise.
Chaque alignement partiel peut être étudié en comparant les topologies des
graphes correspondants, graphes qui peuvent être plus ou moins semblables. Si deux
points de vues ont des graphes « semblables » au sens de la théorie des graphes, on
peut considérer qu'ils ont « bien alignés ». De manière prosaique, l'alignement se
visualise alors par le fait que les deux graphes peuvent être superposés facilement,
chaque construit de l'un étant lié à un construit de l'autre, et les dépendances dans
l'un étant en correspondance avec une dépendance dans l'autre. Sans aller jusqu'à
une telle similarité forte, on peut aussi comparer des partitions de deux points de
vues en cherchant si les dépendances existantes « conservent » ces partitions, au
sens ou « l'image » d'une structure du point de vue A par les dépendances entre A et
le point de vue B serait aussi une structure de B. On peut ainsi proposer une
évaluation quantitative de l'alignement entre deux points de vues par le taux de
dépendances qui sont « transverses » aux partitions des construits de chaque point
de vue.
Le fait de définir l'alignement comme une caractéristique mesurable du
modèle d'entreprise ouvre ainsi un champ d'étude vaste pour transformer une
démarche d'origine managériale en une démarche d'ingénierie outillée.

3 Extension du modèle vers le pilotage

L e graphe étudié peut être plus ou moins étendu selon la granularité du modèle.
On peut en effet prendre en compte non seulement les types de données mais
aussi les données dynamiques de l'encours (ordres d'achat, de vente, de

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 266
 Conclusions et Perspectives / Conclusions et perspectives académiques

fabrication...), la caractérisation non seulement des articles, mais de leurs lots ou

séries, voire la sérialisation de chaque pièce physique, y compris en suivant son
cycle de vie mémorisant les différents « statuts » d'une même pièce. Bien entendu,
un graphe ainsi étendu aux données dynamiques devient un graphe de très grande
taille dont le traitement interdit les approches transactionnelles et pour lequel les
temps de calcul des distances ou les temps de partitionnement deviendront
prohibitifs. Par contre, plus le graphe est détaillé, plus il peut être pertinent de le
considérer comme un graphe orienté, dans la mesure ou les cycles structurels
étudiés précédemment disparaissent le plus souvent à un niveau de détail suffisant.
De plus, les dépendances seront souvent contextuelles et la gestion d'un graphe
dynamique permet d'intégrer le « workflow » du système dans l'étude de
l'intégration. Une dépendance entre demande d'achat et entité de validation peut
ainsi n'être active que pour certains achats.
La prise en compte d'un graphe étendu peut être le support pour aller vers
une étude de l'intégration en terme de pilotage. Au delà de l'ingénierie, et même de
la réingénierie et de la conduite du changement, le graphe dynamique peut
permettre de construire des outils d'aide à l'action en cohérence avec le modèle
d'intégration. C'est une des pistes d'amélioration de la matrice de maturité proposée
dans la section 3.2.7 afin de gérer les plans d'actions en tenant compte des
ressources concernées, des aptitudes nécessaires, des indicateurs de suivi...

4.1.3 Perspectives pour le graphe d'intégration

1 Vers un graphe orienté, valué et hiérarchisé

N ous avons considéré un graphe non orienté, non hiérarchisé, non valué pour
valider un cadre d'ingénierie « typé intégration ». Mais tout indique que les
dépendances d'intégration ne sont pas homogènes. Plusieurs caractéristiques des
dépendances peuvent conduire à un graphe enrichi.
Nous avons proposé de caractériser les dépendances par deux valeurs
représentatives d'une part de leur nature plus ou moins organisationnelle, d'autre
part de la maturité de l'organisation sur ces dépendances (3.2.7). Ces deux
caractéristiques peuvent intervenir dans les notions de voisinage et de partition
évoquées. Cela suppose de raisonner sur un graphe valué par ces caractéristiques.
Mais nous avons souligné qu'une maturité faible pèse négativement sur l'ensemble
d'une chaîne. En quelque sorte, cette caractéristique se propage dans les
dépendances pour affaiblir l'efficacité des construits liés par ces dépendances. A

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 267
 Conclusions et Perspectives / Conclusions et perspectives académiques

l'inverse, une forte maturité peut venir « compenser » des faiblesses en amont ou en
aval... La manière dont le modèle permet de tenir compte de cette tension entre
propagation des erreurs, et actions correctrices ne peut se limiter à une moyenne
quantitative. Le graphe non orienté ne permet pas de tenir compte d'une réalité forte
: les erreurs et les actions correctrices se propagent toujours « chronologiquement ».
De ce point de vue, le graphe non orienté ne permet pas de représenter le temps de
l'action, qu'elle soit positive ou négative sur la maturité, ni son impact sur
l'intégration. Il paraît nécessaire, une fois la structure « statique » de l'intégration
identifiée et analysée, de permettre une approche dynamique du même graphe en
considérant le graphe orienté et en évaluant les distances en terme de « flux » dans
le sens chronologique. On peut alors prendre en compte des choix organisationnels
de « découplage » entre domaines ou entités qui viennent « bufferiser » l'intégration
en remplaçant une dépendance directe entre deux construits par un « couplage
piloté » faisant en général intervenir un acteur qui va prendre des décisions pour
gérer cette dépendance. Ainsi, un stock représente bien évidemment un
« découplage » entre le flux amont et aval de ce stock et nécessite une « gestion de
stock » qui devient elle même un élément du modèle. Cette notion de découplage
peut être généralisée et permet de caractériser une chaîne de dépendances non
seulement par une distance, mais aussi par un mode de pilotage. Cela suppose que
l'unité organisationnelle (ou les unités) responsable des construits source et
destination de la dépendance soit en situation de piloter cette dépendance.
Enfin, la taille d'un graphe rend nécessaire d'en maitriser des
représentations condensées. De nombreuses relations d'agrégation dans le méta-
modèle permettent d'étudier le graphe à différents niveaux de hiérarchisation. On
peut ainsi agréger l'ensemble des dépendances liant des activités (EA) au niveau des
processus (BP), et même au niveau d'un domaine. De même, on peut considérer les
rôles au niveau des unités organisationnelles (OU), mais aussi au niveau des
structures organisationnelles (OC); services, départements, sites... Mais cela
suppose d'étudier comment l'intégration « s'agrège ». nous avons vu dans le cas
académique que le méta-graphe au niveau des partitions était très fortement
connecté (Figure 3.31). Ce comportement est-il général ? Comment caractériser la
le comportement du graphe dans la hiérarchie des construits. Comment garantir la
consistance du graphe de ce point de vue pour éviter que des dépendances se
« croisent » entre niveaux hiérarchiques ? De plus, la hiérarchisation est un enjeu
important de la représentation d'un graphe de grande taille essentielle pour faciliter
l'affichage de modèles navigables.

L 'ensemble de ces éléments peut conduire à considérer un graphe orienté

chronologiquement dans le sens de l'action, valué par les caractéristiques
socio-techniques des dépendances, hiérarchisé par les structures existantes ou

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 268
 Conclusions et Perspectives / Conclusions et perspectives académiques

proposées par un partitionnement. De nombreux outils existent en théorie des

graphes pour supporter de tels graphes mais demandent d'être mis en oeuvre dans
notre contexte. De manière générale, nos travaux n'ont utilisé que des éléments de
base de la théorie des graphes. Or les domaines des réseaux sociaux par exemple
génèrent de nombreux travaux avancés sur l'identification de structures dans un
graphe, sur l'émergence de partitionnements...

2 Analyse locale et dynamique du graphe

N ous avons vu que si la complexité algorithmique du calcul de distance était

faible, sa mise en oeuvre sur des graphes de grande taille reste problématique
d'un point de vue industriel. Si l'intégration doit être prise en compte dans la
modélisation de manière dynamique, il doit être possible de recalculer en
permanence les caractéristiques du graphe. Or, pour un graphe de taille industrielle,
de l'ordre de 10 5 objets, la matrice des distances est évidemment d'une taille trop
grande pour être entièrement recalculée à chaque modification du modèle. La
capacité à travailler « par écart » est donc essentielle. Or, on peut constater
justement que la distance nous permet de définir une notion de « voisinage » et que
cette notion topologique permet justement de considérer qu'une modification du
modèle n'a pas de conséquences fortes « au-delà de son voisinage ». Il s'agit d'une
piste essentielle pour industrialiser notre démarche en proposant des algorithmes de
mise à jour, qui peuvent ne pas être exacts dans la mise à jour des matrices de
distances, mais qui doivent conserver les caractéristiques de ces distances
pertinentes au sens de l'intégration, et notamment l'ordre relatif des voisins d'un
sommet du graphe. La gestion dynamique du graphe et de ses caractéristiques dans
un contexte de « plateforme de gestion d'un modèle d'entreprise » est donc
essentielle.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.1
Institut National des Sciences Appliquées de Lyon 269
 Conclusions et Perspectives / Perspectives d'applications industrielles

Chapitre 4.2
Perspectives d'applications
industrielles

Dans ce chapitre, nous présentons trois types d'application

industrielles de nos travaux.

Le premier concerne la navigation non hiérarchique dans une

application de grande taille, navigation utilisation le graphe
d'intégration comme support pour constituer dynamiquement des
contextes d'intégration pertinent pour le point de vue choisi par
l'utilisateur. Nous avons réalisé sur le cas BAAN un exemple simplifié
concernant la structure des modules de cet ERP.

Le deuxième concerne les éditeurs de progiciels considéré comme

'industriel en proposant une démarche de ré-ingénierie de
l'architecture applicative cherchant des décompositions à faible
couplages. Là encore , un exemple issu de notre expérience BAAN est
proposé concernant les tables de la partie « fabrication ».

Le troisième concerne un projet encours de validation pour un

« configurateur de projet ERP » qui s'appuierait sur un graphe
d'intégration pour constituer des listes de tâches tenant compte des
dépendances du graphed d'intégration et proposer un
dimensionnement de ces tâches.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 271
 Conclusions et Perspectives / Perspectives d'applications industrielles

4.2.1 Navigation non hiérarchique dans un ERP

U ne conséquence de l'intégration d'un système d'information est de rendre

largement inefficace pour l'utilisateur la navigation hiérarchique qui reste le
mode de navigation principal des applications. Les ERP notamment se
« découvrent » principalement à travers des menus pouvant contenir plus de 10
niveaux hiérarchiques et des milliers de transactions de base (près de 20000 pour
SAP). Chaque transaction est elle-même le plus souvent un objet technique riche,
mais la navigation à l'intérieur d'une transaction utilise désormais largement les
pratiques d'ergonomie des interfaces web (popup, liens, raccourcis...). Cependant,
rien ne permet d'indiquer à l'utilisateur que la transaction T1 qu'il utilise est
« dépendante » d'autres transactions Ti qui ne sont pas nécessairement regroupés
dans le même « sous-menu » que T1...
De nombreux travaux ont été réalisés sur des interfaces orientés « rôles »
qui se construisent dynamiquement à partir de modèles de processus et de rôles
associés (Singh et Rein 1992), (Plaisant et Shneiderman 1995). Mais ces travaux
supposent une modélisation externe des rôles et processus. Notre approche peut
permettre au contraire de construire des postes de travail qui « rapprochent » les
éléments de navigation en fonction de leur distance dans le graphe d'intégration. On
a alors un outillage possible pour supporter des postes de travail dynamiques
éclairant au mieux les enjeux de l'intégration pour l'utilisateur. La Figure 4.1
présente une ébauche de cartographie colorée automatiquement à partir des
distances d'intégration. Ces cartes s'inspirent des “Solution Map” de l'éditeur SAP
qui sont des cartes statiques configurables à partir de sélection de domaines ou de
typologies d'activité pour caractériser à haut niveau un périmètre de projet. Notre
approche permet d'enrichir de telles cartes en les transformation en support
d'interrogation pour l'utilisateur afin de l'aider à découvrir les contraintes de
l'intégration. Une telle carte colorable lui permet de découvrir que “si j'utilise telle
fonction, alors il y a un impact sur telles autres fonctions...”
Nous avons réalisé une telle cartographie interactive pour le cas BAAN
avec un modèle limité aux fonctions et processus (Figure 4.1). Quand l'utilisateur
sélectionne un point de vue (un module d'une application), les modules dépendants
sont colorés de manière proportionnelle au nombre de dépendances.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 272
 Conclusions et Perspectives / Perspectives d'applications industrielles

Figure 4.1 cartographie colorée par l'intégration.

Quand l'utilisateur sélectionne un point de vue, les modules BAAN qui

sont « connectés » a ce point de vue sont colorés de manière proportionnelle à leur
couplage avec le point de vue sélectionné. Cette approche suppose d'être étendue à
un modèle plus complet. Elle peut s'appuyer sur de nombreux travaux en
visualisation de graphes de grande taille (Karouach et Dousset 2003).

4.2.2 Re-conception architecture applicative ERP

L e processus continu de conception/reconception d'un système de grande taille

comme un ERP est complexe dans un contexte d'objectifs contradictoires :
réduction du temps de cycle de réalisation mais simplification et réutilisation des
sources existants, capacité d'intégration forte mais souplesse de configuration pour
répondre à des besoins d'intégration variés, enrichissement permanent des
fonctionnalités mais nécessité d'une compatibilité ascendante pour les usages
existants...
Les acteurs de la conception sont donc en permanence conduit à
s'interroger sur la structuration technique du système, autant au plan des données,
que des logiques et services, ou des interfaces. Nous avons ainsi étudié le modèle
de données de l'ERP BAAN5.0c (Millet 2005) dont la partie gestion de production
est organisée en 13 modules avec 381 dépendances (contraintes d'intégrité entre

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 273
 Conclusions et Perspectives / Perspectives d'applications industrielles

tables de la base de données) dont 131 inter-modules. Un partitionnement de ce cas

conduit à des propositions de structures techniques nouvelles soit avec le même
nombre de modules mais moins de dépendances inter-modules, soit avec moins de
modules. On peut ainsi avoir une structure de 13 modules et seulement 89
dépendances inter-modules, donc une architecture plus faiblement couplée. On peut
aussi proposer une architecture en 7 modules avec seulement 79 dépendances inter-
modules, donc encore moins couplée.
L'enjeu d'une telle recherche de simplification de la structure technique
concerne bien entendu la facilité de maintenance de l'application dans la mesure où
la modification d'un composant a un nombre de conséquences à tester qui est
directement lié au couplage de ce composant dans le système. Mais il concerne
aussi l'utilisateur final, la simplicité de l'usage, la lisibilité des supports de
formation, l'ergonomie des interfaces... Du point de vue du graphe de l'intégration
que nous avons étudié, si le degré du graphe au niveau détaillé est représentatif du
couplage maximum entre les objets du modèle, donc du niveau d'intégration du
système, le degré du graphe agrégé au niveau des structures organisationnelles ou
techniques est lui représentatif de la capacité de la structure à absorber cette
intégration. Nous pouvons poursuivre le travail sur des applications de grande taille
pour chercher une approche de partitionnement permettant de faire émerger une
architecture technique plus pertinente pour l'alignement de ces solutions dans des
modèles d'entreprises. On peut s'interroger sur le caractère dynamique de cette
reconfiguration de l'application, l'architecture modulaire la plus efficace pour tenir
compte de l'intégration pouvant être ainsi dépendante du cas mis en oeuvre. La
capacité à proposer une architecture technique dynamique, reconfigurée à la
demande en fonction de typologies des points de vue organisationnel ou
économique du modèle est ainsi une perspective innovante pour les éditeurs de
progiciels, à rapprocher des évolutions vers l'orchestration de services.

4.2.3 Vers un configurateur de projet ERP

L e marché des progiciels pour les systèmes d’information d’entreprise est

devenu un marché de renouvellement dans les grands comptes. Son extension
dans les PME est rendu difficile par les difficultés connues de ces projets, les
incertitudes de leur retour sur investissement, le coût de l’interopérabilité, la
nécessité d’architectures de solutions flexibles et évolutives. Ce constat concerne
d’abord les ERP (Enterprise Resource Planning), mais aussi les autres solutions
d’entreprise; MES (Manufacturing Execution System) pour la production, SCE
(Supply Chain Execution) pour la logistique, PDM (Product Data Management)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 274
 Conclusions et Perspectives / Perspectives d'applications industrielles

pour l’ingénierie… Dans ce contexte, pour permettre au plus grand nombre

d’entreprise de bénéficier des avantages de l’intégration des systèmes
d’information, et donc pour augmenter les revenus de licences et de services, il est
nécessaire :
de réduire les risques et les coûts de la mise en oeuvre des solutions de gestion
intégrées pour les entreprises utilisatrices,
de garantir un cadre d’interopérabilité technique et informationnelle pour un
marché dynamique de l’édition de progiciel.
Cela nécessite des outils de gestion de projet pour maîtriser l’intégration
organisationnelle et informationnelle, s’appuyant sur des référentiels standard
facilitant l’interopérabilité. Dans le contexte évolutif des entreprises et des
progiciels, ces outils doivent s’appuyer sur une modélisation d’entreprise et
permettre de maîtriser son adéquation aux modèles internes des progiciels, en
identifiant les dépendances entre les objets techniques et métiers qu’ils utilisent.
Deux aspects fortement étudiés dans cette thèse sont au cœur d'un tel
« configurateur de projet ERP ».
La prise en compte de référentiels standard au niveau du modèle d'entreprise,
La prise en compte des dépendances entre objets pour identifier à tout moment la
liste des objets/tâches concernées par une tâche, autant en termes de prérequis,
que de conséquences et d'utiliser cet ensemble de dépendances pour calculer un
« poids » de cet objet dans la charge des différents acteurs d'un projet.
Nous avons déposé dans cet esprit un projet de recherche régional dont les
objectifs ont été validés et qui doit se dérouler sur les années 2009-2011. Cette
démarche est proche de celle du leader du marché « SAP Solution Manager »,
application utilisant la plateforme technologique SAP qui supporte l’ensemble du
cycle de vie du système d’information (S.I.), des phases de construction de projet à
la mise en œuvre, puis à l’exploitation et à l’optimisation. Cette solution est
caractérisée par :
son intégration complète à la plateforme SAP, ce qui en fait une force, mais aussi
une limite pour aborder un S.I. hétérogène,
son choix de ne pas intégrer directement un outil de modélisation d’entreprise
compte tenu des accords de partenariat existant avec le leader ARIS (Société IDS
Scheer),
sa structure entièrement arborescente (scénario/processus/transaction) dans le
contexte de la transversalité sur laquelle repose l’intégration caractéristique des
ERP.
L’objectif de cette spécification est à contrario de proposer une solution :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 275
 Conclusions et Perspectives / Perspectives d'applications industrielles

indépendante des applications concernées et pouvant en intégrer plusieurs dans

une approche « multi-applications » ce qui rend nécessaire d’extraire de chaque
application des « modèles de références standard »,
ouverte sur la diversité des solutions de modélisation, notamment en s'appuyant
sur un cadre et un langage normalisé de modélisation,
permettant d’identifier et d’utiliser les dépendances entre objets informationnels
et organisationnels, s’appuyant sur un moteur de gestion de graphes de
dépendances.

U ne telle solution de gestion de projet « ERP » doit répondre à la fois aux

attentes des acteurs d’un processus de sélection de solutions (comparaison,
dimensionnement, sélection... ) et à celles des acteurs d’un projet de mise en œuvre
de progiciels dans leur dimension humaine et organisationnelle (liste de tâches,
rôles, suivi...) avec dans les deux cas une intégration forte entre la gestion de projet
et la documentation associée aux solutions standard (documenter une tâche du
projet à partir des éléments techniques de la tâche fournie par une des solutions)
Les attentes des forces de vente du marché progiciel sont les suivantes :
Gérer la très large documentation associée aux solutions pour construire des
réponses adaptées aux requêtes des prospects (on peut parler d’une gestion
documentaire orientée client à partir d’une documentation standard).
Ce point ne fait pas partie du projet de recherche et est bien évidemment très
dépendant de chaque solution.
Dimensionner les services et charges de travail nécessaires à la réussite d’un
projet dans un périmètre donné, en facilitant la mesure du niveau d’adéquation
entre le standard et le besoin d’entreprise. Cela nécessite :
de structurer le contenu d’un projet de différents points de vue (fonctionnel,
processus, organisationnel, informationnel…),
de structurer une méthode de projet (ressources, jalons, tâches),
de proposer des règles de calcul prenant en compte le périmètre et la méthode
projet, tenant compte des engagements et des caractéristiques propres du client
et du projet, permettant le dimensionnement rapide d’un projet et son
adaptation aux processus de décision et de contractualisation.
Définir les rôles et engagements des différents acteurs, faciliter les analyses de
risques comme support des négociations commerciales, produire les listes de
tâches nécessaires à la gestion de projet :
Cela suppose de modéliser les risques et engagements de projets, et d’en tenir
compte dans l’organisation d’un projet, la définition des jalons et des tâches, le
dimensionnement des charges correspondantes.
Les attentes des acteurs des projets progiciels sont les suivantes :

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 276
 Conclusions et Perspectives / Perspectives d'applications industrielles

Organiser un projet de manière cohérente aux engagements pris dans les phases
commerciales, tout en le détaillant pour tenir compte des ressources réelles, des
contraintes de planning, de logistique, et les modifications de périmètre ou de
priorités que l’entreprise cliente peut décider. Cela nécessite de gérer et tracer les
modifications de périmètre, de méthode, d’engagements ou de caractéristiques
d’un projet afin d’en identifier les conséquences sur l’organisation et le
dimensionnement de projet à partir des structures mises en place en avant-vente.
Distribuer le travail aux différents acteurs de manière précise et actualisée en
fonction de l’avancement de projet. Suivre la réalisation de ces tâches et leur
adaptation nécessaire aux résultats obtenus et aléas de projet rencontrés. Cela
nécessite :
d’identifier la relation entre tâches affectées à une ressource et périmètre de
projet concerné, tout en tenant compte de la transversalité qui fait qu’un objet
du projet peut concerner plusieurs ressources et plusieurs tâches.
de pouvoir fournir à un acteur concerné par une fonction ou processus dans une
tâche de projet l’ensemble des données de base, paramètres ou décisions déjà
prises qui impactent la tâche à réaliser.
Supporter un suivi de projet en termes de temps passé, d’avancement, de
production de livrables et d’évaluation par rapport à la définition de projet. Des
indicateurs pertinents d’évaluation quantitatifs et qualitatifs du projet sont
nécessaires.
Ce besoin est une fonction classique existante dans la plupart des outils de
gestion de projet. Les indicateurs pertinents doivent bien entendu être
construits à partir de la définition du contenu du projet issue de la modélisation
d'entreprise.
Ce projet de recherche est un cadre industriel de mise en oeuvre à la fois
du cadre d'ingénierie d'entreprise et du graphe d'intégration décrit dans cette thèse et
en constitue le prolongement naturel.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 4 / Chapitre 4.2
Institut National des Sciences Appliquées de Lyon 277
 Partie 5

Annexes

Annexe 1 Liste des fonctions de l'ERP BAAN......................................280

Annexe 2 Liste de construits de modélisation....................................281

Annexe 3 Liste des blocs de construction SAP A1...............................282

Annexe 4 Définition des briques applicatives.....................................283

Annexe 5 Algorithmes utilisés..........................................................287

Annexe 6 Bibliographie...................................................................291

Annexe 7 Listes des figures ............................................................305

Annexe 8 Listes des Tableaux..........................................................307

 Annexes / Annexes

Annexe 1 Liste des fonctions de

l'ERP BAAN

C ette liste représente une décomposition modulaire de l'ERP BAAN qui permet
de définir une configuration grossière d’un périmètre applicatif (Tableau 5.1).

MAM Account Management Gestion Compte Tiers

MAP Account Payable Invoices Facturation Fournisseur
MAR Account Receivable Invoices Facturation Client
MAS Fixed Assets Immobilisations
MCM Cash Management Gestion trésorerie
MCO Call/Order Management Gestion des appels
MCS Cost Accounting Comptabilité analytique
MDM Demand Management Gestion de la demande
MEN Engineering Ingénierie
MFM Freight Management Gestion du transport
MGE Master Data Données de base
MHR Human Resource Management Gestion des Ressources Humaines
MIM Inventory Management Gestion des stocks
MMN Production Gestion de Production
MOD Object Data Management Gestion documentaire
MPA Product Assortment Management Gestion des assortiments produits
MPB Financial Planning & Budgeting Budgétisation financière
MPL Enterprise Planning Planification d’entreprise
MPO Posting & Auditing Imputation et audit
MPR Project Management Gestion de projet
MPS Purchase & Sales Schedules Programmes cadencés achat/vente
MPU Purchase Gestion des Achats
MQM Quality Management Gestion de la qualité
MRA Reporting & Analyzing Contrôle de gestion
MSD RMA/ Depot Repair Control Gestion Atelier de réparation
MSE Service Execution Control Gestion des services
MSL Sales Gestion des ventes
MSU Supplier Management Gestion des fournisseurs
MWH Warehousing Gestion des magasins
Tableau 5.1. Liste des Fonctions principales de INFOR ERP LN 6 (BAAN)

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 280
 Annexes / Annexes

Annexe 2 Liste de construits de

modélisation

Code
L e tableau présente les construits utilisés dans le méta-modèle d'intégration et
dont l'étude conduit aux caractérisations proposées du graphe d'intégration.
Construit Source Description
Ev Event 19440 Changement dans l'état d'un objet d'entreprise
Do Domain 19440 Périmètre de projet regroupant des Business Process
BP Business Process 19440 Suite d'activité destinée à produire un résultat
EA Enterprise 19440 Étape d'un processus transformant un objet en utilisant des
Activity ressources
Re Ressource 19440 Objet d'entreprise intervenant dans une activité
FE Functional Entity 19440 Ensemble de ressources assurant certaines fonctions
Ca Capability 19440 Aptitude ou compétence portée par une ressource
EO Enterprise Object 19440 Représentation de tout objet de l'entreprise nécessaire au modèle
OV Object View 19440 Vue partielle d'un objet d'entreprise
Pr Product 19440 Objet particulier portant les caractéristiques de flux physiques
Or Order 19440 Objet particulier portant les caractéristiques d'une décision
OU Organizational 19440 Unité élémentaire qui regroupe des aptitudes et compétences
Unit
OC Organizational 19440 Regroupement hiérarchisé d'unités organisationnelles
Cell
DC Decision Center 19440 Organisation support d'un cadre de décision (grille Grai)
Ob Objective 19440 Objectifs identifiés associés à des unités organisationnelles
Me Metrics SCOR Indicateurs de mesure d'un objectif
Fea Feature SCOR Définition externe d'une fonctionnalité support d'une activité
Pr Practices SCOR Description organisationnelle et fonctionnelle d'une « bonne
pratique » permettant d'atteindre un objectif
Da Data ERP Objet Informatique identifié dans une base de donnée
IT IT Resource ERP Composant ou service informatique dont lidentification est
nécessai à la modèlisation
Lo IT Logic ERP Traitement informatique réutlisable dont l'identification est
nécessaire à la modélisation
In Interface / ERP Objet support d'une interaction entre le système informatique et les
Interaction acteurs
Pa Package ERP Regroupement technique d'un ensemble de ressources
informatiques (progiciel, module...)

Tableau 5.2 : Liste des construits du méta-modèle d'intégration

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 281
 Annexes / Annexes

Annexe 3 Liste des blocs de

construction SAP A1
Ce tableau présente la liste des blocs de construction proposés par l'éditeur SAP dans son offre
pré-packagée SAP A1.

Code Description des Building's Blocks

B46 Cash Management
D41 On-Site Repair Services
D42 Returns and Repairs and Plant
D43 Preventive Maintenance
D44 Internal Maintenance
D48 Project with Intercompany Billing
J09 Travel Management
J45 Spot Consulting
J46 Project with Fixed Price and Time and Material Billing
J47 Contract with Auto Creation of Project, Downpayment
J49 Procurement of Stock Material
J50 Procurement - Contract
J51 Internal Procurement (Stock Transfer with Delivery)
J52 Internal Procurement (Stock Transfer Without Delivery)
J53 Internal Procurement (Cross-Company Stock Transfer)
J54 Third Party With Shipping Notification
J55 Third Party Without Shipping Notification
J56 Bought-In Item
J57 Extended Sales Order Processing
J58 Customer Consignment Processing
J59 Returns and Complaints
J60 Returnable Processing
J61 Batch Recall
J62 Cross-Company Sales Order Processing
J63 Sales Order Processing with Dummy Customer
J64 PP and Discrete Manufacturing - Make-to-Stock
J65 PP and Process Manufacturing - Make-to-Stock
J66 Make-to-Order Quotation Processing/Order Processing
J67 Repetitive Manufacturing
J73 Physical Inventory
N70 Financial Accounting
N71 Standard Cost Center Accounting
N72 Asset Management
N73 Period End Closing for Financial Accounting

Tableau 5.3 : Liste des blocs de construction SAP A1

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 282
 Annexes / Annexes

Annexe 4 Définition des briques applicatives

Sigle Définition proposée Définition APICS Définition GARTNER
Supply Chain Proches des APS, les briques de type SCP « The determination of a set of policies and « A subset of supply chain management
Planning (SCP) sont centrés sur la planification de la chaîne procedures that govern the operation of a (SCM), SCP is the process of coordinating
logistique (réseau, capacités, fabrication, supply chain. Planning includes the assets to optimize the delivery of goods,
distribution) pour traduire la prévision de determination of marketing channels, services and information from supplier to
demande en programmes promotions, respective quantities and customer, balancing supply and demand.
d’approvisionnement interne ou externe timing, inventory and replenishment An SCP suite sits on top of a transactional
optimisés (sourcing : gestion des sources policies, and production policies. Planning system to provide planning, what-if
d’approvisionnements, contrats). establishes the parameters within which the scenario analysis capabilities and real-time
supply chain will operate » demand commitments. Typical modules
include network planning, capacity
planning, demand planning, manufacturing
planning and scheduling, distribution and
deployment planning, and transportation
planning and scheduling. »
Supply Chain Application destinée à diffuser les
Event événements internes et externes dans la
Management chaîne logistique pour fournir une visibilité
(SCEM) globale en temps réel. Lien opérationnel
entre les solutions de SCP et SCE.

Pierre-Alain MILLET Partie 5 / Partie 5

Thèse en informatique/ 2008 283
Institut national des sciences appliquées de Lyon
 Annexes / Annexes

Sigle Définition proposée Définition APICS Définition GARTNER

Advanced Parfois présenté comme un sous-ensemble du « Techniques that deal with analysis and Sous-ensemble «le du SCP contextually describing
Planning and SCP, l’APS est un outil d’aide à la décision planning of logistics and manufacturing
Scheduling (APS) (scénarios multiples) en planification over the short, intermediate, and long- manufacturing »
orientée client utilisant un système term time periods. APS describes any
transactionnel (le plus souvent ERP). Il computer program that uses advanced
permet d’obtenir un disponible à la vente mathematical algorithms or logic to
fiable (ATP, available-to-promise) en perform optimization or simulation on
prévision et en prise de commande, prenant finite capacity scheduling, sourcing,
en compte les stocks et la capacité à produire capital planning, resource planning,
(CTP, capable-to-promise) forecasting, demand management, and
others. »
Business Outils regroupant des données des autres « A computer system designed to assist « An interactive process for exploring and analyzing
Intelligence (BI) briques applicatives dans des entrepôts de managers in selecting and evaluating structured, domain-specific information (often stored in
ou données (datawarehouse), pour des analyses courses of action by providing a logical, data warehouses) to discern trends or patterns, thereby
Système multidimensionnelles (fouille de données, usually quantitative, analysis of the deriving insights and drawing conclusions. The BI
Informatique datamining, OLAP…) afin de produire des relevant factors », process includes communicating findings and effecting
d’Aide à la tableaux de bord et indicateurs supports des change. Domains include customers, suppliers, products,
Décision (SIAD) processus de décision. services and competitors »
Customer Applications support de la connaissance des « A marketing philosophy based on Supplier Relationship Management (SRM)
Relationship clients et prospects, des actions de putting the customer first. The collection
Management prospection (promotions, visites, étude de and analysis of information designed for
(CRM) marché, fidélisation…) et d’une relation sales and marketing decision support (as
intégrée mettant le client au centre des contrasted to enterprise resources
fonctions commerciales, logistiques et de planning information) to understand and
services (satisfaction client, services associés support existing and potential customer
aux ventes, différenciation, traçabilité et needs. It includes account management,
visibilité…) catalog and order entry, payment
processing, credits and adjustments, and
other functions. Syn: customer relations
management. »
Product Data Brique supportant la gestion des données « A system that tracks the configurations « PDM has served as a complementary application tower
Management techniques et permettant la diffusion de ces of parts and bills of material and also the to computer-aided design (CAD) and enterprise resource
(PDM) données, de leurs révisions et de leurs revisions and history of product designs. planning (ERP) systems by providing the main repository
ou documents associés aux acteurs et aux It facilities the design release, distributes for production-approved engineering data (i.e., vaulting)
Système de applications d'exécution qui les utilisent. the design data to multiple manufacturing and managing the changes to production - approved data
Gestion des sites, and manages changes to the design (e.g., engineering change orders and configuration
Données in a closed-loop fashion. It provides the management).. »
Techniques infrastructure that controls the design
(SGDT) cycle and manages change. »
Product Lifecyle Système de gestion étendu des données « for managing the inter-enterprise product development
Management techniques dans le cycle de vie des produits, process from concept through production. The goal of a

Pierre-Alain MILLET Partie 5 / Partie 5

Thèse en informatique/ 2008 284
Institut national des sciences appliquées de Lyon
 Annexes / Annexes

Sigle Définition proposée Définition APICS Définition GARTNER

(PLM) de la conception à la maintenance sur site et PDM II strategy is to provide the proper combination of
parfois appelé la relation client. people, process and technologies to support the
PDM II management of the entire inter-enterprise product
development commercialization process to enhance
competitiveness. The PDM II vision provides a
framework for rationalizing the roles of product data
management (PDM), virtual PDM (VPDM) and enterprise
resource planning (ERP) technologies. »
Supply Chain Ces outils ont pour vocation de rationaliser la « Execution-oriented software « A subset of supply chain management, this is a
Execution (SCE) totalité du cycle de traitement des flux (de applications for effective procurement framework of execution-oriented applications that
l’entrée des commandes à la facturation). Ils and supply of goods and services across a enables the efficient procurement and supply of goods,
regroupent : (a) la gestion de l’entreposage supply chain. It includes manufacturing, services and information across enterprise boundaries to
(WMS), (b) la gestion du transport (TMS) et warehouse, and transportation execution meet customer-specific demand, in its broadest sense »
parfois aussi (c) la gestion avancée des systems, and systems providing visibility including WMS and MES
commandes (AOM : Advanced Order across the supply chain »
Management).
Warehouse « A software application that manages the operations of a
Management warehouse or distribution center. Application
System (WMS) functionality includes receiving, inventory management,
cycle counting, task interleaving, wave planning, order
allocation, order picking, replenishment, packing,
shipping, labor management and automated material
handling equipment interfaces. The use of radio
frequency technology in conjunction with bar codes
provides the foundation of a WMS, delivering accurate
information in real time »

Transportation « System used to plan freight movements, do freight

Management rating and shopping across all modes, select the
System (TMS) appropriate route and carrier, and manage freight bills
and payments »
Enterprise « une offre progicielle regroupant des
«Framework for organizing, defining, « An application and deployment strategy that expands
Ressource applications paramétrables, modulaires,
Planning (ERP) intégrées et ouvertes, s’appuyant sur un and standardizing the businessprocesses from traditional enterprise resource planning (ERP)
référentiel unique de données, de procédures
et de règles de gestion. Configuré et adapté necessary to effectively plan and control functionality to achieve integration of an enterprise’s key
au contexte d’une entreprise, il devient le an organization so theorganization can internal and external collaborative, operational and
support d’une stratégie d’intégration qui vise
à fédérer et à optimiser les processus de use its internal knowledge to seek financial processes. ERP II starts as an application
gestion de l’entreprise et de relation avec ses
external advantage. » strategy, setting a vision for the integration of all
partenaires »

Pierre-Alain MILLET Partie 5 / Partie 5

Thèse en informatique/ 2008 285
Institut national des sciences appliquées de Lyon
 Annexes / Annexes

Sigle Définition proposée Définition APICS Définition GARTNER

enterprise centric, commerce-oriented business
processes, without requiring a single-vendor strategy. As
a deployment strategy, ERP II enables enterprises to
determine the degree of single-vendor-centricity needed
to fulfill enterprise process requirements and — through
native integration capabilities — to include best-of-breed
components from multiple vendors. ERP II includes
capabilities specific to the enterprise, as well as the
ability to connect the enterprise to key business partners
directly or through a private e-marketplace. The process
domain of ERP II includes all collaborative, operational
and financial processes that have the enterprise at the
center. See ERP and e-marketplace. »

Tableau 5.4 : Définition de briques applicatives

Pierre-Alain MILLET Partie 5 / Partie 5

Thèse en informatique/ 2008 286
Institut national des sciences appliquées de Lyon
 Annexes / Annexes

Annexe 5 Algorithmes utilisés

L es outils de calculs sur les graphes reposent sur deux modules principaux, le
calcul des voisinages et des distances et le partitionnement. Les sources
correspondent au langage de calcul scientifique numérique scilab développé par
l'INRIA (version 4.1.2). L'ensemble de la plateforme de test est disponible sur
demande. Et comprend la gestion des cas décrits dans le chapitre 3.4, les outils
d'analyse des résultats des algorithmes, d'affichage, de sauvegarde des matrices...
//-----------------------------------------------------------------------------
// calcul des voisins et aretes voisines
// principe vs(s,n) = liste des voisins de s à la distance n
// vs(s,n+1)= union (vs(j,n), j dans vs(s,1) voisin de s )
// mes voisins-n sont les voisins-n-1 de mes voisins-1
// et mes voisines-n sont les voisines-n-1 des mes voisins-1
// on crée donc progressivement
// une matrice vs(s,l,i), ieme voisin de s a la longueur l
// une matrice vas(s,1,i), ieme arete à la distance l de s
//--------------------------------------------------------------------------------
function [vs,vas]=voisinaretes(out,g,longueur) // jusqu'à la longueur passée en paramètre
[diam,chemindiamètre] = graph_diameter(g) ;
[centre,rayon] = graph_center(g)
[nc,ncomp]=connex(g);
if diam>20, messagetrace(out,'diamètre graphe trop grand: stop'); return; end;
if nc>1, messagetrace(out,msprintf('%s %d','graphe non connexe, nb de composantes', nc)); return; end;
for s=1:node_number(g),
v=neighbors(s,g);
for k=1:size(v,"c")
a=arete(s,v(k),g);
vs(s,1,k)=v(k); // on a initialisé la longueur 1
vas(s,1,k)=a; // on a initialisé la longueur 1
end
end // on a donc les voisines de s dans vs(s,1,:)
for n=2:longueur
for s=1:node_number(g),
vs(s,n,1)=0; //vs(s,1,:) représente les voisins de s
vas(s,n,1)=0;
lvs=[]; for j=1:size(vs(s,1,:),3), lvs=union(lvs,vs(s,1,j)); end // voisins direct de s
if lvs(1)==0, lvs=lvs(2:$); end //0 n'est pas un voisin !
for k=lvs //lvs(k) est le keme voisin direct de s
u=union(vs(s,n,:),vs(k,n-1,:)); // on ajoute les voisins n-1 des voisins 1 de s
if u(1)==0 then u=u(2:$); end
for j=1:size(u,"c"), vs(s,n,j)=u(j); end ;
ua=union(vas(s,n,:),vas(k,n-1,:)); // on ajoute les voisines n-1 des voisins 1 de s
if ua(1)==0 then ua=ua(2:$); end
for j=1:size(ua,"c"), vas(s,n,j)=ua(j); end ;
end

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 287
 Annexes / Annexes

end
end
endfunction
//-------------------------------------------------------
// calcul du caractéristiques d'intégration
// couplage... nombres d'arcs dans le sous-graphe d'intégration reliant les sommets
// dissimilarité relatif.. dissimilarité rapportée à l'intégration totale des deux sommets
// dissimilarité... nombres d'arcs spécifiques à l'intégration de chaque sommet
//------------------------------------------------------
for s1=1:node_number(g),
for s2=1:node_number(g),
if s2<s1 // la matrice est symétrique...
integration(s1,s2)= integration(s2,s1);
couplage(s1,s2)=couplage(s2,s1);
dissimilarite(s1,s2)= dissimilarite(s2,s1);
dissimilariterelative(s1,s2)= dissimilariterelative(s2,s1);
else
vas1=[]; vas2=[];
for l=1:rayon,
vas1=union(vas1,vas(s1,l,:));
vas2=union(vas2,vas(s2,l,:));
end
un_sg=union(vas1,vas2); if un_sg(1)==0, un_sg=un_sg(2:$); end ;
in_sg=intersect(vas1,vas2); if in_sg(1)==0, in_sg=in_sg(2:$); end ;
integration(s1,s2)= size(un_sg,"c");
couplage(s1,s2)=size(in_sg,"c");
dissimilarite(s1,s2)= integration(s1,s2) - couplage(s1,s2);
dissimilariterelative(s1,s2)= (dissimilarite(s1,s2)/integration(s1,s2));
end
end
end
for s1=1:node_number(g),
for s2=1:node_number(g),
if s2<s1 // la matrice est symétrique...
longueur(s1,s2)=longueur(s2,s1);
else
if s1==s2, longueur(s1,s1)=0;
else [p,longueur(s1,s2)]=shortest_path(s1,s2,g,'arc');
end
end
end
end
end

//-------------------------------------------------------------------------------------------
// Algorithme de classification
// tant qu'il y a des sommets à classer
// on prend les deux sommets les plus éloignés
// on regarde leurs proches
// s'il y en a assez, on les mets de coté dans une classe potentielle
// sinon, on incremente un peu la définition des proches
// pour chaque sommet

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 288
 Annexes / Annexes

// on le classe dans la classe potentielle la plus proche

// on classe les sommets résiduels
//-------------------------------------------------------------------------------------------
fproches=0; classemin=3; increment=0.05;
//---------------------------------------------------------------------------PROCHES
function pr=proches(s,d,c,f)
pr=[]; cm=0;
drm=mean(d(s,:))-stdev(d(s,:))+(f*increment); // les plus proches en moyenne...
if drm < 0, // sommet fortement connexe.
drm=0.1+(f*increment); // on fixe une valeur de distance arbitraire
cm=mean(c(s,:))+stdev(c(s,:))-fproches; // on prend les plus fortement couplés
pr=find((d(s,:)<drm)&(c(s,:)>cm)); // on groupe les proches fortement couplés...
pr=[pr s]; // sans oublier le sommet origine (d=c=0 !)
else
if drm>1, // le sommet est très isolé
drm=0.9+(f*increment); // on essaie d'avoir qqchose
pr=sort(find(d(s,:)<drm));
else // cas "normal".. des proches mais pas trop...
pr=sort(find(d(s,:)<drm)); // on ne tient compte que de la distance
end
end
endfunction
//-------------------------------------------------------------------CLASSIFICATION
lac=1:node_number(g); c=0; classepot=[]; classe=[]; maxc=max(couplage);
while lac, // tant qu'il en reste ..
[m,k]=max(dissimilariterelative(lac,lac)+ (couplage(lac,lac)/maxc)); // les plus éloignés mais connectés.
p1=proches(lac(k(1)),dissimilariterelative, couplage,fproches); //les proches du premier
p2=proches(lac(k(2)),dissimilariterelative, couplage,fproches); //les proches du deuxième
if size(p1,'c')> classemin, // s'il y a assez de proches de p1...
c=c+1; classepot(p1,c)=dissimilariterelative(p1,k(1)); fproches=0;
else p1=[]; fproches=fproches+1; end // sinon on augmente le voisinage
if size(p2,'c')> classemin, // idem pour p2
c=c+1; classepot(p2,c)=dissimilariterelative(p2,k(2)); fproches=0;
else p2=[]; fproches=fproches+1; end
lac=difflist(lac,union(p1,p2)); // on supprime les sommets classés de la liste
end
nbc=c; // nombre de classes potentielles créées
for i=1:node_number(g) // la classe potentielle la plus proche
cp=find(classepot(i,:)>0); // on prend les classes possibles de i
if cp <> []
[m,k]=min(classepot(i,cp)) ;
classe(i)=cp(k) ; // on prend celle dont i est le plus proche
end
end
troppetite=find(classe<classemin); // on supprime les classes trop petites ou vides
for i=troppetite, classe(i)=0; end
uc=unique(classe'); // on prend les numéros de classe utilisés...
for i=1:node_number(g) classe(i)=find(uc==classe(i)); end
reste=find(classe==0); // on prend les sommets isolés
for i=reste, // il en reste
[s,k]=sort(dissimilariterelative(i,:));
j=size(k,'c');

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 289
 Annexes / Annexes

while classe(i)==0, classe(i)=classe(k(j)); j=j-1; end // on groupe avec le plus proche déjà classé
end

//--------------------------------------------------------------------
// script dessinant le graphe g avec un algorithme de force
// nécessite d'avoir calculé les matrices
// dissimilariterelative(s1,s2)
// longueur(s1,s2)
g=grapheenrond(g); // positionne les positions des sommets sur un cercle
w1=show_graph(g,'new',2); damping = 0.7; timestep=0.05;
attraction = ones(longueur); // attraction constante
repulsion = dissimilariterelative*(((max(g.node_x) - min(g.node_x))^2+(max(g.node_y) –
min(g.node_y))^2)^0.5)*10; // repulsion comme une gravité..
vitesse= zeros(node_number(g),2);
epsilon=node_number(g); energie = epsilon+1; l=0; limite=2000;
g.node_diam = nodes_degrees(g)^0.5;
energies=[];

while (energie > epsilon)&l<limite // tant que ca bouge un peu...

l=l+1; // on limite le nombre de boucles...
energie = 0; // on va calculer l'énergie cinétique du systeme
for n=1:node_number(g) // pour chaque sommet
force = [0,0]; // on somme les forces appliquées à n
for m=1:node_number(g) // à partir des autres sommets
if m <> n // on calcule la répulsion et l'attraction
dx = (g.node_x(n) - g.node_x(m));
dy = (g.node_y(n) - g.node_y(m));
dn = (dx^2 + dy^2)^0.5 ;
f = (dn*attraction(n,m)*4)/TAILLEGRAPHE -repulsion(n,m)*TAILLEGRAPHE/(4*dn)
if dx <> 0 force(1) = force(1) - f*dx/dn; end
if dy <> 0 force(2) = force(2) - f*dy/dn; end
end
end // les noeuds à fort degré bougent moins vite...
vitesse(n,1)= (vitesse(n,1)*damping) + (timestep * force(1) / g.node_diam(n));
vitesse(n,2)= (vitesse(n,2)*damping) + (timestep * force(2) / g.node_diam(n));
g.node_x(n) = g.node_x(n) + timestep * vitesse(n,1) ;
g.node_y(n) = g.node_y(n) + timestep * vitesse(n,2) ;
energie = energie + (((vitesse(n,1)^2) + (vitesse(n,2)^2))^0.5) ;
g.node_x(n), g.node_y(n),vitesse(n,1), vitesse(n,2)));
end
end
g.node_color = ones(1,node_number(g))*12; // sommet en rouge
g.node_border = nodes_degrees(g)^0.5; // rendre visible le degré
g.node_diam = nodes_degrees(g);
show_graph(g,'rep',0.3,[1000,800]);

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 290
 Annexes / Annexes

Annexe 6 Bibliographie
Abdinnour-Helm, Sue, Mark L. Lengnick-Hall, et Cynthia A. Lengnick-Hall. 2003. Pre-implementation
attitudes and organizational readiness for implementing an Enterprise Resource Planning system.
European Journal of Operational Research 146, no. 2- pp.258-273.
Abdmouleh, Anis, Michel Spadoni, et François Vernadat. 2004. Distributed client/server architecture for
CIMOSA-based enterprise components. Comput. Ind. 55, no. 3- pp.239-253
Abts, C. M., et B. W. Boehm. 1997. COTS Software Integration Cost Modeling Study. Contract 30602,
no. 94-C:1095.
Al-Mashari, Majed, Abdullah Al-Mudimigh, et Mohamed Zairi. 2003. Enterprise resource planning: A
taxonomy of critical factors. European Journal of Operational Research 146, no. 2- pp.352-364.
Albert, C., et L. Brownsword. 2002. Evolutionary Process for Integrating COTS-Based Systems (EPIC).
CMU/SEI-2002-TR-009.
Alter, Steven. 1999. A general, yet useful theory of information systems . Association for Information
Systems. Volume 1. Article 13. 70p.
Amoako-Gyampah, Kwasi, et A. F. Salam. 2004. An extension of the technology acceptance model in an
ERP implementation environment. Information & Management . 41, no. 6- pp.731-745.
ANACT. 2004. Déployer un progiciel de gestion intégré au service de l'organisation. Travail et
Changement, no 299- pp.2-4.
Anthony, R. N. 1964. Framework for analysis. Management Services (March-April): 18-24. Reprinted in
Rosen, L. S. 1974. Topics in Managerial Accounting, 2nd edition. McGraw-Hill Ryerson
Limited- pp.31-42.
APICS. 2002. APICS Dictionary : Thenth edition. 10 éd. Cox and Blackstone Editors.
APICS. 2005. APICS Dictionary : Traduction française, Lexique français-anglais. 11 éd. MGCM.
ATHENA. 2006. ATHENA Public Web Site. [Link] (Accédé Août 29, 2007).
Atle Gulla, J., et T. Brasethvik. 2000. On the challenges of business modeling in large-scale reengineering
projects. Dans Requirements Engineering, 2000. Proceedings. 4th International Conference on,
17-26.
Avila de Lima, Jorge. 2007. Teachers' professional development in departmentalised, loosely coupled
organisations: Lessons for school improvement from a case study of two curriculum departments.
School Effectiveness and School Improvement 18, no. 3 (Septembre)- pp.273-301.
Bakker, Albert R, et Freerk A Leguit. 1999. Evolution of an integrated HIS in the Netherlands.
International Journal of Medical Informatics 54, no. 3- pp.209-224.
Baïna Salah, Hevé Panetto, Khalid Benali. 2006. Apport de l'approche MDA pour une interopérabilité
sémantique : Interopérabilité des systèmes d'information d'entreprise. Ingénierie des systèmes
d'information. VOL 11/3 - 2006 - pp.11-29
Barut, Mehmet, Wolfgang Faisst, et John J. Kanet. 2002. Measuring supply chain coupling: an
information system perspective. European Journal of Purchasing & Supply Management 8, no. 3-
pp.161-171.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 291
 Annexes / Annexes

Beard, Jon W., et Mary Sumner. 2004. Seeking strategic advantage in the post-net era: viewing ERP
systems from the resource-based perspective. The Journal of Strategic Information Systems 13,
no. 2- pp.129-150.
Beatty, Robert C., et Craig D. Williams. 2006. ERP II: best practices for successfully implementing an
ERP upgrade . ACM Press. 49- pp.105-109
Beckert, J., M. Rosemann, et R. Schutte. 1997. Business to business process integration: functions and
methods. Proceedings of the Fifth European Conference on Information Systems (ECIS'97),
Cork, Ireland. Vol. 2, 816-827, GALLIERS R et al, Eds.
Bergeron, Francois, Louis Raymond, et Suzanne Rivard. 2004. Ideal patterns of strategic alignment and
business performance. Information & Management 41, no. 8 (Novembre)- pp. 1003-1020
Bergstrom, Max, et Lars Stehn. 2005. Matching industrialised timber frame housing needs and enterprise
resource planning: A change process. International Journal of Production Economics 97, no. 2-
pp.172-184.
Berio, G., et F. B. Vernadat. 1999. New developments in enterprise modelling using CIMOSA.
Computers in Industry 40, no. 2-3- pp.99-114.
Bernus, Peter, et Laszlo Nemes 1997. Requirements of the generic enterprise reference architecture and
methodology. Annual Reviews in Control 21- pp. 125-136.
Bernus, Peter, et Laszlo Nemes. 1996. A framework to define a generic enterprise reference architecture
and methodology. Computer Integrated Manufacturing Systems 9, no. 3- pp.179-191.
Bernus, Peter, et Laszlo Nemes. 1997. Requirements of the generic enterprise reference architecture and
methodology. Annual Reviews in Control 21- pp.125-136.
Bertolazzi, P., C. Krusich, et M. Missikoff. 2001. An Approach to the Definition of a Core Enterprise
Ontology: CEO. OES-SEO 2001, International Workshop on Open Enterprise Solutions:
Systems, Experiences, and Organizations- pp.14-15.
Besson, P. 1999. Les ERP à l’épreuve de l’organisation. Systèmes d’Information et Management 4, no. 4-
pp.21-51.
Blumenthal, Sherman C. 1969. Management Information Systems. Prentice-Hall, 219p.
Bond, B. et al. 2000. ERP is Dead. Long Live ERP II. Research Note, Gartner Group.
Boston Group. 2000. Getting Value from Enterprise Initiative. A survey of Executives. [Link]
Botta-Genoulaz, V., Pierre-Alain Millet, et Bernard Grabot. 2005. A survey on the recent research
literature on ERP systems. Computers in Industry 56, no. 6- pp.510-522.
Botta-Genoulaz, V., Pierre-Alain Millet, et Gilles Neubert. 2001. The rôle of enterprise modeling in ERP
implementation. IEPM’01, August 20-23, 2001, Proceedings ISBN 2-930294-07-8, Book I,
220-231..
Botta-Genoulaz, Valérie. 2005. Habilitation à diriger les recherches, principes et méthodes pour
l'intégration et l'optimisation du pilotage des systèmes de production et des chaînes logistiques.
Institut National des Sciences Appliquées de Lyon.
Botta-Genoulaz, Valerie, et Pierre-Alain Millet. 2006. An investigation into the use of ERP systems in the
service sector. International Journal of Production Economics 99, no. 1-2- pp.202-221.
Bouillot, Claude. 1999. Mise en place de Progiciels de Gestion Intégrée à l'occasion de fusions et cessions
d'entreprises dans un contexte international. Systèmes d'Information et Management 4, no. 4-
pp.3-20.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 292
 Annexes / Annexes

Boutin, Pascal. 2001. Définition d’une méthodologie de mise en œuvre et de

prototypage d’un progiciel de gestion d’entreprise (ERP). These de doctorat, Ecole Nationale
Superieure des Mines de Saint-Etienne.
Brehm, L., A. Heinzl, et M.L. Markus. 2001. Tailoring ERP systems: a spectrum of choices and their
implications. Dans System Sciences, 2001. Proceedings of the 34th Annual Hawaii International
Conference on, 9 pp.
Buckhout, Scott, Edward Frey, et Joseph Nemec. 1999. Making ERP Succeed, Turing Fair into Promise.
Booz-Allen & Hamilton, Issue 16,- pp.60-72.
Buffard, Pascal. 2006. Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques.
Dunod, Octobre 2006. 273p.
Bygstad, Bendik, Peter Axel Nielsen, et Bjørn Erik Munkvold . 2005. Four Integration Patterns: IS
Development as Stepwise Adaptation of Technology and Organisation. Dans Proceedings of the
Thirteenth European Conference on Information Systems, 242-253.
Calisir, Fethi, et Ferah Calisir. 2004. The relation of interface usability characteristics, perceived
usefulness, and perceived ease of use to end-user satisfaction with enterprise resource planning
(ERP) systems. Computers in Human Behavior 20, no. 4- pp.505-515.
Canonne, Robert, et Jean-Louis Damret. 2002. Résultats d’une enquête sur l’implantation et l’utilisation
des ERP en France. Revue Française de Gestion Industrielle 21, no. 4- pp.29-36.
Caruso, David. 1999. Driving ROI Through ERP Implementation.
Castano, Silvana, Valeria De Antonellis, et Michele Melchiori. 1999. A methodology and tool
environment for process analysis and reengineering. Data & Knowledge Engineering 31, no. 3
(Novembre)- pp. 253-278.
Chapron, Julie. 2006. L'urbanisme organisationnel : méthode et aide à la décision pour piloter l'évolution
du système d'information de l'entreprise. Ecole Nationale Superieure des Mines de Saint-Etienne.
Charalabidis, Y., H. Kühn, et A. Katzilieri. 2005. ACHIEVING INTEROPERABLE ENTERPRISE
APPLICATIONS THROUGH MODEL-DRIVEN INTEGRATION: THE ERP-CRM CASE.
Dans Proceedings of the 16th IFAC World Congress, Prague, Czech Republic.
Chardavoine, Agnès. 2002. " Au secours, l'ERP arrive dans mon entreprise!". L'Usine Nouvelle.
Chen, D., et F. Vernadat. 2001. Standardisation on enterprise modelling and integration: achievements,
ongoing works and future perspectives. Proceedings of IFAC 10th Symposium on Information
Control in Manufacturing,(Invited session), Vienna 20–22.
Choi, Beomjin, T. S. Raghu, et Ajay Vinze. 2004. Addressing a standards creation process: a focus on
ebXML. International Journal of Human-Computer Studies 61, no. 5- pp.627-648.
CIGREF. 2006. 2006 - Capital Immatériel - 7 jours pour comprendre. CIGREF Publications: octobre
2006.
CMMI, Architecture Team. 2007. Introduction to the Architecture of the CMMI Framework.
[Link]
Corniou, Jean-Pierre. 2002. Conclusion de la rencontre "Propos raisonnables sur les ERP". Revue
Française de Gestion Industrielle 21, no. 4- pp.117-118.
Coughlan, Jane, Mark Lycett, et Robert D. Macredie. 2005. Understanding the business-IT relationship.
International Journal of Information Management 25, no. 4 (Août)- pp. 303-319.
Cuenca, LI., M. Hawa, et A. Ortiz. 2001. Analysis of Architectural Issues in Enterprise Modelling: A
compared analysis of DEM (Dynamic Enterprise Modelling) of Baan and CIMOSA (CIM - Open
System Architecture). Dans , 10p. Utrecht, The Netherlands .

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 293
 Annexes / Annexes

Daft, Richard. 1978. A Dual-Core Model of Organizational Innovation. The Academy of Management
Journal 21, no. 2- pp.210, 193.
Daihani , Dadan Umar. 1994. Définition de propositions méthodologiques pour l'intégration des
principales fonctions de décision dans un système de production. Université d'Aix-Marseille 3,
[Link]
Darras, Franck. 2004. Proposition d’un cadre de référence pour la conception et
l’exploitation d’un progiciel de gestion intégré. INSTITUT NATIONAL POLYTECHNIQUE DE
TOULOUSE.
Davenport, T. H. 1996. Holistic Management of Megapackage Change: The Case of SAP. Proceedings of
the Second Americas Conference on Information Systems.
Davenport, Thomas H. 1998. Putting the enterprise into the enterprise system . Harvard University
Graduate School of Business Administration.
Davenport, Thomas H. 2000. The Future of Enterprise System-Enabled Organizations. Information
Systems Frontiers 2, no. 2- pp.163-180.
Dechow, Niels, et Jan Mouritsen. 2005. Enterprise resource planning systems, management control and
the quest for integration. Accounting, Organizations and Society 30, no. 7-8- pp. 691-733.
Deixonne, J. L. 2001. Piloter un projet ERP: transformer et dynamiser l'entreprise par un système
d'information intégré et orienté métier. Dunod.
Delen, Dursun, Nikunj P. Dalal, et Perakath C. Benjamin. 2005. Integrated modeling: the key to holistic
understanding of the enterprise . ACM Press.
Di Battista, G., P. Eades, R. Tamassia, et I. G. Tollis. 1994. Algorithms for drawing graphs: an annotated
bibliography. Google Scholar. /pub/papers/compgeo/[Link].Z and
/pub/papers/compgeo/[Link].Z.
DMG. 2007. Data Mining Group - Predictive Model Markup Language Specifications (PMML), ver. 3.2.
[Link]
Donnadieu, G. 1997. Manager avec le social : l'approche systémique appliquée à l'entreprise
. Liaisons. Rueil-Malmaison .423p.
Donnadieu,, Gérard, Daniel Durand, Danièle Neel, Emmanuel Nunez, et Lionel Saint-Paul. 2003. Qu'est-
ce que l'approche systémique ? [Link]
Donovan, R.M. . 2000. Why the Controversy over ROI from ERP? MidRange ERP, Janvier, MDNH, Inc.
Doumeingts, G. 1984. Methode GRAI: Methode de Conception des Systems en Productique. Higher
Doctoral Thesis, University of Bordeaux, Bordeaux.
Doumeingts, G., Y. Ducq, B. Vallespir, et S. Kleinhans. 2000. Production management and enterprise
modelling. Computers in Industry 42, no. 2-3- pp.245-263.
Dubarry, Pierre, et Virginie Bauvais. 1999. Retour d'expérience ERP. [Link].
Eades, P. 1984. A heuristic for graph drawing. Congressus Numerantium 42, no. 149160- pp. 194-202.
Eades, P., et Mao Ling Huang. 2000. Navigating Clustered Graphs Using Force-Directed Methods.
Journal of Graph Algorithms And Applications 4, no. 3- pp. 157-181.
Elbanna. 2007. Implementing an integrated system in a socially dis-integrated enterprise: A critical view
of ERP enabled integration. Information Technology & People 20, no. 2- pp. 121-139.
Eriksson, Hans-Erik, et Magnus Penker. 1997. UML Toolkit. Bk&CD-Rom. Wiley, Octobre 14.
Eriksson, Henrik. The semantic-document approach to combining documents and ontologies.
International Journal of Human-Computer Studies In Press, Corrected Proof.
Erschler, Jacques. 2003. Production et Logistique dans l'entreprise étendue: modèles et outils
collaboratifs. CNRS [Link] (Accédé Mai 21, 2007).

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 294
 Annexes / Annexes

Everaere, C. 1994. Intégration et flexibilité: une relation ambigu. Revue Française de Gestion, Juin-
Juillet-Août.
Evgeniou, Theodoros. 2002. Information Integration and Information Strategies for Adaptive Enterprises.
European Management Journal 20, no. 5 (Octobre)- pp. 486-494.
Falkenberg, E. D., W. Hesse, P. Lindgreen, et al. 1998. A Framework of Information Systems Concepts.
Ferre, Louis, et Bertrand Jouve. 2002. Partionnement d'une classe de graphes orientés Vertex partitioning
of a class of digraphs. Mathématiques et sciences humaines, no. 158.
[Link]
Fusarelli, Lance D, 2002. Tightly coupled policy in loosely coupled systems: institutional capacity and
organizational change. Journal of Educational Administration 40, no. 6- pp. 561-575.
Gaches, R., et M. Chaumont. 1999. Model-based analysis of the health, safety and environment domain in
the process industry. Computers in Industry 40, no. 2-3 (Novembre)- pp. 231-242.
Gallagher, Brian P. 2002. Interpreting Capability Maturity Model Integration (CMMI) forOperational
Organizations. SEI Technical Note. Carnegie Mellon University.
[Link]
Ganesan, Prasanna, Hector Garcia-Molina, et Jennifer Widom. 2003. Exploiting hierarchical domain
structure to compute similarity. ACM Trans. Inf. Syst 21, no. 1- pp. 64-93.
GARTNER. 2003. Glossary of Information Technology Acronym and Terms.
[Link] (Accédé Août 29, 2007).
Gattiker, Thomas F., et Dale L. Goodhue. 2004. Understanding the local-level costs and benefits of ERP
through organizational information processing theory. Information & Management 41, no. 4
(Mars)- pp. 431-443
Geffroy-Maronnat, Bénédicte, Redouane El Amrani, et Frantz Rowe. 2004. Intégration du système
d'information et transversalité. Comparaison des approches des PME et des grandes entreprises.
SCIENCES DE LA SOCIÉTÉ, no. 61 (Février)- pp. 71-89.
Giachetti, Ronald E. 2006. Understanding Interdependence in Enterprise Systems: A Model and
Measurement Formalism. Dans Business Process Management Workshops, 4103- pp.261-272.
Lecture Notes in Computer Science.
Giachetti, Ronald E., Paula Hernandez, Alba Nunez, et Duane P. Truex. 2005. A Research Framework for
Operationalizing Measures of Enterprise Integration. Dans Knowledge Sharing in the Integrated
Enterprise, 183- pp.237-247. IFIP International Federation for Information Processing.
Gilbert, Patrick. 2001. Systèmes de gestion intégrés et changement organisationnel. Revue de gestion des
ressources humaines 41- pp.21-31.
Gold-Bernstein, Beth, et William Ruh. 2004. Enterprise Integration: The Essential Guide to Integration
Solutions. Pap/Cdr. Addison-Wesley Professional, Juillet 16.
Grangel, Reyes, Ricardo Chalmeta, Stefan Schuster, et Iñaki Peña. 2006. Exchange of Business Process
Models Using the POP* Meta-model. Dans Business Process Management Workshops, 233-244.
Grimson, Jane, W. Grimson et Wilhelm Hasselbring. 2000. The SI challenge in health care. ACM Press.
Gruber, Thomas R. 1993. A translation approach to portable ontology specifications. Knowledge
Acquisition 5, no. 2- pp.199-220.
Gunasekaran, A., E.W.T. Ngai, et R.E. McGaughey. 2006. Information technology and systems
justification: A review for research and applications. European Journal of Operational Research
173, no. 3- pp.957-983.
Haan, Johan den. 2006. Modelling a business process in the right way will be key challenge - bpm,
modeling, orchestration, soa, web service - by Johan den Haan. Septembre 29.
[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 295
 Annexes / Annexes

Hanseth, Ole, et Kristin Braa. 1998. Technology as traitor: emergent SAP infrastructure in a global
organization. Dans Proceedings of the international conference on Information systems, 188-196.
Helsinki, Finland: Association for Information Systems.
Harmon, Paul, et Tom Davenport. 2007. Business Process Change . Dans Business Process Change, 1-25.
Burlington: Morgan Kaufmann.
Harriss, A., et C. Huneke. 1999. Nearly 20 Percent of Businesses Have Implemented ERP. BusinessWire,
Juin [Link]/webbox/bw.061199/[Link].
Helland, P. J., R. Limprecht, M. Al-Ghosein, et D. R. Reed. 2000. Multi-user, multiple tier distributed
application architecture with single-user access control of middle tier objects. US Patent
6,134,594.
Henderson, J., et N. Venkatramen. 1992. Strategic Alignment: A Model for Organisational
Transformation: In Transforming Organizations. In: T. Kochan and M. Unseem, Editors. Oxford
University Press, USA, Janvier 11.
Holland, C.R., et B. Light. 1999. A critical success factors model for ERP implementation. Software,
IEEE 16, no. 3- pp.30-36.
Hossain, Liaquat, et Rolf T. Wigand. 2004. ICT Enabled Virtual Collaboration through Trust. Journal of
Computer-Mediated Communication, Novembre 8, 10, Article 8.
Huin, S. F. 2004. Managing deployment of ERP systems in SMEs using multi-agents. International
Journal of Project Management 22, no. 6 (Août)- pp. 511-517.
Humphreys, P. K., M. K. Lai, et D. Sculli. 2001. An inter-organizational information system for supply
chain management. International Journal of Production Economics 70, no. 3. International
Journal of Production Economics- pp. 245-255.
Hunton, James E., Barbara Lippincott, et Jacqueline L. Reck. 2003. Enterprise resource planning systems:
comparing firm performance of adopters and nonadopters. International Journal of Accounting
Information Systems 4, no. 3- pp.165-184.
IBM RUP. 2003. IBM - Plug-Ins for Rational Unified Process.
[Link]
ISO 10303. 2006. ISO - International Organization for Standardization. Systèmes d'automatisation
industrielle et intégration -- Représentation et échange de données de produits.
[Link]
(Accédé Septembre 15, 2007).
ISO 14528. 2003. ISO 14258:1998: Concepts et règles pour modèles d'entreprise.
[Link]
CSNUMBER=24020&COMMID=&scopelist= (Accédé Août 29, 2007).
ISO 15704. 2005. ISO 15704:2000. [Link]
CSNUMBER=28777&ICS1=25&ICS2=40&ICS3=1 (Accédé Août 29, 2007).
ISO 19440. 2006. DRAFT INTERNATIONAL STANDARD ISO/DIS 19440. Entreprise intégrée —
Constructions pour la modélisation d'entreprise. [Link]
ISO 9001. 2000. ISO 9001:2000 - Quality management systems -- Requirements.
[Link]
ITtoolbox. 2005. ITtoolbox Stocks - Tech Indices. [Link] (Accédé
Septembre 5, 2007).
Jacobson, Ivar, Grady Booch, et James Rumbaugh. 1999. The Unified Software Development Process.
Addison-Wesley Professional, Février 4.
Jain, A. K., M. N. Murty, et P. J. Flynn. 1999. Data clustering: a review. ACM Comput. Surv 31, no. 3- pp.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 296
 Annexes / Annexes

264-323.
Katzy, B. R., et G. Sung. 2003. State-of-the-Art of Virtual Organization Modeling. Building the
Knowledge Economy: Issues, Applications, Case Studies.
Kim, Hee-Woong. 2004. A Process Model for Successful CRM System Development.
[Link]
resourcePath=/dl/mags/so/&toc=comp/mags/so/2004/04/[Link]&DOI=10.1109/MS.2004.1 .
Klaus, Rosemann, et Gable. 2000. What is ERP? Information Systems Frontiers 2, no. 2- pp.141-162.
Klir, George J. 1969. An approach to general systems theory. 1 vols. New York ; Cincinnati ; Toronto :
Van Nostrand Reinhold, [Cop. 1969].
Klostermeyer, A., et E. Klemm. 2003. PABADIS - an agent based flexible manufacturing concept. Dans
Industrial Informatics, 2003. INDIN 2003. Proceedings. IEEE International Conference on,
286-293.
Koch, Christoph, Derek Slater , et E. Baatz. 2000. The ABCs of ERP Compiled from reports .
[Link] (Accédé Janvier 8, 2000).
Kosanke, K., et J. G. Nell. 1999. Standardisation in ISO for enterprise engineering and integration.
Computers in Industry 40, no. 2-3- pp.311-319.
Kosanke, K., et M. Zelm. 1999. CIMOSA modelling processes. Computers in Industry 40, no. 2-3-
pp.141-153.
Kosanke, K., F. Vernadat, et M. Zelm. 1999. CIMOSA: enterprise engineering and integration.
Computers in Industry 40, no. 2-3 (Novembre)- pp. 83-97.
Kosanke, Kurt. 1995. CIMOSA -- Overview and status. Computers in Industry 27, no. 2- pp.101-109.
Kovacs, George L., et Paolo Paganelli. 2003. A planning and management infrastructure for large,
complex, distributed projects--beyond ERP and SCM. Computers in Industry 51, no. 2 (Juin)- pp.
165-183.
Kræmmergaard, et Rose. 2002. Managerial Competences for ERP Journeys. Information Systems
Frontiers 4, no. 2- pp.199-211.
Krumbholz, Marina, et Neil Maiden. 2001. The implementation of enterprise resource planning packages
in different organisational and national cultures. Information Systems 26, no. 3- pp.185-204.
Kumar, Vinod, Bharat Maheshwari, et Uma Kumar. 2002. ERP systems implementation: best practices in
Canadian government organizations. Government Information Quarterly 19, no. 2- pp.147-172.
Kumar, Vinod, Bharat Maheshwari, et Uma Kumar. 2003. An investigation of critical management issues
in ERP implementation: emperical evidence from Canadian organizations. Technovation 23, no.
10- pp.793-807.
LABRUYERE, E., P. SEBBEN, et M. VERSINI. 2002. L’ERP a-t-il tenu ses promesses ?
Lagoze, Carl, et Jane Hunter. 2001. The ABC Ontology and Model . National Institute of Informatics,
Tokyo, Japan.
Lam, Wing, et Venky Shankararaman . 2004. An Enterprise Integration Methodology. IT Professional,
Mars.
Lambert, M. Douglas, et C. Martha Cooper. 2000. Issues in Supply Chain Management. Industrial
Marketing Management 29, no. 1 (Janvier)- pp. 65-83. doi:10.1016/S0019-8501(99)00113-3.
Laudon, Kenneth C., et Jane Price Laudon. 2000. Essentials of Management Information Systems. 5 éd.
Prentice-Hall.
Lawrence, Paul R., et Jay W. Lorsch. 1969. Developing Organizations: Diagnosis and Action. Addison-
Wesley Publishing Company, Reading, Mass. 01867.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 297
 Annexes / Annexes

Le Moigne . 1986. « Vers un système d’information organisationnel?». Revue Française de Gestion 60-
pp. 20-31.
Le Moigne, J. L. 1977. La théorie du système général: théorie de la modélisation. Presses Universitaires
de France.
Lengnick-Hall, Cynthia A., Mark L. Lengnick-Hall, et Sue Abdinnour-Helm. 2004. The role of social and
intellectual capital in achieving competitive advantage through enterprise resource planning
(ERP) systems. Journal of Engineering and Technology Management 21, no. 4 (Décembre)- pp.
307-330.
Lequeux. 1999. Manager avec les ERP. Editions d'Organisation.
Levi, Meir H., et Marios P. Klapsis. 1999. FirstSTEP process modeler -- a CIMOSA-compliant modeling
tool. Computers in Industry 40, no. 2-3 (Novembre)- pp. 267-277.
Light, Ben, Christopher P. Holland, et Karl Wills. 2001. ERP and best of breed: a comparative analysis.
Business Process Management Journal 7, no. 3- pp.216-224.
Lombard, Didier. 2002. ANALYSE DES MODIFICATIONS DE PERFORMANCES INDUITES PAR
L'ERP. Revue Française de Gestion Industrielle 21, no. 4- pp.85-92.
Loos, P. 2000. Advanced Information Technology Application in ERP Systems. Proceedings of 2000
Americas Conference on Information Systems, AMCIS 635-9.
Lopes, P.F. 1992. CIM II: The Integrated Manufacturing Enterprise. Industrial Engineering 24, no. 11-
pp.43-45.
Luftman, Jerry N. , Paul R. Lewis, et Scott H. Oldach. 1993. Transforming the enterprise: the alignment
of business and information strategies - Technical. Mars 1.
[Link]
Lynch, R. L., et K. F. Cross. 1995. Measure Up!: Yardsticks for Continuous Improvement. Blackwell
Publishing.
Mabert, Vincent A., Ashok Soni, et M. A. Venkataramanan. 2000. Enterprise Resource Planning Survey of
US Manufacturing Firms. Production and Inventory Management 41- pp.52-58.
Mabert, Vincent A., Ashok Soni, et M. A. Venkataramanan. 2001. Enterprise resource planning: common
myths versus evolving reality. Business Horizons 44, no. 3- pp.69-76.
Mabert, Vincent A., Ashok Soni, et M. A. Venkataramanan. 2003. Enterprise resource planning:
Managing the implementation process. European Journal of Operational Research 146, no. 2-
pp.302-314.
Malone, T. W., et K. Crowston. 1994. The interdisciplinary study of coordination. ACM Computing
Surveys (CSUR) 26, no. 1- pp. 87-119.
Malone, T. W., K. Crowston, J. Lee, et al. 1999. Tools for Inventing Organizations: Toward a Handbook
of Organizational Processes. Management Science 45, no. 3- pp. 425.
Malone, Thomas W., et Kevin Crowston. 1991. Toward an interdisciplinary theory of coordination. http://
[Link]/1721.1/2356.
Malone, Thomas W., et Kevin Crowston. 1991. Toward an interdisciplinary theory of coordination. Sloan
Working Papers. Center for Coordination Science, Sloan School of Management, Massachusetts
Institute of Technology. [Link]
Markus, M. L., et C. Tanis. 2000. The Enterprise Systems Experience-From Adoption to Success. Dans
Framing the Domains of IT Research: Glimpsing the Future Through the Past, 173–-207 (Chapter
10), R.W. Smud, M.F. Price (Eds).
Martin, R., et E. Robertson. 2002. Framework : comparison and correspondence for three archetypes.
[Link]

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 298
 Annexes / Annexes

McKeen, James D., et Heather A. Smith. 2003. Making IT Happen : Critical Issues in IT Management.
1er éd. Wiley, Mars 4.
Meillassoux, André. 2002. Pré-requis juridiques aux ERP. Revue Française de Gestion Industrielle 21,
no. 4- pp. 77-84.
Miller, Jonathan. 1993. Measuring and aligning information systems with the organization : A case study.
Information & Management 25, no. 4 (Octobre)- pp. 217-228.
Millet, P.A., et Valerie Botta-Genoulaz. 2002. ERP implementation: New topics for research. Dans
Conference on Production System Design, Supply Chain Management and Logistics, 253-260,
Miedzyzdroje (Poland).
Millet, Pierre-Alain, et Valérie Botta-Genoulaz 2007. Contribution des briques applicatives aux processus
Supply Chain. 7e Congrès international de génie industriel (GI 2007). Trois-Rivières, Québec
(CANADA)..
Millet, Pierre-Alain, et Valérie Botta-Genoulaz. 2006. Un référentiel pour l'alignement des systèmes
d'information aux processus logistiques . 6e Conférence Francophone de MOdélisation et
SIMulation - MOSIM’06. 11p, Rabat (Maroc), 3 Avril.
Millet, Pierre-Alain, Gilles NEUBERT, et Valérie Botta-Genoulaz. 2005. Une approche outillée de
l'intégration.6e Congrès international de génie industriel – 7-10 juin 2005 – Besançon (France)
Millet, Pierre-Alain. 2005. A reverse engineering approach of integration with ERP. Conference IFIP 5.7
Advanced in Production Management Systems (APMS), 15p. Rockville (MD, USA), 2005,
Septembre 18.
Møller, Charles. 2005. ERP II: a conceptual framework for next-generation enterprise systems? Journal
of Enterprise Information Management 18, no. 4- pp.483-497.
Morley, Chantal, Jean Hugues, Bernard Leblanc, et Olivier Hugues. 2005. Processus Métiers et systèmes
d'information : Evaluation, modélisation, mise en oeuvre. Dunod, Mars 24.
Mourlon, Sophie, et Laurent Neyer. 2002. « tout ce que nous avons voulu savoir sur les ERP ».
Murphy, K. E., et S. J. Simon. 2002. Intangible benefits valuation in ERP projects. Information Systems
Journal no. 12- pp.301–320.
Mutafelija, B., et H. Stromberg. 2003. Systematic Process Improvement Using ISO 9001: 2000 and
CMMI. Artech House.
Mutafelija, Boris, et Harvey Stromberf. 2003. Mappings of ISO 9001:2000 and CMMI Version 1.1.
Juillet. [Link]
Naumenko A., 1. Wegmann. 2003. Two approaches in system modeling and their illustrations with MDA
and RM-ODP. ICEIS’03, 5th International Conference on Enterprise Information Systems.
pp388-402.
Newman, M.E.J. 2004. Detecting community structure in networks. The European Physical Journal B -
Condensed Matter and Complex Systems 38, no. 2 (Mars 25)- pp. 321-330.
doi:10.1140/epjb/e2004-00124-y.
Nicolaou, Andreas I. 2004. Quality of postimplementation review for enterprise resource planning
systems. International Journal of Accounting Information Systems 5, no. 1- pp.25-49.
Niessink, Franck, et Hans van Vliet. 1998. Towards mature IT services. Software Process: Improvement
and Practice 4, no. 2- pp. 55-71.
Niessink, Franck, et Hans van Vliet. 2000. Software maintenance from a service perspective. Journal of
Software Maintenance: Research and Practice 12, no. 2- pp. 103-120.
NIST, F. 1993. Publication 183: Integration Definition of Function Modeling (IDEF0). National Institute
of Standards and Technology 128.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 299
 Annexes / Annexes

O'Donnell, Ed, et Julie Smith David. 2000. How information systems influence user decisions: a research
framework and literature review. International Journal of Accounting Information Systems 1, no.
3- pp.178-203.
Oberndorf, Patricia A. 2000. An activity framework for COTS-based systems. Carnegie Mellon University,
Software Engineering Institute.
Odette. 2004. VMI Recommendations. [Link] (Accédé Septembre
15, 2007).
Olhager, Jan, et Erik Selldin. 2003. Enterprise resource planning survey of Swedish manufacturing firms.
European Journal of Operational Research 146, no. 2- pp.365-373.
Orton, J. Douglas, et Karl E. Weick. 1990. Loosely Coupled Systems: A Reconceptualization . The
Academy of Management Review 15, no. 2 (Avril)- pp. 203-223. doi:10.2307/258154.
Osterwalder, A. 2004. The Business Model Ontology: A Proposition in a Design Science Approach.
Docteur en Informatique de Gestion, Ecole des Hautes Etudes Commerciales de l'université de
Lausanne.
Paulus, P. 2002. ERP III : les applications secondaires prennent-elles de l’importance ? Technique et
Management- pp.106,109.
Peaucelle, Jean-Louis. 1999. Systèmes d'information : Le point de vue des gestionnaires. Economica.
Pegah, Kris T., Mahmoud Pegah, et Terry M. Dillow. 2003. Higher education ERP: a framework to
reduce the pain . San Antonio, TX, USA : ACM Press.
Pépiot, Grégoire, Naoufel Cheikhrouhou, Jean-Marie Furbringer, et Rémy Glardon. 2007. UECML:
Unified Enterprise Competence Modelling Language . Elsevier Science Publishers B. V.
Péraire, Cécile, et Russel Pannone. 2005. The IBM Rational Unified Process for COTS-based projects:
An introduction. [Link]
pannone/[Link].
Pinelle, et Gutwin. 2005. A Groupware Design Framework for Loosely Coupled Workgroups. ECSCW
2005. [Link]
Plaisant, Catherine, et Ben Shneiderman. 1995. Organization overviews and role management: inspiration
for future desktop environments. Dans Conference companion on Human factors in computing
systems, 419-420, Denver, Colorado, United States: ACM.
Poli, Roberto . 1996. Ontology for knowledge organization. Dans Knowledge Organization and Change,
313-319., Frankfort: Ergon.
POSC. 2005. POSC E&P Catalogue Standards.
[Link] (Accédé Septembre 16, 2007).
Poston, Robin, et Severin Grabski. 2001. Financial impacts of enterprise resource planning
implementations. International Journal of Accounting Information Systems 2, no. 4- pp.271-294.
Prasad. 1999. System Integration Techniques of Sharing and Collaboration among Work-groups,
Computers and Processes. Journal of Systems Integration 9, no. 2- pp. 115-139.
doi:10.1023/A:1008458626272.
Prothman, B. 2000. Meta data: Managing Needles in the proverbial haystacks. Potentials, IEEE 19, no. 1-
pp.20-23.
Ravasi, Davide, et Gianmario Verona. 2001. Organising the process of knowledge integration: the
benefits of structural ambiguity. Scandinavian Journal of Management 17, no. 1 (Mars)- pp.
41-66.
Reix, Robert. 2002. Systèmes d'information et Management des organisastions. 4 éd. Vuibert, Juillet 31.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 300
 Annexes / Annexes

Reyneri, Carla. 1999. Operational building blocks for business process modelling. Computers in Industry
40, no. 2-3- pp.115-123.
RosettaNet. 2002. RosettaNet Business Dictionary.
[Link]
(Accédé Septembre 15, 2007).
Rosnay, Joël de. 1977. Le macroscope. Seuil, Février 1.
Ross, et Vitale. 2000. The ERP Revolution: Surviving vs. Thriving. Information Systems Frontiers 2, no.
2- pp.233-241.
Rowe, Frantz. 1999. Cohérence, intégration informationnelle et changement : esquisse d'un programme
de recherche à partir des Progiciels Intégrés de Gestion. Systèmes d’Information et Management
4, no. 4- pp. 3-20.
Rowell, M. 2002. OAGIS: a canonical business language. XML Journal 3, no. 9.
Ruffier, J. 1998. Efficience productive : Comment marchent les usines.
[Link] CNRS Editions, Septembre 1.
Saint-leger, Guy, G. Neubert, et L. Pichot. 2002. Projet ERP: Incidence des spécificités des entreprises sur
les facteurs clés de succès. 7éme colloque de l’AIM 2002.
Sarkis, J., et A. Gunasekaran. 2003. Enterprise resource planning--modeling and analysis. European
Journal of Operational Research 146, no. 2- pp.229-232.
Scheer, August-Wilhelm, et Frank Habermann. 2000. Enterprise resource planning: making ERP a
success . ACM Press.
Scheer, August-Wilhelm. 1994a. ARIS Toolset: A software product is born. Information Systems 19, no.
8- pp.607-624.
Scheer, August-Wilhelm. 1994b. CIM Towards the Factory of the Future. 3 éd. Springer-Verlag Telos.
Scheer. 2002. ARIS : Des processus de gestion au système intégré d'applications. Springer
Editions,France, Février 1.
Schlenoff Craig. 1997. An Approach to Analyzing Existing Process Representations. National Institute
of Standards and Technology . [Link]
Schwinn, A., et R. Winter. 2005. Success Factors and Performance Indicators for Enterprise Application
Integration. Dans Proceedings of the Eleventh Americas Conference on Information Systems
(AMCIS2005), 2179-2189. Omaha, NE, USA,, Août.
Scott, Kendall. 2001. The Unified Process Explained. Addison-Wesley.
Scott, S. V., et E. L. Wagner. 2003. Networks, negotiations, and new times: the implementation of
enterprise resource planning into an academic administration. Information and Organization 13,
no. 4- pp.285-313.
Seggie, Steven H., Daekwan Kim, et [Link] Cavusgil. 2006. Do supply chain IT alignment and supply
chain interfirm system integration impact upon brand equity and firm performance? Journal of
Business Research 59, no. 8 (Août)- pp. 887-895.
Seng, Jia-Lang, et Woodstock Lin. 2007. An ontology-assisted analysis in aligning business process with
e-commerce standards. Industrial Management & Data Systems 107, no. 3- pp.415-437.
Shepherd, Jim, et David Boulanger. 2000. Don’t Let Your SAP Investment Atrophy—You Can’t Afford
To Start Over.
Simatupang, T. M, A. C Wright, et R Sridharan. 2002. The knowledge of coordination for supply chain
integration. Business Process Management Journal 8, no. 3- pp. 289-308.
Simatupang, T. M, A. C Wright, et R Sridharan. 2002. The knowledge of coordination for supply chain
integration. Business Process Management Journal 8, no. 3- pp. 289-308.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 301
 Annexes / Annexes

Simon, Herbert Alexander. 1996. The Sciences of the Artificial (3rd ed.). 3 éd. MIT Press.
Smets-Solanes, J.-P., et R. Atem de Carvalho. 2003. ERP5: a next-generation, open-source ERP
architecture. IT Professional 5, no. 4- pp. 38- 44.
Soffer, Pnina, Boaz Golany, et Dov Dori. 2003. ERP modeling: a comprehensive approach. Information
Systems 28, no. 6- pp.673-690.
Somers, Toni M., et Klara G. Nelson. 2004. A taxonomy of players and activities across the ERP project
life cycle. Information & Management 41, no. 3- pp.257-278.
Spender J. C, et Grevesen W. 1999. The multinational enterprise as a loosely coupled system: the global
integration - local responsiveness dilemma. Managerial Finance 25, no. 2- pp. 6-8.
Spender, J. C, et P. H. Grinyer. 1995. Organizational Renewal: Top Management's Role in a Loosely
Coupled System. Human Relations 48, no. 8 (Janvier 8)- pp. 909-926.
Srinivasan, Mukundan, et Young B. Moon. 1999. A comprehensive clustering algorithm for strategic
analysis of supply chain networks. Computers & Industrial Engineering 36, no. 3 (Juillet)- pp.
615-633. doi:10.1016/S0360-8352(99)00155-2 .
Stedman , Craig . 2000. ERP woes cut Grainger profits. ERP woes cut Grainger profits.
[Link] (Accédé Mai 21, 2007).
Stephens, Scott. 2001. Supply Chain Operations Reference Model Version 5.0: A New Tool to Improve
Supply Chain Efficiency and Achieve Best Practice. Information Systems Frontiers 3, no. 4-
pp.471-476.
Symeonidis, Andreas L., Dionisis D. Kehagias, et Pericles A. Mitkas. 2003. Intelligent policy
recommendations on enterprise resource planning by the use of agent technology and data mining
techniques. Expert Systems with Applications 25, no. 4 (Novembre)- pp. 589-602.
TARDIEU, H., A. ROCHFELD, et R. COLLETTI. 1983. La méthode Merise, Tome 1. Principes et
outils, Les Editions d’Organisation.
Teo, Thompson S. H., et James S. K. Ang. 1999. Critical success factors in the alignment of IS plans with
business plans. International Journal of Information Management 19, no. 2 (Avril)- pp. 173-185.
Terrasse, Marie-No\&\#246;lle, Marinette Savonnet, Eric Leclercq, Thierry Grison, et George Becker.
2006. Do we need metamodels AND ontologies for engineering platforms? . Shanghai, China :
ACM Press.
Tham, K.D., M.S. Fox, et M. Gruninger. 1994. A cost ontology for enterprise modelling. Dans Enabling
Technologies: Infrastructure for Collaborative Enterprises, 1994. Proceedings., Third Workshop
on, 197-210 [Link] (Accédé Octobre 5, 2007).
Themistocleous, Marinos, Zahir Irani, et Peter E. D. Love. 2004. Evaluating the integration of supply
chain information systems: A case study. European Journal of Operational Research 159, no. 2
(Décembre 1)- pp. 393-405.
Thompson, J. D. 1967. Organizations in Action. Mcgraw-Hill College.
Tomas, Jean-Louis, et Serge Miranda. 1999. ERP et Progiciels intégrés : la mutation des systèmes
d'information. Dunod.
Trunick, Perry A. 1999. ERP: PROMISE OR PIPE DREAM? Transportation and Distribution, Janvier 1.
Uschold, M., et M. Gruninger. 1996. Ontologies: principles, methods and applications. Knowledge
Engineering Review 11, no. 2- pp.93-136.
USCHOLD, M., M. KING, S. MORALEE, et Y. ZORGIOS. 1998. The Enterprise Ontology. The
Knowledge Engineering Review 13, no. 01- pp.31-89.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 302
 Annexes / Annexes

Van der Aalst, W. M. P. 1999. Formalization and verification of event-driven process chains. Information
and Software Technology 41, no. 10- pp.639-650.
Van der Aalst, W. M. P., et A. J. M. M. Weijters. 2004. Process mining: a research agenda. Computers in
Industry 53, no. 3- pp.231-244.
Van der Aalst, W.M.P. 2005. Process mining in CSCW systems. Dans Computer Supported Cooperative
Work in Design, 2005. Proceedings of the Ninth International Conference on, Vol. 1 of, 1- 8 Vol.
1
Van Es, R. M., et H. A. Post. 1996. Dynamic Enterprise Modeling.
Vernadat, F.B. 2007. Interoperable enterprise systems: Principles, concepts, and methods. Annual Reviews
in Control 31, no. 1- pp. 137-145.
Verwijmeren, Martin. 2004. Software component architecture in supply chain management. Computers in
Industry 53, no. 2- pp.165-178.
Vinod, H. D. 1969. Integer Programming and the Theory of Grouping. Journal of the American Statistical
Association 64, no. 326- pp. 506-519.
Wallnau, K. C. 1999. On Software Components and Commercial (" COTS") Software. International
Workshop on Component-Based Software Engineering.
Wang, Zhang, Zhang, et Chen. 2007. Identifying Modules in Complex Networks by a Graph-Theoretical
Method and Its Application in Protein Interaction Networks. Dans Advanced Intelligent
Computing Theories and Applications. With Aspects of Artificial Intelligence, 1090-1101. D.-S.
Huang, L. Heutte, and M. Loog (Eds.):
Watson, Edward E., et Helmut Schneider. 1999. Using ERP systems in education . Association for
Information Systems.
Watson, Edward E., et Helmut Schneider. 1999. Using ERP systems in education . Vol. 1. Association for
Information Systems.
Watson, Richard T., Gigi G. Kelly, Robert D. Galliers, et James C. Brancheau. 1997. Key issues in
information systems management: an international perspective . Vol. 13. M. E. Sharpe, Inc.
Wei, Chun-Chin, Chen-Fu Chien, et Mao-Jiun J. Wang. 2005. An AHP-based approach to ERP system
selection. International Journal of Production Economics 96, no. 1- pp.47-62.
Werner, T., et C. Vetter. 2003. From order to production: a distinct view on integration of plant floor and
business systems. Dans Emerging Technologies and Factory Automation, 2003. Proceedings.
ETFA '03. IEEE Conference, 1- pp.276-281 vol.1.
Westervelt,, Robert. 2005. SAP trumps Oracle in march to SOA.
[Link] (Accédé
Août 29, 2007).
Weston Jr., F. D. Ted. 2003. ERP II: The extended enterprise system. Business Horizons 46, no. 6-
pp.49-55.
Winter, R., et E. Robert. 2003. An Architecture Model for Supporting Application Integration Decisions.
Proceedings of the 11th European Conference on Information Systems.
Winter, R., et E. Robert. 2003. An Architecture Model for Supporting Application Integration Decisions.
Proceedings of the 11th European Conference on Information Systems.
Wohed, Andersson, et Panetto. 2006. Facilitating Interoperability: A Cross-Analysis of the Language
UEML and the Standard ISO/DIS 19440. Dans Business Process Management Workshops, Vol.
3812/2006 of Lecture Notes in Computer Science, 257-268

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 303
 Annexes / Annexes

Worley, J. Hermosillo, K.A. Chatha, R.H. Weston, O. Aguirre, et B. Grabot. 2005. Implementation and
optimisation of ERP systems: A better integration of processes, roles, knowledge and user
competencies. Computers in Industry 56, no. 6- pp.620-638.
Wortmann, J. C., H. M.H. Hegge, et S. Rolefes. 2000. Embedding enterprise software in extended
enterprise models. Comput. Ind. 42, no. 2-3- pp. 231-243.
Wortmann, JC. 2001. Understanding enterprise modelling from product modelling. Production Planning
& Control 12, no. 3- pp.234-244.
Wybo, Michael D., et Dale L. Goodhue. 1995. Using interdependence as a predictor of data standards.
Theoretical and measurement issues. Information & Management 29, no. 6 (Décembre)- pp.
317-329.
Wylie, L. 1990. ERP: A vision of the next-generation MRP II. Computer Integrated Manufacturing,
Gartner Group 1–2.
Yang, Luo, et Li. 2006. A Novel Visual Clustering Algorithm for Finding Community in Complex
Network. Dans Advanced Data Mining and Applications, 396-403. X. Li, O.R. Zaiane, and Z. Li
(Eds.)
Yen, HsiuJu Rebecca, et Chwen Sheu. 2004. Aligning ERP implementation with competitive priorities of
manufacturing firms: An exploratory study. International Journal of Production Economics 92,
no. 3- pp.207-220.
Yu, E., et J. Mylopoulos. 1997. Modelling Organizational Issues for Enterprise Integration. Dans
Proceedings of International Conference on Enterprise Integration and Modelling Technology,
Turin, 28:30.
Yusuf, Yahaya, A. Gunasekaran, et Mark S. Abthorpe. 2004. Enterprise information systems project
implementation: A case study of ERP in Rolls-Royce. International Journal of Production
Economics 87, no. 3- pp.251-266.
Zachman, Johen A. 1987. A framework for Information Systems Architecture. IBM Systems Journal 26,
no. 3. [Link]
Zelm, Martin, Francois B. Vernadat, et Kurt Kosanke. 1995. The CIMOSA business modelling process.
Computers in Industry 27, no. 2- pp.123-142.
Zhang, Zhe, Matthew K.O. Lee, Pei Huang, Liang Zhang, et Xiaoyuan Huang. 2005. A framework of
ERP systems implementation success in China: An empirical study. International Journal of
Production Economics 98, no. 1- pp.56-80.

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 304
 Annexes / Annexes

Annexe 7 Listes des figures

Figure 1.1: Adoption of the ERP concept in IS academe ....................................................21
Figure 2.1: les différents "systèmes" ERP dans le cycle de vie d'un projet.........................35
Figure 2.2: Future application of enterprise system (Davenport 2000)...............................37
Figure 2.3: Approche traditionnelle/Approche progicielle...................................................43
Figure 2.4: Comparaison des méthodologies ERP (Tchokogue et al, 2004)........................43
Figure 2.5: Enterprise System Experience Cycle (Markus et Tanis 2000)...........................45
Figure 2.6: Classification des normes par domaine (Chen et Vernadat, 2001)....................65
Figure 2.7: Standard de l'ingénierie d'entreprise (UEML)...................................................66
Figure 2.8: Le modèle des construits du projet de norme ISO 19440..................................67
Figure 2.9: Modélisation d'entreprise et application informatique (UEML).......................69
Figure 2.10: Les modèles d'un projet ERP (Krumbholz et Maiden 2001) ..........................71
Figure 2.11: Un cadre de référence (Darras 2004)...............................................................72
Figure 2.12: Cadre de positionnement des techniques de modélisation ..............................75
Figure 2.13: La structure d'un processus SCOR..................................................................84
Figure 2.14: Structure du système d'information (Morley)..................................................91
Figure 2.15: Ingénierie système et système d'information...................................................92
Figure 2.16: Le cadre de référence d'une architecture d'entreprise selon Zachman.............93
Figure 2.17: Démarche de projet USDP...............................................................................95
Figure 2.18: Cadre proposé par le MIT en 1990..................................................................97
Figure 2.19: Démarche d'alignement itérative (Soffer 2003)...............................................99
Figure 2.20: Matrice de maturité outil/processus...............................................................102
Figure 2.21: Clusterisation comparée d'architectures (Winter, 2003)...............................113
Figure 2.22: Une taxonomie des approches de clustering (Jain, 1999)..............................114
Figure 2.23: Cartes de Cluster (Chapron, 2006).................................................................116
Figure 3.1: L'ERP dans les différentes phases de modélisation 19439..............................129
Figure 3.2: Un cadre d'étude de l'intégration......................................................................130
Figure 3.3: les construits du méta-modèle SCOR (Millet et Botta 2006)..........................137
Figure 3.4: Méta-modèle des objets d'un ERP...................................................................140
Figure 3.5. Le méta-modèle d'étude de l'intégration..........................................................143
Figure 3.6: Classification des dépendances de processus de Chapron et 19440................146
Figure 3.7. Hiérarchisation du modèle d'intégration..........................................................147
Figure 3.8: Dépendances identifiées et potentielles du méta-modèle................................148
Figure 3.9. Dépendances pour l'alignement du S.I.............................................................150
Figure 3.10. les chaînes de dépendances entre Data et Organizational Unit......................153
Figure 3.11: Dépendances Indirectes.................................................................................163
Figure 3.12 similarité et dissimilarité de graphes d'intégration ........................................164
Figure 3.13 matrice des distances selon la longueur d'intégration.....................................165
Figure 3.14. partitions de processus...................................................................................166

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 305
 Annexes / Annexes

Figure 3.15 voisinages successifs de l'objet A1 dans le graphe E15..................................170

Figure 3.16: Classes d'information échangées dans le modèle SCOR...............................178
Figure 3.17: Briques applicatives.......................................................................................181
Figure [Link] de Lambert : croisement processus / fonctions..................................189
Figure 3.19. Positionnement des ERP dans la matrice de Lambert....................................190
Figure 3.20. positionnement des briques SCM dans la matrice de Lambert......................191
Figure 3.21. cadre d'ingénierie d'entreprise dirigée par les modèles..................................194
Figure 3.22. cadre 19439 et projets de type BPR...............................................................197
Figure 3.23. le cadre 19439 et les projets de type ERP « IT »...........................................198
Figure 3.24. le cadre 19439 et les projets de type ERP « BP »..........................................199
Figure 3.25 Alignement entre modèles dans le cadre d'intégration....................................203
Figure 3.26 le cadre de modélisation dirigé par l'intégration.............................................206
Figure 3.27. graphe d'intégration du cas d'entreprise E104 ...............................................209
Figure 3.28. graphe d'intégration du cas E104 avec algorithme de force..........................209
Figure 3.29 modèle partiel et voisinages par point de vue de l'objet EP............................213
Figure 3.30 graphe interclasses après partitionnement 8-means........................................215
Figure 3.31 Classes C6,C7 du partitionnement K8 du graphe E104..................................216
Figure 3.32: dendogramme classification hiérarchique cas BAAN-WH-BF.....................223

Annexe 8 Listes des Tableaux

Tableau 2.1: Taux de pénétration ERP par secteur (Harriss et Huneke 1999).....................29
Tableau 2.2. Satisfaction Utilisateur par Module (Canonne et Damret 2002).....................30
Tableau 2.3: Facteurs de différenciation / Budgets de projet ..............................................41
Tableau 2.4 Innovation process stage models .....................................................................45
Tableau 2.5 Aspects Critiques de projet et d'après-projet (Nicolaou 2004).........................48
Tableau 2.6.: Personnalisation et Budget de projet ERP. (Mabert et al 2001).....................50
Tableau 2.7.: Utilisation potentielle des modèles de processus..........................................64
Tableau 2.8 MIT Business Model Architecture....................................................................82
Tableau 2.9 : Les deux dimensions de la coordination (Simatupang et al 2002)..............108
Tableau 2.10: Couplage et matrice intégration/réactivité ..................................................111
Tableau 3.1.: Comparaison des cadres ISO 19439 et Zachman+USDP.............................126
Tableau 3.2: Correspondance 19440 / SCOR.....................................................................138
Tableau 3.3: Correspondance modèle ERP et 19440.........................................................141
Tableau 3.4: Relations entre construits 19440....................................................................145
Tableau 3.5: Matrice d'adjacence du graphe de dépendances............................................154
Tableau 3.6.: caractérisation des dépendances par la maturité...........................................161
Tableau 3.7: répartition des distances selon la longueur d'intégration...............................165
Tableau 3.8: Classification ascendante hiérarchique..........................................................167

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 306
 Annexes / Annexes

Tableau 3.9: dissimilarité de longueur d'intégration 2 pour le graphe E15........................167

Tableau 3.10: matrice des couplages du graphe E15..........................................................169
Tableau 3.11 Informations échangées................................................................................174
Tableau 3.12: Classes d'information par processus SCOR de niveau 1.............................178
Tableau 3.13: Liste des blocs de construction SAP A1......................................................185
Tableau 3.14: Briques applicatives référencées par processus SCOR...............................187
Tableau 3.15: Matrice de synthèse par processus SCOR de niveau 1................................187
Tableau 3.16: Typologie d'alignement de modèle dans la démarche.................................202
Tableau 3.17: liste des objets organisationnels du modèle E104.......................................207
Tableau 3.18: Liste des objets de la vue fonctionnelle du modèle E104............................208
Tableau 3.19: liste des objets informationnels et ressource du cas E104...........................208
Tableau 3.20: temps de construction des graphes d'intégration (cas E104).......................210
Tableau 3.21: Couplages répartis par dizaine selon la longueur d'intégration...................211
Tableau 3.22: tableau des couplages dans le graphe E104 pour l'objet EP........................212
Tableau 3.23: Dissimilarité du graphe E104 selon la longueur d'intégration.....................213
Tableau 3.24: Comparaison méthode d'agrégation en CAH..............................................214
Tableau 3.25: Comparaison partitionnement selon nombre de groupes............................214
Tableau 3.26: Classement des "Enterprise Activity" partitionnement 4-means.................216
Tableau 3.27: dépendances techniques inter et intra modules BAAN...............................219
Tableau 3.28: Contribution des applications aux fonctions métiers (BAAN)....................220
Tableau 3.29: Partitionnement tables TI du cas BAAN-TT-568........................................222
Tableau 3.30: Usages "de base" et "avancés" des processus WH de BAAN.....................223
Tableau 3.31: dépendances des processus SCOR D1.1 et D1.2.........................................224
Tableau 3.32: Classification Hiérarchique ascendante des processus SCOR....................226
Tableau 5.1. Liste des Fonctions principales de INFOR ERP LN 6 (BAAN)...................243
Tableau 5.2: Définition de briques applicatives.................................................................248

Pierre-Alain MILLET
Thèse en informatique/ 2008 Partie 5 / Partie 5
Institut National des Sciences Appliquées de Lyon 307
 FOLIO ADMINISTRATIF

THESE SOUTENUE DEVANT L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE

LYON

NOM : MILLET DATE de SOUTENANCE : 14 Octobre 2008

(avec précision du nom de jeune fille, le cas échéant)
Prénoms : Pierre-Alain

TITRE :
Une analyse de l'intégration organisationnelle et informationnelle: application aux systèmes d'information de type
ERP.
NATURE : Doctorat Numéro d’ordre : 2008-ISAL-0071
Ecole doctorale :Ecole doctorale informatique et information pour la société
Spécialité : Infomatique et Information pour la Société
Code B.I.U. – Lyon : T 50/210/19 / et bis CLASSE :
RESUME :
Les systèmes d'information (S.I.) d'entreprise se construisent à partir de progiciels configurés, intégrés et déployés
dans des organisations en mouvement. Les enjeux d'efficacité des projets, d'efficience des usages, de performances
opérationnelles, d'alignement aux stratégies d'entreprise sont connus. Ils fondent la problématique de l'intégration
organisationnelle et informationnelle, avec la généricité nécessaire à la diffusion des bonnes pratiques et normes,
dans une démarche continue mêlant analyse de l'existant, conception et mise en œuvre par l'organisation. Un cadre
d'ingénierie dirigée par les modèles se diffuse progressivement à partir des travaux en modélisation d'entreprise et
en système d'information. Ce mémoire propose une approche centrée sur l'intégration organisationnelle et
informationnelle afin d'enrichir ce cadre dans les phases de conception, d'intégration et d'usage pour prendre en
compte les interdépendances entre les éléments d'un système et entre les points de vue différents sur ce système.
Ce cadre étendu repose sur un méta-modèle de l’intégration et une démarche d’alignement entre les points de vue.
Il s’appuie sur la théorie des graphes pour définir une notion de voisinage permettant de représenter les différentes
formes d'intégration qui conditionnent, permettent ou limitent les résultats des projets. L’analyse de différents cas
issus de référentiels métiers permet de valider la pertinence du cadre proposé pour enrichir les représentations de
ces modèles.

MOTS CLES : Modélisation, Intégration, ERP, partitionnement...

Laboratoire(s) de recherches :Laboratoire d'Informatique pour l'Entreprise et les Systèmes de Production

Directeur de thèse :Valérie Botta-Genoulaz

Président du jury :

Composition du jury
Khalid Benali Maître de conférence HDR, Nancy, Rapporteur
Valérie Botta-Genoulaz Professeur (INSA de Lyon)
Jacques Erschler Professeur (INSA de Toulouse)
Alain Guinet Professeur (INSA de Lyon)
Hervé Pingaud Professeur (ENIT Tarbes), Rapporteur
Michel Schneider Professeur (ISIMAG Clermont)
Kurt Weiz Professeur, Resp. des relations académiques SAP