Mamoghli Sarra 2013 ED269

UNIVERSIT DE STRASBOURG
COLE DOCTORALE Mathmatiques, Sciences de lInformation et de

lIngnieur
LGeCo
THSE
prsente par :
Sarra MAMOGHLI
soutenue le : 18 janvier 2013
pour obtenir le grade de : Docteur de luniversit de Strasbourg

Discipline/ Spcialit : Ingnierie et Technologie / Sciences et technologies
industrielles
Alignement des Systmes dInformation

base de progiciel, vers une ingnierie
dirige par les modles centre
identification des risques
THSE dirige par :
M. RENAUD Jean
Mme BOTTA-GENOULAZ
Professeur, INSA de Strasbourg

Professeur, INSA de Lyon (co-direction)
RAPPORTEURS :
M. BOUREY Jean-Pierre
M. GRABOT Bernard
Professeur, Ecole centrale de Lille

Professeur, ENI de Tarbes
AUTRES MEMBRES DU JURY :

Mme ROLLAND-BENCI Colette
Professeur, Universit Paris 1
M. GOURC Didier
Professeur, Matre-assistant HDR, Ecole des Mines
;;;;;;;;;;;;;;;;;;;;;;;;;;;;; dAlbi-Carmeaux
M. KALIKA Michel
Professeur, Universit Paris-Dauphine
Mme GOEPP Virginie
Matre de confrence, INSA de Strasbourg (co- encadrement)
Remerciements
Je tiens tout dabord exprimer mes sincres remerciements mon encadrante et ma directrice
de thse : Mmes Virginie Goepp, Maitre de confrences lINSA de Strasbourg et Valrie
Botta-Genoulaz, professeur lINSA de Lyon et directrice du laboratoire DISP. Je les remercie
pour leur disponibilit, leurs prcieux conseils et leur soutien. De part leur rigueur intellectuelle,
leur exigence et leur efficacit, travailler sous leur direction fut une exprience trs riche qui ma
beaucoup appris. Par ce biais, jai pu bnficier de lavantage dun double regard sur ma thse,
ce qui ma permis de la mener bien.
Je remercie galement mon co-directeur de thse M. Jean Renaud, professeur lINSA de
Strasbourg mais galement directeur du Laboratoire LGeCO, pour avoir accept la direction de
mes travaux et pour son soutien et sa bonne humeur.
Je tiens remercier M. Jean-Pierre Bourey, professeur lEcole Centrale de Lille, et M. Bernard
Grabot, professeur lENI de Tarbes pour avoir accept de rapporter mes travaux de thse, pour
leur lecture attentive du manuscrit et pour leurs remarques constructives qui mont permis
damliorer la qualit de mon travail. Je tiens remercier galement Mme Colette Rolland, M.
Didier Gourc et M. Michel Kalika qui ont accept dexaminer mes travaux et dont les remarques,
durant la soutenance, ont t, pour moi, trs constructives.
Je tiens galement tmoigner ma reconnaissance mon partenaire industriel. Mes
remerciements vont particulirement M. Fabrice Ruffenach qui a galement accept de
participer au jury de cette thse. Je le remercie de toute la confiance quil ma tmoign mais
aussi de mavoir donn laccs libre tout ce dont javais besoin pour mener bien ma
recherche. Je remercie galement M. Christophe Shalck pour son accueil et ses encouragements.
Enfin, mes remerciements vont M. Clment Ouzilleau, ingnieur de lINSA de Strasbourg et
nouvellement install dans ses fonctions chez mon partenaire industriel, qui ma t dune aide
prcieuse en tant toujours disponible pour rpondre mes questions.
Ma gratitude sadresse toutes les personnes que jai ctoyes au DISP mais galement au
LGeCo durant trois ans avec lesquelles jai partag de si agrables moments : Arash Najari,
Ioana Arsenie, Yannick Bodein, Brunilde Verrier, Wei Yan, Cline Conrardy, Bertrand Rose,
Emmanuel Caillaud, Joelle Capuano, Simon Scherrer, Ali Tahri, Charlyne Millet, Le Ba Danh,
Sebastien Dubois, Cline Ohresser-Oppenhauser, Stphanie Fischer, Qiang Zhang, Nathalie
Gartiser, Jonathan Frechard, Oscar Avila, Didier Casner, Eric Schenk, Homam issa, Anastasie
Schiffer, Tasseda Boukherroub, Selma Khedar, Alain Guinet.
Je ne saurai oublier ma famille, mon pre, ma mre, ma sur, ma grand mre pour leur soutien
inconditionnel quils mont apport tout au long de ma thse et dans les moments difficiles et
qui je ddie mes travaux.
Enfin, je remercie les personnes qui me sont trs chres, que jai rencontres Strasbourg et qui
se reconnatront. Je naurais pu raliser cette thse sans leur grand soutien, leurs conseils et leurs
encouragements.
Table de Matires Gnrale
Chapitre 1 Introduction ...................................................... 1

Chapitre 2 Contexte de recherche et problmatique ........ 5
1
Systmes dInformation et ERP .............................................................................5

1.1
1.1.1
1.1.2
1.2
1.2.1
1.2.2
1.2.3
1.3
2
Vision instrumentaliste ................................................................................................... 5

Vision interprtative et interactionniste ..................................................................... 7
Systmes ERP .................................................................................................8

March des progiciels et des ERP......................................................................................... 8
Quest-ce quun ERP ?......................................................................................................... 9
Pourquoi les ERP ? ............................................................................................................ 10
Echec de projet ERP et alignement ................................................................ 11
Problmatique scientifique ................................................................................... 12

2.1
2.2
2.2.1
2.2.2
2.3
3
Systmes dInformation dentreprise ...............................................................5
Cycle de vie du projet ERP ............................................................................ 13

Dfinition de lalignement ............................................................................. 15
Alignement dans la littrature ............................................................................................ 15
Alignement dans les projets ERP ....................................................................................... 17
Problmatique du Risque de Non-Alignement ............................................... 19
Contexte de la recherche....................................................................................... 21
3.1
3.2
3.3
PME et ERP .................................................................................................. 21

Prsentation de notre partenaire industriel et de son projet ERP ..................... 23
Dmarche de recherche / action ..................................................................... 25
Chapitre 3 Etat de lart pour le traitement du Risque de

Non-Alignement (RNA) ...................................................... 29
1
Mthodes dingnierie dirige par les modles .................................................... 31

1.1
1.1.1
1.1.2
1.1.3
1.2
1.3
1.3.1
1.3.2
1.4
Processus dentreprise ................................................................................... 31

Dfinition selon le cadre de modlisation ISO 19439 .......................................................... 32
Dfinition de la vue intentionnelle...................................................................................... 35
Interdpendance de processus ............................................................................................ 39
Prsentation des mthodes dingnierie dirige par les modles ..................... 43

Analyse des mthodes ................................................................................... 46
Identifier le non-alignement potentiel ................................................................................. 46
Evaluer leffet du non-alignement et y associer des dcisions ............................................. 49
Conclusion et mise en perspective par rapport au cas dtude ........................ 51

i
Management des facteurs de risque ..................................................................... 52

2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.4
3
Analyse des contributions .............................................................................. 53

Analyse et classification des facteurs de risque et de succs des projets ERP . 55
Analyse selon le mode de recueil et la frquence de citation ............................................... 56
Classification selon la nature du facteur de risque ou de succs ........................................... 60
Classification selon le cycle de vie du projet ERP ............................................................... 62
Influences entre les facteurs de risque ou de succs ............................................................ 63
Approches de management des facteurs de risque .......................................... 65

Conclusion et mise en perspective par rapport au cas dtude ........................ 66
Conclusion du chapitre ......................................................................................... 68
Chapitre 4 Model Driven - ERP Alignment .................... 69

1
Prsentation gnrale de la mthode .................................................................... 69

1.1
1.2
1.3
1.3.1
1.3.2
Six dcisions ..................................................................................................................... 73

Critres pour la prise de dcision........................................................................................ 75
Activits du processus dalignement par vue de modlisation ............................ 75

2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.3
2.3.1
2.3.2
Vue macroscopique du processus dalignement ............................................. 69

Processus dalignement et norme ISO 19439 ................................................. 72
Prise de dcision ............................................................................................ 73
Vue intentionnelle ......................................................................................... 76

Construire les modles AS-WISHED et MIGHT-BE .......................................................... 76
Construire le modle TO-BE intentionnel........................................................................... 77
Vue fonctionnelle .......................................................................................... 78

Construire le modle TO-BE fonctionnel ........................................................................... 84
Vue informationnelle ..................................................................................... 88

Construire le modle TO-BE informationnel ...................................................................... 89
Synthse du chapitre ............................................................................................. 90
Chapitre 5 Risk-Factor Driven - ERP Alignment ........... 93

1
Facteurs de risque influenant le RNA ................................................................ 93

1.1
1.2
Facteurs de risque de ltape dadquation ..................................................... 94

Facteurs de risque dduits des liens rsiduels ................................................. 96
Outils didentification des facteurs de risque ...................................................... 97
Outil de traitement des facteurs de risque ......................................................... 101
Mise en uvre de la dmarche travers les outils............................................. 103
Synthse du chapitre ........................................................................................... 106

ii
Chapitre 6 Application un cas dtude ........................107

1
Mthode Model Driven - ERP Alignment .................................................... 108

1.1
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.3
2
Dmarche .................................................................................................... 108

Application de la mthode Model Driven - ERP Alignment au SAV ...... 109
Vue intentionnelle ........................................................................................................... 110
Vue fonctionnelle ............................................................................................................ 113
Vue informationnelle ....................................................................................................... 125
Synthse de la dcision de complment la conduite de changement .......................... 126
Conclusion de lapplication de Model Driven - ERP Alignment ............. 126
Approche Risk-Factor Driven - ERP Alignment ......................................... 127

2.1
2.2
2.2.1
2.2.2
2.3
Dmarche .................................................................................................... 128

Application de lapproche Risk-Factor Driven - ERP Alignment ........... 129
Priode dadquation ....................................................................................................... 129
Priode de retour sur adquation ...................................................................................... 134
Conclusion de lapplication ......................................................................... 139
Chapitre 7 Conclusions et perspectives ..........................141

Rfrences Bibliographiques .............................................145
Annexes ...............................................................................156
A.
Liste des publications de lauteur....................................................................... 156
B.
Cycle de vie du projet ERP et de lERP dans la littrature............................... 157
C.
Mthodes dalignement et de confrontation....................................................... 158
D.
Classification des travaux sur les facteurs de risque et de succs ..................... 171
E.
Sources des facteurs de risque et de succs ........................................................ 177
F.
Rfrences des liens rsiduels ............................................................................. 191
G.
Dtail des variables pour les facteurs de risque du RNA .................................. 195
H.
Confrontation des processus associs aux buts non satisfaits par lERP .......... 202
I.
Confrontation des processus associs aux buts quivalents .............................. 208
J.
Confrontation des processus associs aux buts dcouverts ............................... 226
K. Dtail des variables des facteurs identifis et des pratiques conseilles, priode
adquation .................................................................................................................... 230
iii
L. Dtail des variables des facteurs identifis et des pratiques conseilles, priode
de retour sur adquation ............................................................................................. 233
M.
Liste de Figures ................................................................................................... 235
N.
Liste de Tableaux ................................................................................................ 238
iv
Chapitre 1 Introduction
Le contexte industriel actuel, particulirement difficile, se caractrise par une comptition
exacerbe. Dans ce contexte, pour rester comptitives et assurer leur prennit, les entreprises
investissent de plus en plus dans les progiciels et notamment les ERP - Enterprise Resource
Planning - pour supporter leur Systme dInformation (S.I.). En effet, ils contribuent
intgrer lensemble des domaines fonctionnels dune entreprise et sont loccasion pour elle
dadopter les bonnes pratiques mtier.
Le march des ERP en France est en perptuelle croissance pour atteindre, selon (IDC 2012),
les 2550 milliards d en 2015. Cet essor est particulirement important pour les PME Petites et Moyennes Entreprises - o le taux dquipement en ERP est pass de 31,5% 36%
entre 2009 et 2010, selon les tableaux de bord du Ministre des Finances et de lIndustrie sur
lintgration des TIC1. Cependant les projets ERP se soldent souvent par des checs. Selon
lenqute du (Panorama Consulting Group 2012a) ralise en 2011, 56% des projets ont
dpass le budget fix, 54% les dlais fixs et 44% ont ralis moins de 50% des bnfices
attendus.
Compte tenu de laspect standard de ces progiciels, il est ncessaire de grer lalignement
entre les besoins rels de lentreprise et les fonctionnalits standards de lERP. Il sagit l de
lun des enjeux majeurs des projets ERP (Botta-Genoulaz and Millet 2005) pour assurer leur
succs. Cette gestion est dautant plus difficile dans le contexte des PME que leurs ressources
sont limites (Raymond et al. 1990; Torres 1997; Buonanno et al. 2005; Blackwell et al. 2006;
Halilem and St-Jean 2007). Les travaux de cette thse, cofinancs par une bourse de
valorisation de la Rgion Alsace et une PME franaise, sinscrivent dans ce contexte. Ils ont
t mens en mettant en uvre une dmarche de recherche / action dont le principe consiste
mettre en regard de manire continue les contributions scientifiques et le terrain dapplication,
savoir le projet ERP du partenaire industriel. Ces deux viennent senrichir mutuellement.
Pour aborder la problmatique scientifique, nous avons considr le non-alignement comme
un rsultat indsirable dont nous voulons viter la survenue au cours de la phase
dimplantation de lERP. De ce point de vue, il peut tre considr comme un risque - le
Risque de Non-Alignement - devant tre trait le plus en amont possible dans les phases du
projet ERP. Ainsi, lobjectif de nos travaux est de proposer des stratgies de traitement de ce
risque.
1
http://www.industrie.gouv.fr/p3e/tableau_bord/tic/tic.php
Ce mmoire est organis en 5 chapitres :

Le chapitre 2 vise dfinir les concepts cls de Systme dInformation dentreprise, dERP et
dalignement, prsenter la problmatique de traitement du Risque de Non-Alignement et
galement dcrire le contexte des travaux dans une dmarche de recherche / action.
Dans le chapitre 3, sur la base dune revue de la littrature sur le traitement des risques, nous
tudions plus en dtail les stratgies permettant de traiter le Risque de Non-Alignement et les
moyens pour y parvenir. La premire stratgie consiste en loptimisation anticipative du
Risque de Non-Alignement agissant sur son effet ; un moyen pour la mettre en uvre est
lapplication des mthodes dingnierie dirige par les modles. La seconde consiste en
loptimisation anticipative du Risque de Non-Alignement agissant sur son occurrence ; un
moyen pour la mettre en uvre est le management des facteurs de risque influenant le
Risque de Non-Alignement. Sur la base de cet tat de lart, nous avons construit les deux
contributions de cette thse :
Dans le chapitre 4, nous proposons une mthode dingnierie dirige par les modles appele
Model Driven - ERP Alignment agissant sur leffet du Risque de Non-Alignement. Cette
mthode comporte un processus dalignement mettant en jeu des modles, et permet :
-
didentifier finement les situations dalignement et de non-alignement entre les modles

des processus souhaits par lentreprise et ceux des processus standards de lERP ;
de construire progressivement et de manire guide le modle des processus implanter
en couplant critres dvaluation et prise de dcision.
Dans le chapitre 5, nous proposons une approche de management des facteurs de risque
associs au Risque de Non-Alignement, nomme Risk-Factor Driven - ERP Alignment .
Elle consiste en une dmarche outille didentification et de traitement des facteurs de risque
influenant le Risque de Non-Alignement. Plus exactement, lidentification des facteurs,
sappuie sur trois outils :
-
Une classification des facteurs par rapport au cycle de vie du projet ERP ;
Une matrice de liens rsiduels entre les facteurs ;
Un ensemble de variables dfinissant chaque facteur de risque, permettant didentifier si
un facteur de risque sest matrialis ou non un moment donn durant le projet.
Pour le traitement des facteurs de risque nous proposons une matrice pratiques de gestion /
facteurs de risque. Nous exposons ensuite lutilisation conjointe de ces outils pour la mise en
uvre de la dmarche.
Ces deux contributions se positionnent comme des moyens pour traiter le Risque de NonAlignement, lune agissant sur leffet, lautre sur loccurrence, au niveau de ltape
dadquation de la phase dimplantation dun ERP. Nous exposons dans le chapitre 6 les
rsultats de lapplication de ces deux contributions au projet ERP de notre partenaire
2
industriel et discutons les apports pour lentreprise. Dans le chapitre 7, nous concluons ce
travail et proposons des pistes de recherche futures.
Chapitre 2 Contexte de recherche et problmatique
Chapitre 2 Contexte de recherche et

problmatique
Ce chapitre dcrit la problmatique scientifique dans le contexte dune dmarche de recherche
/ action2 en partenariat avec une PME - Petite et Moyenne Entreprise alsacienne de 120
salaris. Tout dabord, la section 1 dfinit les notions de Systme dInformation (S.I.)
dentreprise et dERP - Enterprise Resource Planning. Ensuite, nous mettons en lumire les
enjeux dterminants dans le succs dun projet ERP, parmi lesquels lalignement. La section 2
dcrit la problmatique scientifique correspondant au traitement du Risque de NonAlignement durant la phase dimplantation. Enfin nous consacrons la section 3 au contexte
industriel de nos travaux en dtaillant la problmatique pour les PME et la dmarche de
recherche / action mise en uvre au sein de lentreprise partenaire.
1
1.1
Systmes dInformation et ERP

Systmes dInformation dentreprise
Dans le contexte conomique actuel, les entreprises manufacturires font face une
concurrence exacerbe impliquant de maintenir un niveau de comptitivit lev. Les S.I. sont
la pierre angulaire de ces entreprises puisquils jouent un rle majeur dans ce maintien et se
rvlent comme un vecteur de performance essentiel (Deixonne 2001).
De nombreuses dfinitions du concept de S.I. sont proposes dans la littrature. Dune
manire synthtique, celles-ci font rfrence deux visions (Goepp 2003) : la premire dite
instrumentaliste et la seconde dite interprtative et interactionniste .
1.1.1
Vision instrumentaliste
Cette vision considre le S.I. comme un rservoir dinformations pour les acteurs de
lentreprise. Son objectif est la collecte, la transmission, le traitement et la diffusion de
linformation (Goepp 2003). Ici le rle du S.I. est dautomatiser les tches quotidiennes. Cette
vision est appuye par les travaux systmiques de (Le Moigne 1990), mais aussi par ceux de
(Davis and Olson 1974) ou encore (Mason and Mitroff 1973).
Cycles de recherche en spiral o contributions scientifiques et terrain dapplication sont mises en regard de
manire continue pour senrichir (Kimmis and McTaggart 1988)
Selon, (Le Moigne 1990), une entreprise est constitue de trois sous-systmes (cf. Figure 1)
savoir le Systme Oprant , le Systme de Pilotage et le Systme dInformation . Le
premier effectue les oprations de lentreprise. Il utilise et produit des informations. Le second
reprsente lquipe dirigeante de lentreprise et prend des dcisions. Le Systme
dInformation se positionne entre ces 2 systmes. Il mmorise linformation produite par le
Systme Oprant ce qui permet au Systme de Pilotage de la considrer dans la prise
de dcision.
Systme de
Pilotage
Systme
dInformation
Systme Oprant
Figure 1- Vision systmique du S.I., inspire des travaux de (Le Moigne 1990)
(Davis and Olson 1974) dfinissent le S.I. comme un systme utilisateur-machine intgr
qui produit de linformation pour assister les tres humains dans les fonctions dexcution, de
gestion et de prise de dcision . Ici, laccent est mis sur le support apport par le S.I. aux
tches quotidiennes.
Pour (Mason and Mitroff 1973), le S.I. consists of at least one person of a certain
psychological type who faces a problem within some organizational context for which he
needs evidence to arrive at a solution (i.e., to select some course of action) and that the
evidence is made available to him through some mode of presentation. Nous le traduisons
en : le S.I. est compos dau moins une personne avec un profil psychologique donn. Cette
personne est confronte un problme dans un contexte organisationnel donn. Pour le
rsoudre (cest--dire choisir des actions), la personne a besoin dlments, qui lui sont mis
disposition travers un certain mode de prsentation. Outre le support aux tches
quotidiennes, cette dfinition replace le S.I. au sein dun contexte organisationnel donn, o
linformation qui est mise disposition doit tre adapte aux acteurs.
Devant limportance prise par les S.I. au sein des entreprises, sest dveloppe, ct de la
vision instrumentaliste, la vision interactionniste et interprtative. Celle-ci met le S.I. au cur
des processus de lentreprise.
1.1.2
Vision interprtative et interactionniste
Dans cette vision le S.I. nest pas seulement une ressource qui manipule et traite
linformation. Il inclut aussi une dimension politique travers laquelle des individus et des
groupes ngocient, distribuent et partagent. Ainsi, laccent est mis sur la gnration et
linterprtation de linformation, la construction de sens et le partage des reprsentations des
individus (Goepp 2003). Les travaux de (Reix et al. 2011) et (Morley et al. 2006) adoptent ce
point de vue.
Selon cette vision, comme le souligne (Reix et al. 2011), tout S.I. est un objet
multidimensionnel pouvant tre caractris par trois dimensions principales :
-
Une dimension informationnelle qui correspond une production par le S.I. de

reprsentations utilisables et ncessaires aux diffrents acteurs - tel quun bilan
comptable ;
Une dimension technologique qui est assimile aux quipements, outils, dispositifs
techniques mis en place en vue de permettre aux individus daccomplir leurs tches.
Chaque acteur sapproprie de manire diffrente cette dimension travers un processus
dassimilation de la technologie - appropriation qui dpend de facteurs tels que lge ou
lexprience professionnelle de la personne, les formations, la facilit dutilisation perue,
etc. ;
Une dimension organisationnelle lie linfluence du S.I. qui agit :
sur le droulement des processus de travail lintrieur et aux frontires de
lorganisation - en structurant le processus de travail c'est--dire en imposant un
mode opratoire ; en coordonnant laction des diffrents acteurs, etc. ;
sur la dynamique des changements de la structure de lorganisation : o lusage de
nouveaux S.I. entrane lapparition de nouvelles formes dactions - ayant une
dimension la fois de signification, de lgitimit et de pouvoir quelles
reprsentent, qui leur tour structurent les nouvelles interactions entre les acteurs.
Celles-ci dterminent, quant elles, la structure de lorganisation.
Compte tenu de ces trois dimensions et comme le souligne (Morley et al. 2006) cette vision
implique de faire la distinction entre le systme informatique et le Systme dInformation (cf.
Figure 2) : Le Systme dInformation dune entreprise est la partie du rel constitue
dinformations organises, dvnements ayant un effet sur ces informations et dacteurs qui
agissent sur ces informations ou partir de ces informations, selon des processus visant une
finalit de gestion et utilisant les technologies de linformation. Le systme informatique est
un ensemble organis dobjets techniques - matriaux, logiciels, applicatifs - dont la mise en
uvre ralise linfrastructure du Systme dInformation et lui permet de fonctionner .
Dans cette vision le S.I. nest plus considr comme un rservoir de stockage, de traitement et
de diffusion de linformation entre le Systme Oprant et le Systme de Pilotage. Il est
dsormais un aspect part entire de lentreprise, entranant deux problmatiques
complmentaires dans la gestion des S.I. (Morley et al. 2006) : lune de contenant
correspondant aux aspects techniques c'est--dire au systme informatique stockant de
linformation dans les bases de donnes ; lautre de contenu correspondant aux aspects
7
conceptuels et organisationnels c'est--dire aux pratiques dusage de linformation par

lensemble des processus dune entreprise dans un contexte organisationnel.
Systme dInformation
Acteurs
Informations
Processus
permet
sappuie sur
systme informatique
Matriels
Logiciels
Applicatifs et bases de
donnes
Figure 2- Distinction entre systme informatique et S.I. (Morley et al. 2006)
Dans cette thse, cest cette deuxime vision des S.I. qui allie problmatiques de
contenant et contenu qui nous intresse. Ainsi, laspect applicatif associ aux
dimensions informationnelle et organisationnelle entre en jeu dans la conception et la gestion
des S.I. dentreprise et interfre avec la dimension technologique.
1.2
1.2.1
Systmes ERP
March des progiciels et des ERP
Les S.I. sont de nos jours de plus en plus bass sur des progiciels encore appels off-the-self
products - produits sur tagre en franais. En effet, le cabinet de recherche et de conseil
Gartner3 prvoyait une croissance annuelle moyenne du march mondial des progiciels entre
2010 et 2014 denviron 6% pour atteindre 297 milliards de $ - environs 241 milliard d - en
2014.
Un progiciel est un ensemble cohrent et indpendant constitu de programmes, de services,
de supports de manipulation d'informations - bordereaux, langages, etc. - et d'une
documentation, conu pour raliser des traitements informatiques standard, dont la diffusion
revt un caractre commercial et qu'un utilisateur peut utiliser de faon autonome aprs une
mise en place et une formation complte (Larousse 1981).
http://www.journaldunet.com/solutions/dsi/marche-mondial-du-progiciel-2009-2014.shtml
Parmi ces progiciels, il y a les ERP - Enterprise Resource Planning - encore appels
Progiciel de Gestion Intgr - PGI - en franais. Ils sont lobjet de nos travaux. Lessor du
march des ERP explique cet intrt. Le groupe mondial de recherche et dtude IDC (IDC
2012) montre que le march franais reprsentait environ 2250 milliards deuros en 2011. Il
est en prvision de croissance constante partir de 2013 pour atteindre environ 2550 milliards
deuros en 2015 (cf. Figure 3).
2600
2500
2400
2300
2200
2100
2000
March en Milliards
d'euros
2011
2012
2013
(+0,05%) (+2,4%)
2014
(+5%)
2015
(+5%)
Figure 3- Croissance du march franais des ERP de 2011 2015 (inspir de (IDC 2012))
1.2.2
Quest-ce quun ERP ?
De nombreuses dfinitions du terme ERP sont disponibles dans la littrature :

Selon (Tournant and Azan 2003), Un ERP est un progiciel (application logicielle
dveloppe par un diteur, concepteur unique) comprenant une couche gnrique pour
rpondre aux besoins de plusieurs clients et une couche spcifique, dveloppe au travers de
paramtrage et parfois de customisations , pour rpondre lactivit, aux mtiers et aux
spcificits de lorganisation cliente .
(Botta-Genoulaz and Millet 2006) le dfinissent comme an integrated software package
composed by a set of standard functional modules (Production, Sales, Human Resources,
Finance, etc.), developed or integrated by the vendor, which can be adapted to the specific
needs of each customer. It attempts to integrate all departments and functions across
accompany onto a single computer system that can serve all those different departments
particular needs. Nous le traduisons en : lERP est un progiciel de gestion intgr compos
dun ensemble de fonctions standard (Production, Ventes, Ressources Humaines, Finances,
etc.), dveloppes ou intgres par le fournisseur, qui peuvent tre adaptes aux besoins
spcifiques de chaque client. Il vise intgrer tous les dpartements et toutes les fonctions
dune entreprise sur un systme informatique unique qui peut servir tous les besoins
particuliers de ces diffrents dpartements.
(Millet 2008) le dfinit comme une offre progicielle regroupant des applications
paramtrables, modulaires, intgres et ouvertes, s'appuyant sur un rfrentiel unique de
donnes, de procdures et de rgles de gestion. Configur et adapt au contexte d'une
entreprise, il devient le support d'une stratgie d'intgration qui vise fdrer et optimiser
les processus de gestion de l'entreprise et de relation avec ses partenaires .
Nous retenons de ces dfinitions les lments suivants :
-
LERP est une offre progicielle dveloppe par un diteur.

LERP intgre tous les domaines de gestion de lentreprise travers des modules
fonctionnels standards : la Figure 4, inspire des travaux de (Botta-Genoulaz and Millet
2006), rcapitule les domaines traditionnellement couvets par les ERP. Le primtre
fonctionnel sest galement ouvert dautres domaines tels que le CRM _ Customer
Relationship Management - et le SCM - Supply Chain Management.
LERP sappuie sur un rfrentiel unique de donnes, de rgles de gestion et de
procdures.
LERP est modulaire : chaque module fonctionnel standard est paramtrable, configurable
et adaptable au contexte spcifique de chaque entreprise qui le met en place.
LERP est le support dune stratgie dintgration et doptimisation des processus de
lentreprise.
Figure 4- Domaines traditionnellement couverts par les ERP, inspir de (Botta-Genoulaz and Millet 2006)
1.2.3
Pourquoi les ERP ?
Compte tenu de ces caractristiques, les ERP permettent aux entreprises de rsoudre les
problmes et dfis S.I. suivants :
-
Lappel un seul diteur rsout les problmes de maintenance auxquels peuvent faire
face les entreprises ayant bti un S.I. qui a eu le temps de se stratifier au fil des annes
(Deixonne 2001).
Lintgration par lERP de lensemble des domaines de lentreprise rsout les problmes
dinterfaage. En effet, les entreprises se retrouvent avec un grand nombre de logiciels qui
doivent tre interfacs les uns aux autres pour assurer une cohrence de lensemble
(Deixonne 2001), alors quils nont pas t conus pour cela.
Lutilisation dune base de donnes commune permet de prendre en compte les
dpendances qui existent entre les processus des diffrents domaines (Deixonne 2001) et
ainsi de rsoudre les problmes dunicit des donnes.
Loffre standard est loccasion pour lentreprise dadopter les bonnes pratiques mtiers
(Light 2005). En effet, par dfaut, lERP offre un ensemble davantages fonctionnels. Par
exemple, il offre souvent une approche multi-socits, multi-sites, multilingues,
multidevises qui lui permet dtre utilis au niveau dun groupe international (Deixonne
2001).
10
Contrairement au projet de mise en place de logiciels conus spcifiquement, le projet

dimplantation de lERP demande lentreprise un effort darbitrage et dadaptation
fonctionnels et organisationnels. En effet, une des caractristiques principales des ERP est sa
gnricit et sa prexistence en dehors du contexte de lentreprise dans laquelle il va tre mis
en place.
1.3
Echec de projet ERP et alignement
Depuis lintroduction des ERP au sein des entreprises, de nombreux projets ERP ont t des
checs. Un chec se traduit gnralement par le triptyque : dpassement de budget, de dlais
et fonctionnalits souhaites non satisfaites (Bradford and Florin 2003; Tiwana and Keil
2006; Aloini et al. 2007; Bradley 2008; Tsai et al. 2009a). Ainsi, selon le rapport 2012 sur les
projets ERP du PCG (Panorama Consulting Group 2012a), un projet ERP peut se solder (cf.
Figure 5) :
-
Soit par un dpassement du budget fix. 56% des entreprises interroges ont dclar avoir
dpass leur budget. Les cots classiques, gnralement pris en compte, sont les cots de
licence, de maintenance sans oublier les cots techniques dimplantation ainsi que les
cots de matriels. Les cots souvent oublis ou sous-estims sont ceux lis aux
changements organisationnels, aux formations des utilisateurs finaux, aux modifications
apportes lERP mis en place, la gestion globale du projet.
Soit par un non-respect des dlais fixs. Dans 54% des cas, les dlais fixs ont t
dpasss. La gestion des changements organisationnels, lampleur des formations ou des
contraintes de ressources sont souvent ngliges.
Soit par la non-ralisation des bnfices attendus. 44% des entreprises interroges
considrent avoir ralis moins de 50% des bnfices attendus. Parmi ces bnfices, on
peut citer une meilleure disponibilit de linformation dans lentreprise, une meilleure
interaction avec les tiers - clients et fournisseurs - et au sein de lentreprise mais aussi de
meilleurs dlais de livraison et une rduction des charges dexploitation.
60
50
40
30
20
10
0
56
54
44
% des entreprises
interroges
Dpassement
budget
Dpassement
dlais
Non-ralisation
des bnfices
Figure 5- Echecs des projets ERP, enqute du (Panorama Consulting Group 2012a)
Dans des cas extrmes, le projet est abandonn comme chez Mobile Europe, Dell computer
ou encore Dow Chemical (Davenport 1998). Le projet peut mme mener la faillite de
lentreprise; tel fut le cas de FoxMeyer Drug (Davenport 1998; Panorama consulting group
2012b).
11
Selon (Davenport 1998; Swan et al. 1999; Iskanius 2009), la raison majeure de lchec dun
projet ERP est son incapacit grer lalignement entre les fonctionnalits standards de lERP
et ses besoins rels. La gestion de lalignement fait donc partie de lun des principaux facteurs
cls de succs des projets ERP (Kamhawi and Gunasekaran 1999; Ramayah et al. 2007;
Millet and Botta-Genoulaz 2008).
Lalignement est en relation directe avec les bnfices attendus de limplantation de lERP,
cl de la performance de lentreprise. Selon (Millet and Botta-Genoulaz 2006), cest
lalignement des S.I. et des processus daffaires qui permet dassurer la contribution des
applications et technologies aux objectifs conomiques et logistiques . Il dtermine les
futures pratiques de gestion de lentreprise c'est--dire ses futurs processus. Ces derniers vont
in fine contribuer sa performance (Soh and Markus 1995; Soffer et al. 2003; Soffer et al.
2005; CIGREF 2011).
Cest au cours de son projet ERP que lentreprise doit tre capable de grer lalignement entre
ses besoins rels et les fonctionnalits standards de lERP. Lobjectif est dviter, lissue du
projet, que les processus mis sous contrle de lERP ne soient pas aligns aux besoins rels.
Ce nest pas une tche simple accomplir (Botta-Genoulaz and Millet 2009). Une entreprise
doit pouvoir valuer les enjeux dun tel projet (Davenport 1998). Cet auteur met les
entreprises en garde de ne pas perdre leur avantage concurrentiel. En effet, elles pourraient se
voir abandonner certains des processus porteurs davantage concurrentiel au profit de
processus plus standards. De plus, (Basoglu et al. 2007) argumentent quune entreprise qui
abandonne sa logique de fonctionnement peut, en retour, faire face la rsistance des
utilisateurs finaux qui nutiliseront pas efficacement le systme. Dautres aspects entrent
galement en compte dans la gestion de lalignement. En effet, les ERP tant conus dans des
pays techniquement avancs, les progiciels peuvent tre un niveau trop lev pour les pays
en voie de dveloppement (Botta-Genoulaz et al. 2005). Cela sest traduit pas un taux de
succs des projets ERP en Chine atteignant uniquement les 10% au dbut des annes 2000
(Botta-Genoulaz et al. 2005). De mme, (Amid et al. 2012) mettent en vidence le cas des
entreprises dorigine iranienne, chinoise ou encore gyptienne dont la gestion de lalignement
sera dautant plus difficile.
La section suivante est consacre dtailler la notion dalignement dans le cas des projets
ERP.
Problmatique scientifique
Lalignement est dfini, selon le dictionnaire Le Petit Larousse , comme le fait daligner
cest--dire de faire concider une chose avec une autre . Dans le cadre des projets ERP,
12
ces deux choses que nous appellerons entits sont : les besoins rels de lentreprise et
les fonctionnalits standards de lERP.
Avant de dfinir finement cette notion ainsi que la problmatique de Risque de NonAlignement, nous la replaons par rapport aux cycles de vie de lERP et de son projet.
2.1
Cycle de vie du projet ERP
De nombreux travaux proposent des cycles de vie de projet ERP qui se distinguent par le
nombre et la dnomination des phases et des tapes constituant le projet (cf. annexe B).
Certains intgrent dans ce cycle de vie des tapes avant - tude de faisabilit - et aprs le
projet - volution et fin de vie, faisant du cycle de vie propos celui de lERP. Dans le
contexte de la gestion de lalignement, nous proposons de dcouper le cycle de vie du projet
en trois phases - pr-implantation, implantation et post-implantation - linstar des auteurs
tels que (Kumar et al. 2003; Motwani et al. 2005; Aloini et al. 2007). Pour dlimiter ces
phases, nous nous sommes inspirs de ces derniers. Cependant, pour leur dcoupage en
tapes, nous nous sommes appuys sur les autres auteurs tudis. Enfin, (Esteves 1999) et
(Tournant and Azan 2003) nous ont permis de dfinir lavant et laprs projet.
Lavant-projet consiste, pour une entreprise, tudier la faisabilit dentamer ou non un projet
ERP. Elle analyse le besoin de mettre en place un tel systme et sa capacit assumer un tel
projet.
La phase de pr-implantation runit les tapes suivantes (cf. Figure 6) :
Pr-implantation
Dfinition des
objectifs stratgiques
et des besoins
Slection du
progiciel
Lancement
Figure 6- Phase de pr-implantation du projet ERP
Dfinition des objectifs stratgiques et des besoins : cette tape concerne la spcification
des besoins macroscopiques de lentreprise. Elle se conclut par la rdaction du cahier des
charges.
Slection du progiciel : lentreprise lance un appel doffre et constitue une liste dditeurs
potentiels - par exemple : SAP, SAGE, ORACLE. Puis, elle analyse et classe ces derniers
afin den choisir un. L'diteur de lERP, lintgrateur et ventuellement un cabinet de
consultant pour accompagner lentreprise sont choisis. LERP devient lERP achet
(Millet 2008).
Lancement : cette tape concerne la nomination des quipes de projet, la planification du
projet et l'tablissement du contrat avec lditeur et lintgrateur.
13
La slection du progiciel a une influence sur lalignement. Lobjectif, lors de la slection, est
de choisir le progiciel dont les fonctionnalits standards rpondent au maximum aux besoins
rels de lentreprise. Si ce nest pas le cas, on sexpose augmenter le non-alignement
potentiel puisquil faudra complter lERP pour obtenir un S.I. qui rponde aux besoins de
lentreprise.
La phase dimplantation runit les tapes suivantes (cf. Figure 7) :
Implantation
Adquation
Intgration
et tests
Mise en
production
Figure 7- Phase dimplantation du projet ERP
Adquation : cette tape consiste configurer lERP dans l'environnement technique de

l'entreprise : lERP devient lERP install (Millet 2008). Puis il sagit de prendre, pour
chaque domaine de lentreprise tels que la comptabilit, la finance, la production, le
commercial, le SAV ou encore la maintenance, des dcisions concernant les processus
mettre sous contrle de lERP.
Intgration et tests : cette tape consiste mettre en uvre les dcisions prises dans ltape
prcdente : lERP est paramtr et adapt (Millet 2008). Cette tape saccompagne de la
prparation des programmes de conversion des donnes et d'interfaage. Egalement, le
systme est test.
Mise en production : cette tape permet de donner la main aux utilisateurs finaux en
passant dabord par leur formation. Cette tape se droule selon une stratgie de mise en
production choisie par lentreprise. Cela peut tre une stratgie Big Bang
correspondant au passage en production de tous les modules la fois sans transition ou
une stratgie progressive par module, par phase, par business unit... Cette tape inclue
galement de lexcution des programmes de conversion des donnes dans le nouveau
systme. Au cours de cette tape, nous passons d'un systme informatique un S.I. ERP
comme le souligne (Millet 2008). Cette tape tablit un lien entre les technologies et les
pratiques d'usage de l'information, tout en sassurant de conduire correctement le
changement.
Ladquation influence lalignement. Pour mettre les processus sous contrle du S.I. ERP, il
est ncessaire didentifier correctement les non-alignements potentiels entre les besoins rels
de lentreprise et les fonctionnalits standards de lERP ainsi que de prendre des dcisions
adquates pour y faire face.
La phase de post-implantation correspond ltape de stabilisation. Cette tape consiste
sassurer en parallle de (cf. Figure 8) :
-
Lutilisation correcte par les utilisateurs finaux du systme mis en place. Ils peuvent
bnficier dune assistance de lintgrateur pour rpondre leurs ventuelles questions.
14
La rsolution des dfauts de fonctionnement du systme observs lors de lutilisation.
Cest durant cette phase que les non-alignements peuvent apparatre puisque lERP nest
utilis rellement quaprs la mise en production. Lappropriation par les utilisateurs finaux
des processus mis sous contrle de lERP est primordiale. Cette mise sous contrle influence
le droulement de ce que (Reix et al. 2011) appellent le processus de travail . Les
utilisateurs finaux se voient attribuer de nouvelles tches ou une nouvelle manire de raliser
leurs tches. La gestion de lappropriation et limpact que cela peut avoir sur lorganisation
sont inhrents aux projets S.I. en gnral. Cela est une ralit quil faut grer et qui influence
lalignement. En effet, un systme non utilis ou mal utilis contribue au non-alignement.
Post-implantation
Stabilisation
Figure 8- Phase de post-implantation du projet ERP
Enfin, laprs-projet consiste utiliser le systme ainsi qu le faire voluer en le mettant, par
exemple, jour suite aux montes de versions de celui-ci. Elle se conclut par la dcision de
lentreprise de changer son S.I. ERP qui est ainsi en fin de vie .
Dans cette thse, nous nous focalisons sur la phase dimplantation (cf. Figure 9). Plus
particulirement, nous proposons de grer lalignement le plus tt possible au cours de cette
phase (tape dadquation) en remontant en amont les bonnes pratiques. En effet, notre
objectif est de permettre lentreprise de ne pas observer de non-alignement lissue de
limplantation.
Cycle de
vie Projet
Pr-implantation
Implantation
Post-implantation
Figure 9- Cycle de vie dun projet ERP
2.2
2.2.1
Dfinition de lalignement
Alignement dans la littrature
De nombreux auteurs en management des S.I., en ingnierie des besoins, en ingnierie des
S.I. ou encore en ingnierie dirige par les modles se sont intresss aux notions
dalignement et de non-alignement. Il nexiste pas de dfinition consensuelle de ces notions
15
dans la littrature. Un nombre important de termes ont t utiliss pour les dsigner :
correspondance pour (Knoll and Jarvenpaa 1994), fitness relationship pour (Potts
1997), harmonie pour (Luftman 2000) ou encore pont pour (Ciborra 1997).
La vision classique de lalignement en management des S.I. sattache lalignement
stratgique des S.I. c'est--dire lalignement entre les S.I. et la stratgie concurrentielle
de lentreprise. La conceptualisation de cette vision se fait gnralement laide du Modle
dAlignement Stratgique - en anglais : Strategic Alignment Model, SAM (Henderson and
Venkatraman 1993). Comme le montre la Figure 10, lalignement stratgique y est
conceptualis selon les deux domaines Business et T.I. - Technologies de
lInformation - et selon les deux niveaux Interne et Externe :
-
Le domaine du Business au niveau Externe dtermine la stratgie concurrentielle

de lentreprise.
Le domaine du Business au niveau Interne correspond la structure
organisationnelle et aux processus mtiers de lentreprise (Business Process).
Le domaine des T.I. au niveau Externe dtermine la stratgie des T.I.
Le domaine des T.I. au niveau Interne dfinit larchitecture et les processus
techniques du S.I.
Intgration fonctionnelle
Externe
Stratgie
concurrentielle de
lentreprise
Stratgie des T.I.
Alignement
stratgique
Interne
Structure
organisationnelle et
processus mtier
de lentreprise
Business
Architecture et
processus
techniques du SI
Technologie de lInformation
(T.I.)
Figure 10- SAM - Strategic Alignment Model - inspir des travaux de (Henderson and Venkatraman
1993)
Le SAM permet galement de conceptualiser des liens dalignement entre ces 4 domaines :
-
L ajustement stratgique : il sagit du lien vertical entre deux niveaux dun mme
domaine.
L intgration fonctionnelle : Il sagit du lien horizontal entre deux domaines dun
mme niveau.
16
Selon le SAM, lalignement stratgique fait intervenir 3 des 4 domaines selon des
squences dalignement diffrentes, c'est--dire, selon des enchanements de liens diffrents.
La plupart des travaux sur lalignement peuvent tre replacs dans ce cadre. Dautres, comme
ceux de (Avila Cifuentes 2009) et (Sakka 2012), se basent sur des extensions de celui-ci.
Lalignement dans les projets ERP peut tre assimil de l intgration fonctionnelle du
niveau Interne . Nous tudions donc comment ce lien est trait dans ce cas particulier. Pour
cela, nous nous inspirons des tats de lart existants sur la notion dalignement tels que (Etien
2007; Avila Cifuentes 2009; Gmati 2011). Ces derniers classifient les travaux dalignement
selon :
-
Les entits qui entrent en jeu dans lalignement telles que la stratgie de lentreprise, les
processus dentreprise ou encore les fonctionnalits du systme.
Le mode de reprsentation des deux entits qui se base soit :
Sur la modlisation : lalignement ou le non-alignement est mesur entre les
lments reprsents dans les deux modles, chacun reprsentant une entit. Les
formalismes de modlisation utiliss diffrent dun auteur lautre.
Sur un ensemble de mtriques, critres ou items identifier : lalignement ou le
non-alignement est identifi via la satisfaction ou non de ces critres. Par
exemple, selon (Thevenet and Salinesi 2009), le critre aisance du conseiller
avec loutil est mesur au moyen dun questionnaire ou du calcul du temps que
le conseiller met excuter certaines tches sur le systme. Ces mesures
permettent destimer si le systme est capable daider le conseiller dans le choix
des produits proposer au client. Si cest le cas, cela permettrait de faire voluer
les offres de lentreprise. Lvaluation de ces critres, mtriques ou items
dterminent le niveau de support du S.I. la stratgie de lentreprise.
Lobjectif sous-jacent lalignement, cest dire :
La mesure de lalignement ou du non-alignement.
La construction de lalignement entre deux entits qui sont la base non-alignes.
Lvolution de lalignement entre deux entits : lobjectif est de rtablir
lalignement entre deux entits la base alignes mais dont lune dentre elle a
subi des volutions.
2.2.2
Alignement dans les projets ERP
Les travaux traitant de lalignement pour les projets ERP tels que (Prakash and Rolland 2001;
Darras 2004; Soffer et al. 2005; Wu et al. 2007; Tserng et al. 2010) sont des processus
itratifs didentification / construction bass sur de la confrontation de modles et de la prise
de dcision. Ils peuvent tre dfinis finement de la manire suivante :
-
Les entits entrant en jeu sont les processus souhaits de lentreprise et les processus
standards de lERP.
Ces entits sont reprsentes sous forme de modles :
un modle pour les processus souhaits : model of the enterprise requirement
(Soffer et al. 2005), customer requirements model (Prakash and Rolland 2001),
future requirements (Tserng et al. 2010), firms requirement (Wu et al. 2007),
Modle particulier de l'entreprise (Darras 2004).
17
un modle pour les processus standards : model of the ERP system capabilities
(Soffer et al. 2005), ERP system requirements model (Prakash and Rolland
2001), ERP modules(Tserng et al. 2010), capabilities of the candidates (Wu
et al. 2007), Modle de reference (Darras 2004).
-
Lobjectif est la mesure de lalignement ou du non-alignement pour ensuite construire

lalignement. Plus exactement (cf. Figure 11) :
Lalignement ou le non-alignement potentiel sont mesurs par confrontation matching - des lments de deux modles pour identifier les situations
dalignement ou de non-alignement - matches, mismatches, gaps. Une
situation dalignement est une relation dquivalence concernant un sousensemble dlments des deux modles. La confrontation consiste se demander,
pour chaque lment du premier modle, si cet lment a une quivalence dans le
second. Si cest le cas, les deux modles seront aligns pour cet lment. Une
situation dalignement est identifie. Par exemple, cest le cas si llment
activit X existe dans les deux modles. Le jugement de cette quivalence
repose gnralement sur celui de lexpert du domaine considr. Ainsi, par
exemple, il va estimer que le terme grer est quivalent au terme traiter .
Lalignement est construit - aligning - pour une situation de non-alignement par
la prise de dcision. Prenons lexemple de lactivit Z. Comme le montre la Figure
11, elle nexiste que dans le premier modle. La dcision sera soit daligner le
second modle au premier modle en conservant lactivit Z, soit daligner le
premier modle au second modle en abandonnant lactivit Z.
Modle 1
Situation
dalignement
Activit Y
Activit X
Modle 2
Activit Y
Activit X
Activit M
Activit w
lment
Activit Z
Pas dquivalence
Situation de nonalignement
Figure 11- Schmatisation des situations dalignement et de non-alignement
Par ailleurs, nous faisons les deux hypothses suivantes :

-
Le modle des processus souhaits de lentreprise est juste et cohrent, c'est--dire que les
besoins qui ont t spcifis reprsentent les besoins rels et que le modle construit ne
contient pas dincohrences. Un modle cohrent est un modle qui prsente des parties
en rapport logique et en harmonie. Ainsi, toutes les parties se tiennent et sorganisent
logiquement (Dictionnaire Larousse). En dautres termes, il ny a pas de contradictions.
Le modle des processus standards de lERP est galement cohrent.
18
Nous considrons le non-alignement comme tant un rsultat indsirable auquel nous ne

voulons pas aboutir lissue de ltape de mise en production. Ce rsultat indsirable est
directement li lobjectif des bnfices attendus du projet ERP. Sous cet angle, le non
alignement peut tre gr comme un risque.
2.3
Problmatique du Risque de Non-Alignement
Afin de dfinir le risque de non-alignement, nous avons fait une revue de littrature de la
notion de risque. Le Tableau 1 rsume les dfinitions du risque trouves dans la littrature
ainsi que leurs origines, risque dans les projets, risque dans les projets S.I.
Courant de
dfinition
Probabilit sur
loccurrence de
lvnement
Auteur
(Bernard et al. 2002a;
Bernard et al. 2002b)
(AFNOR FD X50 - 117

2003)
(Gourc 2006)
Probabilit sur
loccurrence du
rsultat indsirable
(Boehm 1991)
(AFITEP/ AFNOR
1996) reprise par
(Courtot 1998; Morley
2001)
Dfinition
La probabilit doccurrence dun
vnement et de limpact de cet
vnement ce qui met en pril la
ralisation dun objectif
Un vnement dont lapparition
n'est pas certaine et dont la
manifestation est susceptible
d'affecter les objectifs du projet
La possibilit que survienne un
vnement dont loccurrence
entranerait des consquences
(positives ou ngatives) sur le
droulement de l'activit du
projet
La probabilit dun rsultat
indsirable associ la perte si ce
rsultat est non atteint
La possibilit que le projet ne
sexcute pas conformment aux
prvisions de date dachvement,
de cot et de spcifications, ces
carts par rapport aux prvisions
tant considrs comme
difficilement acceptables voir
inacceptables
Origine de la
dfinition
Risque dans les
projets S.I.
Risque dans les

projets
Risque dans les

projets
Risque dans les

projets S.I.
Risque dans les
projets
Tableau 1- Dfinition de la notion de risque dans la littrature
Deux courants de dfinitions de la notion de risque simposent dans la littrature (cf. Tableau
1) :
-
Le premier place le risque au niveau de la probabilit doccurrence dun vnement. Ce

courant sintresse galement la consquence de lvnement sil a lieu. Elle correspond
un objectif fix qui ne serait pas atteint. Dans le cadre dun projet, il sagit des objectifs
de cots, de dlais et de spcifications ou de bnfices attendus par le (Panorama
Consulting Group 2012a).
19
Le second
indsirable.
satisfaction
dfinitions.
indsirable.
place le risque au niveau de la probabilit doccurrence dun rsultat

Dans le cadre dun projet, le rsultat indsirable correspond la nondun objectif - les mmes objectifs que ceux du premier courant de
Ce courant sintresse galement la notion de perte associe au rsultat
Ces deux courants sappuient sur la notion commune d objectif . Dans le premier, la
probabilit porte sur lvnement qui a pour consquence un objectif non atteint. Dans le
second, la probabilit porte sur la non-atteinte de cet objectif . Comme le non-alignement
est un rsultat indsirable qui est li lobjectif des bnfices attendus du projet ERP, nous
dfinissons le Risque de Non-Alignement en nous calquant sur le second courant.
Le Risque de Non-Alignement - RNA - est la probabilit du non-alignement associe la
perte du non-alignement sil a lieu. Il sagit de la probabilit que les processus mis sous
contrle de lERP ne soient pas aligns aux besoins rels de lentreprise vis--vis de ces
processus, associe la perte du non-alignement sil a lieu.
Le RNA peut tre dfini plus prcisment selon les deux dimensions dun risque proposes
par (Gourc 2006), savoir :
-
L occurrence dun risque, cest--dire loccurrence du rsultat indsirable associ au

risque ; correspondant, dans nos travaux, au non-alignement. Les conditions de la
survenue - ou de loccurrence - du rsultat indsirable correspondent aux conditions du
projet. Ces conditions peuvent tre favorables ou non cette survenue. Si cest le cas, il y
a une chance que le rsultat indsirable survienne. Dans ce cas, la probabilit associe
son occurrence est positive.
L effet dun risque, cest--dire leffet du rsultat indsirable associ au risque ; qui
correspond, ici, limpact du rsultat indsirable pour lentreprise. Cet impact est la perte
de performance pour lentreprise.
Ces deux dimensions peuvent tre reprsentes selon deux plans orthogonaux (cf. Figure 12) :
-
lespace doccurrence : reprsentant lvnement cause, lvnement perturbateur

influenant le rsultat indsirable et lvnement consquence,
lespace des effets : reprsentant lvnement perturbateur, le rsultat indsirable et
limpact du rsultat indsirable.
Lvnement perturbateur qui induit le rsultat indsirable li au RNA est la prise de

mauvaises dcisions ou la non-prise de dcision face aux situations de non-alignement entre
les processus standards de lERP et les processus souhaits par lentreprise. Par mauvaise
dcision , nous entendons : prendre des dcisions inconsciemment ou ne pas les prendre en
toute connaissance de cause et de consquence.
Les vnements sont inscrits dans une chane de causalit. Lvnement consistant choisir
de mettre en place un ERP implique de mettre en place une gestion de projet. Des vnements
lis aux activits mme du projet ou ceux lis au contexte de lentreprise peuvent tre des
vnements causes, eux-mmes source de lvnement perturbateur associ au RNA
20
(cf. Figure 12, espace doccurrence du RNA). Ainsi, par exemple, lentreprise va choisir des
consultants. Sils sont incomptents, ils pourraient mal modliser ou mal comprendre les
besoins rels de lentreprise. Les dcisions ne seraient donc pas prises correctement.
Cet vnement perturbateur va entraner un rsultat indsirable - le non-alignement - qui aura
comme impact une perte de performance pour lentreprise (voir la Figure 12, espace des effets
Espace des effets

Impact
Perte de performance
de lentreprise
Rsultat indsirable
Non-alignement
vnement
Choix de
mettre en
place un ERP
vnement cause
vnements lis la
manire dont le
projet est gr et au
contexte du projet et
de lentreprise
Espace doccurrence
vnement
perturbateur
Prendre
mauvaises
Prise dedemauvaises
dcisions
ne pasde
dcisions
ouou
absence
prendre
de
dcisions
dcisions face aux
face
aux situations
situations
de non-de
non-alignement
alignement
vnement
consquence
Gestion du nonalignement observ
en phase de postimplantation
du RNA).
Figure 12- Espace doccurrence et des effets du RNA, inspir des travaux de (Gourc 2006)
Dans ce mmoire, nous allons donc nous attacher rpondre la problmatique scientifique
suivante : comment traiter le Risque de Non-Alignement au cours de ltape dadquation du
projet ERP ?
Contexte de la recherche
Cette thse a t finance par la Rgion Alsace dans le cadre dune Bourse de Valorisation.
Cela nous a permis de mener une dmarche recherche / action avec une PME alsacienne.
3.1
PME et ERP
Lessor du march des ERP touche particulirement les PME ayant moins de 250 salaris
(recommandation du 6 mai 2003 de lUnion Europenne). En effet, selon les tableaux de bord
21
du Ministre de lconomie, des Finances et de lIndustrie sur lintgration des TIC4 dans les
entreprises en France : lutilisation des ERP au sein des PME est croissante. Elle est passe de
9% en 2009 11% en 2010 pour les petites entreprises - entre 10 et 49 salaris ; et de
31,5% 36% pour les moyennes entreprises - de 50 250 salaris. Alors que
paralllement elle a baiss de 63 48% au sein des grandes entreprises de plus de 250
salaris. De mme, (Tomas and Gal 2011) soulignaient le dplacement du centre de gravit
des projets de dploiement dERP des grands groupes internationaux vers des entreprises de
taille petite et moyenne. Entre 2008 et 2013, le revenu tir de ces dernires reprsentera une
progression de plus de 5 points contre 2, 5 points pour les grands groupes .
Les PME sont donc de plus en plus souvent confrontes la problmatique de gestion du
risque de non-alignement et ce, dans un contexte plus difficile que celui des grandes
entreprises. En effet, les PME ont des ressources limites (Raymond et al. 1990; Torres 1997;
Buonanno et al. 2005; Blackwell et al. 2006; Halilem and St-Jean 2007). Le manque de
ressources humaines de ces entreprises les amne optimiser lutilisation de celles qui
existent dj au sein de lentreprise (Halilem and St-Jean 2007). Cependant, lentreprise na
pas ncessairement envie ou les moyens de dcharger des ressources humaines internes pour
un projet qui dure longtemps (Blackwell et al. 2006). Cela engendre les spcificits suivantes
par rapport aux grandes entreprises :
-
Le niveau de lexpertise est relativement bas. Lentreprise est amene employer des
consultants externes dans le cas o ses ressources humaines ont peu dexpertise (Halilem
and St-Jean 2007). En effet, par exemple, le personnel a souvent peu de connaissance du
concept de processus (Blackwell et al. 2006). Qui plus est, la conduite du projet est dicte
par les restrictions de cots de lentreprise (Malhotra and Temponi 2010), ce qui limite
lembauche de ces experts externes.
La prise de dcision au cours du projet est peu encadre et centralise. Le dirigeant exerce
gnralement un contrle total et final sur toutes les dcisions. Ainsi, sa personnalit, son
intuition, son exprience et ses seuls jugements influencent la prise de dcision (Legoherel
et al. 2003; Abi Azar 2005)
Le manque de maturit organisationnelle induit un manque de planification. Ainsi, les
rles et responsabilits de chacun sont souvent mal dfinis ; les personnes cls du projet
sont difficilement identifiables (Buonanno et al. 2005). De plus, les tches sont peu
spcialises et les procdures de planification et de contrle sont peu formalises (Torres
1997; Abi Azar 2005).
Compte tenu de ces spcificits, les PME requirent un encadrement fort durant leur projet.
Elles ont besoin de structuration sans ncessairement faire appel des ressources externes, qui
imposent gnralement leurs propres mthodes souvent coteuses et difficiles mettre en
uvre. Dans ce contexte, la problmatique de gestion du Risque de Non-Alignement
reprsente donc un vritable enjeu pour les PME.
http://www.industrie.gouv.fr/p3e/tableau_bord/tic/tic.php
22
3.2
Prsentation de notre partenaire industriel et de son projet ERP
Notre partenaire industriel que nous nommerons la socit X, est une entreprise familiale
franaise constitue de 110 salaris. Son chiffre daffaire annuel est de lordre de 20 millions
deuros dont environ 15% lexport. Elle fait partie dun groupe constitue de deux socits.
Lune, notre partenaire industriel, la socit X qui fabrique et commercialise des moyens
daccs en hauteur et de mise en protection des personnes. Lautre, la socit Y,
commercialise et monte ces produits. Il sagit de produits standards disponibles sur catalogue,
personnaliss constituant une personnalisation des produits standards ou encore spciaux.
Jusquen 2008, le systme informatique de la socit X tait constitu de plusieurs briques
applicatives dont certaines interfaces :
-
LERP INFOR pour la gestion commerciale, la gestion de production, la gestion des

achats et des approvisionnements, la gestion du stock et la gestion des expditions.
Un logiciel conu par linformaticien de lentreprise pour le Service Aprs-Vente - SAV,
mais non interfac avec les autres logiciels.
Le logiciel Harmonie Finances pour la comptabilit et la finance - saisie virement et
rglement clients.
Le logiciel Mister Maint pour la maintenance.
Les logiciels Autocad et Solidworks pour les plans du bureau dtude.
Les raisons suivantes ont conduit lentreprise, fin 2008, remplacer une partie du systme
informatique par lERP SAGE X3 :
-
Des interfaces entre briques applicatives peu efficaces et compliquant la communication

interservices : par exemple, les commerciaux navaient pas de visibilit sur le paiement
des factures par les clients,
Arrt de la maintenance dINFOR d son anciennet,
Volont daccrotre la comptitivit de lentreprise.
Plus prcisment, en mettant en place de SAGE X3, lentreprise souhaitait diminuer le

nombre de briques applicatives en mettant sous contrle du mme systme les modules SAV,
comptabilit, finance et maintenance. De plus, la mise en place de ce progiciel lui permettait
damliorer lexistant de certains modules :
-
Au niveau de la gestion commerciale, INFOR ne permettait pas la classification et la

slection des clients, la vrification de leur solvabilit ou la gestion des relances.
Au niveau de la gestion de la production, lordonnancement ntait pas support et aucun
indicateur nexistait pour valuer lefficacit de la production.
La gestion des stocks tait incorrecte.
Au niveau de la gestion de lexpdition, certains besoins comme les regroupements
ntaient pas supports.
Avec ce projet, la socit X souhaitait augmenter son chiffre daffaire par lamlioration de la
relation client et la possibilit dindustrialiser et de promouvoir rapidement de nouveaux
23
produits ; elle dsirait galement augmenter sa marge bnficiaire par la rduction des cots
dachat et des dlais de livraison.
Le droulement de son projet ERP a t le suivant (cf. Figure 13) : la phase de primplantation a t initie en avril 2008 permettant la dfinition des objectifs stratgiques et
des besoins ainsi que la slection du progiciel pour aboutir au lancement du projet ERP en
janvier 2009. La phase dadquation a pris place de fvrier juin 2009. Lintgration et les
tests ainsi que la mise en production se sont faits en trois lots dfinis par domaine fonctionnel
- 1 : commercial, comptabilit, finance, achats, stocks et expditions ; 2 : production ; 3 :
maintenance et SAV. Depuis avril 2011, la phase de post-implantation des diffrents
domaines est en cours, sauf pour les modules SAV et de maintenance.
Av.
08
Fev. Ju.
09 09
Janv.
11
Fev.
11
Mars
11
Av.
11
Juill.
11
Aout
11
Sept.
11
Oct.
11
Auj
commercial, comptabilit, finance, achats, stocks et expdition
Adquation
Pr-implantation
Intgration et tests
Mise en
production
Post-implantation
production
Intgration et tests
Mise en
production
Postimplantation
maintenance, SAV
Intgration
et tests
Figure 13- Droulement du projet ERP de la socit X
Lquipe projet a vari au cours des phases du projet :

-
Pour la phase de pr-implantation, lquipe tait constitue de deux membres internes - le

PDG et linformaticien - et de deux membres externes - un consultant et un tudiant en
5me anne de cycle de formation dingnieurs faisant son projet de fin dtude dans la
socit X.
Pour les phases dimplantation et de post-implantation, lquipe tait constitue denviron
8 9 membres :
5 membres internes lentreprise : le PDG, linformaticien et environ 2 3
utilisateurs cls - en fonction des modules traits.
3 ou 4 membres externes lentreprise : 2 intgrateurs, 1 tudiant en cycle de
formation dingnieur et 1 consultant externe. Ces deux derniers ont t prsents
par intermittence : pour ltude dadquation, la socit X na fait appel qu un
tudiant en formation ; il en tait de mme pour la fin de la phase dimplantation
et celle de post-implantation du lot 2, avec, cependant, lintervention irrgulire
24
dun consultant externe ; pour le lot 1, lentreprise na fait appel qu un

consultant externe.
3.3
Dmarche de recherche / action
Dans le cadre de nos travaux, nous avons suivi le projet ERP de la socit X raison dun
jour par semaine partir de mai 2009. Ainsi, nous avons adopt la mthodologie de
recherche / action o terrain et recherche thorique viennent senrichir mutuellement.
Celle-ci est dcrite par (Kimmis and McTaggart 1988) et (Lavoie et al. 1996) et illustre dans
la Figure 14. Elle consiste appliquer en boucle autant de fois que ncessaire le cycle
suivant :
-
Planification,
Action et observation,
Rflexion.
Ds la seconde application de cycle, la planification devient la planification rvise.
Figure 14- La spirale de la recherche / action issue des travaux de (Kimmis and McTaggart 1988) dans
(Lavoie et al. 1996)
Outre limportance de la gestion de lalignement dans les PME, notre intrt pour les petites
et moyennes entreprises est aussi mthodologique dans la mesure o certaines pratiques
stratgiques sont plus lisibles que dans les grandes entreprises o tout est dilu (Torres
1997). La dimension dune PME fait que les phnomnes y sont plus facilement identifiables,
plus lisibles. La recherche en PME permet de faire apparatre concrtement, visiblement aux
25
yeux de l'observateur, ce qui est cach, difficile saisir et interprter dans les organisations
de grande dimension (Torres 1997).
Linstanciation de la spirale de recherche / action nos travaux, qui nous a inspir dans
lorganisation de cette thse, est donne en Figure 15. Elle est constitue de deux cycles de
planification / action et observation / rflexion. Le premier a permis daffiner la
problmatique et de mettre en place les contributions. Le second a permis de mettre les
contributions l'preuve du terrain.
Le premier cycle a t excut avant et pendant la premire anne de thse. Cela
correspondait, pour la socit X, ltape dadquation pour lensemble des modules, et
ltape dintgration et tests des modules de gestion commerciale, comptabilit, finance,
achats, ventes, gestion des stocks et expdition.
Comment le traiter le risque de nonalignement?

Chapitre 3
Manques dans la littrature
scientifique par rapport la
ralit terrain.
tre lintermdiaire entre

les intgrateurs et les
membres de lentreprise.
Aider au paramtrage et
aux tests.
Chapitre 6
Analyser les deltas entre
lapplication des
propositions et la ralit.
Appliquer a posteriori la mthode Model
Driven - ERP Alignment sur le module
SAV et lapproche Risk-Factor - ERP
Alignment deux priodes diffrentes du
projet ERP de la socit X.
Observer la manire dont

le partenaire industriel
traite le Risque de NonAlignement
Comparer pratique terrain
et littrature scientifique
et analyser la littrature
scientifique.
Chapitres 4 et 5
Traiter le Risque de NonAlignement en utilisant
les stratgies anticipatives
complmentaires agissant
sur leffet et sur
loccurrence du risque.
Figure 15- Instanciation de la dmarche recherche / action nos travaux de thse
Durant ce cycle :
-
Nous avons planifi la comprhension du mode de gestion du RNA par lentreprise mais
aussi sa comparaison la littrature scientifique.
Nos actions et nos observations, durant le premier cycle, ont t assez importantes, nous
nous sommes positionns comme lintermdiaire entre les intgrateurs et les membres
internes du projet et nous avons aid au paramtrage et aux tests. Cela a consist :
26
comprendre les lments ncessaires aux intgrateurs pour le paramtrage de

lERP ;
aider les membres de lentreprise fournir ces lments ;
assister aux runions de tests et comprendre les problmes rencontrs lors des
tests. Ces problmes venaient de la manire dont ltape dadquation avait t
gre.
Enfin, cela a servi de base notre rflexion : nous avons pu prendre conscience de la
ralit du terrain et la comparer la littrature scientifique.
Le second cycle a t excut pendant les deuxime et troisime annes de la thse :

-
Nous avons planifi la proposition de deux stratgies doptimisation anticipative pour le

traitement du RNA : lune agissant sur leffet de ce risque et lautre agissant sur son
occurrence.
Au sein de lentreprise, nos actions et observations ont t les suivantes :
Appliquer a posteriori au module SAV la mthode Model Driven - ERP
Alignment pour agir sur les effets du RNA ;
Appliquer a posteriori deux priodes diffrentes du projet ERP lapproche
Risk-Factor Driven - ERP Alignment pour agir sur loccurrence du RNA ;
Rendre compte de nos observations lentreprise.
Notre rflexion, suite ces actions, nous a men constater loccurrence du RNA pour le
projet de la socit X qui aurait pu tre vit par lapplication des deux contributions que
nous proposons.
27
28
Chapitre 3 Etat de lart pour le traitement du Risque de Non-Alignement
Chapitre 3 Etat de lart pour le

traitement du Risque de NonAlignement (RNA)
La problmatique scientifique de Risque de Non-Alignement nous amne tudier les travaux
raliss sur le management des risques dans les projets. Cette problmatique a t largement
traite et les dfinitions sont normalises :
-
Le management des risques dun projet correspond au processus dapplication de la

politique de lorganisme permettant la mise en uvre itrative et continue de lanalyse et
de la gestion des risques dun projet (AFNOR FD X50 - 117 2003).
La gestion des risques est, quant elle, dfinie comme le processus de (1) traitement, (2)
suivi, et (3) contrle, mmorisation des risques et des actions entreprises pour les traiter
(AFNOR FD X50 - 117 2003).
Pour le RNA, nous nous intressons ltape de traitement cest--dire au processus de

slection et de mise en uvre des mesures visant modifier le risque (ISO/IEC Guide
73:2002 (E/F) 2002).
Les mesures de traitement peuvent inclure le refus du risque, son optimisation, son transfert
ou sa prise de risque (ISO/IEC Guide 73:2002 (E/F) 2002). Dautres auteurs tels que
(Boehm 1991; Courtot 1998; Baccarini et al. 2004; Gourc 2006) proposent ces mmes
mesures. Une mesure peut agir sur les dimensions doccurrence et / ou deffet du risque (cf.
section 2.3 du chapitre 2).
-
Ainsi, le refus du risque correspond la dcision visant ne pas tre impliqu dans une
situation risque, ou se retirer dune situation risque (ISO/IEC Guide 73:2002 (E/F)
2002). Il sagit de se mettre dans de bonnes conditions en agissant sur loccurrence du
rsultat indsirable pour ne pas observer la probabilit lie celui-ci ou pour ne plus
observer cette probabilit.
Loptimisation du risque correspond au processus visant, pour un risque, minimiser les
consquences ngatives [...] et la probabilit associe (ISO/IEC Guide 73:2002 (E/F)
2002). Dans nos travaux, les consquences ngatives correspondent au rsultat indsirable
associ son effet. La probabilit est celle porte par loccurrence du rsultat indsirable.
Le transfert du risque consiste au partage avec une autre partie de la charge de la perte
[...] dun risque (ISO/IEC Guide 73:2002 (E/F) 2002). Par exemple, lautre partie peut
tre la souscription une assurance qui va combler la perte financire (Courtot 1998).
Cest donc leffet du rsultat indsirable qui est partag.
La prise de risque consiste en l acceptation de la charge dune perte [...] dun risque
(ISO/IEC Guide 73:2002 (E/F) 2002). Leffet du rsultat indsirable est accept.
29
Outre son effet sur lune des dimensions du risque (cf. Figure 16), une mesure peut tre mise
en uvre avant ou aprs loccurrence du rsultat indsirable. En effet, selon (Gourc 2006), le
projet est planifi pour suivre une trajectoire et loccurrence du rsultat indsirable signifie
que la trajectoire est dvie de cette trajectoire de rfrence. Dans ce cas, lobjectif
initialement dfini, dans notre cas lalignement, nest pas atteint. Avant cette occurrence, le
risque peut exister ou non. Lorsquil existe, la probabilit doccurrence est positive, sinon,
celle-ci est nulle. Ainsi, les mesures peuvent tre appliques de manire :
-
Pr-anticipative : lorsque la probabilit de loccurrence du rsultat indsirable est nulle,

Anticipatives (Chapman 1997; Gourc 2006; Ho et al. 2009) : avant loccurrence du
rsultat indsirable mais lorsque la probabilit de loccurrence du rsultat indsirable est
positive,
Correctives (Chapman 1997; Gourc 2006) : aprs loccurrence du rsultat indsirable.
Une stratgie de traitement correspond la mise en place dune mesure agissant sur une des
deux dimensions du risque un instant donn par rapport la probabilit doccurrence (cf.
Figure 16).
Pranticipatives
Anticipatives
Correctives
Refus
Occurrence
Refus
Optimisation
Optimisation
Effet
Transfert
Optimisation
Prise de risque
Transfert
Transfert
Trajectoire modifie
P=0
= Objectif non atteint

= Non-alignement
P>0
Trajectoire de rfrence
planifie (telle que souhaite)
occurrence du rsultat indsirable
Figure 16- Stratgies de traitement du risque en fonction de la dimension et de linstant
Pour le RNA, il sagit de dfinir les stratgies les plus pertinentes :

-
Concernant linstant de mise en uvre, les stratgies ne peuvent tre quanticipatives :

En effet, lERP est un progiciel qui, par nature, ne recouvre pas totalement les
besoins rels dune entreprise particulire. Lorsque la phase dimplantation
dbute, la probabilit de loccurrence du rsultat indsirable associ au RNA est
positive. La mise en uvre pr-anticipative des mesures nest donc pas possible.
De plus, nous ne voulons pas agir de manire corrective, c'est--dire lorsque le
non-alignement survient.
Parmi les mesures anticipatives, nous nallons pas adopter celle de prise de risque
car le non-alignement nest pas acceptable. Le transfert du risque na pas de sens
30
ici. Nous ne pouvons pas refuser le risque car celui-ci existe de manire
intrinsque au cours dun projet ERP.
Concernant les dimensions du risque sur lesquelles agir, les stratgies mettre en uvre
doivent agir tant sur loccurrence que sur leffet.
Ainsi, nous allons optimiser le risque de manire anticipative en agissant sur son
occurrence et sur son effet (cf. les stratgies entoures dans la Figure 16). En dautres termes,
il sagit de minimiser les consquences ngatives et leur probabilit doccurrence.
La mise en uvre de ces stratgies anticipatives passe par la matrise de lespace des effets et
de lespace de loccurrence. Pour le premier, il sagit daider les dcideurs avoir le contrle
sur le rsultat indsirable et son effet cest--dire la perte de performance pour lentreprise
associe ce rsultat indsirable. Les mthodes dingnierie dirige par les modles
permettent dy parvenir : (i) en identifiant le non-alignement potentiel par la confrontation des
modles des fonctionnalits standards et des besoins rels ; (ii) en valuant leffet du nonalignement ; (iii) et en construisant le modle des processus mettre sous contrle de lERP.
Pour lespace doccurrence du RNA, il sagit de se concentrer sur les vnements causes car
ils sont lorigine de lvnement perturbateur qui va induire le non-alignement. Le
management des facteurs de risque qui influencent ces vnements causes en appliquant des
pratiques de gestion permet dy parvenir.
Dans la suite de ce chapitre, nous prsentons un tat de lart des mthodes dingnierie dirige
par les modles (section 1) et des moyens permettant le management des facteurs de risques
(section 2).
Mthodes dingnierie dirige par les modles
Le concept de processus dentreprise qui est un concept cl dans ces mthodes dingnierie
est dabord dfini (2.1). Puis nous enchanons sur la prsentation des mthodes (2.2), et sur
leur analyse (2.3).
1.1
Processus dentreprise
Un processus dentreprise est une suite coordonne dactivits destine produire un rsultat
final souhait (ISO/DIS 19440 2004). Il peut tre modlis selon diffrentes dimensions.
Nous les dcrivons en nous basant sur :
-
Le cadre de modlisation et les construits de modlisation fournis par les normes ISO
19439 et 19440 (2.1.1),
Les travaux dingnierie des besoins pour dfinir la vue intentionnelle (2.1.2),
Les interdpendances qui existent entre les processus dune entreprise (2.1.3).
31
1.1.1
Dfinition selon le cadre de modlisation ISO 19439
Le cadre de modlisation dentreprise (ISO 19439 2006) dfinit et spcifie les concepts
gnriques ncessaires la cration de modles dentreprise. Les trois dimensions suivantes y
sont dfinies (cf. Figure 17) :
-
Phases du cycle de vie qui permet de progresser de la cration dune entit jusqu sa
fin de vie.
Niveaux de gnricit qui permet daller des concepts particuliers aux concepts plus
gnraux.
Vues de modlisation reprsentant une perception slective dun modle dentreprise,
soulignant certains aspects particuliers de lentreprise.
Figure 17- Dimensions de la norme (ISO 19439 2006)
1.1.1.1
Phases du cycle de vie
La dimension du cycle de vie dcrit les phases du cycle de vie dun modle dentreprise. Il
sagit du processus de dveloppement dun modle depuis sa cration, en passant par sa mise
en uvre jusqu sa fin de vie. Le cycle de vie de la norme comporte sept phases :
-
La dfinition du domaine (domain identification) permet didentifier le domaine

dentreprise qui doit tre modlis en termes dobjectifs, ses entres / sorties, leurs
destinations et origines respectives et les fonctionnalits et capacits basiques du
domaine .
La dfinition des concepts (concept definition) permet de dfinir les concepts
dentreprise qui facilitent la ralisation des objectifs de lentreprise .
La dfinition des besoins (requirements definition) permet de dfinir les
fonctionnalits dun domaine de lentreprise en termes de processus, activits, entres /
sorties, capacits requises .
32
La spcification de la conception (design specification) permet de spcifier la

manire dtaille dont les besoins du domaine seront satisfaits . Ceci inclut
lidentification des technologies ncessaires.
La description de limplantation (implementation description) permet de dcrire tout
ce qui est ncessaire la ralisation des tches par le systme oprationnel du domaine .
Lutilisation des modles (domain operation) constitue lutilisation oprationnelle du
modle .
La fin de vie des modles (decommission definition) permet de dfinir ltat final de
fin de vie du systme oprationnel pour un domaine particulier de lentreprise .
1.1.1.2
Niveaux de gnricit
La norme propose trois niveaux de gnricit :

-
Le niveau gnrique correspond une collection de construits de langages de

modlisation gnriques . Ce niveau est utilis pour gnrer les modles des deux autres
niveaux.
Le niveau partiel correspond une spcialisation du modle gnrique selon une
typologie dentreprises c'est--dire selon son secteur dactivits - de services ou encore
de production de biens.
Le niveau particulier correspond au modle particulier et spcifique du domaine dune
entreprise .
1.1.1.3
Vues de modlisation
La dimension des vues de modlisation permet lobservation du monde rel en mettant

laccent sur les aspects pertinents en regard du contexte et des objectifs particuliers de
modlisation. La norme (ISO 19439 2006) dfinit quatre vues de modlisation (fonctionnelle,
informationnelle, de ressources et organisationnelle). Celles-ci peuvent tre compltes par
des vues supplmentaires selon les besoins du modlisateur.
La vue fonctionnelle permet la reprsentation et la modification des processus dune
entreprise, plus exactement lenchanement des activits qui composent le processus ainsi que
ses entres et sorties . Cette vue est caractrise par les construits domaine, processus
dentreprise, activit dentreprise et vnement (ISO/DIS 19440 2004), dfinis dans le
Tableau 2.
Construits de
la vue
fonctionnelle
domaine
processus
dentreprise
activit
dentreprise
vnement
Dfinition (ISO/DIS 19440 2004)
une partie de lentreprise [...] pour laquelle un modle dentreprise doit tre cr
une suite coordonne dactivits dentreprise qui peuvent tre excutes pour
atteindre un rsultat final souhait
une tape excute dans une entreprise qui consomme des entres et alloue du
temps et des ressources pour produire des sorties .
un fait sollicit ou non indiquant un changement dtat dans lentreprise ou dans
son environnement
Tableau 2- Dfinition des construits de la vue fonctionnelle (ISO/DIS 19440 2004)
33
La vue informationnelle permet la reprsentation et la modification de linformation dune

entreprise telle quidentifie dans la vue fonctionnelle . Elle est caractrise par les construits
objet dentreprise et vue dobjet. Un objet dentreprise peut tre spcialis en produit,
commande, march ou rapport (ISO/DIS 19440 2004), dfinis dans le Tableau 3.
Construits de la
vue
informationnelle

un lment dinformation dans le domaine de lentreprise [...] dont les
caractristiques sont ncessaires la modlisation . A ce niveau de modlisation,
il sagit dune description des caractristiques cest--dire des attributs.
toutes les tapes intermdiaires du cycle de vie du produit - exemple : le stock
mini, les rgles de regroupement, le lot conomique, la nomenclature dun
produit, etc.
ce qui doit tre fait, quels produits doivent tre produits, quelles ressources
doivent tre utilises et quels achats doivent tre raliss (exemple : ordre
dachat, ordre de fabrication, bon de commande).
une information telle que le client ou encore le fournisseur.
une information telle que le rapport de cot.
ltat dun objet dentreprise un instant donn, cest dire la valeur que prend
lensemble des attributs cet instant pour un but particulier et dans une activit
particulire en entre ou sortie. Cest une vue partielle dun objet dentreprise.
objet
dentreprise
produit
commande
march
rapport
vue dobjet
Tableau 3- Dfinition des construits de la vue informationnelle (ISO/DIS 19440 2004)
La vue de ressources permet la reprsentation et la modification des ressources dune

entreprise . Cette vue est caractrise par les construits ressource et sa spcialisation en entit
fonctionnelle (ISO/DIS 19440 2004), dfinis dans le Tableau 4.
Construits de la
vue de
ressources
ressource
entit
fonctionnelle

spcialisation dun objet dentreprise qui porte tout ou partie des capacits
requises pour lexcution de lactivit dune entreprise .
spcialisation du construit ressource, un ensemble de ressources qui rassemble
un ensemble de capacits capable, lui seul, de supporter une fonction .
Tableau 4- Dfinition des construits de la vue de ressources (ISO/DIS 19440 2004)
Ces construits permettent de classifier et dcrire toute aide matrielle et informationnelle

dune entreprise telle que les quipements, outils et infrastructures de production, les
personnes et groupes organisationnels, les quipements pour le traitement des donnes, les
documents et fichiers requise pour excuter, permettre ou supporter les activits de
lentreprise. Ainsi, il y a trois types de ressource les ressources machine, acteur ou
application. Celles-ci peuvent avoir des rles diffrents cest--dire diffrentes fonctions
typiques. Ainsi, le rle dune mme ressource peut diffrer au cours du temps et de son cycle
de vie. Cela est particulirement vrai pour les ressources acteur, dont la norme (ISO/DIS
19440 2004) dfinit deux types de rle. Le rle organisationnel, reprsent par le construit
34
unit organisationnelle, est relatif la dfinition des diffrentes responsabilits et

comptences. Le rle oprationnel, quant lui reprsent par le construit entit fonctionnelle,
identifie les capacits oprationnelles et les fait correspondre celles ncessaires aux tches
oprationnelles assignes aux acteurs.
La vue organisationnelle permet la reprsentation et la modification de la structure
organisationnelle et dcisionnelle dune entreprise ainsi que des responsabilits et autorits
des personnes et units organisationnelles au sein de lentreprise . Cette vue est caractrise
par les construits capacit et unit organisationnelle (ISO/DIS 19440 2004), dfinis dans le
Tableau 5.
Construits de la
vue
organisationnelle
capacit
une qualit porte par une ressource et ncessaire la ralisation dune tche
fait partie de la structure formelle, hirarchique et administrative dune
unit
entreprise . Elle reprsente un groupement dorganisations qui sont relies par
organisationnelle des tches spcifiant les diffrents travaux et responsabilits travers une partie
de lentreprise
Tableau 5- Dfinition des construits de la vue organisationnelle (ISO/DIS 19440 2004)
1.1.2
Dfinition de la vue intentionnelle
Les travaux dingnierie des besoins tels que (Dardenne et al. 1993; Anton 1996; Kavakli and
Loucopoulos 2003; Matuleviius and Heymans 2007; Engelsman et al. 2010) abordent le
concept de but. Ce concept joue un rle important dans la modlisation des besoins dans un
projet S.I. (Rolland and Salinesi 2005) puisque son utilisation facilite llicitation les besoins
des membres dun projet. Il permet aussi de supporter les ngociations entre les diffrents
membres du projet.
La modlisation des buts amliore la qualit des besoins licits. Elle permet de modliser les
diffrentes alternatives fonctionnelles sous contrle dun systme et dassurer lexhaustivit
des besoins (Rolland and Salinesi 2005). Cela est intressant dans le cas des ERP qui offrent
plusieurs alternatives pouvant convenir un ensemble dentreprises dun mme secteur
dactivit mais ayant des modes de gestion diffrents.
De ce fait, nous ajoutons une vue supplmentaire aux 4 vues de la norme (ISO 19439 2006).
La vue intentionnelle permet la reprsentation et la modification des buts ports par chaque
processus dentreprise dun domaine de lentreprise.
1.1.2.1
Concept de but
Plusieurs dfinitions du concept de but sont proposes dans la littrature :

-
A goal is an objective the system under consideration should achieve. Goal formulations
thus refer to intended properties to be ensured; they are optative statements as opposed to
indicative ones, and bounded by the subject matter. (Van Lamsweerde 2001). Ce que
35
nous traduisons en : un but est un objectif que le systme considr devrait atteindre.
Les formulations de but se rfrent des proprits destines tre assures ; il sagit de
formulations optatives et non indicatives dlimites par lobjet tudi. .
A goal is a nonoperational objective to be achieved by the composite system.
Nonoperational means that the objective is not formulated in terms of objects and actions
available to some agent in the system; in other words, a goal as it is formulated cannot be
established through appropriate state transitions under control of one of the agents.
(Dardenne et al. 1993). Ce que nous traduisons en : un but est un objectif non
oprationnel atteindre par le systme composite. Non oprationnel signifie que le
but nest pas formul en termes dobjets et dactions disposition dun agent dans le
systme ; en dautres termes, un but tel quil est formul ne peut pas tre tabli grce des
transitions appropries dtat sous contrle de lun des agents. . Selon (Dardenne et al.
1993), les buts sont oprationnalisables travers leur raffinement et les contraintes
correspondantes.
Nous retenons de ces dfinitions quun but est :

-
un objectif ncessaire atteindre par le systme considr et non une simple indication ;
non oprationnel cest--dire quil ne peut tre tabli travers des transitions dtat
dobjets mis la disposition dun agent dans le systme ;
oprationnalisable travers son raffinement et les contraintes correspondantes.
Plusieurs classifications de buts sont proposes dans la littrature. Chacune a ses propres
objectifs. Nous les prsentons dans le Tableau 6.
Un but peut faire lobjet de plusieurs classifications : ainsi, par exemple la performance ou
encore linteroprabilit des systmes dune entreprise sont mesurables travers des
techniques de vrification : ce sont donc des buts non fonctionnels mais galement des hard
goals.
Dans le cadre des projets ERP, nous souhaitons modliser les buts ports par les processus
souhaits par lentreprise, ou encore les buts ports par les fonctionnalits de lERP. Ainsi,
nous nous intressons tous les buts fonctionnels, parmi lesquels les buts de bas niveau,
formuls avec une dimension technique. En effet, tout but fonctionnel nest pas forcment de
bas niveau. Par exemple, inscription des tudiants satisfaite est un but fonctionnel. Sil est
formul avec une dimension technique comme par exemple : inscription des tudiants
satisfaite avec un maximum de 100 inscriptions par jour , il sagira dun but fonctionnel de
bas niveau. La formulation des buts de haut niveau et des buts non fonctionnels est considre
comme un pralable la formulation des buts fonctionnels en ingnierie des besoins. En effet,
cela permet de se concentrer sur les besoins essentiels de lentreprise. Par exemple, si le but
non fonctionnel interoprabilit ou encore celui de haut niveau plus de passagers
servis ont t formuls, il est possible ensuite de formuler les buts fonctionnels qui leur sont
lis.
La classification des buts selon les classes achieve goals, cease goals, maintain goals et avoid
goals est intressante car elle permet de prciser les buts fonctionnels.
36
Enfin, nous ne nous intressons pas, dans le cadre de cette thse, la classification hard
goals / soft goals, car nous navons pas pour objectif de mesurer si le but a t atteint ou pas.
Rfrences
(Van
Lamsweerde
2001)
Objectif de la
classification
Distinction
entre les buts
spcifiant un
fonctionnement
vs. une qualit
attendue du
systme
Distinction
entre les buts
avec une
dimension
technique vs.
sans dimension
technique
Classe
buts
fonctionnels
Concernent les services attendus du systme

commande client traite
buts non
fonctionnels
Concernent les qualits attendues du systme

scurit , performance , facilit
dutilisation , personnalisation ,
interoprabilit
buts de haut
niveau
buts de bas
niveau
achieve goals
(Dardenne
et al. 1993;
Rolland and
Salinesi
2005)
Affinement des
buts
fonctionnels
cease goals
maintain goals
avoid goals
(Van
Lamsweerde
2001)
Prcision entre
un but
mesurable vs.
non mesurable
Dfinition et exemples
hard goals
soft goals
Concernent les proccupations stratgiques du

systme
plus de passagers servis , service de trsorerie
en continue fourni , nombre de contrats
augment de 20%
Concernent les proccupations techniques du
systme
carte avale au bout de 3 mots de passe
errones , acclration dclenche toutes les 3
secondes
Concernent les buts dsignant un comportement
que le systme doit atteindre
achieve demand resquested traduit en ::
atteindre la demande enregistre
Concernent les buts dsignant un comportement
que le systme ne doit plus satisfaire
cease demand treated by Internet traduit en :
cesser la demande traite par internet
Concernent ce que le systme doit maintenir
maintain the demand pending traduit en :
maintenir la demande en attente
Concernent ce que le systme doit viter, cest une
restriction
avoid more than 20 demands treated traduit en :
viter plus de 20 demandes traites
Concernent les buts dont la satisfaction peut tre
tablie travers des techniques de vrification
chiffre daffaire augment de 20%
Concernent les buts dont la satisfaction nest pas
mesurable
limite de vitesse maintenue , porte maintenue
ferme pendant le dplacement du train
Tableau 6- Classifications des buts dans la littrature
1.1.2.2
Langages
Il existe plusieurs langages pour modliser les buts. Comme le souligne (Mylopoulos et al.
1999; Kavakli and Loucopoulos 2003; Engelsman et al. 2010), ils permettent de reprsenter le
concept de but de manire semi-formelle - sous la forme de graphes ou encore de manire
37
formelle - sous la forme dassertions logiques. Outre le type de modlisation, ces langages se
distinguent par leur intuitivit (capacit de mise en uvre sans connaissances pralables), leur
expressivit (capacit reprsenter la richesse du concept de but) ou encore leur lien potentiel
avec les construits de la modlisation dentreprise. La possibilit de raffiner les buts semble
primordiale pour assurer la compltude des besoins. Plusieurs raffinements existent :
-
Celui raffinant les buts de haut niveaux en buts de bas niveaux - rponse la question
pourquoi ? ;
Celui appel reduction pour (Dardenne et al. 1993) ou mean-ends pour (Engelsman
et al. 2010) - rponse la question comment ? ;
La dcomposition (Engelsman et al. 2010) qui permet de dtailler davantage un but.
Nous analysons les langages les plus rpandus savoir i* (Yu 1995), KAOS (Dardenne et al.
1993), BMM (Business Rules Group 2010) et GBRAM (Anton 1996) selon les critres dfinis
prcdemment (cf. Tableau 7).
Langages
Type de
modlisation
Intuitivit
Expressivit
Type de
raffinement
Lien avec la
modlisation
dentreprise
i* (Yu 1995)
Semi-formel
et formel
--
++
Comment ?
Pourquoi ?
Dcomposition
Non
KAOS
(Dardenne et
al. 1993)
Semi-formel
et formel
++
++
Comment ?
Pourquoi ?
Dcomposition
Oui
BMM
(Business
Rules Group
2010)
Semi-formel
+++
--
Non
GBRAM
(Anton 1996)
Semi-formel
++
Comment ?
Pourquoi ?
Dcomposition
Non
Tableau 7- Analyse des langages de modlisation de la vue intentionnelle
Tous les langages proposent de modliser les buts de manire semi-formelle.

Les qualits dintuitivit et dexpressivit sopposent. En effet, le langage i* est le plus
expressif en proposant les trois types de raffinements mais aussi en tablissant les
dpendances stratgiques entre les buts. Il semble, en contrepartie, tre le moins intuitif. En
effet, selon (Engelsman et al. 2010), il amne faire la confusion entre certains termes tels
que tches et buts . De plus, les graphes obtenus, lissue de la modlisation, sont
complexes faisant intervenir un grand nombre de liens et de buts. A linverse, BMM est le
plus intuitif mais le moins expressif, puisquil ne propose aucun raffinement. KAOS et
GBRAM sont plus quilibrs bien que le premier, dfinissant clairement les termes utiliss,
reste le plus intuitif des deux.
38
KAOS est le seul langage qui fait aisment le lien entre les buts et la modlisation
dentreprise en liant le construit activits dentreprise , travers le raffinement de certains
buts qui peuvent tre oprationnaliss en actions . En effet, the action meta-concept is
linked to object through the input / output meta-relationships and to event through the cause /
Stop meta-relationships (Dardenne et al. 1993) ; que nous traduisons en : le mta-concept
daction est li aux objets travers les mta-relations dentres / sorties et aux vnements
travers les mta-relations causes / stop . De nombreux auteurs, tels que (Leite et al. 1997;
Antn and Potts 1998; Haumer et al. 1998; Sutcliffe et al. 1998; Kaindl 2000), ont vant
lintrt de faire ce lien. En effet, les activits dentreprise et les buts se compltent lun
lautre car ces derniers doivent tre concrtiss par la modlisation de la manire de les
atteindre (Rolland and Salinesi 2005).
1.1.3
Interdpendance de processus
Nous avons vu dans la section 2.2.2 du chapitre 2 que la construction de lalignement entre
deux entits reprsentes par leurs modles ncessite daligner lun des deux modles
lautre. En dautres termes, il sagit de se calquer sur lun des deux modles en supprimant ou
modifiant, limage du modle choisi, les construits de lautre modle. Compte tenu de
linterdpendance des processus dune entreprise, la modification dun construit dun modle
peut impacter un modle dpendant. Linterdpendance des processus se dfinit par les
contraintes dexcution existantes entre les processus ainsi que par les construits que leurs
modles partagent (Attie et al. 1993; Malone and Crowston 1993; Carter et al. 2003; Chapron
2006).
Nous avons class les interdpendances de processus proposes dans (Attie et al. 1993;
Malone and Crowston 1993; Carter et al. 2003; Chapron 2006) en trois catgories :
-
Les interdpendances correspondant au partage par deux activits dun mme construit :
Partage par deux activits faisant partie de processus diffrents dune mme
ressource application ou machine : shared ressource (Malone and
Crowston 1993), partage dapplicatif (Chapron 2006).
Partage par deux activits faisant partie de processus diffrents dune mme
ressource acteur : partage dacteurs (Chapron 2006).
Partage par deux activits faisant partie de processus diffrents du mme objet
dentreprise : partage dobjets mtiers (Chapron 2006).
Partage de la mme unit organisationnelle : utilisation par deux activits
faisant partie de processus diffrents de deux acteurs distincts mais appartenant
la mme unit organisationnelle, avec une limite sur la distance qui les spare
dans lorganigramme : dpendance structurelle (Chapron 2006).
Utilisation par deux activits faisant partie de processus diffrents de deux
ressources application diffrentes avec un change de flux de donnes entre
les ressources : dpendance lie au flux de donnes (Chapron 2006).
Partage par plusieurs activits faisant partie de processus diffrents dun mme
but : task / subtasks (Malone and Crowston 1993).
39
Les interdpendances correspondant au partage du construit objet dentreprise lorsque

cet objet dentreprise constitue la fois la sortie dune activit et lentre de la deuxime
activit interdpendante. Parfois lobjet dentreprise peut saccompagner dun vnement
dclencheur de la deuxime activit. Nous retrouvons : dpendance vnementielle
(Chapron 2006), transfer (Malone and Crowston 1993), usuability (Malone and
Crowston 1993).
Les interdpendances correspondant des contraintes dexcution entre activits :
Deux activits doivent se drouler en mme temps, il sagit dune contrainte de
simultanit : simultaneity constraint (Malone and Crowston 1993).
Une activit 1 ne commence que si une activit 2 est termine, cela nimpose pas
ncessairement lexcution de lactivit 2 : prerequisite constraint (Malone and
Crowston 1993), typical trigger transition (Carter et al. 2003).
Une activit 1 ne commence que si une activit 2 a commenc : atypical trigger
transition (Carter et al. 2003).
Une activit 1 ne se termine que si une activit 2 est dj termine : non trigger
transition (Carter et al. 2003).
Si les activits 1 et 2 ont lieu alors lactivit 1 doit tre excute avant lactivit 2,
cela suppose quelles ne peuvent avoir lieu indpendamment lune de lautre :
commit dependency (Attie et al. 1993).
Si lactivit 1 avorte, lactivit 2 doit aussi avorter abord dependency (Attie et
al. 1993).
Si lactivit 1 et lactivit 2 ont eu lieu alors lactivit 3 doit avoir lieu (Attie et al.
1993).
Les deux premires catgories concernent les vues (i) de ressources - avec le construit de
ressource application , machine ou acteur , (ii) organisationnelle - avec le construit
unit organisationnelle , et (iii) informationnelle - avec le construit objet dentreprise .
La troisime catgorie fait rfrence la vue fonctionnelle notamment avec la relation
vnementielle entre les processus concernant le construit vnement .
1.1.3.1
Interdpendance de processus au niveau de la vue fonctionnelle
Concentrons-nous sur la partie du diagramme de classes relatif la vue fonctionnelle (cf.

Figure 18). Deux processus sont interdpendants au niveau de la vue fonctionnelle sils
partagent une activit. Par partage dactivit, nous entendons quune activit dun processus
dclenche une activit dun autre processus. Cela se traduit par le partage dun mme
vnement par deux activits. Comme lindique le diagramme, une activit dentreprise dun
processus peut gnrer plusieurs vnements dont ceux qui initient des activits dentreprise
faisant partie dautres processus. Pour lune, cela sera lvnement initiateur et pour lautre,
lvnement quelle gnre.
40
Figure 18- Diagramme de classes des construits de la vue fonctionnelle (norme ISO 19440)
Un vnement saccompagne gnralement dune interdpendance informationnelle entre les

deux processus qui partagent cet vnement (Malone and Crowston 1993; Chapron 2006).
1.1.3.2
Interdpendance de processus sur la vue informationnelle
Concentrons-nous sur la partie du diagramme de classes relatif la vue informationnelle (cf.

Figure 19).
Construits vue
informationnelle
Figure 19- Diagramme de classes des construits de la vue informationnelle lis au construit activit
dentreprise (norme ISO 19440)
Comme lindique le diagramme, une activit dentreprise a en entre / sortie une plusieurs
vues dobjet. De plus, une vue dobjet est lentre / sortie dune multitude dactivits. Ainsi,
une vue dobjet peut tre partage par plusieurs activits de processus diffrents. En outre,
une vue dobjet est ltat dun objet dentreprise un instant donn avec une certaine valeur
prise par ses attributs. Le partage entre activits se fait donc plus prcisment sur les valeurs
41
que prennent les attributs de la vue. Il y a, dans ce cas, interdpendance au niveau de la vue
informationnelle.
Par ailleurs, ces attributs de vue dobjet partags entre deux activits peuvent constituer la
sortie dune activit et lentre de la deuxime activit. Et dans certains cas, ce partage
dentres / sorties saccompagne dun vnement qui dclenche lactivit - interdpendance
fonctionnelle - utilisant en entre les attributs.
1.1.3.3
Interdpendance de processus sur la vue de ressources (acteur, machine ou

application)
Concentrons-nous sur la partie du diagramme de classes relatif la vue de ressources (cf.

Figure 20).
Construits vue de
ressources
Figure 20- Diagramme de classes des construits de la vue de ressources lis au construit activit
Comme lindique le diagramme, une activit dentreprise est supporte par une plusieurs
ressources. De plus, une ressource peut tre le support dune plusieurs activits. En
consquence, la ressource peut tre partage par plusieurs activits de processus diffrents.
Cela constitue linterdpendance au niveau de la vue de ressources.
1.1.3.4
Interdpendance de processus sur la vue organisationnelle
Concentrons-nous sur la partie du diagramme de classes relatif la vue organisationnelle (cf.

Figure 21)
Construits vue organisationnelle

Figure 21- Diagramme de classes des construits de la vue organisationnelle lis au construit activit
42
Nous considrons deux activits dentreprise supportes par deux ressources acteur
diffrentes. Chaque ressource acteur possde une capacit pouvant faire partie de plusieurs
units organisationnelles. Ainsi, ces ressources acteurs peuvent faire partie de la mme unit
organisationnelle. Deux activits de processus diffrents peuvent donc tre supportes par une
seule unit organisationnelle. Les processus sont alors interdpendants au niveau de la vue
organisationnelle.
1.2
Prsentation des mthodes dingnierie dirige par les modles
Les mthodes prsentes ici (cf. Tableau 8) concernent lalignement dans les projets ERP et
sont issues de travaux dingnierie des besoins et dingnierie dirige par les modles. Parmi
celles-ci, nous distinguons :
-
Les mthodes dalignement permettant lidentification de lalignement et du nonalignement par la confrontation des modles AS-WISHED, MIGHT-BE et ventuellement
AS-IS ainsi que la construction de lalignement par la modlisation du TO-BE. Il sagit
des propositions de (Prakash and Rolland 2001; Darras 2004; Soffer et al. 2005; Zoukar
2005; Tserng et al. 2010).
Les mthodes de confrontation permettant uniquement la confrontation des modles ASWISHED, MIGHT-BE et ventuellement AS-IS (Wu et al. 2007; Millet 2008).
Par unification du vocabulaire, nous avons choisi les termes suivants pour dsigner les
modles mis en uvre :
-
Le modle AS-IS correspond la reprsentation des processus existants de lentreprise.

Le modle AS-WISHED permet la reprsentation des processus souhaits par
lentreprise : ce sont ses besoins exprims.
Le modle MIGHT-BE permet la reprsentation de la solution offerte par lditeur, cest-dire les processus standard de lERP.
Le modle TO-BE reprsente les processus tels quils seront rellement implants
lissue du projet ERP.
Les mthodes tudies prconisent lapplication dun processus de confrontation ou

dalignement mettant en jeu des modles. Ce processus est support par des outils de
construction et de confrontation. Il comporte gnralement les tapes de construction,
confrontation et le cas chant, pour les mthodes dalignement, ltape de prise de dcision
correspondant la construction progressive du modle TO-BE. Le Tableau 8 synthtise la
prsentation des mthodes en suivant le schma : modles, outils, processus dalignement. La
prsentation dtaille des mthodes est donne en annexe C en suivant le mme schma.
Pour chaque modle, nous prcisons :
-
le cadre de modlisation dans lequel sinscrit sa construction, sil y en a un ;

les vues modlisation et construits de modlisation reprsents et confronts travers ce
modle - sur la base du vocabulaire de la norme (ISO/DIS 19440 2004) et de la vue
intentionnelle :
FUN : pour la vue fonctionnelle
43
Rf.
Modles
Modles
(abstraction, gnricit, cycle
de vie)
Outils
Vues et
construits
confronts
Langage
Mesures
Raffiner
Interdpendances
(Prakash
and
Rolland
2001)
AS-IS (-, -, -);

AS-WISHED (-, -, -)
MIGHT-BE (-, -, -);
TO-BE (-, -, -)
FUN (activits)
INT (buts)
MAP
Non
Oui (non
dtaill)
Non
(Darras
2004)
AS-WISHED (spcification
mtier, particulier, -) ;
MIGHT-BE (spcification,
gnrique, -) ;
TO-BE (spcification &
conception, particulier, -)
FUN (activits)
UML :
Diagramme
dactivits
Non
Oui (non
dtaill)
Non
(Soffer et
al. 2005)
AS-WISHED (-, -, -);

MIGHT-BE (-,-, -);
TO-BE (-, -, -)
FUN (activits)
INF (objets
dentreprise en E
/ S)
OPM :
diagramme OPD
Oui
Non
(non
dtaill)
Oui
(Zoukar
2005)
AS-WISHED (-, -, -);

MIGHT-BE (-, -, -);
TO-BE (-, -, -)
IN (buts)
FUN (activits)
MAP
Oui
Oui (non
dtaill)
Non
Etapes cls du processus dalignement ou de

confrontation
o Construire les modles AS-IS, AS-WISHED
et MIGHT-BE
o Confronter ces 3 modles en tirant par lun ou
lautre des modles tout en construisant
progressivement le modle TO-BE
o Construire les modles AS-WISHED et
MIGHT-BE
o Confronter ces 2 modles tout en construisant
progressivement le modle TO-BE :
Dabord au niveau spcification, puis
Traduit au niveau conception, et enfin
Complt avec les dveloppements
spcifiques faire sur lERP
MIGHT-BE
o Confronter ces modles tout en reformulant
progressivement le modle AS-WISHED ;
avec vrification de la faisabilit de ces
reformulations. Et boucler tant que :
Lentreprise nest pas satisfaite du
modle AS-WISHED
o Construire le TO-BE, sur la base des
modifications faites sur le modle ASWISHED (abandonning, mapping)
MIGHT-BE
o Confronter les modles en utilisant une ou
plusieurs des approches (Top down,
Bottom up et Mixte) tout en construisant
progressivement le modle TO-BE dans le
langage MAP
o Dduire le modle TO-BE fournir
lentreprise et lditeur dans le langage
souhait
44
Rf.
(Tserng et
al. 2010)
(Wu et al.
2007)
(Millet
2008)
Modles
Modles
(abstraction, gnricit, cycle
de vie)
Outils
Vues et
construits
confronts
Langage
AS-IS (-, -, -);

AS-WISHED (-, -, -)
MIGHT-BE (-, -, -);
TO-BE (-, -, -)
FUN (processus)
INF (objets
dentreprise)
Diagramme
ARIS-House
AS-WISHED (-, -, -) ;
MIGHT-BE (-, -, -)
FUN (activits)
INF (vues objets
+ att. en sortie)
INT (buts)
-UML : Cas
dUtilisation
orient buts +
diag. dactivits
-Drawing
-Glossaire
Mesures
Non
Oui
Raffiner
Non
Non
Interdpendances
Etapes cls du processus dalignement ou de

confrontation
Non
o Construire les modles AS-IS, AS-WISHED

et MIGHT-BE
o Confronter les couples de modles AS-IS /
MIGHT-BE et AS-WISHED / MIGHT-BE
tout en construisant progressivement le modle
TO-BE
Non
Pour chaque vue, dabord intentionnelle, puis

fonctionnelle puis informationnelle :
MIGHT-BE
o Confronter des lister les non-alignements
AS-WISHED (-, particulier &

partiel, identification du
FUN, INF, RES
domaine et dfinition des
ORG
concepts) ;
construits norme
Graphe
Oui (non
MIGHT-BE
Oui
Oui
MIGHT-BE
+ construits mtadintgration
prcis)
o Confronter les modles et reprer les
(-, gnrique & partiel,
modle SCOR et
alignements
oprationnalisation du domaine
ERP
& description de
limplantation)
Tableau 8- Analyse des mthodes dalignement et de confrontation diriges par les modles
45
INF : pour la vue informationnelle

RES : pour la vue de ressources
ORG : pour la vue organisationnelle
INT : pour la vue intentionnelle
Pour les outils, nous prcisons :

-
les langages de modlisation utiliss,

si le raffinement des modles est introduit,
si les interdpendances des processus sont modlises,
si des mesures de similarit sont proposes pour la confrontation des modles.
Nous rcapitulons les tapes cls pour les processus dalignement ou de confrontation.
1.3
Analyse des mthodes
Nous analysons les mthodes dingnierie dirige par les modles dans leur aptitude
constituer un moyen pour mettre en uvre la stratgie doptimisation agissant sur leffet du
RNA. Pour ce faire, nous avons analys chaque mthode selon sa capacit :
-
identifier le rsultat indsirable de lespace des effets du RNA savoir le non-alignement

potentiel entre les fonctionnalits de lERP et les besoins exprims par lentreprise,
valuer limpact savoir leffet de ce non-alignement, et y associer des dcisions pour
construire le modle TO-BE correspondant.
1.3.1
Identifier le non-alignement potentiel
Lidentification du non-alignement potentiel passe ncessairement par la construction des

modles AS-WISHED, MIGHT-BE et ventuellement AS-IS puis par leur confrontation. Ce
sont ces deux lments que nous analysons plus finement.
1.3.1.1
Construction des modles
Pour commencer, les formalismes proposs pour construire les modles sont varis. Par
exemple, (Soffer et al. 2005) prconisent le formalisme OPM, (Prakash and Rolland 2001)
ainsi que (Zoukar 2005), le formalisme MAP, et (Millet 2008) le graphe dintgration. Les
deux premiers formalismes sont spcifiques cest--dire quils ont t conus par ces auteurs.
Le formalisme OPM, lui, permet de reprsenter les diffrentes alternatives offertes par lERP.
Le formalisme MAP est facile comprendre et est aisment accessible toute personne
nayant pas dexprience dans la modlisation dentreprise. Le graphe dintgration, quant
lui, offre la possibilit de reprsenter aisment les interdpendances de processus.
Cependant, certains langages prsentent des inconvnients. Cest le cas du graphe
dintgration et du langage OPM. Lutilisation du premier fait appel des outils danalyse de
l'intgration. Ces outils ncessitent le recours des calculs longs et fastidieux, dont la
complexit crot lorsquil sagit de les appliquer des graphes dintgration dentreprise de
taille relle. En effet, en prenant en compte lensemble de ses domaines fonctionnels
46
simultanment - commercial, comptabilit, finance, SAV, production etc. -, le nombre

dobjets en moyenne peut atteindre les 105. Quant au langage OPM, le mcanisme des
options demande une priode dassimilation et les membres de lentreprise ne sexpriment pas
en ces termes. Ils sexpriment gnralement en termes dactivits qui senchanent et dentres
/ sorties des activits et non en termes doptions.
De plus, certains auteurs tels que (Zoukar 2005) ou encore (Darras 2004) accompagnent la
construction de leurs modles de conseils. Le premier conseille, par exemple, de construire le
modle MIGHT-BE par abstraction de la documentation fournie avec le systme et de la
connaissance des experts de chaque domaine considr. Ou encore, il propose de construire le
modle AS-WISHED par analyse des dysfonctionnements de lexistant ou par adoption des
bonnes pratiques sous-jacentes lERP. Le second auteur propose dutiliser la grille GRAI
oriente but comme point de dpart pour formuler les besoins.
1.3.1.2
Confrontation des modles
Pour la confrontation des modles, nous avons analys :

-
les modles confronts savoir le choix des modles confronter et leur niveau de
granularit,
les mesures de similarit,
les vues de modlisation : les construits des vues de modlisation confronts et
lexploitation des vues au cours de ltape de confrontation,
la formalisation de lalignement ou du non-alignement entre les modles.
Les modles AS-WISHED et MIGHT-BE sont gnralement ceux qui sont confronts. Cela
permet de vrifier si lERP rpond aux besoins exprims par lentreprise. La confrontation du
modle AS-IS est propose par (Soffer et al. 2005) et (Tserng et al. 2010). Lobjectif sousjacent est dvaluer lcart entre lexistant et les processus qui seront implants. La plupart
des auteurs (Prakash and Rolland 2001; Darras 2004; Soffer et al. 2005; Zoukar 2005)
proposent dappliquer le raffinement des modles. Cest--dire quil est possible de choisir le
niveau de granularit des modles lors de leur construction et de leur confrontation. Par
contre, aucun auteur ne guide prcisment ce choix. Ainsi, les niveaux de granularit - en
termes de construits ou encore du nombre de construits reprsents, par exemple - ne sont pas
spcifis. Seul (Zoukar 2005) prconise des approches Bottom-up, Top-down et Mixte
qui mettent en jeu diffrents ordres de confrontation des niveaux de granularit. Cette
proposition est intressante dans la mesure o elle augmente la chance didentifier le nonalignement potentiel entre les modles. Mais en contrepartie, elle est assez complexe mettre
en uvre. En effet, cela implique un trs grand nombre de modles confronter. Lauteur a
valu, par exemple, que la complexit algorithmique de lapproche Bottom-up tait
quadratique.
47
Les mesures de similarit entre construits de modles sont proposes par (Soffer et al. 2005),
(Zoukar 2005) et (Millet 2008). Seul (Zoukar 2005) dtaille le degr dalignement entre les
construits. Pour les autres auteurs, les construits sont simplement aligns ou non. Les mesures
sont intressantes et compltes. Elles calculent la fois :
-
la similarit des construits contenus entre les deux modles confronts ;

la similarit des liens entre construits contenus dans les deux modles confronts. Par
exemple, deux liens sont similaires sils ont la mme entit cible, la mme entit source, et
la mme cardinalit (Soffer et al. 2005) ; ou encore, le lien du premier modle et le lien du
second modle ont la mme entit cible (Zoukar 2005) ;
lagrgation des similarits. Par exemple, deux modles ont 5 construits identiques sur 15
(Soffer et al. 2005; Zoukar 2005); ou encore, (Millet 2008) rcapitule le nombre de
dpendances dun sous-graphe prsentes dans le sous-graphe qui lui est confront.
(Zoukar 2005) introduit plusieurs degrs de similarit : deux termes ne sont pas uniquement
similaires, ils peuvent tre identiques , proches , synonymes ou encore
hypronymes . De plus, (Soffer et al. 2005) introduit limportance du jugement de lexpert.
En effet, deux processus ayant t mesurs comme non-aligns peuvent tre aligns par leurs
objectifs. Le concept dobjectif reste flou car il ne le modlise pas.
Concernant les vues de modlisation :
-
La vue intentionnelle est mise en uvre dans la moiti des mthodes tudies. Elle est
confronte mais elle nest pas utilise pour structurer la confrontation des autres vues de
modlisation. En effet, (Prakash and Rolland 2001) et (Zoukar 2005) confrontent les vues
fonctionnelle et intentionnelle lune aprs lautre sans les diffrencier. Par contre, (Wu et
al. 2007) distinguent la confrontation des construits de la vue intentionnelle de celle des
autres vues. Elle est confronte en premier mais aucune connaissance nest capitalise ce
sujet. Lalignement des buts de la vue intentionnelle ne dbouche pas sur la confrontation,
au niveau de la vue fonctionnelle, des processus associs ces buts.
La vue fonctionnelle - utilise intuitivement dans un projet pour exprimer les besoins - est
prconise par lensemble des auteurs. Nous la retrouvons sous la forme de sousprocessus, stratgies, ou encore options.
La vue informationnelle est confronte uniquement par (Soffer et al. 2005), (Tserng et al.
2010) et (Wu et al. 2007). Les construits de cette vue sont simultanment confronts avec
les construits de la vue fonctionnelle sans prciser lordre de confrontation des construits.
(Soffer et al. 2005) et (Tserng et al. 2010) confrontent uniquement lexistence des objets
dentreprise sans les distinguer des vues dobjet. Cette distinction est peut-tre ralise
implicitement par (Soffer et al. 2005) par lintermdiaire des diffrents niveaux doptions
proposes mais les modalits associes restent floues. (Wu et al. 2007), par la
confrontation des diffrents champs des captures dcran, confrontent les attributs des
vues dobjet et galement leur format. Cependant, ils ne dtaillent pas les objets
dentreprise ni les vues dobjets possdant ces attributs.
Concernant les vues organisationnelle et de ressources, seul (Millet 2008) les confronte. Il
met laccent sur limportance de ces construits, de par leur interdpendance avec les autres
construits des autres vues. (Darras 2004) ne les confronte pas mais il les dfinit, une fois
le modle TO-BE construit.
48
Enfin, concernant la formalisation de lalignement et du non-alignement, celui-ci se rduit

celui des construits - avec ventuellement une mesure du degr dalignement. Il ny a pas de
distinction entre les construits de chaque vue puisquil est conseill de confronter lensemble
des vues sans ordre prconis. Ainsi, les construits reprsentant deux vues diffrentes dun
mme processus sont considrs comme indpendants, dans le sens o lalignement ou le
non-alignement de lun nest pas pris en compte dans lalignement ou le non-alignement de
lautre. Par exemple, le non-alignement du construit objet dentreprise associ
lalignement du construit activits dentreprise dun processus nest pas considr.
1.3.2
Evaluer leffet du non-alignement et y associer des dcisions
Lvaluation de leffet du non-alignement et la prise de dcision associe constituent le

deuxime point analyser dans le cadre du traitement du RNA par la stratgie doptimisation
anticipative agissant sur leffet. Compte tenu de limpact que peuvent avoir les dcisions sur
les construits interdpendants des processus, nous analysons galement si linterdpendance
des processus est prise en compte.
Aucun auteur ne propose dvaluer leffet du non-alignement ni mme ne donne de critres
pour lvaluer.
Dune manire gnrale, la construction de lalignement par la prise de dcision nest pas
dtaille. En effet, les construits aligns entres les modles AS-WISHED et MIGHT-BE sont
repris tels que dans le modle TO-BE. Les construits non aligns prsents dans le modle ASWISHED sont ajouts au modle TO-BE et le dveloppement spcifique est prconis sans
dtails supplmentaires. (Soffer et al. 2005) ajoutent que ces processus peuvent tre supports
manuellement et donc non supports par le S.I. ERP. Pour ceux uniquement prsents dans le
modle MIGHT-BE, ils sont ajouts au modle TO-BE sils sont jugs pertinents. Enfin,
(Soffer et al. 2005) proposent, pour les processus qui sont aligns par leurs objectifs - selon le
jugement de lexpert du domaine concern - dappliquer le splitting. Cela consiste
construire le modle TO-BE soit limage du processus construit dans le modle ASWISHED, soit limage de celui construit dans le modle MIGHT-BE. Nous reprsentons la
synthse de ces diffrentes propositions sur la Figure 22.
Le panel des dcisions potentielles que lon retrouve dans la littrature (cf. Tableau 9) nest
donc pas pris en compte. Celles-ci sont classes dans le tableau par ordre croissant des
modifications apportes au S.I. ERP. Pour chaque rfrence, nous spcifions le vocabulaire
utilis. Les mthodes dingnierie dirige par les modles tudies exploitent uniquement le
paramtrage et le dveloppement spcifique sans distinguer le degr de modifications
apportes au S.I. ERP.
49
Figure 22- Processus dalignement dans la littrature
Dcisions avec le vocabulaire de chaque auteur

support manuel du processus (Soh et al. 2000)
handled manually without involving the ERP
system (Soffer et al. 2005)
configuration tables (Davenport 1998)
paramtrage (Zoukar 2005)
configuration (Glass 1998; Brehm et al. 2001;
Millet 2008)
customization (Glass 1998)
screen masks (Brehm et al. 2001)
masque dcran (Zoukar 2005; Millet 2008)
extended reporting (Brehm et al. 2001)
rapports tendus (Zoukar 2005)
dition (Millet 2008)
Workflow (Brehm et al. 2001)
programmation de workflows (Zoukar 2005)
programmation de procdures (Millet 2008)
Dfinition de la dcision
Il sagit de supporter un processus donn par
un moyen autre que le S.I. base dERP. Par
exemple, par un fichier Excel non interfac
avec lERP ou manuellement.
Il sagit de choisir une alternative parmi les
alternatives de paramtrage que lERP
propose en standard.
Il sagit de modifier la prsentation visuelle
de linterface utilisateur cest--dire la
manire de prsenter les onglets, les champs,
les listes droulantes, etc.
Il sagit de modifier la prsentation visuelle
des rapports ou tats tels que les ordres de
mission, les factures envoyes au client, les
tiquettes etc.
Il sagit de mettre des conditions sur
certaines activits afin de les contrler. Par
exemple, mise en place de la procdure
consistant demander laccord du chef de
lentreprise avant de valider une commande
de plus de 30000 .
50

Dcisions avec le vocabulaire de chaque auteur
modifications (Glass 1998)
code modification (Davenport 1998)
core customization to amend the base code (Soh et
al. 2000)
package code modification (Brehm et al. 2001)
modification du code de lERP (Zoukar 2005)
modification de sources (Millet 2008)
use existing system and build interfaces between It
and the ES (Davenport 1998)
ERP programming (Brehm et al. 2001)
programmation dans lERP (Zoukar 2005)
programmation ERP (Millet 2008)
extension (Glass 1998)
non-core customization (interfacing with add-on
module) (Soh et al. 2000)
standard interface (Scott and Kaindl 2000)
bolt-ons (Brehm et al. 2001; Zoukar 2005)
mise en uvre de modules complmentaires tiers
(Millet 2008)
interface development (Brehm et al. 2001)
dveloppement dinterfaces (Zoukar 2005; Millet
2008)
bolting on customized programs (Scott and Kaindl
2000)
programming (Brehm et al. 2001)
ajout de code (Zoukar 2005)
dclencheur de base de donnes (Millet 2008)
Dfinition de la dcision
Il sagit de modifier les lignes de code dj
prsentes dans le code source de lERP.
Il sagit dajouter des lignes de code au code

source de lERP.
Il sagit de paramtrer linterface dune

brique applicative correspondant un
progiciel interfaable en standard avec
lERP.
Il sagit de dvelopper linterface entre une

brique applicative et lERP.
Il sagit du dveloppement spcifique dun
logiciel et de son interface avec lERP. Ce
logiciel peut utiliser les donnes standards de
la base de donnes de lERP.
Tableau 9- Panel des dcisions issues de la littrature
Enfin, deux mthodes introduisent limportance des interdpendances de processus :

-
1.4
(Millet 2008), mais sa proposition concerne une mthode de confrontation sans prise de
dcision.
(Soffer et al. 2005), mais leur proposition est implicite cest--dire quelle est formule
par lintermdiaire de lvaluation de la faisabilit des modles. Celle-ci est ralise en
formulant des assertions logiques avec lalgorithme Bottum-Up Aggregation. En effet,
valuer cette faisabilit sous-entend que les processus sont interdpendants mais ces
interdpendances ne sont pas formalises.
Conclusion et mise en perspective par rapport au cas dtude
Notre analyse des mthodes dingnierie nous montre que :

-
Les contributions relatives la construction des modles sont intressantes tant au niveau
des langages de modlisation proposs que de laccompagnement dans la construction des
modles.
51
Pour la confrontation, seules les propositions concernant les mesures de similarit sont
compltes. Les autres - relatives au niveau de granularit, aux construits des vues de
modlisation confrontes, leur exploitation ou encore la formalisation de lalignement
et du non-alignement - sont trop peu dveloppes pour rpondre notre problmatique.
De mme, lvaluation de leffet nest pas prise en compte alors que cela est crucial pour
pouvoir optimiser le RNA.
Enfin, lassociation aux dcisions, permettant de construire lalignement, reste basique.
Les dcisions proposes dans la littrature et regroupes dans le Tableau 9 sont
pertinentes ; mais elles ne sont pas associes aux situations dalignement ou de nonalignement dans les mthodes existantes tudies.
La construction des modles, la confrontation des modles, lvaluation de leffet du nonalignement et la prise de dcision ont t des points sensibles durant le projet ERP de notre
partenaire industriel, la socit X.
-
Pour la construction des modles, nous avons constat que ni les besoins de lentreprise ni
les processus standards de lERP navaient t modliss.
La confrontation des modles na pas rellement t ralise : lors de runions,
lintgrateur projetait les interfaces utilisateurs de lERP sur un cran. Cette projection
tait accompagne dexplications de lintgrateur et de commentaires des membres de
lentreprise sur ce qui tait projet. Il ny avait aucune structuration des lments
prsents. Les commentaires des membres de lentreprise avaient pour objectif dexprimer
si ce qui tait projet tait quivalent ou non leurs besoins.
Pour lvaluation de leffet du non-alignement et la prise de dcision, une analyse des
documents signs suite ltude dadquation - correspondant au modle TO-BE - nous
montre quils taient incomplets et formaliss sans structure et avec une redondance du
contenu. De plus, au cours des runions dadquation, les dcisions ont t prises sur le
tas lors de la projection des interfaces. Elles ntaient pas mmorises ou valides au fur
et mesure par les membres de lentreprise. Lintgrateur prenait simplement des notes.
Enfin, nous avons eu loccasion dobserver la phase de post-implantation et donc
dutilisation de certains modules par les utilisateurs finaux. Cela nous a permis de
constater que certaines dcisions avait t mal prises : soit les besoins rels ntaient pas
satisfaits, soit les modifications faites sur lERP ne servaient rien.
Management des facteurs de risque
Cette section vise faire ltat des contributions relatives au management des facteurs de
risque. Dans ce contexte, nous nous sommes focaliss sur plusieurs types de contribution : les
listes de facteurs de risque, leur caractrisation ou encore les travaux proposant un processus
pour leur management.
La notion de facteur de risque (FR) est traite dans de nombreux travaux ayant trait au
management des risques. En voici une slection :
-
Un facteur de risque est une situation qui a le potentiel de causer une perte (Standards
Association of Australia 2004) dans (Bernard et al. 2002a).
Un facteur de risque est une circonstance ou un environnement qui aggravera les risques
lis lexcution dune tche donne ((MDNFC 2002), dans (Ravalison 2006)).
52
Un facteur de risque est une condition de lenvironnement interne ou externe du projet

qui influence la probabilit doccurrence dun rsultat indsirable (Bourdeau et al.
2003).
Un facteur de risque est un lment identifi ou une condition de lenvironnement
interne ou externe du projet dont lexistence est de nature influencer la survenue dun
vnement et donc de modifier la mesure de la probabilit doccurrence du risque
(Gourc 2006).
Un facteur de risque se comporte comme un rvlateur du risque (Ravalison 2006).
Par facteur de risque, nous entendons constat effectu par lacteur , que ce constat
soit objectif ou subjectif (Ravalison 2006).
Nous retenons de ces dfinitions que le facteur de risque :

-
est un constat,
est une situation qui sest matrialise un moment donn durant le projet, cette situation
est avre ou non,
ou est une condition de lenvironnement interne ou externe du projet,
et augmente la probabilit doccurrence du rsultat indsirable associe au risque.
La notion de management de facteurs de risque est similaire celle de management des

risques dfinit en introduction de ce chapitre. Il sagit de lapplication, au cours du cycle de
vie du projet, des tapes didentification, dvaluation, de priorisation, de traitement, de suivi
et de contrle / mmorisation des facteurs de risques (Zafiropoulos et al. 2005; Iskanius
2009).
La section suivante prsente une premire analyse des contributions. Nous dtaillons ensuite
les travaux relatifs lanalyse des facteurs de risque et de succs (section 2.2) puis ceux
relatifs leur management (section 2.3).
2.1
Analyse des contributions
La littrature relative aux facteurs de risques et leur management dans les projets ERP est
intimement lie celle des facteurs de succs (FS). En effet, si la connaissance des FR est
indispensable pour grer les risques durant un projet ERP, un autre point de vue consiste
sattacher aux FS cest--dire aux lments qui permettent dassurer le succs des projets
ERP. Devant le lien vident entre ces deux notions nous proposons dinclure les travaux
relatifs aux FS dans notre tude.
Notre analyse chronologique se base sur 86 articles scientifiques issus de bases de donnes
telles que Science direct et ISI web of sciences et rpondant aux mots-cls risk
factors, success factors, ERP project, ERP implementation, management,
assessment, identification. Lobjectif est, tout dabord, de donner une vision globale des
tendances de recherche en fonction de cinq types de contributions que nous avons identifies :
-
Liste de FR ou FS : nous prcisons sil sagit dune liste de FR et de FS ainsi que le mode
de recueil - tudes de cas dans des entreprises ayant entrepris un projet ERP, interviews et
53
enqutes auprs de personnes ayant une forte exprience dans les projets ERP, revue de
littrature, etc.
Sous-ensemble de FR ou FS : si les travaux tudis se focalisent sur un sous-ensemble de
FR ou de FS qui est analys plus en profondeur sur son importance durant le projet ERP
ou son influence sur le succs ou lchec du projet.
Classification des FR ou FS : nous prcisons sil sagit dun classement selon le cycle de
vie du projet ERP ou la nature du facteur.
Influences entre facteurs : lorsquil est propos de dfinir des influences entre les FR ou
FS.
Approches de management : certains travaux concernent le processus de management des
FR et les outils pour mettre en uvre certaines tapes de ce processus. Nous prcisons, le
cas chant, ltape du processus sur laquelle se concentre lauteur - identification,
valuation, priorisation, traitement, suivi ou contrle / mmorisation.
Le tableau des travaux tudis par ordre chronologique et selon ces 5 types de contributions
est mis en annexe D et permet de faire lanalyse suivante. Le nombre de contributions
annuelles (cf. Figure 23) a augment entre 2000 et 2011, avec des pics en 2005 et 2008. Nous
navons pas inclus lanne 2012 car les rsultats auraient t biaiss puisque lanne nest pas
complte. Cependant, il y a dj 5 contributions, ce qui montre lessor de ce sujet.
14
12
10
8
6
4
2
0
nombre de contributions/
anne
Figure 23- Evolution du nombre de contribution de 1999 2011
Concernant le nombre de contributions par type (cf. Figure 24), les listes et sous-ensembles de
facteurs reprsentent 56% des contributions - 60 sur 107 sachant que certains articles
comportent plusieurs contributions. Cette tendance se confirme en analysant ce type de
contribution par anne (cf. Figure 25) puisque ceux-ci sont majoritaires compars
lensemble des autres contributions runies. Ce sont dailleurs, les contributions sur les FS qui
sont beaucoup plus nombreuses que celles sur les FR raison de 5 pour 1. Cela montre que
les chercheurs se sont avant tout intresss ce qui pouvait conduire au succs dun projet
ERP plutt que le contraire. Les contributions sur les influences sont, quant elles, peu
nombreuses et ne reprsentent que 9% des travaux tudis. Par ailleurs, ce thme est
relativement rcent puisque les articles qui en font rfrence sont, lexception dun,
postrieurs 2006. Les approches de management et de classification ont reu globalement la
mme attention au fil des ans en reprsentant respectivement 15% et 20% des travaux tudis.
54
Le management des facteurs a merg de manire significative en 2008 et conserve depuis

une attention rgulire . Cest surtout lvaluation des facteurs - plus de 80% de ces articles
- qui a t tudie. En effet, cest un pralable la gestion des facteurs. Les classifications
sont abordes sur lensemble de la priode tudie. On constate que depuis 2005 le nombre
darticles par an sur ce thme a doubl.
10
8
listes/ sous-ensemble de
facteurs
classifications
4
influences
2
2011
2012
2009
2010
2007
2008
2004
2005
2006
2002
2003
2000
2001
1999
approches de management
Figure 24- Evolution du type de contribution entre 1999 et 2012

16
60 - listes/ sous-ensemble de facteurs
10
21 - classifications
60
21
10 - influences
16 - approches de management
Figure 25- Proportion de chaque type de contribution
Les modes de recueils tels que les tudes de cas, enqutes, interviews ou retours
dexpriences dans les pays orientaux sont environ deux fois plus levs que ceux des pays
occidentaux. Ces modes de recueil pour les pays orientaux sont galement deux fois plus
levs que le mode de recueil de type revue de littrature.
2.2
Analyse et classification des facteurs de risque et de succs des projets

ERP
Pour mener bien cette analyse, nous avons constitu une liste de 29 FR (facteurs de risque).
Pour ce faire, nous nous sommes bass sur les 60 contributions listant ou se focalisant sur un
sous-ensemble de facteurs mentionns en tant que FR ou FS (facteurs de succs). Quatre
contributions se basent sur les retours dexprience de pays orientaux, que nous avons
complt par un retour dexprience dans les entreprises occidentales, savoir (BottaGenoulaz and Millet 2005).
Les 29 facteurs sont lists dans le Tableau 10 selon lordre croissant de leur nombre de
citation dans la littrature. Six FR concernent les membres du projet et leur travail en commun
- chef de projet, utilisateurs cls, intgrateur, comit de pilotage, consultants externes. Deux
55
FR sattachent aux utilisateurs finaux. Nous distinguons la qualit de leur formation, de leur
implication au sein du projet. Deux FR sont lis la communication, lun au sein de lquipe
et lautre entre lquipe et les utilisateurs finaux. Quatre FR sont lis la gestion de projet.
Celle-ci est dfinie selon le triptyque classique temps, production et ressources (Morley
2001).
Nous ajoutons laspect gestion des risques, du changement organisationnel et des buts
stratgiques du projet. Il y a galement tous les FR qui relvent dun aspect technique tel que
les problmes denvironnement informatique, la maintenance, les tests, la complexit du
progiciel, la conversion des donnes ou ladaptation de lERP. Dautres FR relvent de
lexpression des besoins de lentreprise et de leur alignement avec les processus standards de
lERP tels que la qualit de lexpression des besoins, le BPR (Business Process Engineering),
lalignement entre les processus, la slection du progiciel et laspect multi-sites. Enfin, le
dernier facteur est propre lentreprise et sa capacit assumer un tel projet.
Nous avons class, en annexe E, les facteurs proposs dans la littrature en fonction de leur
synonymie ou de leur capacit se complter pour exprimer une mme ide. Par exemple,
des besoins incomprhensibles et des besoins incomplets se compltent pour
constituer des besoins exprims mal dfinis .
2.2.1
Analyse selon le mode de recueil et la frquence de citation
Nous avons analys les facteurs en fonction du nombre de citation et du mode de recueil (cf.
Tableau 10).
Pour le nombre de citation, nous avons distingu les facteurs qui sont peu cits mais rcents,
ceux qui sont peu cits et plus anciens, et ceux pour lesquels il y a un quilibre dans le
nombre de citations en tant que FR et en tant que FS.
Nous avons mis en lumire grce au mode de recueil :
-
les facteurs qui sont cits dans autant (X) voir davantage (XX) de revues de littrature que
dans dautres modes de recueil,
les facteurs les plus cits dans les retours dexprience,
les facteurs marqus par une influence culturelle cest--dire (i) ceux qui sont apparus
pour les pays orientaux depuis 2004, (ii) ceux qui ne sont plus cits pour les pays
occidentaux depuis 2005, (iii). ceux qui sont cits continuellement depuis 2000.
Les facteurs principalement cits dans des revues de littratures (XX) et ceux qui sont peu
cits ne sont pas classables selon les influences culturelles - cases grises dans le tableau.
Le facteur Gestion inadquate du non-alignement est le plus cit - 36 fois. Cela renforce
notre intrt pour la problmatique de traitement du risque de non-alignement. Il sagit dun
sujet de proccupation majeur dans la gestion des projets ERP.
Les facteurs :
56
Manque dexpertise / dimplication du comit de pilotage

Gestion de projet inefficace
Mauvaise constitution de lquipe projet
Gestion inadquate de la conversion des donnes
Manque dexpertise / dimplication / absence de consultants externes
sont les plus critiques, cest dire quils sont trs cits - plus de 20 fois - de manire continue
depuis 2000 et ce, quelle que soit la zone culturelle concerne.
Les facteurs :
-
Formation inadquate / insuffisante des utilisateurs finaux

Slection inadquate du progiciel
Gestion inadquate de la conversion des donnes
sont galement critiques car, en plus dtre trs cits, ils ressortent particulirement dans les
retours dexprience.
Les facteurs :
-
Gestion inadquate du non-alignement

Manque dexpertise / dimplication / rsistance au changement des utilisateurs finaux
Formation inadquate / insuffisante des utilisateurs finaux
Slection inadquate du progiciel
Communication inefficace au sein de lquipe projet
Problme avec le chef de projet
BPR inadquat
Difficults de travail commun entre lentreprise et les membres externes
Manque dexpertise de lintgrateur
Buts stratgiques mal dfinis
ne sont plus cits pour les grandes entreprises de pays occidentaux depuis 2005 mais le sont
pour les entreprises orientales depuis 2004. Ces facteurs sont essentiellement lis aux aspects
de gestion de lquipe de projet et dalignement entre les besoins de lentreprise et les
processus standards de lERP. Les grands groupes occidentaux ont acquis, depuis les annes
2000, une maturit dans la gestion de leur projet ERP. Cela explique leur maturit dans le
management de ces facteurs. Ce nest pas le cas des PME occidentales. Ces dernires nont
dailleurs quasiment pas fait lobjet dtudes de cas. Ce dcalage dans la matrise de ces
facteurs sexplique par le fait que le march des ERP a merg, pour les PME occidentales et
les entreprises orientales, plus rcemment. Ces entreprises nont donc pas encore acquis la
maturit ncessaire pour assurer le management de ces facteurs.
57
/ nombre de citations
Liste des facteurs - nombre de citation
Peu
cits et
rcents
Peu
cits et
peu
rcents
Eq.
FR et
FS
/ mode de recueil
Lis influence culturelle
Autres
Revue
de litt.
Retour
dexp.
Occident
2000
2005
Occident
2005 auj.
Orient
2000
2004.
Orient
2004
auj.
Gestion inadquate du non-alignement 36
Manque dexpertise / dimplication du comit de pilotage 32
Gestion de projet inefficace 30
Mauvaise constitution de lquipe projet 28
Manque dexpertise / dimplication / rsistance au changement

des utilisateurs finaux 24
Formation inadquate / insuffisante des utilisateurs finaux 24
Slection inadquate du progiciel 22
Problmes techniques 21
Gestion inadquate du changement organisationnel 20
Gestion inadquate de la conversion des donnes 20
Manque dexpertise / dimplication / absence de consultants

externes 20
Instabilit organisationnelle / manque dexpertise / dimplication

de lentreprise 19
Gestion inadquate de ladaptation de lERP 19
Communication inefficace au sein de lquipe projet 18
Problme avec le chef de projet 18

BPR inadquat ( Business Process Reengineering ) 17
X
58
/ nombre de citations
Liste des facteurs - nombre de citation
Peu
cits et
rcents
Peu
cits et
peu
rcents
Eq.
FR et
FS
/ mode de recueil
Lis influence culturelle
Autres
Revue
de litt.
Mauvaise planification temporelle du projet 14

Mauvaise gestion des ressources financires et matrielles 14
Retour
dexp.
Occident
2000
2005
X
X
Difficult de travail commun entre lentreprise et les membres

externes (intgrateurs et / ou consultants) 13
Manque dexpertise / dimplication des utilisateurs cls - 12
Manque dexpertise de lintgrateur 11
Buts stratgiques mal dfinis 10

X
Communication inefficace entre lquipe projet et le reste de

lentreprise 9
Ralisation inadquate des tests 6
Gestion inadquate de la maintenance 4
XX
Difficult de gestion de laspect multi-sites 2
Mauvaise gestion des risques 5
Haut degr de complexit du progiciel 4
Orient
2000
2004.
Orient
2004
auj.
X
X
Mauvaise expression des besoins 9
Occident
2005 auj.
X
X
XX
Tableau 10- Liste et analyse des facteurs de risque
59
A linverse, les facteurs :

-
Ralisation inadquate des tests

Gestion inadquate de maintenance
Difficults de gestion de laspect multi-sites
sont les moins critiques, dans le sens o ils sont les moins cits - moins de 6 fois - et le sont
dans des revues de littrature anciennes. Ils semblent donc avoir moins proccup les
chercheurs car les aspects concerns sont certainement de mieux en mieux matriss au regard
de la maturit acquise sur les systmes ERP.
Il nen est pas de mme pour les facteurs :
-
Mauvaises gestion des risques

Haut degr de complexit du progiciel
qui sont peu cits mais dont nous pensons quils demeurent un sujet de proccupation rcent
et toujours actuel.
Les facteurs trs cits - plus de 22 fois - le sont majoritairement en tant que FS. Ceux pour
lesquels il y a un quilibre de citations en tant que FR et FS concernent gnralement des
aspects lis la gestion de lquipe projet. Cela semble cohrent dans le sens o ils peuvent
la fois contribuer lchec ou au succs du projet.
2.2.2
Classification selon la nature du facteur de risque ou de succs
Une premire cl de classement des FR est leur nature. (Holland and Light 1999; Grabski and
Leech 2007; Peng 2009; Hakim and Hakim 2010; Amid et al. 2012) proposent de lister des
facteurs de risque les classent selon leur nature ; (Leopoulos et al. 2006; Chen et al. 2009b;
Kop et al. 2011) proposent uniquement une classification, sans liste de facteurs ; enfin
(Capaldo et al. 2008; Yunna and Zhijun 2008; Hua 2009; Jian et al. 2010) proposent une
classification pour valuer les risques. Lobjectif sous-jacent commun est damliorer la
comprhension de ce qui mne lchec ou au succs dun projet ERP pour ainsi supporter
les quipes projet dans la gestion des risques. En effet, connatre la nature dun facteur de
risque permet de savoir sur quoi agir.
Une premire distinction est faite entre les facteurs externes et internes : cette classification
peut tre interprte de deux manires diffrentes. La premire amne distinguer les facteurs
lis ce qui dfinit un projet - interne - des facteurs qui ne sont pas lis au projet mais qui
influencent son succs - externe. Parmi ces derniers, on retrouve les facteurs lis une
mauvaise situation politique ou conomique du pays ; ou encore les facteurs lis une
mauvaise organisation de lentreprise. La seconde interprtation amne distinguer ce qui est
li lentreprise de ce qui ne lest pas. Selon cette vision, le facteur li lorganisation de
lentreprise est interne. Par contre, ceux lis aux intgrateurs ou consultants sont externes. Les
auteurs proposant des listings nintgrent pas les facteurs conomiques ou politiques, car il
60
nest pas possible dagir directement sur ces derniers. De plus, la notion dinterne nest
propose que par (Yunna and Zhijun 2008) alors que la notion dexterne se retrouve sous
diffrents termes tels que legal (Leopoulos et al. 2005), external conditions par (Yunna
and Zhijun 2008), external (Hua 2009) ou encore market (Jiang and G. 1999).
Dautres auteurs distinguent les facteurs lis la gestion de limplantation de ceux lis au
systme mis en place ; on retrouve cette classification sous diffrentes dnominations :
-
project management / consultant and planning activities vs. alignment of the

business and the new information system (Grabski and Leech 2007),
management / financial vs. technical (Leopoulos et al. 2005),
implementation vs. system (Chen et al. 2009b),
implementation vs. software (Hua 2009),
project management / specialized skills / user vs. system / technology (Hakim
and Hakim 2010),
project management vs. technological / functional (Kop et al. 2011),
implementation / management vs. software (Jian et al. 2010),
project management / human resources / managerial / vendor and consultants vs.
technical / processes (Amid et al. 2012).
Comme le soulignent les termes employs, les facteurs lis la gestion de limplantation
peuvent eux-mmes faire lobjet dune sous-classification. Celle-ci permet de distinguer :
-
Les facteurs lis la gestion des ressources humaines : ceux relatifs aux consultants
externes, intgrateurs, chef de projet, utilisateurs finaux, leur expertise, leur implication, la
communication tablie entre eux, leur formation, etc. Cette catgorie peut tre divise en
facteurs lis aux utilisateurs finaux - user (Hakim and Hakim 2010) - et en facteurs lis
lquipe de projet - staff dans (Chen et al. 2009b), consultant / provider dans
(Amid et al. 2012), consultant and planning activities dans (Grabski and Leech 2007),
specialized skills dans (Hakim and Hakim 2010).
Les facteurs relatifs aux autres aspects de la gestion du projet savoir la gestion du
planning, des cots, des risques et de la conduite du changement.
Les facteurs lis au systme concernent la gestion de certaines tapes cls du projet : la
dfinition des besoins, la slection du systme, les tests, la maintenance, lalignement, son
installation dans un environnement technique donn, etc. Ils peuvent galement faire lobjet
dune sous-classification qui permet de distinguer :
-
Les facteurs lis laspect technique tels que les facteurs lis aux tests, aux problmes
techniques, etc., classification retrouve sous les termes de technical (Amid et al. 2012)
ou encore technological (Kop et al. 2011).
Les facteurs lis aux processus qui seront sous contrle de lERP cest--dire ceux lis la
dfinition des besoins ou encore la gestion du non-alignement. Cette classification peut
prendre diffrentes dnominations : software (Hua 2009), processes (Amid et al.
2012) ou encore functional (Kop et al. 2011).
61
Trois classifications sont transversales la classification gestion de limplantation /

systme et permettent de distinguer les facteurs lis :
-
A la prise de dcision de ceux qui ne le sont pas. Cette classification est uniquement
propose par (Kop et al. 2011).
A la prise en compte du changement organisationnel induit par la mise en place dun
nouvel ERP de ceux qui ne le sont pas. Parmi ceux-l il y a naturellement la prise en
compte des facteurs lis la conduite du changement, mais galement ceux lis la
dfinition des besoins ou la gestion du non-alignement. Nous retrouvons cette
classification sous les termes de organizational wide (Peng and Nunes 2009),
change (Chen et al. 2009b), transformation (Hua 2009), change management
(Grabski and Leech 2007), organisation-wide (Peng and Nunes 2009), ou encore
organizational (Capaldo et al. 2008; Kop et al. 2011; Amid et al. 2012).
A la distinction entre les facteurs tactiques et stratgiques propose par (Holland and Light
1999). Ainsi, tout ce qui est en rapport avec les buts stratgiques de lentreprise, la gestion
de projet ou encore le comit de pilotage est stratgique . Quant laspect tactique ,
il regroupe laspect systme mais aussi la communication ou encore ce qui est en lien
avec les utilisateurs finaux.
2.2.3
Classification selon le cycle de vie du projet ERP
Une seconde cl de classement est le cycle de vie du projet ERP qui permet de savoir quel
moment grer un facteur de risque donn. La majorit des auteurs qui proposent ce classement
le combine avec un listing de facteurs de risque. Le cycle de vie utilis par chacun des auteurs
est diffrent - il varie de 3 6 phases. Par contre, les travaux tudis proposent dtablir ce
classement en fonction de limportance du facteur dans la phase considre. Pour dterminer
cette importance, certains se basent sur des interviews dexperts tels que (Somers and Nelson
2001; Olson and Zhao 2007a; Plant and Willcocks 2007). Dautres dfinissent limportance
selon la possibilit de matrialisation du facteur au cours dune phase comme (Bernard et al.
2002b; Motwani et al. 2005; Chen et al. 2006; Nah and Delgado 2006; Aloini et al. 2007;
Zhang 2009). Pour ce faire, la plupart se basent sur leur exprience et leur connaissance des
projets ERP. Quoi quil en soit, les conclusions tirer de ces travaux, dun point de vue
management, sont les mmes :
-
Les facteurs de risque les plus importants doivent tre grs au cours des premires tapes
du cycle de vie du projet ERP. Ces facteurs concernent des dcisions importantes telles
que la slection du progiciel ou la dfinition des buts stratgiques. La prpondrance de
ces dcisions au dbut du projet montre quil est crucial de bien le dmarrer sinon cela se
rpercute sur le reste du projet.
Certains facteurs de risque sont transversaux au cycle de vie du projet ERP cest--dire
quils doivent tre grs tout au long de ce cycle. Il sagit de la plupart des facteurs de
risque appartenant la catgorie gestion de limplantation du classement selon la
nature des facteurs. Ainsi, les facteurs manque dexpertise / dimplication / absence de
consultants externes et communication inefficace au sein de lquipe projet ont t
classs dans 3 des 4 phases proposes par (Olson and Zhao 2007b).
Les articles traitant la phase de post-implantation viennent confirmer la prsence de
facteurs transversaux au cours de cette phase. Ainsi, selon (Peng and Nunes 2009; Singh
62
et al. 2010), les facteurs manque dexpertise / dimplication / absence de consultants

externes et manque dimplication / dexpertise du comit de pilotage existent au
cours de cette phase.
Dautres facteurs doivent tre grs uniquement au cours dune phase donne du cycle de
vie. Ils sont lis certaines activits ponctuelles du projet telles que le choix du progiciel,
ltablissement des buts stratgiques du projet, etc. Il sagit de tous les facteurs de la
catgorie systme et de certains facteurs de la catgorie management - tel que la
formation des utilisateurs. Par exemple le facteur Gestion inadquate de la conversion
des donnes est class par (Al-Mashari et al. 2003; Chen et al. 2006), (Motwani et al.
2005) et (Zhang 2009) en fin de phase dimplantation.
2.2.4
Influences entre les facteurs de risque ou de succs
Les travaux tudis sur ce thme dcrivent diffrentes influences entre facteurs. Celles-ci
peuvent tre de causalit, de covariance et de rsidualit.
Linfluence causale entre facteurs implique quun facteur gnre un autre facteur (Akkermans
and Van Helden 2002b; Bueno and Salmeron 2008; Peng and Nunes 2009; Tsai et al. 2009d;
Aloini et al. 2012a; Aloini et al. 2012b). Ainsi, par exemple, un support actif du comit de
pilotage va se matrialiser par un dveloppement des activits de communication (Bueno and
Salmeron 2008). Selon (Aloini et al. 2012a; Aloini et al. 2012b) cest chaque entreprise
dtablir les influences causales propres son projet. Dans le cadre de ces travaux aucune
illustration nest donne. Les autres auteurs, savoir (Akkermans and Van Helden 2002b;
Ojala et al. 2006; Bueno and Salmeron 2008; Peng 2009; Tsai et al. 2009d), illustrent la
notion dinfluence causale travers quelques facteurs. Ces influences sont dfinies sur la base
dtudes de cas, soit denqutes auprs de personnes ayant particip un projet ERP ou
encore de revues de littrature. Connatre les influences causales est utile pour le management
des facteurs de risque car il ne doit pas se faire indpendamment pour chaque facteur. En
effet, si un facteur influenant un autre facteur nest pas trait, il y a des chances que le
facteur influenc se matrialise en raison de cette influence causale. Voici quelques exemples
des influences causales que nous avons mises jour :
-
Le facteur buts stratgiques mal dfinis influence le facteur besoins rels mal
exprims (Akkermans and Van Helden 2002b).
Le facteur instabilit organisationnelle / manque dexpertise / dimplication de
lentreprise influence les facteurs besoins rels mal exprims , manque
dimplication / dexpertise du comit de pilotage (Akkermans and Van Helden 2002b) et
mauvaise gestion des risques (Ojala et al. 2006).
Le facteur manque dexpertise / dimplication / absence de consultants externes
influence les facteurs gestion de projet inefficace (Tsai et al. 2009a), instabilit
organisationnelle / manque dexpertise / dimplication de lentreprise (Akkermans and
Van Helden 2002b) et besoins rels mal exprims (Peng and Nunes 2009).
Le facteur mauvaise gestion des ressources financires et matrielles influence les
facteurs instabilit organisationnelle / manque dexpertise / dimplication de
lentreprise (Akkermans and Van Helden 2002b), formation inadquate / insuffisante
63
des utilisateurs finaux et gestion inadquate du non-alignement (Peng and Nunes

2009).
(Akkermans and Van Helden 2002b) approfondissent la notion dinfluence causale en
suggrant quelles forment des cercles vertueux ou vicieux. En effet, deux facteurs peuvent
sinfluencer mutuellement de manire positive ou ngative. (King 2005) approfondit la
proposition de (Akkermans and van Helden 2002a) en regroupant les facteurs de succs selon
(1) quils font partie du contexte organisationnel incluant la communication au sein du
projet et la stabilit de lentreprise ou (2) quils concernent les membres du projet - chef de
projet, comit de pilotage, intgrateurs, etc. - ou encore, (3) quils concernent lorganisation
du projet savoir les buts, la gestion de projet, la slection du progiciel, les ressources
humaines ou la formulation des besoins. Puis les influences entre les groupes de facteurs sont
agrges. Ainsi le contexte organisationnel influence les membres du projet qui eux
supportent lorganisation du projet.
La covariance des facteurs signifie quun facteur de succs seul ne peut mener au succs
du projet (Wang et al. 2008). Ainsi, pour une tche donne durant le projet, les facteurs
doivent se complter et travailler ensemble . Au niveau de la gestion du non-alignement
entre les processus souhaits par lentreprise et les processus standards, un certain nombre
dexemples de facteurs internes et externes (cf. section 2.2.2 de ce chapitre) devant se
complter sont donns. Ainsi, par exemple, le rle des consultants externes et des membres
internes de lentreprise est didentifier ensemble ce non-alignement, le rle du fournisseur qui
est externe est de proposer des moyens pour le mettre en uvre - par ladaptation de lERP,
par exemple.
Enfin, la rsidualit des facteurs se dfinit comme linfluence que peut avoir le non traitement
dun facteur de risque dune phase du projet sur la phase suivante du projet (Deng and Bian
2008). La notion de rsidualit a t introduite par (Kajko-Mattsson and Nyfjord 2008) sous le
terme de lien consquentiel . Elle est galement aborde par (Velcu 2010) qui stipule quil
y a une forte interdpendance entre les phases dun projet. Ainsi, le succs dune phase
influence le succs dune autre phase. Plus exactement, les facteurs de risque qui ne sont pas
traits au cours dune phase ont un impact sur les phases suivantes. Ainsi, soit ces facteurs
engendrent la matrialisation de nouveaux facteurs de risque ; soit ils doivent tre traits au
cours de la phase suivante. Dans le premier cas, la rsidualit est un cas particulier de
linfluence causale entre facteurs. Il sagit du cas o le facteur influenc se matrialise au
cours de la phase suivant celle o se matrialise le facteur qui influence. (Deng and Bian
2008) proposent ainsi un mcanisme de management consistant toujours identifier,
valuer et traiter les facteurs dune phase et ceux de la phase prcdente qui nont pas t
traits.
64
2.3
Approches de management des facteurs de risque
Puisque notre objectif consiste traiter le RNA, nous nous intressons, dans cette section,
uniquement aux tapes didentification et de traitement des facteurs de risques telles quelles
sont dfinies dans la section 3.1 de ce chapitre. Nous tudions, les outils proposs par (Ho et
al. 2009), (Iskanius 2009) et (Zafiropoulos et al. 2005) pour les projets ERP. Comme il sagit
dun sujet naissant dans ce domaine, il nous a sembl judicieux de les complter par une
prsentation de deux approches fortement cites dans la littrature provenant du domaine des
projets S.I. en gnral savoir (Boehm 1991) et (Morley 2001).
Dune manire gnrale, les outils utiliss pour identifier les facteurs de risque se divisent en
deux catgories :
-
Check-list de facteurs de risque : (Boehm 1991) propose, pour les projets S.I. en gnral,
une checklist des 10 facteurs de risque les plus influents tablie grce une enqute
auprs de managers de projets expriments. (Zafiropoulos et al. 2005) et (Morley 2001)
sont, eux, plus prcis. Les premiers dfinissent, pour chaque facteur de risque, une
question et trois rponses possibles. Les rponses choisies permettent de dterminer si un
facteur sest matrialis ou non. Ainsi, par exemple pour le facteur relatif la dfinition
des besoins, la question propose est les besoins fonctionnels sont : et les rponses
possibles sont simples et comprhensibles , peu connues mais complexes et trs
vagues et complexes . Ainsi, si la rponse est simples et comprhensibles , le facteur
ne sest pas matrialis au cours du projet. (Morley 2001), quant elle, propose de vrifier
un ensemble de dimensions pour chaque facteur. La matrialisation dune dimension
amne la matrialisation du facteur lui-mme. Par exemple, la difficult technique est
analyse travers lexprience de lentreprise sur les techniques utilises , la
diffusion de ces techniques sur le march ou encore lexistence de la direction
informatique interne . La criticit dun facteur varie selon le nombre de dimensions
matrialises. Cela permet, pour lensemble des facteurs de risque, de reprsenter le profil
de risque du projet.
Points de vrification ou questionnaire en relation avec le cycle de vie du projet : (Ho et
al. 2009) proposent un ensemble de checks pour chaque phase du cycle de vie solution feasibility check, solution integration check, solution performance tunning,
data integrity check, operational check ou encore data consistency check. Ils ne
sont pas dtaills mais chacun dentre eux est associ un ensemble de facteurs de risque.
Par exemple, le check nomm vrification de lintgration de la solution permet
didentifier les facteurs de risque li aux adaptations de lERP ou encore aux problmes
techniques. (Iskanius 2009) propose, quant lui, dappliquer une liste de questions en
relation avec les phases du cycle de vie du projet ERP mais qui nest pas dtaille par
lauteur.
Les outils de traitement sont moins dtaills et se divisent en deux catgories :

-
Actions ou activits de traitement : il sagit des propositions les plus courantes. (Boehm
1991) et (Ho et al. 2009) ne dtaillent pas ces activits. Le premier propose cependant de
les cadrer en se posant les questions suivantes : Pourquoi ? Quoi ? Quand ? O ?
Comment ? Combien ? (Zafiropoulos et al. 2005) donnent, plus de prcisions mais les
activits proposes restent, cependant, vagues car incluses dans la dfinition de chaque
facteur. Ainsi, par exemple, concernant le facteur li au manque dexprience des
membres de lquipe du projet, lauteur dfinit la notion de manque dexprience. Puis il
65
conseille, tout en dfinissant cette notion, de choisir des membres avec une exprience
technique. Enfin, (Morley 2001) dtaille finement un ensemble dactivits mais qui ne
sont pas rutilisables dans le cadre du projet ERP. Il sagit entre autres de choisir cette
stratgie de dveloppement en fonction des difficults rencontres puis dlaborer un plan
de dveloppement en vue de mettre en uvre la stratgie au cours du projet. La stratgie
de dveloppement consiste choisir un modle de dveloppement - spiral, cycle RAD
signifiant Rapid Application Development, W, etc. - sachant que pour chaque profil de
risque, il existe un modle de dveloppement appropri. Par exemple, un problme li
aux utilisateurs peut tre rsolu en favorisant la participation et la prise de dcision
grce au cycle RAD.
Gestion de sous-projets : (Iskanius 2009) propose de diviser le projet en sous-projets project scope management, communication management, human resource
management, time management, etc. - pour traiter les facteurs risques. Cependant, il
nexplique pas davantage en quoi consiste la gestion de chaque sous-projet.
2.4
Conclusion et mise en perspective par rapport au cas dtude
Lanalyse des travaux de la littrature montre que la majorit se focalise sur les listes de
facteurs de risque et seulement une dizaine des 87 contributions tudies propose un
processus de management. Cependant, uniquement trois dentre-elles tudient les tapes
didentification et de traitement. Les outils utiliss restent trop peu dtaills pour pouvoir tre
mis en uvre au cours dun projet ERP. En particulier, les actions de traitement pourraient
tre approfondies par lintermdiaire de la notion de pratique de gestion, dfinie ainsi :
-
The words practice management have been used by financial advisers, consultants and
product advisers to describe various aspects and activities prevalent in running a financial
services practice, selon linstitut des pratiques de management5. Traduit en : les mots
pratiques de management ont t utiliss par les conseillers et consultants financiers et
par les conseillers en produit pour dcrire les aspects et activits divers qui prvalent dans
la pratique (ou la gestion) dune entreprise de services financiers.
Pour (Wenger 1998), la pratique relve du faire, dans ses dimensions la fois
historiques et sociales, et dans sa capacit produire de la structure et une signification
aux actions. Ce concept de pratique inclut la fois le champ de lexplicite (le langage, les
outils, les documents, les symboles, les procdures, les rgles que les diffrentes pratiques
rendent explicites), et le registre du tacite (relations implicites, conventions, hypothses,
reprsentations sur le monde). (Chanal 2000)
Toute pratique de gestion na pas ncessairement prouv quelle ft une bonne pratique. Selon
(Baumann-Chardine 2011) :
-
Une bonne pratique est formalise. Sa formalisation prend souvent la forme de fiche.
Cette fiche est structure en trois parties : le problme rencontr est minutieusement
dcrit ; puis la solution apporte ce problme est alors dtaille par lindividu ; enfin les
rsultats obtenus sont indiqus, preuve que cest une pratique efficace et qui ncessite une
rutilisation (Perrin 2006).
http://www.practice101.net/General/Default.aspx
66
Elle est efficace. Son efficacit doit se mesurer sur lensemble des critres dvaluation
de la performance dun processus : la pertinence, la cohrence, lefficacit, lefficience, la
robustesse et la prennit (Bronet 2006).
Elle est rutilisable. En effet, bien qutant attache un contexte, une bonne pratique est
appele tre reproduite fidlement, ou plus couramment, tre adapte un autre
contexte - a best practice could be adapted to another situation (KIT17)6.
De plus, les travaux sur les influences entre facteurs et ceux sur les classifications pourraient
tre exploits pour optimiser le RNA en agissant sur son occurrence. Il sagirait entre autres
de dfinir plus finement les influences entre facteurs de risque et RNA. Celles-ci ne sont pas
tablies car il est considr gnralement que tous les facteurs influencent tous les risques.
Afin de traiter le RNA en agissant de manire anticipative sur son occurrence, une entreprise
doit mettre en place un processus de management des facteurs de risque. Cela na pas t le
cas pour la socit X. A premire vue, les facteurs de risque suivants auraient pu tre
identifis et ne lont pas t :
-
Mauvaise expression de besoins : il ny a quasiment pas eu de formalisation des

besoins, ils taient pour la plupart formuls oralement. Le seul document pouvant faire
office de besoins exprims reprsentaient 9 processus - de vente de produits standards, de
vente de produits clients, de fabrication sur mesure, de fabrication de produits standards et
clients, de comptabilit etc. Il sagissait des processus tels quils taient excuts dans
lexistant avec des annotations concernant les changements souhaits sur ces processus.
Gestion inadquate du non-alignement : les runions dadquation nont quasiment
pas t prpares lavance, le non alignement a t identifi oralement, au fur et
mesure, durant les runions, travers la projection des crans utilisateurs de SAGE X3.
Problme avec le chef de projet : il ny avait pas de chef de projet.
Malgr nos recommandations, la socit X na pas mis en place une dmarche lui permettant
didentifier et de traiter les facteurs de risque de son projet ERP. Certaines runions du comit
de pilotage ont t organises pour discuter des problmes rencontrs au cours du projet.
Cependant, leur description est reste floue, macroscopique et sans structuration. Pas de
dynamique durant le projet , les tapes du projet ne sont pas respectes , les membres
du projet ne se comprennent pas , telles sont les phrases quon pouvait entendre durant ces
runions. Il ne sagissait pas den tablir la cause, cest--dire didentifier les facteurs de
risque traiter.
Aucune bonne pratique na t rellement mise en place lors du projet ERP de la socit X.
Quelques rares mesures ont cependant t prises telle que la mise en place dune assistance de
lintgrateur pour les membres de lentreprise.
Royal Tropical Institut (KIT). Disponible sur www.kit.nl
67
Conclusion du chapitre
Dans ce chapitre, nous avons identifi les diffrentes voies possibles pour traiter le risque de
non-alignement dans les projets ERP. Nous avons analys les travaux existants permettant de
mettre en uvre deux stratgies anticipatives complmentaires doptimisation agissant sur
loccurrence et sur leffet du RNA. Ils mritent cependant dtre davantage dvelopps pour
satisfaire aux exigences du terrain et pour constituer pleinement des moyens pour traiter le
RNA. Cest ce que nous proposons de faire travers nos deux contributions prsentes aux
chapitres 4 et 5, mettre en uvre durant ltape dadquation du projet ERP.
A lissue de chapitre 3, nous achevons ltape de rflexion du premier cycle de la spirale de
recherche / action (cf. Figure 26).
Stratgie agissant sur leffet

Peu dencadrement pour
-Lidentification du rsultat indsirable - nonalignement - associ au RNA
-Lvaluation de ce non-alignement et son association
des dcisions adquates
Stratgie agissant sur loccurrence

Peu de structuration pour
Lidentification et le traitement des facteurs
de risque
Comparaison ralit terrain et littrature

Mthodes dingnierie dirige par les modles
-Identification du non-alignement : formalismes bien exploits,
niveaux de granularit et vues de modlisation dentreprise peu
exploits
-Evaluation et association aux dcisions : pas dvaluation,
association aux dcisions macroscopique et pas de prise en compte
des interdpendances
Moyens pour identifier et traiter les facteurs

de risque
-Peu dapproches didentification et de
traitement
-Outils proposs peu dtaills
-Classifications et influences peu exploites pour
ces tapes
-Tous les facteurs influencent tous les risques
Figure 26- Phase de rflexion de la dmarche de recherche / action
68
Chapitre 4 Model Driven ERP Alignment
Chapitre 4 Model Driven - ERP

Alignment
Nous proposons dans ce chapitre une mthode dingnierie dirige par les modles Model
Driven - ERP Alignment qui constitue un moyen pour mettre en uvre la stratgie
doptimisation anticipative agissant sur leffet du RNA durant ltape dadquation du projet
ERP.
Cette mthode consiste en un processus dalignement de modles qui vise combler les
manques des mthodes existantes en permettant :
-
didentifier finement les situations dalignement et de non-alignement entre les modles

des processus souhaits par lentreprise et ceux que lERP propose en standard,
construire progressivement et de manire guide le modle TO-BE en couplant critres
dvaluation et prise de dcision.
La section 1 est consacre une prsentation gnrale de la mthode. Nous y prsentons les
modles entrant en jeu dans la mthode ainsi quune vision macroscopique du processus
dalignement. La section 2 dtaille chaque activit de ce processus ainsi que les outils utiliss
pour la mettre en uvre.
1
1.1
Prsentation gnrale de la mthode

Vue macroscopique du processus dalignement
Le processus dalignement que nous proposons est prsent de manire macroscopique dans
la Figure 27. Les quatre modles entrant en jeu dans ce processus sont repris des mthodes
dingnierie dirige par les modles existantes. Nous rappelons que :
-
Le modle AS-IS permet la reprsentation des processus existants de lentreprise.

Le modle AS-WISHED permet la reprsentation des processus souhaits de lentreprise :
ce sont ses besoins exprims pour lesquels nous faisons lhypothse quils correspondent
bien aux besoins rels.
Le modle MIGHT-BE permet la reprsentation de la solution offerte par lditeur cest-dire des processus standards de lERP. Ce modle contient diffrentes alternatives du fait
du caractre paramtrable de lERP.
Le modle TO-BE permet la reprsentation des processus qui seront rellement implants
lissue du projet ERP au sein du S.I. ERP.
69
Les langages de modlisation utiliss pour reprsenter ces modles sont des formalismes
classiques.
Vues de modlisation
(norme ISO 19439)
Phases du cycle de vie du modle TO-BE

(norme ISO 19439)
Dfinition des besoins de lentreprise
Vue
informationnelle
Vue
fonctionnelle
Vue
intentionnelle
Conception du modle TO-BE
Figure 27- Processus dalignement macroscopique
70
Le processus dalignement est un enchanement dactivits de construction et confrontation de

modles et de prise de dcision structur autour des vues de modlisation suivantes :
intentionnelle, fonctionnelle et informationnelle. La confrontation des modles permet
didentifier les situations dalignement ou de non-alignement, auxquelles un panel dtaill de
dcisions est associ. La prise de dcision est guide par une valuation de leffet du nonalignement. Outre, les dcisions ncessaires la construction du modle TO-BE dune vue
donne, nous proposons dy ajouter, le cas chant, une dcision de complment la
conduite du changement . Elle met laccent sur les actions entreprendre lorsque le modle
TO-BE nest pas construit limage du modle AS-WISHED. Contrairement aux mthodes
existantes tudies dans le chapitre 3, les vues de modlisation sont prises en compte dans un
ordre privilgi permettant une construction itrative du modle TO-BE pour lensemble des
vues. En effet, les dcisions relatives la construction du modle TO-BE dune vue donne
sont capitalises pour construire le modle TO-BE de la vue de modlisation suivante. Nous
proposons dappliquer le processus dalignement domaine par domaine conformment la
norme (ISO 19439 2006). Les interdpendances des processus au sein dun domaine donn
sont exploites pour prendre les dcisions de manire conjointe et cohrente. Les modles
confronter, AS-WISHED et MIGHT-BE, peuvent tre construits en parallle ou lun aprs
lautre. La construction du modle AS-IS napparat pas explicitement dans notre proposition
mais est nanmoins utile pour analyser lexistant et servir de base la construction du modle
AS-WISHED par lentreprise. Les activits du processus dalignement sont les suivantes :
-
Construire la vue intentionnelle des modles AS-WISHED et MIGHT-BE pour lensemble

des processus pour un domaine donn. Ainsi, chaque but formul est associ un
processus dentreprise.
Confronter les construits de la vue intentionnelle des modles AS-WISHED et MIGHT-BE
but par but. Cela permet lidentification des situations dalignement et de non-alignement
pour cette vue. Pour chaque but, trois situations sont possibles : (i) soit il y quivalence du
but dans les deux modles, (ii) soit le but existe uniquement dans le modle MIGHT-BE but dcouvert, (iii) soit le but existe uniquement dans le modle AS-WISHED - but non
satisfait. Une dcision est associe chaque situation identifie pour construire
progressivement la vue intentionnelle du modle TO-BE.
Construire la vue fonctionnelle des modles AS-WISHED et MIGHT-BE pour tous les
processus associs aux buts formuls dans le modle TO-BE intentionnel. La construction
de cette vue pour lensemble des processus permet lidentification des interdpendances
entre processus au sein du domaine considr.
Confronter les construits de la vue fonctionnelle des modles AS-WISHED et MIGHT-BE
processus par processus en trois tapes : (1) dabord les processus associs aux buts non
satisfaits (absents du modle MIGHT-BE et modliss dans le TO-BE limage du
modle AS-WISHED), (2) puis les processus associs aux buts quivalents et enfin (3) les
processus associs aux buts dcouverts (absents du modle AS-WISHED et modliss
dans le TO-BE limage du modle MIGHT-BE). Cela permet lidentification des
situations dalignement et de non-alignement sur la vue fonctionnelle pour chaque
processus. A chaque situation identifie, est associe une dcision. Cela dtermine les
processus mis sous contrle de lERP pour construire progressivement le modle TO-BE
71
1.2
fonctionnel. Avant de prendre une dcision sur les activits dun processus, nous donnons
la possibilit de les modliser un niveau de granularit plus fin. Le modle TO-BE
obtenu sur cette vue oriente alors la construction de la vue informationnelle.
Construire la vue informationnelle des modles AS-WISHED et MIGHT-BE.
Confronter les construits de la vue informationnelle des modles AS-WISHED et MIGHTBE pour chaque entre / sortie. Cela permet lidentification des situations dalignement et
de non-alignement pour cette vue. A chaque situation identifie, est associe une dcision
permettant de construire progressivement le modle TO-BE informationnel.
Processus dalignement et norme ISO 19439
Le processus dalignement propos respecte les trois dimensions de la norme (ISO 19439
2006) dfinies en section 1.1.1 du chapitre 3.
De manire gnrale, prendre en compte les vues de modlisation permet de filtrer les
observations du monde rel en mettant laccent sur certains aspects qui sont pertinents par
rapport aux objectifs et contexte de modlisation. Cela permet de structurer la construction et
la confrontation des modles mais aussi et surtout rendre la construction de lalignement plus
efficace. Nous prenons en compte trois vues :
-
La vue intentionnelle, base sur le concept de but, permet de se concentrer sur les objectifs
sans sattacher immdiatement la manire de les satisfaire ; il est donc possible
didentifier, ds le dbut du processus dalignement, des non-alignements potentiels, do
notre proposition de la traiter en premier.
La vue fonctionnelle est au cur de la modlisation des processus dune entreprise. Elle
est considre comme centrale dans les architectures de rfrence de modlisation
dentreprise telles que CIMOSA, UEML ou encore ISO (Kosanke et al. 1999; Vernadat
2002; ISO/DIS 19440 2004), la vue informationnelle gravitant autour delle.
Intuitivement, cest le premier moyen quutilisent les entreprises pour exprimer leurs
besoins. Le traitement de cette vue, en particulier le traitement des activits et des entres /
sorties, est donc ltape principale de notre processus dalignement.
La vue informationnelle sintresse aux caractristiques des lments dinformation en
entre / sortie, dfinis lors du traitement de la vue fonctionnelle. Do notre proposition de
la traiter aprs la vue fonctionnelle.
Les quatre modles mis en jeu au cours au cours de la mthode Model Driven - ERP
Alignment ont les niveaux de gnricit de la norme (ISO 19439 2006) suivants :
-
Le niveau partiel est celui du modle MIGHT-BE. En effet, il sagit de construire un

modle reprsentant lensemble des fonctionnalits standards de lERP pouvant tre mises
en uvre pour un ensemble dentreprises.
Le niveau particulier est celui des modles AS-IS, AS-WISHED et TO-BE. Chacun de ces
modles est spcifique lentreprise.
Pour chacune des vues, cest--dire intentionnelle, fonctionnelle et informationnelle, un

modle partiel - MIGHT-BE - est confront avec un modle particulier - AS-WISHED.
Lentreprise va identifier si, parmi les alternatives qui soffrent elle, une lui convient.
72
La dimension des phases du cycle de vie des modles de la norme (ISO 19439 2006) permet
de structurer la construction du modle TO-BE :
-
Les phases 1 et 2 de ce cycle de vie, savoir la dfinition du domaine tudi et la

dfinition des concepts , sont prliminaires la dfinition des besoins dune entreprise.
Elles sont mises en uvre avant lapplication du processus dalignement, lors de la phase
de pr-implantation.
Les phases 3 et 4 sont mises en uvre pour chaque vue de modlisation successivement
durant ltape dadquation (premire tape de la phase dimplantation). La phase 3 de
dfinition des besoins de lentreprise est mise en uvre travers les activits de
construction des vues intentionnelle, fonctionnelle et informationnelle du modle ASWISHED. La phase 4 de conception du modle est mise en uvre travers les
activits de construction du modle MIGHT-BE, de sa confrontation avec le modle ASWISHED ainsi que de prise de dcision pour la construction du modle TO-BE.
Les trois dernires phases du cycle de vie des modles proposes par la norme (ISO 19439
2006) sont mises en uvre dans les dernires tapes du cycle de vie du projet ERP et de
lERP. La phase 5 de description de limplantation correspond aux tapes
dintgration et tests et de mise en production de la phase dimplantation. Elle consiste
appliquer rellement au systme les dcisions prises pour construire le modle TO-BE. La
phase 6 d utilisation des modles correspond aux phases de post-implantation et
daprs-projet. Elle consiste en lutilisation de lERP par les utilisateurs finaux. La phase 7
de fin de vie des modles prend place lors de ltape de fin de vie de laprs-projet.
1.3
Prise de dcision
1.3.1
Six dcisions
Nous proposons six dcisions associer aux situations dalignement et de non-alignement.

Elles regroupent lensemble des dcisions dfinies dans la section 1.3.2 du chapitre 3,
auxquelles nous avons donn une dsignation qui nous a sembl la plus explicite. Deux
dcisions supplmentaires ont t ajoutes : labandon total dun besoin exprim et le
complment la conduite du changement (cf. Tableau 11).
Dcisions
Variantes
/
Modification des lignes de code
D2 : Dveloppement spcifique dans lERP
Ajout de lignes de code
Interfaage dun progiciel avec interface prvue
D3 : Ajout dune brique applicative
Interfaage dun progiciel sans interface prvue
Interfaage dun logiciel dvelopp spcifiquement
D4 : Support manuel
/
D5 : Abandon
/
D6 : Complment la conduite de changement /
Tableau 11- Les dcisions et leurs variantes
D1 : Paramtrage
Le paramtrage (D1) consiste choisir une alternative parmi celles proposes par
lERP pour des activits et objets, des crans, des rapports ou tats.
73
Le dveloppement spcifique dans lERP (D2) est possible dans la limite de laccs au
code. Il peut concerner des activits, des objets, des crans, des rapports, ou encore des
conditions sur ces lments et peut prendre diffrentes formes :
Modification de lignes de code : il consiste modifier le code source de lERP.
Ajout de lignes de code : il consiste ajouter du code au code source standard de
lERP sans modifier celui-ci.
Si le code source nest pas disponible, les dcisions D3, D4 ou D5 sont possibles.
L ajout dune brique applicative (D3) consiste ajouter un logiciel supplmentaire et
linterfacer lERP. La brique interface peut tre de nature diffrente :
Progiciel avec interface prvue : il faut dans ce cas paramtrer linterfaage du
progiciel avec lERP.
Progiciel sans interface prvue : il est ncessaire de dvelopper et paramtrer
linterface de ce progiciel avec lERP.
Logiciel dvelopp spcifiquement : il sagit de dvelopper un logiciel et son
interface avec lERP.
Le support manuel (D4) correspond une gestion du besoin compltement en dehors
du S.I. ERP : manuellement, plus ou moins formalise ou aide par des outils
bureautiques. Cela peut sappliquer des activits ou des conditions sur des activits.
L abandon (D5) consiste ne pas supporter le besoin exprim.
La mise en place du S.I. ERP ncessite que lon sintresse galement la question de son
utilisation efficace et efficiente dans lentreprise. Les nouveaux modes de
fonctionnement (nouvelles procdures attribues, nouvelles formes de donnes manipules,
nouveaux crans, nouvelles interfaces...) induits par la mise en place de lERP impacte les
utilisateurs finaux. Ils peuvent alors faire preuve de rsistance face au changement et avoir du
mal intgrer ou comprendre les nouvelles pratiques de travail qui leur sont imposes.
Nous faisons lhypothse que lentreprise a conduit le changement relatif la diffrence entre
les modles AS-IS et AS-WISHED. Le traitement du RNA nous conduit proposer
lentreprise une aide la dcision lorsque les dcisions de construction du modle TO-BE
diffrent de ce quelle avait prvu dans le modle AS-WISHED. La sixime dcision de
complment la conduite de changement est prise conjointement une des cinq dcisions
prcdentes durant le processus dalignement. Elle recouvre les actions suivantes :
-
organiser une formation sur de nouveaux concepts sil y a mise en place dactivits ou de
donnes dcouvertes et implantes,
ajuster les procdures en fonction des nouveauts,
rdiger la documentation sur des logiciels, des interfaces ou des fonctions supplmentaires
dveloppes spcifiquement et que lditeur dERP ne propose donc pas,
organiser une communication accrue sur les activits dont la codification des donnes en
E / S ne correspond pas celle souhaite,
grer limpact des nouveaux rles ou des rles souhaits et non implants.
74
1.3.2
Critres pour la prise de dcision
Lorsque le modle MIGHT-BE est diffrent du modle AS-WISHED, lentreprise doit faire
un choix entre lune ou lautre des cinq premires dcisions (D1 D5). Nous proposons
quatre critres pour aider lentreprise faire ce choix :
-
Le cot : adapter le S.I. base dERP, que ce soit en faisant un dveloppement spcifique
dans lERP ou en ajoutant une brique applicative, peut tre coteux pour lentreprise en
termes de temps, dargent ou encore de ressources impliques pour effectuer les
dveloppements. Les ressources tant limites, surtout pour les PME (cf. section 3.1 du
chapitre 2), celle-ci doit les allouer efficacement pour mener bien son projet.
Lentreprise doit valuer ces cots et/ou ngocier avec lintgrateur choisi. Des mthodes
daide lvaluation des cots, comme celle de (Yahia 2011) valuant linteroprabilit
entre les systmes dinformation dentreprise, peuvent tre utilises.
Lintrt pour lentreprise : une alternative est intressante pour lentreprise si elle
contribue sa performance. Plusieurs mthodes permettant dvaluer la performance des
processus dentreprise peuvent tre mises en uvre telle que la mthode ECOGRAI
(Bitton 1990).
Lintgrit de lintgration : les dcisions de dveloppement spcifique dans lERP ou
dajout de brique applicative interfac lERP risquent de perturber lintgration native
du systme ERP propos en standard par lditeur et porteur de bonnes pratiques. Par
ailleurs, lors des montes de version de lERP, ces dveloppements sont trs rarement
compatibles. Les membres de lentreprise, ne pouvant valuer ce critre eux-mmes,
doivent tre vigilants ce que lintgrateur le prenne en compte.
La cohrence du modle TO-BE en-cours de construction : la dcision de paramtrage
prise lors du non-alignement dun construit (reprise du modle MIGHT-BE au lieu de ASWISHED) peut remettre en cause la pertinence du AS-WISHED sur dautres construits.
Ce critre est gr au niveau de lanalyse des interdpendances lors du traitement de la
vue fonctionnelle.
Activits du processus dalignement par vue de

modlisation
Pour les activits de construction des modles, nous dtaillons les construits modliss pour
chaque vue. Pour ce faire, nous nous basons sur la dfinition quen fournit la norme (ISO/DIS
19440 2004). Nous prconisons lutilisation de formalismes existants. La construction des
modles AS-WISHED et MIGHT-BE sappuie sur la connaissance des personnes
interroges : les membres de lentreprise pour le modle AS-WISHED et lditeur et / ou
lintgrateur pour le modle MIGHT-BE.
Pour les activits de confrontation et prise de dcision, nous dfinissons lensemble des
situations dalignement et de non-alignement possibles pour chaque construit de chaque vue.
Nous les associons aux critres valuer et aux dcisions potentielles prendre pour
construire le modle TO-BE. La confrontation des modles est ralise visuellement. De plus,
contrairement certains auteurs (cf. section 1.2 du chapitre 3) qui dfinissent plusieurs degrs
75
dalignement ou de non-alignement entre les construits de deux modles confronts, nous

considrons quun construit est soit align, soit non-align. Nous faisons lhypothse que
lapprciation de lalignement entre deux construits repose sur le jugement des experts de
chaque domaine considr.
2.1
2.1.1
Vue intentionnelle
Construire les modles AS-WISHED et MIGHT-BE
Pour la vue intentionnelle telle que nous lavons dfinie dans la section 1.1.2 du chapitre 3,
nous nous intressons aux buts fonctionnels. La construction de cette vue du modle ASWISHED consiste modliser les buts que lentreprise souhaite voir satisfaits par lERP.
Pour le modle MIGHT-BE, il sagit pour lintgrateur et / ou lditeur choisi, de modliser
les buts satisfaisables par lERP en standard.
Suite lanalyse que nous avons faite des langages de modlisation des buts dans la section
1.1.2 du chapitre 3, nous avons choisi le langage KAOS. En effet, il rpond nos besoins de
modlisation car il (i) est intuitif, (ii) permet de reprsenter le concept de but de manire semiformelle, (iii) est suffisamment expressif permettant les raffinements Comment ? ,
Pourquoi et Dcomposition mais galement la formulation des buts fonctionnels sous
forme Achieve goals, Maintain goals etc. et enfin (iv) permet de faire le lien avec le
construit activit dentreprise de la vue fonctionnelle. Ce langage permet de reprsenter
les buts raffins sous forme de graphes. Un but X raffin par un but Y sera situ un niveau
suprieur dans larbre. Par exemple, dans la Figure 28, le but Achieve Request Satisfied a
t raffin en deux buts Achieve Request Issued et Achieve Request Handled.
Figure 28- Pattern Achieve Request Satisfied de KAOS (Respect-IT 2007)
De plus, le langage KAOS fournit :

76
Des Patterns gnriques qui doivent tre instancis au cas particulier dun projet et qui
permettent de formuler un but sous la forme Achieve ou Cease ou Maintain ou
Avoid + nom + verbe au participe pass. Par exemple, sur la Figure 28, le but Achieve
Request Satisfied peut tre instanci par le but Achieve Demande de location de
produit satisfaite . De mme, les buts Achieve Request Issued et Achieve Request
Handled peuvent respectivement tre instancis par les buts Achieve Demande de
location mise et Achieve Produit lou . Ces patterns sont modifiables selon les
besoins de modlisation.
Une dmarche accompagnant le raffinement Comment ? . Nous reprenons la dmarche
en deux tapes de (Dardenne et al. 1993) qui permet, le cas chant, de modifier ou
complter les Patterns :
Etape 1 : formuler les buts non oprationnels parents , Par exemple :
Satisfaire
la
demande
demprunt
dun
livre (traduction
de
BookRequestSatisfied).
Etape 2 : pour chaque but non oprationnel formul :
A : formuler les actions qui leur sont lies ainsi que les prconditions de
ces actions et formuler les entres / sorties de chaque action - ce qui
correspond la vue fonctionnelle. Par exemple : Faire une demande
demprunt (sortie : demande) et faire le check-out du livre (sortie :
demande) qui a comme prcondition : un exemplaire du livre est
disponible dans la bibliothque .
B : raffiner les buts en sous-buts sur la base des prconditions en se
posant la question comment ? . Par exemple : le but parent peut
donc tre atteint non pas uniquement par lexcution des actions
formules en A), mais aussi par la satisfaction dun de ses sous-buts qui
permet de satisfaire la prcondition : Achieve Suffisamment
dexemplaires du livre disponibles la bibliothque , Achieve
Disponibilit rgulire du livre garantie la bibliothque et Achieve
Emprunteur averti en cas de retour dun exemplaire du livre demand .
C : parmi les sous-buts obtenus, retourner ltape 1 sils ne sont pas
encore oprationalisables, sinon arrter le raffinement.
2.1.2
Construire le modle TO-BE intentionnel
Le traitement de la vue intentionnelle consiste confronter / faire correspondre les buts

fonctionnels du modle AS-WISHED ceux du modle MIGHT-BE. Aprs confrontation,
trois situations sont identifiables :
-
La situation dalignement correspond lquivalence des buts entre les modles MIGHTBE et AS-WISHED. Les buts aligns sont ajouts au modle TO-BE.
Les deux situations de non-alignement correspondent la non-quivalence des buts entre
les modles AS-WISHED et MIGHT-BE. Soit les buts sont dcouverts, soit ils sont nonsatisfaits :
But dcouvert : le but existe dans le modle MIGHT-BE mais pas dans le modle
AS-WISHED. Si le but dcouvert intresse lentreprise, elle lajoute dans le
modle TO-BE.
But non-satisfait : le but existe dans le modle AS-WISHED mais est absent du
modle MIGHT-BE. Il nest donc pas satisfait en standard par lERP. En fonction
des critres de cots et dintrt pour lentreprise, le but est ajout dans le modle
TO-BE limage du modle AS-WISHED, ou la dcision D5 d abandon est
77
prise. Dans ce dernier cas, la dcision D6 de complment la conduite de

changement est prise conjointement D5. En effet, lentreprise devra
potentiellement rorganiser la rpartition des rles qui avait t initialement
prvue pour le processus associ ce but abandonn.
Lordre de confrontation des buts nest pas fig. Nous prconisons de regrouper les buts en
buts quivalents, buts dcouverts et buts non satisfaits, puis de prendre les dcisions but par
but pour chaque groupe.
Le modle TO-BE comporte donc, lissue de cette phase, une liste de buts : buts quivalents,
buts dcouverts et buts non satisfaits. Les processus associs ces buts seront traits au
niveau de la vue fonctionnelle.
2.2
Vue fonctionnelle
2.2.1
Il sagit de construire les construits de la vue fonctionnelle des modles AS-WISHED et

MIGHT-BE associs tous les buts qui ont t modliss dans le modle TO-BE intentionnel.
La construction des modles de la vue fonctionnelle prend en compte lidentification des
interdpendances entre processus, ainsi que le choix dun niveau de granularit pour la
modlisation des activits.
2.2.1.1
Les construits et leurs interdpendances
Pour la vue fonctionnelle, nous proposons de modliser les construits suivants (cf. section
1.1.1 du chapitre 3) :
-
processus dentreprise,
activits dentreprise,
vues dobjet en entre / sortie (E / S) des activits.
Le construit domaine nest pas modlis ici ; sa dfinition a t ralise avant la mise en
uvre du processus dalignement. Le construit vnement est modlis implicitement. Une
activit peut gnrer un vnement et galement tre gnre par un vnement. Lexistence
de lactivit ainsi que sa modlisation implique donc implicitement lexistence de
lvnement gnrateur de lactivit et de celui gnr par celle-ci.
Ainsi, nous proposons de modliser lenchanement dactivits composant un processus ainsi
que les attributs des vues dobjet en E / S de ces activits et ventuellement les valeurs prises
par ces attributs. En effet, la norme permet de dissocier les construits vue dobjet et objet
dentreprise (cf. Figure 29). De plus, compte tenu du paramtrage de lERP, certains attributs
des vues dobjet du modle MIGHT-BE nont pas encore de valeurs et dautres ont plusieurs
valeurs possibles choisir. Pour ceux qui nont pas de valeurs, seule lexistence de lattribut
est confronte.
78
Figure 29- Lien entre le construit activit dentreprise et les construits vue dobjet et objet dentreprise
Le formalisme prconis est le diagramme dactivit dUML pour lenchanement dactivits

et le flot dobjet dUML pour les E / S des activits.
La vue fonctionnelle des modles AS-WISHED et MIGHT-BE est construite pour lensemble
des processus associs aux buts du modle TO-BE intentionnel dans la limite de lexistence
de la vue fonctionnelle de ces modles. Ainsi, quand le but tait prsent uniquement dans le
modle MIGHT-BE intentionnel, avant dtre ajout au modle TO-BE intentionnel, on ne
construira, pour ce but, que le modle MIGHT-BE fonctionnel. Il en est de mme pour le
modle AS-WISHED fonctionnel.
Lors de la construction du modle AS-WISHED, nous proposons de marquer les activits qui
ont une interdpendance fonctionnelle de sorte les reprer lors de la confrontation. Il sagit
des interdpendances sur les vnements ou les attributs de vues dobjet en E / S telles que
nous les avons dfinies dans la section 1.1.3 du chapitre 3. Lobjectif est daider lentreprise
prendre des dcisions qui garantissent la cohrence du modle TO-BE en cours de
construction (quatrime critre pour la prise de dcision, cf. section 1.3.2 de ce chapitre). Un
modle cohrent est un modle qui prsente des parties en rapport logique et en harmonie
cest--dire dont toutes les parties se tiennent et sorganisent logiquement (Dictionnaire
Larousse). Prenons lexemple du construit Attribut M de la Figure 30 en sortie de
l Activit X et qui ne trouve pas dquivalence dans le modle MIGHT-BE. Si, pour
construire lalignement, l attribut M est modifi, cela aura un impact sur l activit Y
du modle AS-WISHED. Ces interdpendances sont utiles pour la prise de dcision. Pour les
grer au mieux, nous prconisons dinitier la confrontation par les processus qui gnrent des
interdpendances - ici le processus compos de l attribut M . Ce sont les processus dont les
79
vnements gnrs initient dautres processus ou qui ont en sortie des attributs utiliss en
entre par dautres processus.
Modle MIGHT-BE
Modle AS-WISHED
Activit X
sortie
Attribut M
Activit Y
Situation de non-alignement (absence de

lattribut M dans le modle MIGHT-BE)
Figure 30- Illustration de lintrt de la modlisation des interdpendances au niveau de la vue fonctionnel
2.2.1.2
Les niveaux de granularit
Le construit activit dentreprise de la vue fonctionnelle peut tre modlis diffrents

niveaux de granularit correspondant une dcomposition plus ou moins fine de lactivit.
Les niveaux peuvent tre caractriss en fonction des attributs des vues dobjet en E / S et des
liens entre ces E / S. Le niveau de dcomposition le plus fin est celui de lactivit atomique,
inspir du concept d action du langage UML (Audibert 2009).
Une activit atomique na soit aucune entre, soit un attribut en entre qui ninfluence pas la
sortie, soit deux attributs en entre sur lesquels une seule action est entreprise. Elle a au plus
un attribut de vue dobjet en sortie ayant une et une seule valeur. Le diagramme UML de la
Figure 31 illustre la structure des activits atomiques. Il sagit des activits :
-
De cration, par exemple : crer une commande ou un devis. Dans ce cas, lobjet
dentreprise commande est cr (il sagit dune sortie) mais aucun attribut de lobjet nest
encore instanci.
Denregistrement, par exemple : enregistrer une demande ou un devis. Dans ce cas, les
attributs de lobjet dentreprise demande (ou devis) ont dj t instancis. Seul lattribut
correspondant au statut de la demande sera ventuellement modifi. Il sagit dune sortie.
De rception ou denvoi, par exemple : envoyer la demande daccord au client,
rceptionner une commande. Dans ce cas, seul lattribut correspondant au statut de la
demande daccord sera ventuellement modifi.
De liaison, par exemple : lier la commande dachat avec la demande de Service-AprsVente. Dans ce cas, seul lattribut relatif cette liaison entre les objets dentreprise
concerns sera modifi.
De saisie dun attribut, par exemple : saisir le numro de tlphone du client. Dans ce cas,
seul lattribut tlphone de la vue dobjet client sera instanci.
De calcul lmentaire effectu sur deux attributs, exemple : calculer le salaire. Dans ce
cas, les attributs en entre salaire mensuel et prime sont additionns pour obtenir
lattribut salaire en sortie.
80
Figure 31- Structure dune activit atomique
Les entits peuvent tre agrges ou dsagrges de diffrentes manires selon le lien existant
entre elles. On distingue trois types dagrgation :
-
Type 1 : les activits dcomposables en squences dactivits atomiques,

Type 2 : les activits dcomposables en activits atomiques lies par des nuds de
dcision ,
Type 3 : les activits dcomposables en activits atomiques lies par des nuds
d union .
Les activits dcomposables en squences dactivits atomiques (Type 1) nont pas dentre
ou ont des entres qui ninfluencent pas leurs sorties. Elles ont plusieurs attributs dune ou
plusieurs vues dobjet. Il sagit des activits de saisie dun ensemble dinformations telles que
la saisie des informations dune commande ou encore la saisie des informations dun nouveau
client. Le diagramme UML de la Figure 32 illustre la structure et la dcomposition de ces
activits. Les niveaux de granularit associs la dcomposition en activits atomiques sont
dfinis de la manire suivante :
-
Le niveau de granularit le plus lev correspondant lactivit agrgeant lensemble de

ses attributs en sortie - exemple : saisir les coordonnes du client.
Les niveaux de granularit intermdiaires correspondent la modlisation des activits
avec un sous-ensemble dattributs en sortie, le nombre dattributs des sous-ensembles
tant suprieur strictement 1 - exemples : saisir lancienne adresse, saisir la nouvelle
adresse, saisir la situation professionnelle, etc.
Le niveau de granularit le plus bas correspond la modlisation des activits sous forme
dun ensemble dactivits atomiques avec un seul attribut en sortie - exemples : saisir la
rue de lancienne adresse, saisir la ville de lancienne adresse, etc.
81
Figure 32- Structure et dcomposition dune activit atomique agrge
Pour les activits dcomposables en activits atomiques lies par des nuds de dcision
(Type 2), nous nous basons sur la notion de nud de dcision tel quil est dfini dans le
langage de modlisation UML(Audibert 2009)(Audibert 2009). Le nud de dcision est
un nud de contrle qui permet de faire un choix entre plusieurs flots sortants. Le diagramme
UML de la Figure 33 illustre la structure et la dcomposition de ce type dactivit. Il sagit
des activits qui ont un attribut de vue de dobjet en sortie. Cet attribut peut prendre plusieurs
valeurs. Ces activits ont plusieurs attributs dune ou plusieurs vues dobjet en entre. Les
valeurs prises par les attributs en entre influencent la valeur prise par lattribut en sortie. Il
peut galement sagir dactivits de saisie.
Figure 33- Structure et dcomposition dune activit dcomposable en nud de dcision
Les deux niveaux de granularit associs ce type dactivit sont dfinis de la manire
suivante :
82
Le niveau le plus lev de granularit correspond lactivit avec tous les attributs en
entre et lattribut en sortie sans mise en vidence de linfluence des entres sur la ou les
sortie(s) - exemple : lactivit saisir le type daffectation de larticle expdi a en sortie
lattribut type daffectation de la vue dobjet affectation article . Celle-ci peut
prendre les valeurs par fret ou par colis . Lactivit a aussi en entre les attributs
poids et volume de la vue dobjet article .
Le second niveau de granularit, qui est le niveau le plus bas, consiste modliser les
diffrents chemins possibles. Chaque chemin mne une activit issue de la
dcomposition. Chaque activit obtenue permet dattribuer une valeur lattribut en
sortie. Il y donc autant dactivits modlises que de valeurs possibles pour lattribut en
sortie. Cela permet dobtenir une activit atomique. On obtient donc le niveau de
granularit le plus bas.
Les activits dcomposables en activits atomiques lies par des nuds d union (Type 3)
ont plusieurs attributs dune ou plusieurs vues dobjet en entre qui sont synchroniss par un
nud dunion tel quil est dfini dans le langage de modlisation UML. Un nud
dunion est un nud de contrle qui synchronise les flots multiples. Ces activits ont un
attribut de vue dobjet en sortie. La valeur prise par lattribut en sortie est le rsultat dun
calcul des valeurs des attributs en entre. La dcomposition consiste dcomposer le nud
d union en plusieurs activits atomiques de calcul lmentaire lies par des nuds
dunions . Le diagramme UML de la Figure 34 illustre la structure et la dcomposition de
ces activits.
Figure 34- Structure et dcomposition dune activit dcomposable en activits atomiques lies par des
nuds d union
83
Les niveaux de granularit associs ce type dactivit sont dfinis de la manire suivante :
-
Le niveau le plus lev de granularit correspond lactivit avec tous les attributs en
entre synchroniss par un nud dunion et lattribut en sortie sans mise en vidence
des tapes de calcul - exemple : calculer le salaire des employs qui possde, en
entre, les attributs : revenu par heure , nombre dheures travailles , nombre de
contrats , prime par contrat et, en sortie lattribut salaire .
Les niveaux de granularit intermdiaires correspondent la modlisation dun sousensemble dtapes du calcul. Ce sous-ensemble correspond au moins deux tapes du
calcul. Les activits modlises ont galement plusieurs attributs en entre synchronises
par un nud dunion et dont le nombre est strictement suprieur 2. Elles ont un
attribut en sortie. Par exemple lactivit ajouter la prime possde, en entre, les
attributs : nombre de contrats , prime par contrat , salaire de base . Dans ce cas,
les tapes du calcul inclues dans lactivit sont : calculer la prime et ajouter la prime au
salaire de base. Les nuds dunion permettent de lier les activits issues de la
dcomposition entre elles.
Le niveau de granularit le plus bas consiste obtenir un ensemble dactivits atomiques,
dont chacune correspond une seule tape de calcul. Chacune de ces activits a deux
attributs en entre synchronises par un nud dunion et un attribut en sortie.
Pour conclure sur les niveaux de granularit, nous prconisons le niveau le plus lev pour
chaque type dactivit. Il est bien videmment possible de modliser une activit agrgeant les
3 types dactivits dfinies. Ce choix est li au contexte du projet. Le niveau prconis facilite
la confrontation de deux processus car il revient confronter des enchanements dactivits
linaires. Cela permet de contourner le problme de la bote noire . En effet, le droit
daccs au code source des ERP dit propritaire est limit. Certaines activits ne peuvent
donc tre modlises qu un niveau de granularit lev. Pour ces activits, il est uniquement
possible de connatre leurs E / S.
2.2.2
Construire le modle TO-BE fonctionnel
Lenchanement des activits de confrontation / prise de dcision ddi la vue fonctionnelle

est appliquer chaque processus dentreprise associ un but de la vue intentionnelle du
modle TO-BE. Le choix de lordre de confrontation des processus est libre mme si nous
prconisons lordre suivant : dabord (1) les processus associs aux buts non satisfaits, puis
(2) ceux des buts quivalents et ensuite (3) ceux des buts dcouverts. En effet, les buts non
satisfaits par lERP semblent les plus critiques vis--vis du RNA. Pour ces processus,
lvaluation de leffet de ce non-alignement et lassociation la dcision adquate risquent
dtre plus dlicates que pour les processus associs aux autres buts.
Que ce soit pour les processus associs aux buts non-satisfaits, aux buts quivalents ou aux
buts dcouverts, chaque dcision prise, sauf pour celles consistant ne pas implanter le
construits au sein du S.I. ERP, le modle TO-BE est mis jour.
En cas de confrontation portant sur une activit marque (ayant une interdpendance avec
dautres activits), il est ncessaire de vrifier la cohrence du modle TO-BE en-cours de
84
construction pour prendre une dcision ; nous proposons de confronter conjointement le ou les
processus interdpendants sur le construit partag. La dcision sera donc prise conjointement
aprs confrontation de lensemble des processus interdpendants.
La dcision D6 de complment la conduite de changement est prise conjointement aux
dcisions de dveloppement spcifique dans lERP (D2), d ajout de brique applicative
(D3), de support manuel (D4) ou encore d abandon (D5) des processus, activits ou E
/ S non satisfait(e)s. Par exemple, le dveloppement spcifique dans lERP dune E ou une
S va ncessiter de complter la documentation dlivre par lditeur. En effet, lactivit ne
sera plus excute telle que dcrite dans cette documentation. La dcision D6 est galement
prise conjointement la dcision de paramtrage (D1) pour les processus, activits ou E
ou S dcouverts. Cela peut concerner un complment de formation sur les nouveaux concepts.
2.2.2.1
Processus associs aux buts non-satisfaits
Pour les processus associs aux buts non-satisfaits (cf. Figure 35), il sagit, en valuant les
critres de cot, dintrt, dintgrit de lintgration et de cohrence du modle TO-BE, de
prendre une des dcisions suivantes : soit les activits du processus sont supportes par le S.I.
ERP par dveloppement spcifique dans lERP (D2) ou par l ajout dune brique
applicative (D3), soit il nest pas support. Il sagit, dans ce cas, soit du support manuel
(D4), soit de l abandon des activits du processus et de leur E / S (D5). De plus, il peut
tre ncessaire de modliser plus finement lenchanement des activits pour prendre une
dcision.
2.2.2.2
Processus associs aux buts quivalents
Pour ces processus nous disposons des modles AS-WISHED et MIGHT-BE. Il sagit de
confronter les activits selon leur enchanement dans le processus. Pour chaque activit
confronte, trois situations sont identifiables correspondants au trois branches de la Figure
36 :
-
Lactivit est dcouverte dans le modle MIGHT-BE mais na pas dquivalence dans le
modle AS-WISHED - situation de non-alignement,
Lactivit est non-satisfaite, elle est absente du modle MIGHT-BE et prsente dans le
modle AS-WISHED - situation de non-alignement,
Les activits sont alignes entre les deux modles - situation dalignement.
A chaque situation pour une activit confronte, selon lvaluation des critres de cots
dintrt, dintgrit de lintgration et de cohrence du modle TO-BE, est associe une
dcision. Par exemple, si une activit est absente, lentreprise a trois possibilits : support
manuel de lactivit (D4), ajout dune brique applicative (D3) ou dveloppement
spcifique dans lERP (D2). Cette dernire dcision consistera, selon le cas, ajouter des
85
lignes de codes ou modifier des lignes de code. De mme que pour les processus nonsatisfaits, il peut tre ncessaire de modliser plus finement lenchanement des activits.
Pour chaque activit aligne, les E / S correspondantes sont alors confrontes les unes aprs
les autres et regroupes selon les situations suivantes constituant trois nouvelles branches dans
la Figure 36 :
-
Les entres ou sorties sont dcouvertes - situation de non-alignement

Les entres ou sorties sont non satisfaites - situation de non-alignement
Les entres ou sorties sont alignes - situation dalignement
Pour chacun de ces groupes, selon les critres de cot, dintrt et dintgrit de lintgration,
il y aura prise dcision pour chaque E / S lune aprs lautre. En cas dabsence dE ou S, les
dcisions deffectuer un dveloppement spcifique dans lERP (D2) ou d abandon des
E / S (D5) pourront tre prises. Bien videmment, les dcisions dabandon sont limites aux
entres et sorties qui ne sont pas bloquantes pour la ralisation de lactivit correspondante. Si
le nombre dE / S est lev, les dcisions peuvent tre regroupes. Cela peut tre le cas, par
exemple, pour lensemble des E / S alignes.
Figure 35- Prise de dcision sur la vue fonctionnelle ddie aux processus associs aux buts non satisfaits
86
Figure 36- Enchanement des activits de confrontation / prise de dcision pour la vue fonctionnelle des processus associs aux buts quivalents
87
2.2.2.3
Processus associs aux buts dcouverts
Pour ces processus, il sagit, si lentreprise est intresse, de prendre la dcision de

paramtrage des activits du processus et de leur E / S D1 (cf. Figure 37). De mme, la
dsagrgation des activits peut tre utile pour prendre cette dcision.
Figure 37- Prise de dcision sur la vue fonctionnelle ddie aux processus associs aux buts dcouverts
2.3
2.3.1
Vue informationnelle
Pour la vue informationnelle, nous proposons de modliser le construit objet dentreprise en

E / S des activits, le construit vue dobjet ayant t trait au niveau de la vue fonctionnelle.
En outre, nous proposons de modliser la forme prise par les attributs des objets dentreprise
en E / S des activits - par exemple, forme numrique ou alpha numrique.
Cette vue est formalise laide des contraintes structurelles sur les attributs de classes
dUML.
Les modles MIGHT-BE et AS-WISHED de cette vue sont construits pour les activits et
vues dobjet en E / S prsents sur le modle TO-BE fonctionnel. La construction du modle
88
MIGHT-BE informationnel nest ralise que pour les attributs qui ont fait lobjet dun
paramtrage sur la vue fonctionnelle.
2.3.2
Construire le modle TO-BE informationnel
Nous reprsentons par le diagramme dactivits UML de la Figure 38 lenchanement des

activits de confrontation / prise de dcision ddies la vue informationnelle.
Figure 38- Enchanement des activits de confrontation / prise de dcision pour la vue informationnelle
Nous conseillons dabord de confronter lensemble des formes prises par les attributs et ce,
attribut par attribut. Puis il sagit de les regrouper selon les trois situations correspondant aux
deux branches imbriques de la Figure 38 :
-
La forme des attributs des objets dentreprise en E / S des activits existe dans les deux
modles :
Celle souhaite du modle AS-WISHED est aligne celle du modle MIGHTBE - situation dalignement.
Elle nest pas aligne entre les deux modles - situation de non-alignement.
La forme nexiste que dans le modle AS-WISHED signifiant que la forme souhaite
nest pas satisfaite de labsence de lattribut lui-mme dans lobjet dentreprise situation de non-alignement.
Ensuite nous prconisons, groupe groupe, dassocier des dcisions chaque forme dattribut
lune aprs lautre. Par exemple, si les formes sont alignes, la dcision de paramtrage
(D1) est prise. Il est galement possible de regrouper la prise de dcision concernant la forme
de plusieurs attributs la fois surtout lorsquils sont nombreux. Cest dailleurs le cas pour
toutes les formes des attributs modlises uniquement dans le modle AS-WISHED. A
chaque dcision prise, le modle TO-BE informationnel est mis jour.
89
Effectuer un paramtrage (D1) signifie, par exemple, paramtrer lattribut identifiant

pour tous les clients en utilisant la forme propose par lERP. Le modle TO-BE sera
construit limage du modle MIGHT-BE. Effectuer un dveloppement spcifique dans
lERP signifie, ici, modifier les lignes de code pour la modification du type dun attribut. Il
sera, par exemple, modifi de Integer String . Le code source netant souvent pas
disponible, lajout de lignes de code pour crer un nouvel attribut avec sa propre forme est
donc plus courant. Le modle TO-BE est, dans ce cas, construit limage du modle ASWISHED.
Pour un non-alignement de la forme, choisir entre le dveloppement spcifique dans
lERP (D2) pour supporter celle souhaite par lentreprise ou le paramtrage (D1) de
lERP implique de faire une balance entre les critres de cots, dintrt et dintgrit de
lintgration. Lentreprise peut nanmoins y voir lopportunit damliorer la codification.
Enfin la dcision de complment la conduite de changement (D6) est prise
conjointement la dcision de paramtrage (D1) ou celle de dveloppement spcifique
dans lERP (D2) dune forme non aligne. Dans le premier cas, une communication accrue
est prvoir sur lactivit correspondante. Dans le second cas, la documentation propose par
lditeur pour lutilisation de lERP est mettre jour ou complter.
Synthse du chapitre
Nous avons propos, dans ce chapitre, la mthode Model Driven - ERP Alignment afin de
mettre en uvre la stratgie doptimisation anticipative agissant sur leffet du RNA. Le
modle SADT de la Figure 39 en rcapitule les principes essentiels.
Le non-alignement potentiel entre les besoins rels de lentreprise et les fonctionnalits
standards de lERP est identifi par lintermdiaire dune confrontation fine des modles ASWISHED et MIGHT-BE pour les vues de modlisation intentionnelle, fonctionnelle, et
informationnelle de la norme (ISO 19439 2006) et des travaux dingnierie des besoins. Ce
sont plus exactement les situations dalignement et de non-alignement de chacune de ces vues
que nous proposons didentifier. Les domaines de lentreprise sont considrs lun aprs
lautre.
Lassociation des dcisions aux situations se fait sur la base :
-
Des dcisions existantes de la littrature auxquelles nous avons ajout deux dcisions
supplmentaires labandon total dun besoin exprim D5 et le complment la conduite
du changement D6. Cette dernire (cf. synthse du Tableau 12) met laccent sur le fait que
la mise en place dun nouveau S.I. impacte le mode de fonctionnement de tous les
membres de lentreprise. Elle est prise conjointement aux autres dcisions.
Dune valuation du non-alignement identifi selon les critres de cot, dintrt,
dintgrit de lintgration et de cohrence du modle TO-BE en cours de construction.
90
Figure 39- Principes de la mthode Model Driven - ERP Alignment
Association la dcision D6 : complment la

conduite de changement
Dcisions
D1 : paramtrage
D2 : dveloppement
spcifique dans lERP
D3 : ajout dune
brique applicative
D4 : support manuel
D5 : abandon
Construits et situations
Processus dcouvert
Activit dcouverte
E ou S dcouverte
Forme non aligne
Processus non satisfait
Activit non satisfaite
E ou S non satisfaites
Forme non aligne
But non satisfait
Tableau 12- Dcision D6 associes aux autres dcisions
91
Sur la base du TO-BE obtenu lissue du processus dalignement, lentreprise est en mesure
de dterminer et modliser les rles oprationnels (vue de ressources) et organisationnels (vue
organisationnelle) ncessaires lexcution des activits implantes.
Nous appliquons, dans le chapitre 6, la mthode propose sur un cas dtude.
La mthode Model Driven - ERP Alignment constitue une premire tape de la phase de
planification rvise du second cycle de la dmarche de recherche / action (cf. Figure 15 de la
section 3.3 du chapitre 2). La stratgie doptimisation anticipative agissant sur leffet du RNA
seule nest pas suffisante pour traiter ce risque ; cette mthode doit tre complte par un
moyen permettant de mettre en uvre la stratgie doptimisation anticipative agissant sur
loccurrence du RNA. Cest lobjet du chapitre 5.
92
Chapitre 5 Risk-Factor Driven ERP Alignment
Chapitre 5 Risk-Factor Driven - ERP

Alignment
Dans ce chapitre, nous proposons un moyen pour mettre en uvre la stratgie doptimisation
anticipative agissant sur loccurrence du Risque de Non-Alignement (RNA) travers
lapproche Risk-Factor Driven - ERP Alignment . Elle consiste en une dmarche
didentification et de traitement des facteurs de risque supporte par un ensemble doutils que
nous concentrons sur ltape dadquation. Cette approche comble, pour le RNA, les manques
des outils existants didentification et de traitement des facteurs de risque dans la littrature
des projets ERP. Elle intgre notamment la classification, linfluence entre facteurs qui ne
sont pas suffisamment exploites dans les approches de management. Elle prend galement en
compte lanalyse que nous avons faite des facteurs de risque.
Plus exactement, lidentification des facteurs, sappuie sur une slection de facteurs de risque
(section 1) influenant le RNA, ainsi que trois outils (section 2) :
-
une classification des facteurs par rapport au cycle de vie du projet ERP ;
une matrice de liens rsiduels entre les facteurs ;
un ensemble de variables dfinissant chaque facteur de risque, permettant didentifier si
un facteur de risque sest matrialis ou non un moment donn durant le projet.
Pour le traitement des facteurs de risque nous proposons une matrice pratiques de gestion /
facteurs de risque (section 3). La mise en uvre de la dmarche, base sur lutilisation
conjointe des outils prcdents, est expose en section 4.
Facteurs de risque influenant le RNA
Lalignement se construit au cours de ltape dadquation du projet ERP (cf. section 2 du

chapitre 2). Les facteurs de risque de cette tape influencent donc directement le RNA.
Cependant, les facteurs ne sont pas indpendants. Pour tudier ces dpendances (cf. Figure
40), un premier travail a consist classer les 29 facteurs lists dans la section 2.2 du chapitre
3 en fonction des diffrentes tapes du projet ERP en vue de slectionner ceux relatifs
ltape dadquation (section 1.1). Puis nous avons dduit les facteurs de risque qui
influencent ceux de cette tape. Pour ce faire, nous avons construit la matrice globale des liens
rsiduels de lensemble des facteurs de risque pour nous concentrer sur les colonnes
correspondant aux facteurs de ltape dadquation (section 2.2).
93
Liste des 29 facteurs de risque
Implantation
Pr-implantation
Post-implantation
Adquation
Matrice globale des liens rsiduels
Extraction des colonnes correspondant aux facteurs de ltape dadquation
Figure 40- Dmarche suivie pour la slection de facteurs de risque influenant le RNA
1.1
Facteurs de risque de ltape dadquation
Dune manire gnrale, pour slectionner les facteurs influenant le RNA, nous prenons en
compte ceux lists dans la section 2.2 du chapitre 3 sauf ceux lis la difficult de gestion de
laspect multi-site et linstabilit organisationnelle. En effet, le premier est un facteur peu
rcent et trs peu cit. De plus, sa gestion se fait via dautres facteurs tels que celui li
lexpression des besoins puisque laspect multi-site peut engendrer des besoins diffrents. Le
facteur li linstabilit organisationnelle de lentreprise est externe au projet comme cela est
dfini dans la section 2.2.4 du chapitre 3. Il dpasse le cadre qui nous intresse savoir celui
du primtre daction des membres du projet ERP.
Sur cette base et pour slectionner les facteurs de ltape dadquation, nous classons
lensemble des facteurs en facteurs horizontaux - grer tout au long du cycle de vie - et en
facteur verticaux - grer une ou plusieurs tapes du cycle de vie. Ainsi le facteur de risque
besoins de lentreprise mal dfinis entre en jeu au cours de la phase de pr-implantation en
vue de choisir le progiciel travers une dfinition macroscopique des besoins. Ce facteur
entre galement en jeu au cours de ltape dadquation lorsquil faut dfinir plus finement les
processus mettre sous contrle de lERP. Nous replaons les facteurs selon le cycle de vie
du projet ERP tel que nous lavons dfini la section 2.1 du chapitre 2. Aprs classement,
94
nous obtenons 14 facteurs horizontaux et 13 facteurs verticaux (cf. Figure 41). Pour tablir ce
classement, nous nous sommes bass sur les classifications existantes (cf. section 2.2.3 du
chapitre 3) et sur notre exprience terrain.
F1 : Manque dimplication / dexpertise du comit de pilotage

F2 : Gestion de projet inefficace
F3 : Mauvaise constitution de lquipe projet
F4 : Gestion inadquate du changement organisationnel
Facteurs horizontaux
F5 : Manque dexpertise / dimplication / absence de consultants externes

F6 : Communication inefficace au sein de lquipe projet
F7 : Problme avec le chef de projet
F8 : Mauvaise planification temporelle du projet
F9 : Mauvaise gestion des ressources financires et matrielles
F10 : Difficult de travail commun entre lentreprise et les membres externes
F11 : Manque dexpertise / dimplication des utilisateurs cls
F12 : Manque dexpertise de lintgrateur
F13 : Communication inefficace entre lquipe projet et le reste de lentreprise
F14 : Mauvaise gestion des risques
Pr-implantation
Facteurs verticaux
Dfinition des
Slection du
objectifs stratgiques
progiciel
et des besoins
F15 : BPR inadquat F18 : Slection
inadquate du
F16 : Buts stratgiques
progiciel
mal dfinis
F17a : Mauvaise
expression des besoins
Post-implantation
Implantation
Lancement
Adquation
Intgration
et tests
Mise en
production
Stabilisation
Stabilisation
F22 : Problmes F24 : Manque F27 : Gestion

F19 : Gestion
inadquate
dexpertise /
inadquate du non- techniques
de la
dimplication /
alignement
F23 : Ralisation
rsistance au maintenance
inadquate des
F20 : Gestion
changement des
tests
inadquate de
utilisateurs finaux
ladaptation de lERP
F25 : Formation
F17b : Mauvaise
inadquate /
expression des
insuffisante des
besoins
utilisateurs finaux
F21 : Haut degr de
F26 : Gestion
complexit du
inadquate de la
progiciel
conversion des
donnes
Figure 41- Classement des facteurs de risque par rapport au cycle de vie du projet ERP
Nous allons maintenant nous concentrer sur les facteurs verticaux de ltape dadquation - en
gras et italique dans la Figure 41 - cest--dire :
-
Gestion inadquate du non-alignement,

Gestion inadquate de ladaptation de lERP,
Mauvaise expression des besoins,
Haut degr de complexit du progiciel.
95
1.2
Facteurs de risque dduits des liens rsiduels
Ici, nous nous attachons aux liens rsiduels dfinis dans la section 2.2.4 du chapitre 3 mais
pour lesquels nous tendons la dfinition. Ainsi, nous considrons quun lien rsiduel ne
concerne pas uniquement deux facteurs de deux phases qui se suivent. Il peut exister entre
deux facteurs quelle que soit leur phase, dans la limite de la chronologie du cycle de vie. Plus
exactement, nous appelons facteurs de risque rsiduels, ceux qui rsultent du traitement
dautres facteurs de risque. Le facteur influenc sera appel facteur en aval du lien. Le facteur
influenant sera appel facteur en amont du lien.
Pour dfinir les liens rsiduels entre facteurs, nous avons construit une matrice des liens
rsiduels pour lensemble des 29 facteurs tudis en nous appuyant sur :
-
Les travaux de (Akkermans and Van Helden 2002b; Ojala et al. 2006; Bueno and
Salmeron 2008; Peng and Nunes 2009; Velcu 2010) qui dtaillent des influences causales
entre les facteurs de risque.
Les articles qui dfinissent les facteurs de risques tels que (Sumner 2000; Somers and
Nelson 2001; Al-Mashari et al. 2003; Nah et al. 2003; Umble et al. 2003; Huang et al.
2004; Ehie and Madsen 2005; Motwani et al. 2005; Aloini et al. 2007; Grabski and Leech
2007; Jarrar et al. 2010; Jouffroy 2010; Law et al. 2010; Singh et al. 2010) (Taylor 2005).
En effet, certaines de ces dfinitions incluent galement lidentification des influences
entre facteurs que nous avons rcapitules grce aux expressions suivantes :
causing,play a useful role in, affect, enable, help in, result in, influences
on, positively related facilitate ou encore leads to.
La matrice complte avec les rfrences bibliographiques est donne en annexe F. Une cellule
grise de la matrice correspond un lien rsiduel entre deux facteurs dcrit dans la littrature.
Ainsi, selon (Somers and Nelson 2001; Akkermans and Van Helden 2002b; Grabski and
Leech 2007), le facteur de risque F7 : problme avec le chef de projet peut subsister du
mauvais traitement du facteur de risque F1 : manque dimplication / dexpertise du comit
de pilotage . Il y a donc un lien rsiduel entre ces deux facteurs o le facteur manque
dimplication / dexpertise du comit de pilotage est en amont du lien et problme avec le
chef de projet est en aval. Lenrichissement de cette matrice avec dautres travaux ou
expriences terrains nest pas exclu.
Le Tableau 13 reprsente la matrice des liens rsiduels des FR influenant le RNA. Cette
matrice est extraite de la matrice globale en se limitant, pour les colonnes, aux quatre facteurs
de risque de ltape dadquation.
96
Facteurs en amont du lien rsiduel
Facteurs de risque rsiduels de ltape

dadquation
Gestion
Haut degr
Mauvaise
Gestion
inadquate
de
expression inadquate
de
complexit
des
du nonladaptation
du
besoins
alignement
de lERP
progiciel
(F17b)
(F19)
(F20)
(F21)
(F1)
Manque dexpertise /
dimplication du comit de
pilotage
(F2) Gestion de projet inefficace
(F3) Mauvaise constitution de lquipe
de projet
(F5) Manque dexpertise /
dimplication / absence de
consultants externes
(F7) Problme avec le chef de projet
(F8) Mauvaise planification
Horizontaux
temporelle du projet
(F9) Mauvaise gestion des ressources
financires et matrielles
(F10) Difficult de travail commun
entre lentreprise et les membres
externes
(F11) Manque dexpertise /
dimplication des utilisateurs cls
(F12) Manque dexpertise de
lintgrateur
(F14) Mauvaise gestion des risques
(F15) BPR inadquat
(F16) Buts stratgiques mal dfinis
Verticaux
(F17a) Mauvaise expression des besoins
(F18) Slection inadquate du progiciel
Tableau 13- Matrice des liens rsiduels des facteurs de risque influenant le RNA
Outils didentification des facteurs de risque
Nous reprenons comme outils didentification :

-
le classement des facteurs influenant le RNA en facteurs horizontaux et verticaux et

la matrice des liens rsiduels des facteurs de risque influenant le RNA.
Nous proposons dy ajouter un troisime outil dont lobjectif est de dtailler un facteur donn
par un ensemble de variables. En effet, selon (Bourdeau et al. 2003), un facteur de risque est
dfini comme un construit multidimensionnel agrg qui implique quun facteur de risque
ne peut pas tre dfini sans tenir compte de chacune de ses dimensions sous-jacentes, dfinies
comme tant des variables. Les variables dun facteur tant lies conceptuellement entre elles,
la somme de celles-ci permet dobtenir le portrait dun facteur de risque .
Nous proposons des variables (cf. Figure 42) pour chaque facteur vertical de ltape
dadquation et pour les facteurs qui ont un lien rsiduel en amont avec eux.
97
F1 : Manque dimplication /
dexpertise du comit de pilotage
-Manque dimplication
-Manque dexpertise des membres
-Manque de soutien ou support de
la direction de lentreprise
-Mauvaises prises de dcisions
-Manque de participation de la
direction de lentreprise
F8 : Mauvaise planification
-Planning non raliste
-Pas de prise de la prcdence
des activits
-Planning incompatible

-Processus de gestion de risque partiel
-Outils de gestion des risques mal utiliss
F15 : BPR inadquat
-BPR inexistant
-Echec dans la redfinition des
processus
-Redfinition incomplte
-BPR au mauvais moment

-Manque de mthodes de gestion
de projet
-Manque doutils de gestion de
projet
-Mthodes de gestion de projet
non adquates
-Outils de gestion de projet
inefficace
-Utilisation inadquate des
mthodes de gestion de projet
-utilisation inadquate des outils de
gestion de projet
-Pas de respect du planning
F9 : Mauvaise gestion ressources
-Estimation inadquate des
ressources financires
-Rpartition inadquate des
ressources financires
-Pas de libration des ressources
matrielles
F16 : Buts stratgiques mal

dfinis
-Dsaccord sur les buts
-Flous sur les buts
-Non prise en compte de la
raison de changer de S.I.
F18 : Slection inadquate du progiciel

-Pas de slection en fonction du budget
-Pas de slection en fonction des dlais
-Pas de slection en fonction de laspect fonctionnel
-Pas de slection en fonction des aspects techniques pour la
slection
-Pas de slection en fonction du fournisseur
-Qualit de service du fournisseur
F3 : Mauvaise constitution de
lquipe projet
-Rpartition inadquate des rles
et responsabilits
-Comptences non quilibres
-Turnover des membres
-Nombre insuffisants de membres
F10 : Difficult de travail commun

entre lentreprise et les membres
externes
-Cultures diffrentes
-Mthodologies de travail
diffrentes
-Dsaccords entre les membres de
lquipe intgratrice
F17a : Mauvaise expression de

besoins
-Besoins exprims faux
-Besoins exprims incomplets
-Besoins exprims incomprhensibles
-Pas de formalisation des besoins de
haut niveau
-Formulation des besoins non base
sur lexistant
-Besoins exprims non stabiliss
-Niveau de granularit non adquat
-Mauvaise prise en compte du
primtre fonctionnel
-Manque de formalisme dans
lexpression des besoins
F5 : Manque dexpertise / dimplication /

absence de consultants externes
-Pas dapport dexpertise pour lentreprise
-Manque de expertise mtier
-Manque dexprience
-Manque de comptences techniques
-Pas de consultants externes
F11 : Manque dexpertise / dimplication

des utilisateurs cls
-Manque dexpertise mtier
-Manque de comptences dans la gestion
de projet
-Manque de prsence
-Travail non fait
-Peu de confiance en soi

-Pas de chef de projet
-Mauvais fdrateur
-Pas dautorit
-Manque de disponibilit
-Pas de volont de russite
-Manque de participation
-Mauvais planificateur
-Travail dlgu
-Manque de comptences mtiers
F12 : Manque dexpertise de

lintgrateur
-Manque dexpertise
-Manque dexprience
-Mauvaise gestion de projet
F19 : Gestion inadquate du non-alignement F20 : Gestion inadquate de

-Diffrentes cultures
ladaptation de lERP
-Manque de modlisation des processus
-Pas danalyse de la ncessit
souhaits
dadapter en fonction de lintrt
-Pas de formalisation des fonctionnalits
de lentreprise
standards de lERP
-Pas danalyse des cots
-Mauvaise gestion des runions dadquation dadaptation
-Pression sur la prise de dcision
-Pas de gestion de lintgrit de
-Dcisions prises la lgre
lintgration
-Pas de prise en compte de lintgrit de
lintgration
F21 : Haut degr de complexit du progiciel
-Pas destimation de la complexit des modules
-Pas de prise en compte de la complexit des
modules
Pr-implantation
F17b : Mauvaise expression de

besoins
-Besoins exprims faux
-Besoins exprims non stabiliss
-Besoins exprims
incomprhensibles
-Pas de formalisation des besoins
dtaills
-Formulation des besoins non
base sur lexistant
Implantation
Figure 42- Variables des facteurs de risque
98
Ce travail se base sur :

-
Les dfinitions des facteurs de risque fournies par les auteurs tudis dans le chapitre 3 ;
Les travaux dcrivant linfluence de sous-ensembles de facteurs de risque sur le succs
des projets ERP (Hong and Kim 2002a; Chou and Chang 2008; Morton and Hu 2008;
Chen et al. 2009a; Malhotra and Temponi 2010; Santamaria-Sanchez et al. 2010) ;
Les listes des facteurs de risques des projets S.I. que proposent (Ewusi-Mensah 1997;
Baccarini et al. 2004) : ils prcisent certaines dimensions de facteurs de risque que nous
avons juges pertinentes dans le cadre des projets ERP, l o les travaux spcifiques aux
projets ERP font parfois dfaut ;
Notre exprience terrain chez notre partenaire industriel, il sagit des variables sans
rfrence bibliographique.
Nous dtaillons ci-dessous les variables des cinq facteurs de risque que nous rutilisons dans
le chapitre 6. Le reste est mis en annexe G.
-

Pas dapport dexpertise pour lentreprise : les consultants napportent pas une
expertise complmentaire lexpertise dj prsente au sein de lentreprise
(Ewusi-Mensah 1997; Grabski and Leech 2007).
Manque dimplication : les consultants externes ne suivent pas lvolution du
projet de prs et ne sen tiennent pas informs (Sumner 2000).
Manque dexpertise mtier : les consultants externes nont pas une bonne
connaissance des processus de lentreprise (Grabski and Leech 2007).
Manque dexprience : les consultants nont pas dexprience de projets
dimplantation similaires (Ewusi-Mensah 1997; Aloini et al. 2007; Grabski and
Leech 2007) ou dun domaine dactivits similaire lentreprise cliente (EwusiMensah 1997; Somers and Nelson 2001).
Manque de comptences techniques : les consultants externes nont pas une
bonne connaissance des modules de lERP qui sont mis en place (Somers and
Nelson 2001; Aloini et al. 2007) et / ou des aspects techniques de lERP (Aloini
et al. 2007).
Pas de consultants : il ny a pas de consultant externe qui accompagne les
membres de lquipe de projet.
Manque dexpertise : lquipe dintgration ne dtient pas lexpertise souhaite
par lentreprise notamment pour comprendre leurs besoins (Ewusi-Mensah
1997; Sumner 2000; Law et al. 2010).
Manque dexprience : lintgrateur na pas suffisamment dexprience
notamment dans le type lindustrie de lentreprise cliente - agroalimentaire,
pharmaceutique, du btiment, etc. (Ewusi-Mensah 1997).
Mauvaise gestion de projet : lintgrateur ne grent pas correctement les
membres de lquipe ; les runions de travail ne sont pas suffisamment
prpares.
F15 : BPR inadquat
BPR inexistant : aucune rflexion sur la pertinence ou la refonte des processus
dentreprise (Botta-Genoulaz et al. 2001).
Echec dans la redfinition des processus : les processus ont t mal redfinis
(Huang et al. 2004).
99
Redfinition incomplte : la redfinition na pas pris en compte tous les

processus de lentreprise ncessitant un Rengineering (Amid et al. 2012)
(Motwani et al. 2005).
BPR au mauvais moment : le BPR na pas t ralis avant la slection du
progiciel et avant lexpression de besoins rels de lentreprise (Botta-Genoulaz
et al. 2001).
F19 : Gestion inadquate du non-alignement
Diffrence de cultures : la culture lie aux fonctionnalits de lERP qui est mis
en place est trop loigne de la culture de lentreprise (Taylor 2005; Morton and
Hu 2008).
Manque de modlisation des processus souhaits : les processus souhaits par
lentreprise pour lesquels il est ncessaire didentifier le non-alignement
potentiel avec les processus standards de lERP ne sont pas modliss avec
minutie.
Pas de formalisation des fonctionnalits standards de lERP : les fonctionnalits
standard ne sont formalises laide dun langage de modlisation.
Mauvaise gestion des runions dadquation : ce qui doit tre confront nest pas
tabli lavance ; ce qui a t tabli nest pas respect.
Pression sur la prise de dcision : les dcisions sont prises sous pression car il y
a des tensions entre les membres de lentreprise et lintgrateur.
Dcisions prises la lgre : les personnes responsables de la prise de
dcision relative aux processus mettre sous contrle de lERP ne ralisent pas
limportance de cette prise dcision.
Pas de prise en compte de lintgrit de lintgration : lordre de mise en place
des modules et les dcisions concernant ces modules nont pas tenu compte de
lintgrit de leur intgration (Sumner 2000; Aloini et al. 2007).
Linterdpendance entre processus que ce soit au sein dun module ou entre
diffrents modules (partage dinformation, de ressources acteurs, etc.) nest pas
pris en compte dans la prise de dcision face au non-alignement (Bernard et al.
2002b).
F17b : Mauvaise expression des besoins
Besoins exprims faux : les besoins de lentreprise qui sont exprims ne
correspondent pas aux besoins rels.
Besoins exprims non stabiliss : les besoins exprims changent tout au long du
projet (Huang et al. 2004).
Besoins exprims incomplets : les besoins exprims sont incomplets (Baccarini
et al. 2004).
Besoins exprims incomprhensibles : les besoins de lentreprise ne sont pas
comprhensibles (Huang et al. 2004) par les intgrateurs et les consultants
externes.
Pas de formalisation des besoins dtaills.
Formulation des besoins non base sur lexistant : la formulation des besoins de
lentreprise est ralise sans se baser sur les problmes rencontrs dans lexistant
de lentreprise.
Manque de formalisme dans lexpression des besoins : pas dutilisation de
langage de modlisation pour la formalisation.
Nous considrons, comme (Morley 2001), quun facteur sest matrialis si au moins une
des variables lest. Cependant, le poids de chaque variable sur le facteur de risque peut
100
diffrer. Par exemple, la variable pas de chef de projet du facteur problme avec le
chef de projet aura plus de poids que la variable manque dautorit .
Outil de traitement des facteurs de risque
Le traitement des facteurs de risque se base sur une slection de pratiques de gestion
mettre en uvre. Il ny a, ce jour, pas de rfrentiel de bonnes pratiques pour le
traitement des facteurs de risque dans les projets ERP sur lesquels nous pouvons nous baser.
Les pratiques que nous proposons sont au nombre de 37 (cf. Tableau 14) et en rapport avec
les facteurs de risque influenant le RNA.
Num
P1
P2
P3
P4
P5
P6
P7
Pratiques de gestion
Slectionner le progiciel en deux tapes : faire une short list de 2 ou
3 progiciels candidats puis faire la slection finale du progiciel. La
short list doit tre ralise en quelques jours maximum quelques
semaines en fonction du choix des concurrents et des critres
gographique, technique, de prennit, de notorit, de couverture
internationale. Le choix final doit tre ralis sur la base de la couverture
fonctionnelle.
Slectionner la socit dintgration en fonction des critres
dexprience, de comptences des intervenants proposs par la socit.
Slectionner la socit dintgration en fonction des critres
gographiques, de proposition de management, de reconnaissance par
rapport lditeur.
Nommer un chef de projet en fonction des critres de lgitimit, de
charisme et de comptences.
Slectionner les utilisateurs cls en fonction des critres dexprience, de
comptences, dintgration, dadaptation et de motivation.
Formaliser, laide dun formalisme simple et intuitif, les processus
souhaits par lentreprise et les fonctionnalits standards de lERP.
P8
Modliser et analyser lexistant mtier de lentreprise. Il sera une base

pour modliser ses souhaits.
Etablir le plan de formation des utilisateurs cls.
P9
Etablir le plan de dploiement des modules.
P10
Organiser de courtes runions hebdomadaires du comit de pilotage.

Celles-ci doivent tre prsides par le chef de projet avec un compte
rendu rdig rapidement aprs la runion.
P11
Organiser de courtes runions dinformation hebdomadaires de lquipe

projet pour rendre compte des runions du comit de pilotage, avec un
compte rendu rdig rapidement aprs la runion.
Organiser des runions de validation des demandes dadaptation de
lERP en fonction des critres denjeux conomiques, fonctionnels et
budgtaires.
P12
Sources
(Deixonne 2001; Tournant
and Azan 2003)
(Tournant and Azan 2003;

Quellenec 2007; Jouffroy
2010)
(Lequeux 1999; Deixonne
2001)
(Quellenec 2007; Jouffroy
2010)
(Zafiropoulos et al. 2005)
and Azan 2003; Quellenec
2007; Jouffroy 2010)
(Jouffroy 2010)
(Lequeux 1999; Deixonne
2001; Zafiropoulos et al.
2005; Quellenec 2007;
Sotiaux 2008; Jouffroy
2010)
(Deixonne 2001; Ho et al.
2009)
(Deixonne 2001;
Zafiropoulos et al. 2005;
Sotiaux 2008; Jouffroy
2010)
(Deixonne 2001;
Zafiropoulos et al. 2005;
Jouffroy 2010)
(Quellenec 2007; Jouffroy
2010)
101

Num
P13
P14
P15
P16
P17
P18
P19
P20
P21
P22
P23
P24
P25
P26
P27
P28
P29
P30
P31
P32
P33
P34
P35
P36
P37
Pratiques de gestion
Prvoir le budget des principaux postes budgtaires suivants : matriel et
infrastructure, quipe interne mtier, quipe interne S.I. et quipe
externe.
Identifier, en fonction de la nature de la dcision, les membres du projet
ayant du poids sur celle-ci.
Disposer dun chef ce projet reconnu comme tant linterlocuteur
principal pour prendre les dcisions qui sont bloquantes tant sur les
aspects techniques que mtiers.
Choisir ds le dbut du projet, en fonction des caractristiques de
lentreprise et de ses habitudes, un mode de pilotage adapt : ouvert,
ferm, ou matriciel.
Etablir la relation ad hoc entre le chef de projet et chacun des acteurs du
projet pour faire avancer le projet.
Mettre en place le processus dynamique en spiral de mise en confiance
des membres de lquipe projet.
Appliquer la rgulation de lquipe. en prenant une pause dans les
activits oprationnelles pour parler de lquipe elle-mme.
Rdiger et valider le compte rendu pendant les runions.
Ne pas inclure dans le contrat forfaitaire les ventuelles adaptations de
lERP.
Dterminer par crit ds le dbut du projet les rles et responsabilits de
chaque membre de lquipe.
Etablir ds le dbut du projet la philosophie concernant ladaptation de
lERP et sen tenir jusqu la fin du projet.
Tenir le chef de projet au courant de tout ce qui sest pass durant le
projet, grce une procdure formelle.
Librer officiellement les membres du projet de leurs tches
quotidiennes.
Organiser des exercices de travail en quipe.
Dfinir la contribution du projet aux objectifs stratgiques de
lentreprise.
Mettre en adquation la formulation des objectifs stratgiques du projet
avec la formulation des objectifs stratgiques de lentreprise.
Slectionner les consultants externes en fonction des critres
dexprience et de comptences.
Mettre en place un processus de management des risques.
Prparer les runions dadquation en modlisant les processus aligner
et sy tenir.
Mettre la disposition de lquipe de projet lquipement matriel
ncessaire.
Planifier finement les tapes du projet.
Choisir entre effectuer un BPR radical, pragmatique, ou opportuniste en

fonction des objectifs de lentreprise en termes de cots, de temps et de
retour sur investissement attendu.
Effectuer le BPR avant la slection du progiciel et la dfinition des
besoins
Dterminer le niveau de granularit le plus adquat pour la formulation
macroscopique des besoins avant la slection du progiciel.
Dterminer le primtre fonctionnel concern par la modlisation
macroscopique des besoins
Tableau 14- Liste des pratiques de gestion
Sources
(Quellenec 2007)
(Quellenec 2007)
(Zafiropoulos et al. 2005;
Quellenec 2007)
(Quellenec 2007)
(Sotiaux 2008)
(Sotiaux 2008)
(Zafiropoulos et al. 2005;
Sotiaux 2008)
(Sotiaux 2008)
(Jouffroy 2010)
(Lequeux 1999)
and Azan 2003)
(Deixonne 2001)
(Deixonne 2001; Jouffroy
2010)
(Deixonne 2001)
(Tournant and Azan 2003;
Quellenec 2007; Jouffroy
2010)
(Tomas 1999)
(Botta-Genoulaz et al.
2001)
(Tomas 1999)
(Tomas 1999)
Ces pratiques proviennent :
102
Des travaux de (Zafiropoulos et al. 2005) et (Ho et al. 2009) proposant des pratiques
pour traiter les facteurs de risque dans les projets ERP.
De livres de gestion de projets ERP et de gestion dquipes projet tels que (Lequeux
1999; Deixonne 2001; Tournant and Azan 2003; Quellenec 2007; Sotiaux 2008;
Jouffroy 2010). Ces livres sont le plus souvent rdigs par des consultants ayant eu de
lexprience dans la gestion des projets ERP. Les pratiques qui y sont prconises ont t
juges pertinentes et efficaces suite lexprience de leur mise en uvre.
Et enfin, nous avons ajout des pratiques que nous avons juges pertinentes suite notre
exprience personnelle de terrain : ce sont celles pour lesquelles aucune source nest
indique.
Le traitement des facteurs de risque influenant le RNA sappuie sur une matrice pratique /
facteurs de risque (cf. Tableau 15). Les lignes de cette matrice sont les facteurs de risque
influenant le RNA que nous avons dfinis dans la section 1 de ce chapitre. Les colonnes
correspondent aux facteurs du Tableau 13. Chaque case grise de la matrice est un lien
pratique / facteur explicits dans les travaux tudis. Par exemple, la pratique P14 identifier, en fonction de la nature de la dcision, les membres du projet ayant du poids sur
celle-ci - influence le facteur gestion inadquate de ladaptation de lERP .
Les pratiques se rpartissent de manire uniforme par rapport aux facteurs. Seuls les facteurs
concernant le haut degr de complexit du progiciel, la planification temporelle du projet et
la gestion des risques sont peu abords. La gestion du planning est aborde implicitement.
En effet, les travaux tudis sont structurs selon les phases du cycle de vie du projet ERP ce
qui sous-entend une gestion du planning temporel. Les facteurs concernant la gestion du
projet et celles concernant les membres de lquipe projet sont ceux pour lesquels il y a le
plus de pratiques.
Mise en uvre de la dmarche travers les outils
La mise en uvre de la dmarche anticipative agissant sur loccurrence du RNA sappuie

sur les trois outils didentification et loutil de traitement prsents dans les sections
prcdentes. Nous conseillons donc de lappliquer au plus tt durant la phase dadquation,
mme si elle peut tre applique tout moment au cours du projet.
A une tape donne, nous proposons lidentification des facteurs qui ne se sont pas encore
matrialiss mais qui ont de fortes chances de ltre dans les activits qui suivent du projet,
et de ceux qui se sont matrialiss.
Le premier outil utiliser est le classement des facteurs selon le cycle de vie du projet ERP horizontal / vertical - de la Figure 44, pour dterminer en fonction de ltape courante, les
facteurs qui peuvent potentiellement se matrialiser. Un facteur sera identifi comme avr
si au moins une de ses variables est avre (cf. Figure 42, annexe G).
103
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
F1
F2
F3
F5
F7
F8
F9
F10
F11
F12
F14
F15
F16
F17
F18
F19
F20
F21
Tableau 15- Matrice des liens pratiques de gestion / facteurs de risque influenant le RNA
104
Enfin, les facteurs ayant de fortes chances de se matrialiser sont identifis grce la matrice
des liens rsiduels entre les facteurs du Tableau 13. Il faut alors se baser sur les facteurs
avrs ce moment - l du projet - facteurs en ligne de la matrice (cf. Tableau 13), et
identifier les facteurs avec un lien rsiduel en aval de ces facteurs avrs - facteurs en
colonne.
Une fois les facteurs identifis, nous proposons dappliquer les pratiques de gestion qui leur
sont associes dans la matrice pratiques / facteurs du Tableau 15. Par ce biais, nous proposons
trois stratgies de traitement des facteurs (cf. Figure 43) :
-
La stratgie doptimisation correspond au cas o toutes les pratiques, pour le facteur

identifi comme avr, ne peuvent pas tre appliques car certaines concernent des
acticits sur lesquelles il nest plus possible ou il est difficile de revenir - tel que la
slection de lintgrateur. Ainsi, les pratiques appliques permettront de rduire la criticit
du facteur sans forcment faire en sorte de ne plus lobserver.
La stratgie de refus ractif correspond au cas o toutes les pratiques associes au facteur
identifi sont applicables et permettent de refuser le facteur, cest--dire de ne plus
lobserver. Sa criticit est rduite zro.
La stratgie de refus anticipatif correspond au cas o les pratiques sont appliques par
anticipation pour viter que le facteur ne se matrialise. Le facteur est refus par
anticipation.
Cycle de vie
Projet ERP
Pr-implantation
Implantation
Implantation
Post-implantation
un instant donn, tat des facteurs

- Non avrs mais ayant de fortes
chances de se matrialiser
Refus anticipatif
Avrs
Refus ractif
Optimisation
Figure 43- Stratgies de traitement des facteurs de risque
A un moment donn durant le projet, il est possible dappliquer ces trois stratgies
simultanment pour diffrents facteurs de risque. Nous prconisons lapplication de la
dmarche de refus anticipatif ds le dbut la phase de pr-implantation du projet. Ensuite, au
cours du projet, lapplication de lun ou lautre des stratgies dpend de ltat des facteurs ce
moment-l du projet. Cela est fonction des facteurs qui se sont matrialiss. Pour ceux qui se
sont matrialiss, cela est aussi fonction des activits sur lesquelles il nest plus possible de
revenir.
La mise en uvre des pratiques, pour chaque facteur, est adapter selon le contexte du projet,
cest--dire selon les variables identifies pour chaque facteur. Prenons lexemple du facteur
associ la gestion des ressources. Dans le cas o seules les ressources financires posent
problme, seules les pratiques permettant de traiter cet aspect sont appliquer - par exemple
105
P13 : Prvoir le budget des principaux postes budgtaires suivants : matriel et infrastructure,
quipe interne mtier, quipe interne S.I. et quipe externe.
Synthse du chapitre
Lapproche Risk-Factor Driven - ERP Alignment permet dagir sur loccurrence du RNA
par le management des facteurs de risque qui linfluencent. Nous nous focalisons sur les
facteurs de risque de ltape dadquation et sur ceux qui ont un lien rsiduel en aval avec ces
facteurs. Lapproche propose sarticule autour dune dmarche mise en uvre grce trois
outils didentification et un outil de traitement.
La proposition :
-
du classement des facteurs de risque par rapport au cycle de vie du projet,

des variables attribues chaque facteur,
de la matrice des liens rsiduels des facteurs de risque influenant le RNA,
et de la matrice facteurs de risque / pratiques de gestion,
permet de guider prcisment les tapes didentification et de traitement.

Afin dagir au mieux sur loccurrence du RNA, nous proposons trois stratgies de traitement
des facteurs de risque : refus anticipatif, refus ractif et optimisation. Lapplication de lune
ou lautre des stratgies dpend de ltat du facteur un instant donn du projet - avr ou pas
encore - mais galement des pratiques quil est possible ou non dappliquer.
Enfin, travers ce chapitre, nous achevons la phase de planification rvise du second cycle
de la dmarche de recherche / action que nous suivons (cf. Figure 15 de la section 3.3 du
chapitre 2).
106
Chapitre 6 Application un cas dtude
Chapitre 6 Application un cas

dtude
Nous prsentons dans ce chapitre lapplication de la mthode Model Driven - ERP
Alignment (section 1) et de lapproche Risk-Factor Driven - ERP Aligment (section 2)
au projet ERP de la socit X (cf. Figure 44).
La mthode Model Driven - ERP Alignment a t applique a posteriori au module SAV
en mai 2012. Par ce biais, nous avons reconstitu ltude dadquation de ce module qui a t
ralise en mars / avril 2009. Lapproche Risk-Factor Driven - ERP Aligment a galement
t applique a posteriori sur deux priodes du projet ERP de la socit X : la priode
dadquation qui sest droul de mars juin 2009 et une priode de retour sur adquation
ralis durant ltape de tests de novembre 2009 janvier 2010. Au cours de ces deux
priodes, il a t question des modules du premier lot, savoir commercial, comptabilit,
finance, achats, stocks et expdition.
Ces applications permettent de mettre en uvre la phase daction et observation du second
cycle de notre dmarche de recherche / action (cf. Figure 15 de la section 3.3 du chapitre 2).
Les conclusions de ces applications, quant elles, en constituent la phase de rflexion.
Application de la mthode Model
Driven ERP Alignment a posteriori
Application de lapproche Risk-Factor

Driven ERP Aligment a posteriori
Action et observation
Action et observation
mars juin 2009 : 1re priode

dadquation (plusieurs modules)
mars / avril 2009 : tude dadquation

du module SAV
novembre 2009 janvier 2010 : 2nde priode

de retour sur adquation (plusieurs modules)
mai 2012 : reconstitution de ltude

dadquation du module SAV
aot 2012 : reconstitution du processus

de management des facteurs de risque
sur ces deux priodes
Rflexion
Conclusion des applications

Figure 44- Application des contributions notre cas dtude : phases dactions, observations et rflexion
de la dmarche recherche / action
107
Mthode Model Driven - ERP Alignment
Dans la section 1.1, nous dfinissons notre dmarche de travail et fixons les objectifs dans le
cadre de lapplication de la mthode Model Driven - ERP Alignment au module SAV de
la socit X. Dans la section 1.2 nous appliquons cette mthode en suivant la dmarche de
travail propose vue par vue sur le domaine SAV. Enfin, nous synthtisons dans la section
1.3, les apports pour lentreprise.
1.1
Dmarche
Avant limplantation de SAGE X3, le SAV tait support par un logiciel dvelopp
spcifiquement par linformaticien de lentreprise. Ce logiciel ntait pas interfac lERP
INFOR et servait essentiellement stocker les informations concernant les demandes de
service reues des clients. Il comportait un seul cran utilisateur avec trs peu de champs tels
que objet du litige , date souhaite , ou informations complmentaires . La socit X
a vu dans limplantation du module SAV une occasion pour, entre autres, amliorer sa
relation avec les clients en leur offrant davantage de services. Lentreprise a souhait, par ce
biais, mettre en place un contrat de garantie, un suivi de la clientle et des interventions chez
le client.
Pour appliquer la mthode Model Driven - ERP Alignment a posteriori (cf. Figure 45),
nous avons identifi toutes les situations dalignement et de non-alignement relatives
lensemble des vues de modlisation traites. Cette identification a t faite sur la base de la
reconstitution et de la confrontation des modles AS-WISHED et MIGHT-BE. Des interviews
et documents fournis par lentreprise et lintgrateur ont permis de faire cette reconstitution.
Les modles ont t valids par les personnes concernes.
Ensuite, nous avons associ aux situations identifies les dcisions qui ont t rellement
prises durant le projet ERP et non celles que nous aurions pu conseiller lentreprise. Cette
reconstitution de la prise de dcision a t ralise sur la base :
-
Dun document rdig suite ltude dadquation du module SAV fourni par
lintgrateur. Nous appelons ce document la version Vintgrateur du modle TO-BE.
Dun document fourni par le PDG de la socit que nous appellerons la version Ventreprise.
Celle-ci diffre de la version de lintgrateur et dfinit ce qui a t valid pendant les
runions dadquation et que le PDG a sign.
Dune interview de lintgrateur nous confirmant certaines dcisions prsentes dans
aucune des deux versions.
108
MIGHT-BE
AS-WISHED
2 - Prise de
dcision et
construction
progressive du
modle TO-BE
1 - Confrontation : pour un
construit align, non satisfait ou
dcouvert
AS-IS
Si construit prsent dans Vintgrateur du modle TO-BE ou confirm par

interview intgrateur Alors
Dcision dimplanter (D1, D2 ou D3) et modlisation TO-BE
Si construit non prsent dans V
Alors dcision prise
entreprise
inconsciemment
FinSi
Sinon
Dcision de ne pas implanter (support manuel D4 ou abandon D5)
Demande de confirmation lentreprise si dcision inconsciente ou
non
FinSi
Figure 45- Dmarche suivie pour lapplication de la mthode Model Driven - ERP Alignment au
module SAV
Ainsi, pour toutes les dcisions dimplantation - paramtrage (D1), dveloppement

spcifique dans lERP (D2) ou ajout dune brique applicative (D3) - nous avons pu
tablir celles que lentreprise a prise inconsciemment compte tenu de lcart entre les versions
Ventreprise et Vintgrateur des modles TO-BE ainsi que notre interview de lintgrateur. Ces
dcisions dimplantation nous ont permis de construire le modle TO-BE. De mme, pour les
dcisions de support manuel (D4) et d abandon (D5), nous avons pu tablir celles
prises inconsciemment ou non par notre interview des membres lentreprise. Nous avons
galement mis en lumire les dcisions que nous aurions prconises notamment celle de
complment la conduite de changement (D6).
1.2
Application de la mthode Model Driven - ERP Alignment au

SAV
Dans cette section, nous appliquons le processus dalignement, activit par activit, telles que
dcrites dans les sections 2.1 2.3 du chapitre 4. Comme lentreprise na pas formul de
besoins pour la vue informationnelle, les activits du processus dalignement relatives cette
vue ne sont pas appliques au cas dtude. Cependant, nous en donnons un exemple afin de
lillustrer. De plus, nous synthtisons la prise de dcision conjointe de la dcision D6 avec les
autres dcisions (D1 D5).
109
1.2.1
1.2.1.1
Vue intentionnelle
Les modles de buts KAOS des Figure 46 et Figure 47 reprsentent respectivement la vue
intentionnelle des modles AS-WISHED et MIGHT-BE.
Le modle AS-WISHED, contient 5 buts pouvant tre oprationnaliss cest--dire atteints
par un ensemble dactivits : Achieve Contrat garantie cr , Achieve Contrat service
cr , Achieve Qualit traite , Achieve Suivi produit cr , Achieve Demande
analyse . De plus, les modles AS-WISHED et MIGHT-BE contiennent tous deux le but
Achieve Demande SAV satisfaite ayant t raffin successivement la fois avec le
raffinement Dcomposition et le raffinement Comment notamment grce au Pattern
Achieve Request satisfied et la dmarche de (Dardenne et al. 1993) tous deux dcrit dans la
section 2.1.1 du chapitre 4. Par exemple, le but Achieve Demande SAV satisfaite a t
raffin par le raffinement Dcomposition en deux buts Achieve Demande SAV mise
et Achieve Demande SAV traite . Il en est de mme pour ces derniers et pour le but
Achieve Demande SAV effectue . Les autres buts de larbre - sauf ceux reprsents
travers les feuilles - ont t raffins avec le raffinement Comment .
1.2.1.2
Confronter les modles AS-WISHED et MIGHT-BE
Les quatre buts prsents dans les deux modles et raffins avec le raffinement
Dcomposition nont pas t confronts. En effet, ce raffinement signifie que lensemble
des sous-buts composent ce but. La satisfaction des sous-buts est donc suffisante pour assurer
la satisfaction du but.
Nous avons dabord confront lensemble des buts puis nous les avons classs en trois
groupes : les buts non satisfaits (cf. Tableau 16), les buts dcouverts (cf. Tableau 17) et les
buts quivalents (cf. Tableau 18).
Modle AS-WISHED
Achieve Demande SAV analyse
Achieve Qualit traite
Achieve Accord obtenu
Maintain Intervention lheure
Achieve Responsable identifi
Achieve Commande achat envoye
Tableau 16- buts non satisfaits par SAGE X3
Modle MIGHT-BE
Achieve Contrat rsili
Achieve Contrat renouvel
Achieve Contrat cltur
Achieve Historique facturation contrat
service mise jour
Achieve Demande garantie valide
Achieve Solution archive
Achieve Activits demandes horodates
Achieve Ressources rserves
Tableau 17- Buts dcouverts
110
Figure 46- Vue intentionnelle du modle AS-WISHED
111
Figure 47- Vue intentionnelle du modle MIGHT-BE
112

Modle AS-WISHED
Achieve Contrat de garantie cr
Achieve Contrat service cr
Achieve Demande enregistre
Achieve Consommation renseigne
Achieve Intervention planifie
Achieve Intervention clture
Achieve Suivi produit cr
Achieve Facture envoye
Achieve Commande enregistre
Modle MIGHT-BE
Achieve Contrat de service cr
Achieve Demande enregistre
Achieve Consommations renseignes
Achieve Parc client cr
Tableau 18- Buts quivalents
Nous navons pu, au niveau intentionnel, retracer les dcisions rellement prises par
lentreprise. Les buts quivalents sont, dans tous les cas, ajouts au modle TO-BE
intentionnel. Nous avons galement ajout les buts non-satisfaits et les buts dcouverts afin
dtudier les dcisions qui ont t prises leur propos par lentreprise sur la vue fonctionnelle.
1.2.2
1.2.2.1
Vue fonctionnelle
Nous avons construit la vue fonctionnelle des modles AS-WISHED et MIGHT-BE pour tous
les processus associs aux buts du modle TO-BE intentionnel. Ils sont prsents au fur et
mesure du processus dalignement travers les modles confronts. Le modle AS-WISHED
a t construit sur la base de documents fournis par lentreprise, dinterviews du responsable
SAV et du PDG. Il a t valid par ces derniers. Le modle MIGHT-BE a t reconstitu,
dabord, sur la base dune manipulation du module SAV en standard de SAGE X3 puis par
une validation de lintgrateur. Pour chaque modle, nous avons dtaill les attributs en entre
et en sortie de chaque activit dans un tableau. Certaines activits telles que les activits de
cration ou denregistrement ne modifient que ltat de lobjet activits atomiques. Les vues
dobjet correspondantes ne contiennent donc pas dattributs.
Le niveau de granularit le plus lev a t respect. Prenons lexemple de lactivit saisir
les informations concernant le rapport dexpertise du processus associ au but Achieve
Responsabilit identifie . Il sagit dune activit qui agrge les activits renseigner le type
de dusure , renseigner le responsable et saisir les informations complmentaires (cf.
Figure 48 et Tableau 19). Renseigner le type de dusure et saisir les informations
complmentaires sont des activits atomiques de saisie. La seconde renseigner le
responsable est une activit elle-mme dcomposable en nud de dcision (cf. Figure
49 et Tableau 20). En fonction de la valeur de lattribut typeUsure - dutilisation ou
anormale - de lobjet RapportExpertise , la valeur de lattribut responsable est soit
garantie soit facturable .
113
Figure 48- Dcomposition de lactivit agrge saisir les informations concernant le rapport
dexpertise
Attributs en entre et
en sortie
Vues dobjet
Attributs
AS-WISHED, sortie
RapportExpertise saisi 1
idRapport, typeUsure (anorrmale / utilisation)
AS-WISHED, entre
RapportExpertise
typeUsure (anorrmale / utilisation)
AS-WISHED, sortie
responsable (facturable / garantie)
AS-WISHED, sortie
infoSupp
Tableau 19- Attributs des vues dobjets pour le processus associ au but Achieve Responsabilit
Identifie
Figure 49- Dcomposition en nud de dcision de lactivit renseigner le responsable
114
Attributs en entre et en
sortie
Vues dobjet
Attributs
AS-WISHED, sortie
idRapport, typeUsure (anorrmale / utilisation),
AS-WISHED, sortie
responsable : garantie
AS-WISHED, sortie
responsable : facturable
AS-WISHED, sortie
infoSupp
Identifie
Construire le modle AS-WISHED simultanment pour lensemble des processus nous a

permis didentifier trois interdpendances de processus. Nous les avons marques en vert
sur les figures. Par exemple, lattribut responsable de la vue dobjet rapport
dexpertise constitue la fois la sortie de lactivit saisir les informations concernant le
rapport dexpertise et lentre de lactivit crer un devis associe au but Achieve
Accord obtenu (cf. Figure 50). Cette interdpendance dE / S est accompagne dun
vnement. En fonction de la valeur prise par lattribut responsable , lactivit crer un
devis sera excute ou non. En dautres termes, si le responsable nest pas le client, alors
cette activit et toutes les activits qui suivent ne sont pas excutes. Les interdpendances de
processus sont prendre en compte dans la prise de dcision pour respecter la cohrence du
modle TO-BE en cours de construction. Cependant, puisque dans ce cas dtude, il ny a pas
eu de modification de construits dans le modle AS-WISHED, nous navons pas pu appliquer
la prise de dcision conjointe pour deux processus interdpendants.
Figure 50 Illustration de linterdpendance de processus
1.2.2.2
Confronter les modles AS-WISHED et MIGHT-BE
Pour la confrontation des processus, nous avons suivi lordre suivant : processus associs aux
buts non satisfaits, processus associs aux buts quivalents, processus associs aux buts
dcouverts. Nous privilgions galement les processus qui gnrent des interdpendances tels
115
que le processus associ au but Achieve Responsabilit identifie . En effet, cest la sortie
de lune des activits de ce processus qui constitue lentre dun autre processus. Ainsi, il est
prfrable de commencer par le processus qui gnre la sortie.
Confrontation des processus associs aux buts non satisfaits par lERP
Parmi les 6 processus associs aux buts non satisfaits par lERP, nous prsentons ici le
modle associ au but : Achieve Responsabilit identifie (cf. Figure 51 et Tableau 21).
Les 5 autres sont mis en annexe H.
Figure 51- Vue fonctionnelle associe au but Achieve Responsabilit identifie
Attributs en
entre et en
sortie
Vues dobjet
Attributs
AS-WISHED,
entre
RapportExpertise
typeUsure (anorrmale / utilisation)
AS-WISHED,
sortie
RapportExpertise saisi
idRapport, typeUsure (anorrmale / utilisation),

responsable (facturable / garantie), infoSupp
identifie
Le niveau de granularit employ pour modliser les activits suffit pour comprendre leur
enchanement. Elles ne sont donc pas dsagrges.
Ce processus nest prsent dans aucune des versions Vintgrateur et Ventreprise du modle TO-BE.
Il na donc pas t support par le S.I. base dERP et nous ne le modlisons pas dans le
modle TO-BE fonctionnel que nous construisons au fur et mesure. Par contre, la dcision
prise a t le support manuel (D4) du processus, ce qui a t influenc par lexistant,
puisque cela est dj le cas. Linterview du PDG de la socit a confirm que la dcision a t
prise inconsciemment. En effet, ce besoin navait pas t formul lors des runions
116
dadquation. Ce choix entrane une absence de traabilit pour le processus identification

de la responsabilit . Cela peut donc amener des erreurs concernant lidentification du
responsable sans aucune vrification possible.
Compte tenu de la dcision prise, cela nous amne conseiller, prsent, lentreprise un
complment la conduite de changement (D6) pour faire face au non-support par le S.I.
ERP du processus souhait. Lentreprise devra notamment penser formaliser les procdures
manuelles.
La dcision de dveloppement spcifique dans lERP (D2) aurait pu tre prise. Plus
prcisment, il aurait t possible dajouter du code au code source de lERP afin dajouter
lattribut type lobjet dentreprise Intervention en vue de gnrer des interventions de
type analyse de la demande et non de type rparation. Lentreprise aurait pu valuer le cot
que cette dcision aurait pu engendrer. Nous aurions galement conseill lassociation de cette
dcision celle de complment la conduite de changement (D6) afin de mettre jour la
documentation associe ce dveloppement spcifique.
Il faut noter que si le but associ au processus Achieve responsabilit identifie navait
pas t support mme manuellement, cela aurait perturb la cohrence du modle TO-BE en
cours de construction de par linterdpendance sur lattribut responsable voque
prcdemment.
Pour lensemble des processus associs aux buts non satisfaits par lERP, toutes les dcisions
ont t prises inconsciemment. On peut en faire le bilan suivant (cf. Figure 52) :
-
1 processus sur 6 a t paramtr (D1). Le processus est cependant satisfait en parti car
cest une fonctionnalit de lERP qui a t dtourne. En effet, il sagit de lenvoi du devis
au client sans le lier une demande SAV.
1 processus a fait lobjet dun dveloppement spcifique dans lERP (D2) par lajout
de code source.
3 processus ont t supports manuellement (D4).
1 processus a t abandonn (D5). Pour ce processus, nous sommes ici en prsence de
loccurrence du rsultat indsirable associ au RNA.
1 processus support par dveloppement spcifique dans
l'ERP, insconciemment
1 processus paramtr insconciemment
1
3
1
1
1 processus abandonn (RNA), inconciemment

3 processus supports manuellement, insconciemment
Figure 52- Dcisions prises pour les processus associs aux buts non satisfaits par lERP
Les processus de ces deux derniers points ne sont pas modliss dans le modle TO-BE
fonctionnel que nous construisons progressivement. La vue informationnelle lie ces
processus ne sera pas construite et confronte dans la suite du processus dalignement. Il
117
aurait t possible deffectuer un dveloppement spcifique dans lERP (D2) associ un

complment la conduite de changement (D6) pour satisfaire ces processus. Cela na pas
t le cas.
Pour lensemble des dcisions rellement prises, sauf celle de paramtrage , nous
conseillons lentreprise dy associer la dcision de complment la conduite de
changement (D6).
Confrontation des processus associs aux buts quivalents
Parmi les neuf processus associs aux buts quivalents, nous prsentons celui associ au but
Achieve Demande enregistre (cf. Figure 53, Figure 54 et Tableau 22). Les 8 autres sont
mis en annexe I.
Figure 53- Vue fonctionnelle du modle AS-WISHED pour le processus associ au but Achieve Demande
enregistre
Figure 54- Vue fonctionnelle du modle MIGHT-BE pour le processus associ au but Achieve Demande
enregistre
118
Objets
AS-WISHED,
sortie
Demande saisie
Attributs
idDemande, type (installation / suivi / rparation), numClient,
numCommandeOrigine, dateSouhaite, gravit (urgent / non urgent)
infoSupp, idSuiviProduit, idProduit, dsignationProduit
idDemande, site, interlocuteur, responsableOuverture, dateOuverture,

origineOuverture, numClient, numCommandeOrigine, titreDemande,
MIGHT-BE,
descriptionDemande, idProduit, modeAffectationTechnicien
Demande saisie
sortie
(dispatching / collaborateur / queue), familleComptenceChoisie,
technicienChoisi, dateAffectation, dateSouhaite, heureSouhaite,
gravit (urgent / non urgent), idContrat, motif
Tableau 22- Attributs des vues dobjets pour les processus associs au but Achieve Demande
enregistre des modles AS-WISHED et MIGHT-BEActivits
Activits
La premire activit est aligne mais la vue dobjet en sortie na pas dattributs, elle est
uniquement cr activit atomique de cration.
La deuxime activit est aligne. Nous compltons le modle TO-BE fonctionnel de cette
activit et nous confrontons ses entres / sorties.
Entres / sorties
Nous navons pas confront lattribut modeAffectationTechnicien en entre indiquant
uniquement un nud de dcision non dcompos. Il signifie quen fonction de la valeur
prise par cet attribut, les autres attributs de lobjet Demande ne seront pas tous saisis. Par
exemple, si le mode queue est choisi, la famille de comptence du technicien ne sera pas
renseigner ce niveau. Ainsi, lattribut familleComptenceChoisie ne sera pas saisi. Nous
avons confront les attributs de la vue dobjet Demande en sortie et nous les avons classs
en 3 catgories : attributs non satisfaits par lERP et uniquement prsents dans le modle ASWISHED, attributs aligns et attributs dcouverts dans le modle MIGHT-BE. Nous avons
opt pour des dcisions de groupe.
Les
8
attributs
suivants
sont
aligns
:
idDemande ,
numClient ,
numCommandeOrgine , dateSouhaite , idProduit , gravit ainsi que ses valeurs
urgent et non urgent . Nous considrons lattribut infoSupp align
descriptionDemande , idSuiviProduit align idContrat ainsi que motif align
type . Ces attributs sont prsents dans les versions Vintgrateur et Ventreprise du modle TO-BE.
La dcision de paramtrage (D1) a t prise en toute connaissance de cause. Nous
ajoutons au modle TO-BE fonctionnel ces 8 attributs.
Un attribut est non-satisfait : dsignationProduit . Il a t abandonn (D5). La saisie des
informations concernant la demande ne permet pas donc de prciser le nom du produit
concern mais uniquement son numro. Cette dcision a t prise inconsciemment et
correspond la survenue de loccurrence du rsultat indsirable associ au RNA. Cela nous
119
amne conseiller lentreprise un complment la conduite de changement (D6) pour

faire face cet abandon. Cela pourrait tre une communication accrue auprs des personnels
concerns. La dcision de dveloppement spcifique dans lERP (D2) aurait pu tre prise
en ajoutant cet attribut lobjet dentreprise Demande et en modifiant lcran par lajout
dun champ permettant de saisir la dsignation du produit. Mme si le cot est valuer, ce
dveloppement spcifique aurait permis de gagner en clart lors de la consultation ou de la
cration de la demande de service. De plus, nous aurions conseill lassociation de cette
dcision celle de complment la conduite de changement (D6) pour mettre jour la
documentation associe ces dveloppements spcifiques.
Onze attributs sont dcouverts : site , interlocuteur , responsableOuverture ,
dateOuverture , origineOuverture , titreDemande , modeAffectationTechnicien
avec ses valeurs, familleComptenceChoisie , technicienChoisi , dateAffectation ,
heureSouhaite . Lensemble de ces attributs sont prsents dans les versions Vintgrateur et
Ventreprise du modle TO-BE. Ils ont donc tous t paramtrs (D1) en toute connaissance de
cause. Le modle TO-BE fonctionnel est complt avec ces 11 attributs. Nous conseillons,
prsent, lentreprise un complment la conduite de changement (D6) afin dorganiser
un complment de formation sur lensemble de ces nouveaux concepts.
Activits
La troisime activit est aligne mais la vue dobjet en sortie na pas dattributs, elle est
uniquement cr activit atomique denregistrement.
La vue fonctionnelle du modle TO-BE obtenu lissue des trois dcisions est reprsente sur
la Figure 55 et le Tableau 23.
Figure 55- Modle TO-BE fonctionnel construit lissue de lensemble des dcisions associes au but
Achieve Demande enregistre (1 / 2)
120
Objet
Demande
saisie
Attributs
idDemande, site, interlocuteur, responsableOuverture, dateOuverture, origineOuverture,
numClient, numCommandeOrigine, titreDemande, descriptionDemande, idProduit,
modeAffectationTechnicien (dispatching / collaborateur/ queue),
familleComptenceChoisie, technicienChoisi, dateAffectation, dateSouhaite,
heureSouhaite, gravit (urgent / non urgent), idContrat, motif
Tableau 23- Modle TO-BE fonctionnel construit lissue de lensemble des dcisions associes au but
Achieve Demande enregistre (2 / 2)
La confrontation des construits de la vue fonctionnelle des modles AS-WISHED et MIGHTBE associs aux buts quivalents peut tre synthtise de la manire suivante (cf. Figure 56,
Figure 57 et Figure 58 ).
Concernant les activits et attributs prsents uniquement dans le modle AS-WISHED (cf.
Figure 56) :
-
12 attributs sur 15 ainsi que 2 activits prsents uniquement dans le modle AS-WISHED
ont t abandonns (D5). Ces dcisions ont t prises inconsciemment et correspondent
la survenue de loccurrence du rsultat indsirable associ au RNA. Nous leur avons
associ les dcisions de dveloppement spcifique dans lERP (D2) et de
complment la conduite de changement (D6). Nous avons galement mis en avant
les critres de cot, dintrt et dintgrit de lintgration de lERP sur lesquelles
lentreprise aurait d se pencher pour prendre sa dcision. Le fait dabandonner les
souhaits engendre un manque de traabilit, une moins bonne relation avec les clients ou
encore la dtrioration de la visibilit analytique. Ces situations de non-alignement nont
sans doute pas t identifies lors de ladquation du module SAV en 2009.
2 attributs sur 15 identifis comme non satisfaits par lERP ont fait lobjet de
dveloppements spcifiques dans lERP (D2). Ils ont t ajouts aux objets
dentreprise et lcran a t modifi afin que lutilisateur puisse saisir la valeur de ces
attributs. Puisque ces attributs ne sont prsents que dans la version Vintgrateur et non dans la
version Ventreprise du modle TO-BE, les deux dcisions ont t prises inconsciemment.
Pour ces attributs, nous ne pouvons pas savoir si cela vient dune non-identification du
non-alignement pendant les runions dadquation ou si les dcisions ont t prises sans
lavis de lentreprise et donc en dehors de ces runions.
Enfin, seul un attribut non align et uniquement prsent dans le modle AS-WISHED a
bnfici dun dveloppement spcifique dans lERP (D2) et ce en toute connaissance
de cause.
De plus, il sagit, prsent, pour lentreprise de mettre en place un complment la

conduite de changement (D6) dune part, pour mettre jour, en fonction des
dveloppements spcifiques effectus, la documentation fournie par lditeur ; et dautre part,
pour faire face labandon des attributs et activits.
121
1
2
14 (2 activits et 12 attributs) abandonnes

(RNA), inconsciemment
2 attributs supports par dveloppement
spcfique dans l'ERP, inconsciemment
1 attribut support par dveloppement
spcfique dans l'ERP, consciemment
14
Figure 56- Dcisions sur les attributs et activits uniquement prsents dans le modle AS-WISHED
Concernant les attributs prsents uniquement dans le modle MIGHT-BE et associs des
activits alignes (cf. Figure 57Figure 56) :
-
Seul 1 attribut sur les 85 attributs dcouverts na pas t implant au sein de lERP et ce,
consciemment.
Concernant les 84 autres attributs, 47 attributs - c'est--dire environs 55% - ont t
paramtrs (D1) inconsciemment. Les 37 autres ont t paramtrs en toute connaissance
de cause. Cela signifie que tout ce que lintgrateur a jug comme pertinent dimplanter
na pas t discut durant les runions dadquation avec lentreprise. Cependant,
lentreprise a bnfici ici du fait quil y avait peu de processus mis en place au niveau du
module SAV dans lexistant. Ainsi, beaucoup dattributs ont t dcouverts. Lentreprise
navait peut-tre pas la maturit suffisante dans ce domaine pour les exprimer. Pour
lensemble de ces attributs dcouverts et implants, un complment la conduite de
changement (D6) est, prsent, ncessaire en vue dorganiser la ou les formations
relatives lensemble de ces nouveaux concepts.
1
1 attribut non paramtr consciemment
37
47 attributs paramtrs inconsciemment

47
37 attributs paramtrs consciemment
Figure 57- Dcisions prises pour les attributs non aligns, uniquement prsents dans le modle MIGHTBE et associs des activits alignes entre les modles
Les 43 attributs aligns lis des activits alignes ont t paramtrs (D1). Sur ces 43
dcisions de paramtrage , 15 - ce qui reprsente 35% des dcisions - ont t prises
inconsciemment (cf Figure 58). Nous pensons que ces situations dalignement nont pas t
identifies pendant les runions dadquation soit parce que lentreprise na pas clairement
exprim ses besoins, soit parce que la confrontation ntait pas structure.
122
15
28
15 attributs paramtrs inconsciemment

28 attributs paramtrs consciemment
Figure 58- Dcisions prises pour les attributs aligns des activits alignes entre les modles AS-WISHED
et MIGHT-BE
Confrontation des processus associs aux buts dcouverts

Sur les 8 processus associs aux buts dcouverts, nous prsentons ici celui associ au but
Achieve Contrat renouvel (cf. Figure 59 et Tableau 24).
Figure 59- Vue fonctionnelle du modle MIGHT-BE pour le processus associ au but Achieve Contrat
renouvel
MIGHT-BE, sortie
Vues dobjet
Contrat renouvel
Attributs
tat : renouvel
Tableau 24- Attributs des vues dobjets pour le processus associ au but Achieve Contrat renouvel
Lactivit du processus ne peut pas tre modlise un niveau de granularit plus fin (cest
une activit atomique) et est prsente dans la version Vintgrateur du modle TO-BE cest--dire
que cette activit et ses E / S ont t paramtres (D1). Cependant, cette activit nest pas
prsente dans la version Ventreprise. La dcision a donc t prise inconsciemment. Le modle
TO-BE fonctionnel est complt avec ce processus. La dcision dun complment la
conduite de changement (D6) afin dorganiser un complment de formation sur ce processus
est prconise conjointement.
La Figure 60 et le Tableau 25 reprsentent un modle TO-BE fonctionnel partiel obtenu
lissue de la confrontation / prise de dcision des trois processus que nous avons dtaills ici.
123
Figure 60- Modle TO-BE fonctionnel construit lissue des trois processus confronts dans lapplication
(1 / 2)
Objets
Demande
saisie
Contrat
renouvel
Attributs
idDemande, site, interlocuteur, responsableOuverture, dateOuverture, origineOuverture,
numClient, numCommandeOrigine, titreDemande, descriptionDemande, idProduit,
modeAffectationTechnicien (dispatching / collaborateur/ queue),
familleComptenceChoisie, technicienChoisi, dateAffectation, dateSouhaite,
heureSouhaite, gravit (urgent / non urgent), idContrat, motif
tat : renouvel
Tableau 25- Modle TO-BE fonctionnel construit lissue des trois processus confronts dans
lapplication (2 / 2)
Nous concluons, pour les processus associs aux buts dcouverts (cf. Figure 61) que :
-
2 dcisions de paramtrage (D1) ont t prises en toute connaissance de cause.

Pour 4 processus il a t dcid de ne pas les paramtrer et cela a t ralis
inconsciemment. Nous sommes en prsence de loccurrence du rsultat indsirable associ
au RNA. Cela reprsente une perte pour lentreprise. Lapplication de la mthode Model
Driven - ERP Alignmment aurait pu lui permettre didentifier ces processus dcouverts.
Ainsi, elle aurait pu bnficier dune amlioration de la relation avec sa clientle dautant
plus que paramtrer ces processus naurait pas engendr de cots supplmentaires.
Un processus a t paramtr (D1) et cela inconsciemment.
Enfin, 1 dcision de ne pas paramtrer un processus a t prise consciemment.
1
2 processus paramtrs, consciemment

4 processus non paramtrs, inconsciemment (RNA)
1 processus paramtr, inconsciemment
1 processus non paramtr, consciemment
4
Figure 61- Dcisions prises pour les processus associs aux buts dcouverts
124
1.2.3
Vue informationnelle
La socit X na pas exprim de besoins au niveau de cette vue.

Sur les 158 attributs de vue dobjet du modle TO-BE construit au cours de la confrontation
des construits de la vue fonctionnelle dans le modle TO-BE fonctionnel, 4 dont lattribut
sav pour les objets dentreprise CommandeAchat et Commande ainsi que
priocidicitIntervention pour les objets dentreprise ContratGarantie et
ContratService , ont fait lobjet dun dveloppement spcifique dans lERP (D2). Plus
exactement, ces attributs ont t ajouts aux objets dentreprise car ils nexistaient pas en
standard. Pour ces 4 attributs, la vue informationnelle du modle MIGHT-BE nexiste pas.
Pour les 154 autres, mme si cela na pas t fait en ralit, il aurait t possible de construire
les modles MIGHT-BE et AS-WISHED. Cela sapplique galement aux attributs pour
lesquels le modle AS-WISHED fonctionnel nexistait pas. Prenons lexemple de lattribut
dateOuverture de lobjet dentreprise Demande . Il napparaissait pas initialement dans
le modle AS-WISHED fonctionnel de lentreprise. Il sagit donc dun attribut dcouvert que
lentreprise a dcid de paramtrer. Il va donc tre modlis au niveau de la vue
informationnelle du modle AS-WISHED car il faut en spcifier la forme souhaite.
La construction de ce modle AS-WISHED aurait consist, par exemple, modliser une
contrainte structurelle au niveau de lattribut dateOuverture avec une forme du type
jj/mm/aaaa . Pour le modle MIGHT-BE, la contrainte structurelle aurait pu tre
mm/jj/aaaa .
Enfin, la confrontation aurait consist confronter lensemble des formes modlises au
niveau des modles AS-WISHED et MIGHT-BE puis de les regrouper selon les situations
suivantes : les formes des 4 attributs prsents uniquement dans le modle AS-WISHED, les
formes alignes et les formes non alignes. Puis une dcision aurait t associe chaque
forme une par une ou par groupe de formes, au choix selon le contexte. Le non-alignement au
niveau de la forme de lattribut dateOuverture aurait t ainsi identifi. Dans ce cas,
lentreprise aurait pu dcider dabandonner son souhait en paramtrant lERP (D1). Cela
aurait eu pour consquence dcrire dornavant ses dates sous la forme mm/jj/aaaa . Elle
aurait galement pu effectuer un dveloppement spcifique dans lERP (D2) en modifiant
la forme prise par la date. Chacune de ces dcisions aurait ncessit de prendre conjointement
la dcision dun complment la conduite de changement (D6). Ainsi, dveloppement
spcifique dans lERP (D2) aurait ncessit de mettre jour la documentation fournie par
lditeur et le paramtrage (D1) aurait ncessit une communication accrue sur les
activits dont la forme des dates nest pas celle qui avait t initialement prvue.
125
1.2.4
Synthse de la dcision de complment la conduite de changement
Association la dcision D6 : complment la conduite

de changement
Pour lensemble de lapplication, et compte tenu des dcisions prises, il a t prconis

dappliquer la dcision de complment la conduite de changement (D6) conjointement
aux autres dcisions. Nous synthtisons cette prise de dcision dans le Tableau 26.
Dcisions
D1 : paramtrage
D2 : dveloppement
spcifique dans lERP
D3 : ajout dune brique
applicative
D4 : support manuel
D5 : abandon
Construits et situations
Processus dcouvert
Activit dcouverte
E ou S dcouvertes
Forme non aligne
Forme non aligne
But non satisfait
Construits et situations dans

lapplication
3 processus dcouverts
Non
84 attributs dcouverts
Non
1 processus non satisfait
Non
3 attributs non satisfaits
non
Non
Non
3 processus non satisfaits
Non
Non
1 processus non satisfait
2 activits non satisfaites
12 attributs non satisfaits
Tableau 26- Dcision D6 prise conjointement aux autres dcisions durant lapplication
1.3
Conclusion de lapplication de Model Driven - ERP Alignment
Lapplication a posteriori de la mthode Model Driven - ERP Alignment sur le module

SAV a montr que le S.I. ERP na pas align aux besoins rels de lentreprise. Elle nous a
galement permis de valider lapplicabilit et lintrt des contributions proposes.
Pour commencer, la construction de la vue intentionnelle permet une exhaustivit de
lexpression des besoins. La construction de la vue fonctionnelle au niveau de granularit le
plus lev nous a grandement aid pour, ensuite, confronter les modles de cette vue. Elle
aurait t moins vidente si les modles avaient t construits un niveau plus fin, notamment
en dcomposant certaines activits en nuds de dcision . De plus, modliser tous les
processus simultanment pour cette vue a permis didentifier aisment les interdpendances et
de disposer dune cartographie des processus pour dterminer ceux qui devaient tre
confront en premier.
En ce qui concerne la confrontation des modles, commencer par la vue intentionnelle a
permis de structurer le processus dalignement en mettant en lumire, ds le dbut, les buts
non satisfaits, les buts aligns et les buts dcouverts. Lentreprise aurait pu, par ce biais,
dcider de ne pas implanter certains processus et ce, ds les premires activits du processus
126
dalignement. La confrontation de la vue fonctionnelle au niveau de lenchanement des

activits et des E / S a permis didentifier des situations dalignement et de non-alignement
qui navaient pas t identifies lors des runions dadquation. En effet, plus de la moiti des
dcisions - 51% - pour face ces situations ont t prises inconsciemment. Pour les construits
dcouverts, que ce soit des activits ou des E / S, lentreprise a surtout bnfici des
opportunits offertes par lERP. Cependant, si toutes les situations avaient t identifies, ce
bnfice aurait pu tre plus important et notamment pour les 4 processus dcouverts pour
lesquels il a t dcid inconsciemment de ne pas les paramtrer. La dcision de ne pas
supporter les construits non-satisfaits par le S.I. ERP a abouti la survenue du rsultat
indsirable associ au RNA. En effet, ces besoins rels ne sont pas aligns aux processus
implants. Bien que la confrontation / prise de dcision de la vue informationnelle nait pu
tre mise en pratique, nous lavons illustre sur un exemple. Lutilit de la vue
informationnelle concerne surtout les modules pour lesquels lentreprise a un existant plus
riche et dont, notamment, les codifications sont normalises. Dans ce cas-l, elle peut
exprimer le besoin de conserver une codification spcifique de ses attributs.
La prise de dcision a t facilite par lutilisation des construits de la norme (ISO/DIS 19440
2004). En effet, cette modlisation oriente objet permet de visualiser les ventuelles
modifications faire au niveau de lERP de manire plus aise. De plus, grce lassociation
situations / dcisions de notre mthode, nous avons pu proposer dautres dcisions que celles
prises par lentreprise. Nous avons galement mis en avant la prise en compte des critres de
cots, intrt, intgrit de lintgration et cohrence du modle TO-BE en cours de
construction sur lesquels lentreprise aurait d se pencher. Pour ce dernier critre, puisque
tous les processus interdpendants ont t supports mme manuellement, la cohrence du
modle TO-BE en cours de construction na pas t perturbe. La mise en production du
module SAV nayant pas encore t ralise, lentreprise peut appliquer le complment la
conduite de changement que nous proposons, en fonction des dcisions quelle a prises consciemment ou non. Nous avons en particulier mis en avant la ncessit deffectuer des
formations sur de nouveaux concepts, de prvoir une rorganisation des rles ou encore de
mettre jour la documentation fournie par lditeur.
Approche Risk-Factor Driven - ERP Alignment
Dans cette section, nous appliquons au projet ERP de la socit X lapproche de management
des facteurs de risque Risk-Factor Driven ERP - Alignment propose dans le chapitre 5.
Avant de dtailler cette application, nous dfinissons, dans la section 2.1, la dmarche suivie.
127
2.1
Dmarche
Lapproche Risk-Factor Driven - ERP Alignment est applique a posteriori sur les
facteurs de risque correspondant deux tapes cls du projet ERP de la socit X, savoir :
-
Ltape dadquation qui a eu lieu de mars juin 2009 et que nous appellerons dans la
suite la priode dadquation.
Ltape de tests qui a eu lieu de novembre 2009 janvier 2010. Durant cette priode le
RNA a t identifi. En effet, une partie des processus mis sous contrle de lERP suite
aux runions dadquation ont t identifis comme non aligns aux besoins rels de
lentreprise. Les runions de tests se sont transformes en runions dadquation,
comme la confirm lintgrateur. Nous appellerons cette priode la priode de retour sur
adquation.
Pour ces deux priodes, aucune approche de management navait t encore mise en uvre.
Notre dmarche (cf. Figure 62) a consist :
-
Appliquer les stratgies doptimisation et de refus ractif :

En identifiant, chaque priode, les facteurs de risque qui staient matrialiss.
Les facteurs de la phase de pr-implantation ont t identifis uniquement lors de
la premire priode dadquation.
Puis en mettant en lumire les pratiques qui auraient d tre appliques.
Appliquer la stratgie de refus anticipatif :
En identifiant, chaque priode, les facteurs qui avaient de fortes chances de se
matrialiser mais qui nont pas t identifis comme avrs pour autant.
Puis en dtaillant les pratiques appliquer pour traiter ces facteurs.
Priode de retour sur

adquation
Priode dadquation
Dmarche
Impact
Identifier facteurs avrs
Traiter ces facteurs avec
les pratiques
Identifier facteurs non
avrs mais avec forte
chance de se matrialiser
Traiter ces facteurs avec
les pratiques
Outils
utilissEspace
Variables des facteurs
Matrice pratiques de
gestion / facteurs de
risque
Matrice des liens
rsiduels pour les
facteurs influenant le
RNA
Matrice pratiques de
gestion / facteurs de
risque
Stratgies
Business
Evolution?
Refus ractif
Nouveaux facteurs
avrs ?
Optimisation
Facteurs traits ?
Refus
anticipatif
Ajustement
Pratiques appliques
par lquipe de projet ?
Pratiques non
appliques ?
Figure 62- Dmarche suivie pour lapplication a posteriori de lapproche Risk-Factor Driven - ERPAlignment
Ainsi, cest lassociation de lapplication de lapproche pour ces deux priodes cls qui
constitue loriginalit de ce cas. Dune part, cela permet didentifier les facteurs qui se sont
128
matrialiss et / ou ceux qui ont t traits par lquipe projet dune priode lautre. Dautre
part, nous soulignons les pratiques qui auraient dues tre appliques la suite dune premire
identification des facteurs mais qui ne lont pas t, ou celles qui ont t mises en place.
2.2
Application de lapproche Risk-Factor Driven - ERP Alignment
2.2.1
2.2.1.1
Priode dadquation
Identification et traitement des facteurs avrs
Nous indiquons dans le Tableau 27, pour chaque facteur, la ou les variable(s) avre(s), la ou
les pratique(s) mettre en uvre pour les traiter ainsi que les stratgies de traitement mises en
uvre - refus anticipatif, optimisation et refus ractif.
Un facteur sur les quatre facteurs verticaux de la phase de pr-implantation a t identifi
comme avr. Il sagit du facteur BPR inadquat , dont les variables redfinition
incomplte et BPR au mauvais moment ont t identifies comme avres. En effet, Le
BPR a t appliqu peu de processus tels que celui de stockage. Cependant, dautres tels que
ceux lis la production ou lexpdition nont pas fait lobjet de rflexion et refonte. De plus,
ce BPR na pas t ralis en phase de pr-implantation mais plutt en parallle, notamment,
aux runions dadquation et ltape de test et intgration. Ce facteur naurait pu ni tre
optimis, ni refus. Les pratiques qui lui sont associes concernent des activits sur lesquelles
il ntait plus possible de revenir durant ltape dadquation.
Les autres facteurs de risque verticaux de la phase de pr-implantation nont pas t identifis
comme avrs. Lentreprise semble avoir appliqu les pratiques suivantes correctement :
-
Concernant la formulation des buts stratgiques, elle a pris en compte la stratgie de

lentreprise qui consistait stendre un march plus vaste pour faire face la
concurrence.
Concernant la slection du progiciel, celui-ci a t slectionn en rapport avec son
primtre fonctionnel et une short-list avait t constitue comme base pour faire la
slection finale.
Concernant la formulation des besoins - ici macroscopiques - lentreprise sest base sur
lexistant, elle a pris en compte lensemble du primtre fonctionnel de lentreprise, a
utilis les formalismes adquates, ou encore, a modlis ses processus niveau de
granularit suffisamment macroscopique.
Pour les 11 facteurs de risque horizontaux, nous en avons identifi 6 comme avrs. Pour les
facteurs verticaux de ltape dadquation, nous en avons identifi 3 sur 4 comme avrs.
Nous avons opt pour le refus ractif de lensemble de ces facteurs identifis afin de ne plus
les observer. En effet, lensemble des pratiques conseilles pour chaque facteur auraient pu
tre mises en place durant la priode dadquation. Parmi ces 10 facteurs identifis, nous en
dtaillons 3. Les autres sont dtaills en annexe K.
129

Cycle de vie
Verticaux,
phase de primplantation
Variables avres
-Redfinition incomplte
-BPR au mauvais moment
/
/
/
/
-Pas dutilisation de mthodes de gestion de projet
-Pas dutilisation doutils de gestion de projet
- Rpartition inadquate des rles et responsabilits
-Pas de consultants externes
Horizontaux
Aucune
F16 : Buts stratgiques mal dfinis

F17a : Mauvaise expression des besoins
F1 : Manque dimplication / dexpertise du comit de
pilotage
P11, P17, P19, P20
Refus ractif

F5 : Manque dexpertise / dimplication / absence de
P22
Refus ractif
P22, P29
Refus ractif

F9 : Mauvaise gestion des ressources financires et
matrielles
F10 : Difficult de travail commun entre lentreprise et
les membres externes
F11 : Manque dexpertise / dimplication des
utilisateurs cls

/
-Pas de processus de gestion des risques
-Manque de modlisation des processus souhaits
-Pas de formalisation des fonctionnalits standards de
lERP
-Mauvaise gestion des runions dadquation
-Pas danalyse de la ncessit dadapter en fonction de
lintrt de lentreprise
-Pas danalyse des cots dadaptation
-Pas de formalisation des besoins dtaills
-Manque de formalisme dans lexpression des besoins
/
Stratgie
Pratiques conseilles
F15 : BPR inadquat
Verticaux,
tape dadquation
Facteurs
P4, P15, P17, P22, P24,

P25
-
Refus ractif
-
P5, P8, P18, P19, P22,

P25, P26
-
Refus ractif
-
P30
Refus ractif
P6, P14, P15, P31
Refus ractif
F20 : Gestion inadquate de ladaptation de lERP
P12, P14, P15, P23
Refus ractif
P6
Refus ractif
Refus
anticipatif
Tableau 27- Identification et traitement des facteurs de la priode dadquation
130
F5 : Facteur manque dexpertise / dimplication / absence de consultants externes

La variable pas de consultants externes a t identifie comme avre. En effet, il ny
avait pas de consultants externes durant les runions dadquation. Nous aurions conseill
lentreprise les pratiques de gestion suivantes :
-
P22 : Dterminer par crit ds le dbut du projet les rles et responsabilits de chaque
membre de lquipe que nous avons adapt en : dterminer par crit, pour les consultants
externes nouvellement slectionns, leurs rles et responsabilits.
P29 : Slectionner les consultants externes en fonction des critres dexprience, de
comptences. Cest une pratique qui aurait d tre mise en place depuis le dbut du projet.
Cependant, il est possible dy remdier au cours du projet et de slectionner des
consultants externes.
Dans le contexte du projet, les pratiques P18, P19 et P26 - associes galement ce facteur nont pas lieu dtre conseilles. En effet, cela ne sert rien dorganiser des exercices de
travail en quipe et de mettre en place la rgulation dquipe ainsi que le processus de mise en
confiance pour des consultants qui nont pas encore t slectionns.
F19 : Facteur gestion inadquate du non-alignement
Les variables suivantes ont t identifies comme avres :
-
Manque de modlisation des processus souhaits : les processus souhaits et

confronts correspondaient des activits macroscopiques des processus dit
principaux , tels que nous la confirm lintgrateur. Cette slection dactivits
aligner navait aucune logique.
Pas de formalisation des fonctionnalits standards de lERP : ces fonctionnalits ont
t montres aux membres de lentreprise en projetant les interfaces utilisateurs de
lERP sur un cran sans relle structuration des lments prsents.
Mauvaise gestion des runions dadquation : le non-alignement a t identifi par les
utilisateurs cls sur la base des commentaires des membres de lentreprise exprimant si ce
qui tait projet tait quivalent ou non leurs besoins.
Dcisions prises la lgre : les utilisateurs cls prsents lors des runions ne
savaient pas si les dcisions qui taient prises taient dfinitives ou non.
Pour ces facteurs, 4 pratiques de gestion auraient pu tre mises en place :

-
P6 : Formaliser, laide dun formalisme simple et intuitif, les processus souhaits par
lentreprise et les fonctionnalits standards de lERP.
P14 : Identifier, en fonction de la nature de la dcision, les membres du projet ayant du
poids sur celle-ci.
P15 : Disposer dun chef ce projet reconnu comme tant linterlocuteur principal pour
prendre les dcisions qui sont bloquantes tant sur les aspects techniques que mtiers.
P31 : Prparer les runions dadquation en modlisant les processus aligner et sy tenir.
La premire pratique permet de pallier aux variables concernant la formalisation des

processus souhaits et des fonctionnalits standards. Les trois autres permettent de pallier aux
facteurs associs au droulement des runions dadquation et la prise de dcision pendant
ces runions.
131
F17b : Facteur besoins rels mal exprims

Les variables suivantes ont t identifies comme avres :
-
Besoins exprims incomplets : lentreprise na pas pris la peine de rflchir ses

besoins rels dtaills. De ce point de vue, nous considrons quils taient incomplets.
Besoins exprims incomprhensibles : lintgrateur a eu plusieurs reprises des
difficults comprendre les besoins rels de lentreprise. Ils taient exprims sur le tas
pendant les runions. Les intgrateurs sont mme revenus plusieurs fois sur les besoins
exprims, en indiquant que ce ntait sans doute pas comme cela que les acteurs
procdaient.
Pas de formalisation des besoins dtaille : les besoins de lentreprise ont t
formaliss un niveau trop macroscopique, seules les activits des processus principaux
ont t modlises.
Manque de formalisme dans lexpression des besoins : aucun formalisme na t
utilis pour reprsenter les besoins confronts lors des runions dadquation.
Nous aurions conseill lentreprise la pratique de gestion suivante :

-
P6 : Formaliser, laide dun formalisme simple et intuitif, les processus souhaits par
lentreprise et les fonctionnalits standards de lERP.
La pratique P7 impliquant de se baser sur lexistant pour modliser les processus souhaits a
t applique par lentreprise. Plus prcisment, lexistant a servi de base la modlisation
des souhaits mais un niveau trop macroscopique. La pratique P6 a dj t conseille pour le
facteur F19 concernant la gestion du non-alignement. Nous aurions donc conseill
lentreprise de modliser finement les processus souhaits dans un formalisme adquat. Cela
lui aurait permis de prendre le temps de rflchir ses besoins rels. Ils auraient t davantage
complets, comprhensibles et dtaills.
2.2.1.2
Identification et traitement des facteurs ayant une chance de se matrialiser
Comme lindique la matrice des liens rsiduels des facteurs du RNA (cf. Tableau 13, page
97), le facteur haut degr de complexit du progiciel peut subsister du mauvais traitement
des facteurs lis aux utilisateurs cls et au chef de projet qui ont t identifis comme avrs.
Comme il existe un lien rsiduel entre ce facteur et les deux facteurs identifis, il avait des
chances de se matrialiser mme sil na pas t identifi comme avr. Ainsi, mme si la
complexit des modules - variable associe au facteur considr ici - a t estime par les
utilisateurs cls et le chef de projet, cette estimation aurait pu avoir t mal ralise en raison
dun manque de comptences ou de labsence de ces derniers.
Nous aurions conseill la pratique P9 relative ltablissement dun plan de dploiement des
modules, notamment pour ceux pour lesquels ltude dadquation na pas encore eu lieu.
132
2.2.1.3
Conclusion de la priode dadquation
Comme le souligne la Figure 63, pour la priode dadquation, nous avons identifi 10
facteurs comme avrs ainsi quun facteur non avr ayant des chances de se matrialiser par
le biais des liens rsiduels.
7 facteurs influenant le RNA non identifis
1
7
1 facteur identifi a posteriori, vertical, tape de primplantation

3 facteurs identifis a posteriori, verticaux, tape
adquation
6 facteurs identifis a posteriori, horizontaux
1 facteur non avr mais avec des chances de se
matraliser
Figure 63- Proportion de facteurs influenant le RNA identifies a posteriori pour la priode dadquation
Nous avons considr que deux pratiques associes des facteurs avrs taient matrises par
lentreprise : P7 concernant la modlisation des souhaits sur la base de lexistant et P16 sur le
choix du mode de pilotage ouvert du projet. Cela na visiblement pas t suffisant pour traiter
ces facteurs de risque.
Les pratiques les plus conseilles (cf. Figure 64) sont la pratique P22 - dterminer par crit
ds le dbut du projet les rles et responsabilits de chaque membre de lquipe - et P15 disposer dun chef de projet reconnu comme tant linterlocuteur principal pour prendre des
dcisions bloquantes - qui apparaissent respectivement quatre et trois fois. Un certain nombre
de pratiques ont t conseilles deux fois : P6 - modliser les processus souhaits par
lentreprise et les fonctionnalits standards de lERP-, P14 - identifier les membres du projet
ayant du poids dans certaines dcisions -, P17 - relation ad hoc avec le chef de projet -, P19 appliquer la rgulation dquipe - et enfin P25 concernant la libration officielle des membres
du projet de leur tche quotidienne.
4,5
4
3,5
3
2,5
nbre de fois, adquation
2
1,5
1
0,5
0
P22 P19 P18 P26 P15 P14 P17 P25 P6
Figure 64- Pratiques les plus conseilles durant la priode dadquation
133
Ces pratiques auraient dues tre mises en place en priorit car elles permettent de traiter
plusieurs facteurs la fois.
2.2.2
2.2.2.1
Priode de retour sur adquation
Identification et traitement des facteurs avrs
De mme que pour la priode dadquation, nous avons identifi les facteurs avrs grce aux
variables correspondantes. Ensuite, nous leur avons associ les pratiques de gestion et
soulign la stratgie de traitement applique pour chaque facteur (cf. Tableau 28). De plus,
nous identifions lvolution des variables entre les deux priodes ainsi que les pratiques qui
ont t mises en uvre durant cette deuxime priode mais qui ne ltaient pas durant la
premire.
Sur les 10 facteurs identifis lors de la prcdente priode dadquation, un facteur a t trait.
Malgr la mise en place partielle de certaines pratiques, ce nest pas le cas des autres facteurs.
Egalement, 3 facteurs horizontaux supplmentaires ont t identifis comme avrs durant
cette deuxime priode - facteurs en gras dans le Tableau 28. Sur les 12 facteurs identifis
pour cette priode celui de ltape de pr-implantation tant le mme -, nous proposons den
refuser 10 et den optimiser un seul. Nous naurions toujours rien pu faire, linstar de la
priode dadquation, pour celui associ au BPR. Quatre facteurs sont dtaills ici : celui qui a
t trait, un nouveau et deux qui sont rests avrs entre les deux priodes malgr la mise en
place des pratiques. Le dtail des autres facteurs est donn en annexe L.
Facteur manque dexpertise / dimplication / absence de consultants externes (F5) :
Deux pratiques de gestion ont t mises en place et ont permis de traiter ce facteur :
-
La pratique P22 a t mise en place partiellement car seuls les rles et responsabilits du
consultant externe ont t identifies par crit.
La pratique P29 a t mise en place car un consultant externe a t slectionn.
Facteur manque dexpertise de lintgrateur (F12) :

Ce facteur navait pas t identifi comme avr durant la priode dadquation. Les deux
variables suivantes se sont matrialises durant cette deuxime priode :
-
Manque dexpertise et notamment dexpertise technique. En effet, pour certains nonalignements identifis, lintgrateur na pas su associer de dcision adquate pour
satisfaire le besoin de lentreprise et est donc rest sans rponse. Cela a t le cas, par
exemple, pour lassociation des cots de transport lors de ltablissement de la facture
dun produit command par le client.
Mauvaise gestion de projet : notamment dans la gestion dquipes. En effet, par
exemple, lintgrateur a eu beaucoup de mal expliquer ce dont il avait besoin pour les
catgories articles. Ce point a t expliqu trois reprises dans trois runions diffrentes
sans que les intresss ne comprennent quel tait le travail faire. De plus, certaines
runions ntaient pas suffisamment bien prpares.
134
Cycle de vie
Evolution
pratique entre
les 2 priodes ?
Facteurs
Pratiques
conseilles
Stratgie
F1 : Manque dimplication / dexpertise du

comit de pilotage
Une variable en
plus
P20
P11, P17,
P19
Refus ractif
Mme variable
1 en moins
F5 : Manque dexpertise / dimplication /

absence de consultants externes
Mme variable
/
-Pas dutilisation de mthodes de
gestion de projet
-Pas dutilisation doutils de gestion
de projet
-Pas de respect du planning
- Rpartition inadquate des rles et
responsabilits
Horizontaux
Evolution des
variables ?
Variables avres
-Planning non raliste
Nouveau facteur
F8 : Mauvaise planification temporelle du

projet
F9 : Mauvaise gestion des ressources
F10 : Difficult de travail commun entre
lentreprise et les membres externes
P22
(partiellement)
P22 (partiellement
pour les
consultants
externes), P29
Aucune
P4, P15,
P17, P22,
P24, P25
Refus ractif
P33
Refus ractif
-Mthodologies de travail
diffrentes
Nouveau facteur

-Manque de prsence
-Travail non fait
2 en plus
F11 : Manque dexpertise / dimplication des

utilisateurs cls
Nouveau facteur
Mme variable
-Manque dexpertise
-Mauvaise gestion de projet
-Pas de processus de gestion des
risques
Refus ractif
P11
P18, P19,
P26
P5, P8,
P18, P19,
P22, P25,
P26
P18, P19,
P22, P26
P30
Refus ractif
Optimisation
Refus ractif
135
Cycle de vie
Verticaux,
tape
dadquation
Evolution des
variables ?
Facteurs
Evolution
pratique entre
les 2 priodes ?
Mmes variables
P6 (partiellement)
P14, P15,
P31
Refus ractif
Mmes variable
F20 : Gestion inadquate de ladaptation de

lERP
P12, P15
(partiellement)
P14, P23
Refus ractif
1 en moins
P6 (partiellement)
Variables avres
-Manque de modlisation des
processus souhaits
-Pas de formalisation des
fonctionnalits standards
-Mauvaise gestion des runions
dadquation
-Pas danalyse de la ncessit
dadapter en fonction de lintrt de
lentreprise
-Pas danalyse des cots dadaptation
/
Pratiques
conseilles
Stratgie
Refus ractif
Refus
anticipatif
Tableau 28- Identification et traitement des facteurs pour la priode de retour sur adquation
136
Il aurait sagit de mettre en uvre les pratiques P18 - mettre en place le processus de mise en
confiance des membres de lquipe projet -, P19 - rgulation dquipe -, P22 - rles et
responsabilits par crit - et P26 - organiser des exercices de travail en quipe. Ces pratiques
auraient permis lintgrateur de sinvestir davantage dans lquipe projet et dans les
runions dadquation, davoir conscience de son rle.
Le facteur aurait t optimis car les pratiques P2 et P3 - slection de lintgrateur en fonction
de critres prcis - auraient d tre mises en place ds le dbut du projet. Il aurait t dlicat,
durant la priode tudie, de demander lentreprise de changer dintgrateur. Dans ce
contexte, les pratiques prconises auraient servies baisser la criticit du facteur sans le
refuser.
Facteur gestion inadquate du non-alignement et mauvaise expression des besoins
(F19 et F17b) :
Malgr la mise en place partielle de la pratique P6 commune aux deux facteurs - modliser les
processus souhaits par lentreprise et les fonctionnalits standards de lERP -, ces facteurs
nont pas t traits. Les processus nont pas t rellement modliss avec un formalisme
choisi. Les activits de processus ont plutt t listes dans un tableau sans mettre en vidence
leurs entres et sorties et sans prendre en compte leurs niveaux de granularit. De plus, la
modlisation na concern que les besoins de lentreprise et non les fonctionnalits standards
de lERP. Les mmes variables ont donc t observes pour le facteur li au non alignement et
une variable en moins a t observe pour le facteur li au besoin - concernant le dtail de la
formalisation. En effet, lentreprise a ralis quelle devait dtailler davantage ses besoins
pour ladquation.
Pour les deux facteurs, nous aurions nouveau conseill la pratique P6. Et pour celui li au
non alignement, nous aurions, en plus, conseill les pratiques P14 - membres du projet ayant
du poids sur les dcisions -, P15 - chef de projet comme interlocuteur principal - et P31 prparation des runions dadquation.
2.2.2.2
Identification et traitement des facteurs ayant une chance de se maternaliser
Le facteur haut degr de complexit du progiciel avait, comme pour la priode

dadquation, toutes les chances de se matrialiser par le biais des liens rsiduels. La pratique
prconise - P9 - est la mme que prcdemment.
2.2.2.3
Conclusion de la priode dadquation bis
Pour conclure, la socit X a pris conscience des risques de son projet ERP. Lentreprise a
donc mis en place, de sa propre initiative 8 des 21 pratiques de gestion que fournit la matrice
pratiques / facteurs (cf. Figure 65). La pratique P8 - tablir le plan de formation des
137
utilisateurs cls - avait t conseille par le consultant externe mais na pourtant pas t mise
en place.
13 pratiques conseilles dans la priode
d'adquation mais non mises en place durant la
priode de retour sur adquation
8 pratiques conseilles dans la priode d'adquation
et mises en place durant la priode de retour sur
adquation
8
13
Figure 65- Proportion des pratiques mises en place entre les deux priodes sur celles qui auraient t
conseilles
La mise en place des pratiques P22 (partiellement) et P29 correspondant dterminer par
crit ds le dbut du projet les rles et responsabilits du consultant externe et slectionner les
consultants externes en fonction des critres dexprience et de comptences - a permis de
traiter le facteur manque dexpertise / dimplication / absence de consultants externes .
Cela na cependant pas t suffisant pour traiter les autres facteurs. Les trois facteurs
difficult de travail commun entre lentreprise et les membres externes , manque
dexpertise de lintgrateur , et mauvaise planification temporelle du projet se sont
matrialises entre les deux priodes.
Ainsi, le nombre de pratiques conseilles est pass de 21 19 sachant que les pratiques P2 et
P3, relatives la slection de lintgrateur et permettant de traiter le facteur manque
dexpertise de lintgrateur , nont pas pu tre conseilles.
De plus, les pratiques permettant de traiter plusieurs facteurs la fois, a, en moyenne,
augment (cf. Figure 66). Alors que dune part, les pratiques P14, P17 et P25 ont stagn, et
que dautre part, la pratique P22 nest conseille que 3 fois au lieu de 4 et P15, 2 fois au lieu
de 3, nous observons que les pratiques P18 et P26 ont tripl et que la pratique P19 a
doubl .
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
nbre de fois, adquation

nbre de fois, retour sur
adquation
P22
P19
P18
P26
P15
P14
P17
P25
P6
Figure 66- Evolution des pratiques les plus conseilles entre les deux priodes
138
Nous pouvons conclure, de par cette augmentation du nombre de facteurs influenant le RNA,
que loccurrence de celui-ci a volu.
2.3
Conclusion de lapplication
Lapplication a posteriori de lapproche Risk-Factor Driven - ERP Alignment au projet

ERP de la socit X a permis de mettre en avant son utilit. Notre partenaire industriel aurait
pu en bnficier. Sa prise de conscience entre les deux priodes na pas t suffisante.
Pour les deux priodes analyses, nous avons identifi un grand nombre de facteurs de risque
influenant le RNA qui auraient pu tre identifies : 10 pour la priode dadquation et 12
pour la priode de retour sur adquation. Les variables dfinissant chaque facteur se sont
avres trs utiles pour cette identification. Cela a permis davoir un portrait-robot des
facteurs de risque qui se sont matrialiss au cours du projet et donc destimer lexistence du
RNA.
De plus, par lapplication des pratiques de gestion que nous avons associes pour traiter les
facteurs, la socit X aurait pu traiter en partie le RNA en agissant sur son occurrence.
139
140
Chapitre 7 Conclusions et perspectives
Chapitre 7
Conclusions et perspectives
Dans cette thse, nous avons adopt une dmarche de recherche / action pour rpondre la
problmatique de traitement du Risque de Non-Alignement (RNA) dans les projets ERP. Le
RNA est la probabilit que les processus mis sous contrle de lERP ne soient pas aligns aux
besoins rels de lentreprise vis--vis de ses processus, associe la perte du non-alignement
sil a lieu. Un tat de lart des travaux concernant le management du risque dans les projets,
nous a amen dfinir deux stratgies doptimisation anticipatives complmentaires : lune
agissant sur leffet et lautre sur loccurrence du RNA.
Un moyen pour mettre en uvre la stratgie doptimisation anticipative agissant sur leffet du
RNA est lapplication des mthodes dingnierie dirige par les modles. Nous avons analys
sept mthodes dans leur capacit identifier le rsultat indsirable - le non-alignement - et
lvaluer afin de prendre des dcisions adquates pour y pallier. Ces mthodes se focalisent
principalement sur les outils ncessaires la construction des modles : formalismes et
mesures de similarit ; cependant leur processus dalignement reste macroscopique ;
notamment ils ne prennent pas ou peu en compte les interdpendances de processus ou les
niveaux de granularit.
Nous avons propos une mthode dingnierie dirige par les modles Model Driven - ERP
Alignment qui vise combler les manques identifis au cours de notre analyse. Elle consiste
en lapplication dun processus dalignement, support par des outils et qui met en jeu quatre
modles : les modles AS-IS, AS-WISHED, MIGHT-BE et TO-BE. Loriginalit de cette
mthode rside construire, confronter et prendre des dcisions en considrant
successivement les trois vues de modlisation intentionnelle, fonctionnelle et
informationnelle, issues de la norme (ISO/DIS 19440 2004) et des travaux sur lingnierie des
besoins. Tout en prconisant le niveau de granularit le plus lev pour les processus, nous
proposons des rgles de dsagrgation des activits. Lvaluation du non-alignement se fait
sur la base des critres de cot, dintrt, dintgrit de lintgration et de la cohrence du
modle TO-BE construit. Ce dernier critre se base sur lexploitation des interdpendances
des processus dun domaine donn. Enfin, nous associons les dcisions proposes dans la
littrature aux situations dalignement et de non-alignement identifies. Nous ajoutons
nouvelle dcision complment la conduite du changement qui doit tre prise
conjointement aux autres dcisions lorsque le modle TO-BE nest pas construit limage du
modle AS-WISHED. Cette dcision met laccent sur le fait que la mise en place dun
nouveau S.I. impacte le mode de fonctionnement de tous les membres de lentreprise.
141
Un moyen pour agir de manire anticipative sur loccurrence du RNA est le management des
facteurs de risque qui lui sont associs. Nous avons analys 107 contributions scientifiques
sur le management des facteurs de risque (FR) dans les projets ERP dans leur capacit
constituer un moyen pour mettre en uvre cette stratgie. Il en ressort que les approches de
management des FR sont peu outilles et sattachent essentiellement ltape dvaluation.
Elles ne prennent que peu en compte les caractrisations existantes des facteurs de risque,
notamment les classifications et les influences.
Nous avons propos lapproche Risk-Factor Driven - ERP Alignment , pour identifier et
traiter les facteurs de risque influenant le RNA. Ce sont les facteurs de ltape dadquation
du cycle de vie du projet ERP et ceux dont le traitement a pour rsidu ces facteurs.
Lidentification sappuie sur trois outils : (i) le classement des FR influenant le RNA selon
les tapes du projet ERP, (ii) la matrice des liens rsiduels influenant le RNA et (iii) une liste
de variables permettant de dfinir si un FR donn sest matrialis durant le projet. Le
traitement sappuie sur une matrice FR / pratiques de gestion, dans laquelle 37 pratiques sont
recenses. Enfin, nous proposons une mise en uvre de la dmarche didentification /
traitement qui amne traiter les facteurs selon trois stratgies possibles : refus anticipatif,
refus ractif et optimisation.
La mthode Model Driven - ERP Alignment a t applique a posteriori au module SAV
de la socit X. Lapproche Risk-Factor Driven - ERP Alignment a t applique a
posteriori deux priodes diffrentes du projet ERP de la socit X. Cela nous a permis de
valider nos propositions scientifiques.
La premire application a permis lentreprise X de raliser les dcisions prises
inconsciemment face aux situations dalignement et de non-alignement et den mesurant les
effets. La deuxime application a mis en lumire labsence de management des facteurs de
risques par lentreprise ce qui la conduit devoir renouveler lanalyse de ladquation durant
ltape de tests, du fait de laugmentation du nombre de facteurs de risque matrialiss.
Le travail ralis dans le cadre de cette thse ouvre la voie de nombreuses perspectives de
recherche :
Concernant la mthode Model Driven - ERP Alignment :
-
Le choix des processus construire et confronter pourrait tre affin. Bien que nous
prconisions de commencer par ceux qui gnrent des interdpendances et ceux associs
aux buts non satisfaits, il serait intressant de ne modliser finement que les processus
critiques - source de non-alignement. Pour ce faire, un autre critre serait, par exemple, la
maturit des processus, abords notamment dans les travaux tels que (Lee et al. 2007;
Rohloff 2009).
La construction du modle MIGHT-BE pourrait tre diffrencie selon le type dERP
considr : open-source ou propritaire. En effet, le code source des premiers est libre
142
alors que les seconds limitent fortement son accs. Les obstacles sont donc diffrents.
Pour les ERP Open source , il semble possible de modliser les processus au niveau de
granularit le plus fin alors que pour les seconds, il sagit de faire confiance la
connaissance et lexprience de lintgrateur.
La mesure des trois critres de cots, intrt et intgrit de lintgration pourraient tre
affine en y associant des mesures telles que celles prconises dans le graphe
dintgration de (Millet 2008).
Le guidage de lordre des domaines confronts pourrait tre affin, notamment par la prise
en compte des liens entre ces domaines, ou des interdpendances de processus de deux
domaines diffrents.
Un atelier dalignement pourrait supporter la mthode afin de guider chaque tape du
processus dalignement propos et permettre une traabilit des dcisions prises. Nous
pourrions imaginer une tape darbitrage des dcisions une fois lensemble des domaines
traits.
Pour lapproche Risk-Factor Driven - ERP Alignment :

-
Les pratiques de gestion pourraient tre analyses travers des enqutes afin de constituer
un rfrentiel de bonnes pratiques, limage du modle SCOR7 pour la gestion des
chanes logistiques.
Ltape dvaluation des risques pourrait tre davantage exploite afin dvaluer
prcisment la criticit des facteurs de risque et les prioriser tel que le font (Aloini et al.
2012a) qui prennent dailleurs en compte les interdpendances entre processus dans le
mode dvaluation.
Enfin, une fois le RNA trait, lalignement doit tre maintenu aprs le projet. Il sagirait de
sorienter vers une logique dalignement dynamique et continu prenant en compte lvolution
de lentreprise et de ses processus ainsi que celles de lERP - lors de montes de versions par
exemple. Pour ce faire, des techniques de co-volution de modles telles que celles dcrites
dans (Etien 2007) pourraient tre mises en uvre.
http://supply-chain.org/.
143
144
Rfrences bibliographiques
Rfrences Bibliographiques
19439, I. 2006. Enterprise integration Framework for enterprise modelling
Abi Azar, J. 2005. Les outils de contrle de gestion dans le contexte des PME : cas des PME au Liban.
In 26me congrs de l'AFC.
AFITEP/ AFNOR. 1996. Dictionnaire de management de projet.
AFNOR FD X50 - 117. 2003. Management des risques.
Akkermans, H., and K. van Helden. 2002a. Vicious and virtuous cycles in ERP implementation: a case
study of interrelations between critical success factors. European Journal of Information
Systems 11 (1):35-46.
Akkermans, H., and K. Van Helden. 2002b. Vicious and virtuous cycles in ERP implementation: a case
study or interrelations between critical success factors. european Journal of Information
Systems 11:35-46.
Al-Mashari, M., A. Al-Mudimigh, and M. Zairi. 2003. Enterprise resource planning: a taxonomy of
critical factors. European Journal of Operation Research 146 (2):352-364.
Allen, D., T. Kern, and M. Havenhand. 2002. ERP Critical Success Factors: an exploration of the
contextual factors in public sector institutions. Paper read at 35th Hawaii International
Conference on System Sciences, at Hawaii.
Aloini, D., R. Dulmin, and V. Mininno. 2007. Risk management in ERP project introduction: Review of
the literature. Information & Management 44 (6):547-567.
. 2012a. Modelling and assessing ERP project risks: A Petri Net approach. European Journal of
Operational Research 220 (2):484-495.
. 2012b. Risk assessment in ERP projects. Information Systems 37 (3):183-199.
Amid, A., M. Moalagh, and A. Z. Ravasan. 2012. Identification and classification of ERP critical failure
factors in Iranian industries. Information Systems 37 (3):227-237.
Amoako-Guyampah, K. 2004. ERP implementation factors: A comparison of managerial and end-user
perspectives. Business Process Management Journal 10 (2):171-183.
Anton, A. I. 1996. Goal Based Requirements Analysis. Paper read at 2nd ICRE96, International
Conference on Requirements Engineering.
Antn , A. I., and C. Potts. 1998. The use of goals to surface requirements for evolving systems. In
ICSE98- International Conference on Software Engineering Kyoto, Japan, 157-166.
Attie, P. C., M. P. Singh, A. Sheth, and M. Rusinkiewicz. 1993. Specifying and Enforcing Intertask
Dependencies Paper read at 19th VLDB, International Conference of Very Large Data Bases,
at Dublian, Ireland.
Audibert, L. 2009. UML 2 : De l'apprentissage la pratique. Ellipses ed.
Avila Cifuentes, O. J. 2009. Contribution lAlignement Complet des Systmes dInformation
Techniques, LGeCo - Laboratoire du Gnie et de la Conception, INSA Strasbourg, Strasbourg,
france.
Baccarini, D., G. Salm, and L. P.E.D. 2004. Management of risks in information technology projects.
Industrial Management and Data Systems 104 (4):286-295.
145
Basoglu, N., T. Daim, and O. Kerimoglu. 2007. Organizational adoption of enterprise resource
planning systems: A conceptual framework. ournal of High Technology Management
Research 18:7397.
Baumann-Chardine, E. 2011. Modles dvaluation des performances conomique,
environnementale et sociale dans les chanes logistiques DISP - Dcision et Informatique
pour les Systmes de Production, INSA Lyon, Lyon, France.
Bernard, J.-G., B. Aubert, S. Bourdeau, E. Clment, C. Debuissy, M.-J. Dumoulin, M. Laberge, N. De
Marcellis, and I. Peignier. 2002a. Le risque: un modle conceptuel d'intgration: CIRANO:
centre interuniversitaire de recherche en analyse des organisations.
Bernard, J.-G., S. Rivard, and B. Aubert. 2002b. Evaluation du risque d'implantation de progiciel:
CIRANO: centre interuniversitaire de recherche en analyse des organisations.
Bitton, M. 1990. Performance measure system implementation and design for industrial
organisations (in French), University of Bordeaux 1, Bordeaux, France.
Blackwell, P., E. M. Shehab, and J. M. Kay. 2006. An Effective Decision-Support Framework for
Implementing Enterprise Information Systems within SMEs. International Journal of
Production Research 44 (17).
Boehm, B. W. 1991. Software Risk Management: Principles and Practices. IEEE Software 8 (1):32-41.
Botta-Genoulaz, V., and P.-A. Millet. 2005. A classification for better use of ERP systems. Computers
in Industry 56 (6):572586.
. 2009. The SCOR model for the alignment of business processes and information systems.
Enterprise Information Systems 3 (4):393-407.
Botta-Genoulaz, V., P.-A. Millet, and G. Neubert. 2001. The role of Enterprise Modeling in ERP
Implementation. International Conference on Industrial Engineering and Production
Management. Paper read at IEPM01 : International Conference on Industrial Engineering
and Production Management, at Quebec, Canada.
Botta-Genoulaz, V., and P. A. Millet. 2006. An investigation into the use of ERP systems in the service
sector. International journal of production economic 99 (1-2):202-221.
Botta-Genoulaz, V., P. A. Millet, and B. Grabot. 2005. A survey on the recent research literature on
ERP systems. Computers in Industry 56 (6):510-522.
Bourdeau, S., S. Rivard, and H. Barki. 2003. Evaluation du risque en gestion de projet.
Bradford, M., and F. Florin. 2003. Examining the role of innovation diffusion factors on the
implementation success of the enterprise resource planning systems. International Journal of
Accounting Information Systems 4 (3):205-225.
Bradley, J. 2008. Management based critical success factors in the implementation of Enterprise
Resource Planning systems. International Journal of Accounting Information Systems 9:175200.
Brehm, L., A. Heinzl, and M. L. Markus. 2001. Tailoring ERP systems: a spectrum of choices and their
implications. Paper read at HICSS'34 - 34th Annual Hawaii International Conferenceon
System Sciences, at Hawaii.
Bronet, V. 2006. Amlioration de la performance industrielle partir dun processus rfrent Dploiement inter entreprises de bonnes pratiques, Gnie Industriel, Annecy Le Vieux:
Universit de Savoie, Annecy.
Bueno, S., and J. L. Salmeron. 2008. TAM-based success modeling in ERP. Interacting with Computers
20:515-523.
Buonanno, G., P. Faverio, F. Pigni, A. Ravarini, D. Sciuto, and M. Tagliavini. 2005. Factors affecting ERP
system adoption : A comparative analysis between SMEs and large companies. Journal of
Enterprise Information Management 18 (4):384-426.
Business Rules Group. 2010. The Business Motivation Model.
146
Capaldo, G., L. Iandoli, P. Rippa, S. Mercanti, G. Troccoli, and E. Int Assoc. 2008. An AHP Approach to
Evaluate Factors Affecting ERP Implementation Success.
Carter, B. M., J. Y.-C. Lin, and M. E. Orlowska. 2003. Customizing Internal Activity Behaviour for
Flexible Process Enforcement. Paper read at 5th ADC, Australasian Database Conference, at
Dunedin, New Zealand.
CEN ENV 40003. 1991. Computer Integrated Manufacturing - Systems Architecture - Framework for
Enterprise Modelling.
Chanal, V. 2000. Communauts de pratique et management par projet : A propos de l'ouvrage de
Wenger (1998) Communities of Practice: Learning, Meaning and Identity. M@n@gement 3
(1):1-30.
Chang, T. H., S. C. Hsu, T. C. Wang, and C. Y. Wu. 2012. Measuring the success possibility of
implementing ERP by utilizing the Incomplete Linguistic Preference Relations. Applied Soft
Computing 12 (5):1582-1591.
Chapman, C. 1997. Project risk analysis and management-- PRAM the generic process International
Journal of Project Management 15 (5):273-281.
Chapron, J. 2006. Organisational urbanism: method and decision support to manage enterprise
information systems evolution (in french), Industrial Engineering, National Superior School of
Mines of Jean Monnet University, Saint-Etienne, FRANCE.
Chen, C. C., C. C. H. Law, and S. Yang. 2009a. Managing ERP Implementation Failure: A Project
Management Perspective. IEEE transactions on engineering management 56 (1):157-170.
Chen, G. H., C. Q. Li, and Y. X. Sai. 2006. Critical success factors for ERP life cycle implementation. In
Research and Practical Issues of Enterprise Information Systems, edited by A. M. Tjoa, L. Xu
and S. S. Chaudhry, 553-562.
Chen, G. H., Y. X. Sai, and J. Zhang. 2009b. ERP Implementation Based on Risk Management Theory:
Empirical Validation In MASS '09: International Conference on Management and Service
Science, 1- 4
Chen, H. M., and F. Ming. 2008. The Research On Critical Success Factors of ERP Implementation.
Edited by H. Zhang, R. M. Zhao and Q. Zeng.
Chou, S.-W., and Y.-C. Chang. 2008. The implementation factors that inuence the ERP (enterprise
resource planning) benets. Decision Support Systems 46:149157.
Ciborra,
C.
1997.
De
profundis?
Deconstructing the concept of strategic alignment.
Journal of Information Systems 9 (1):67-82.
CIGREF. 2011. Pratiques et discours des grandes entreprises sur la valeur et la performance des SI.
Courtot, H. 1998. La gestion des risques dans les projets. Economica ed.
Dardenne, A., A. Van Lamsweerde, and S. Fickas. 1993. Goal-Directed Requirements Acquisition.
Science of Computer Programming 20:3-50.
Darras, F. 2004. Propodition of a framework for the design and the operation of an ERP system (in
french). Speciality Industrial Engineering, INP Toulouse, France.
Davenport, T. H. 1998. Putting the enterprise into the enterprise system. Harvard Business review 76
(4):121-131.
Davis, R., and M. Olson. 1974. Management Information Systems.
Deakins, J. T. 2004. ERP in practice: Implementation success factors in the paint and coatings
industry. Jct Coatingstech 1 (10):98-101.
Deixonne, J.-L. 2001. Piloter un projet ERP: tranformer et dynamiser l'entreprise par un systme
d'information intgr orient mtier. Dunod ed. Paris.
147
Deng, J., and Y. Bian. 2008. Constructing a Risk Management Mechanism Model of ERP Project
Implementation. Paper read at 2008 IEEE International Conference on Information
Management, Innovation Management and Industrial Engineering, at China.
Dezdar, S., and S. Ainin. 2011. The influence of organizational factors on successful ERP
implementation. Management Decision 49 (6):911-926.
Dowlatshahi, S. 2005. Strategic success factors in enterprise resource-planning design and
implementation: a case-study approach. International Journal of Production Research 43
(18):3745-3771.
Ehie, I. C., and M. Madsen. 2005. Identifying critical issues in enterprise resource planning (ERP)
implementation. Computers in Industry 56.
Engelsman, W., C. Quartel, H. Jonkers, and M. Van Sinderen. 2010. Extending enterprise architecture
modelling with business goals and requirements. Enterprise Information Systems 5 (1):9-36.
Esteves, P. 1999. An ERP life-cycle-based research agenda. In The First International Workshop in
Enterprise Management and Resource Planning: Methods, Tools and Architectures. Italy.
Etien, A. 2007. ACEM Method for the enterprise processes - information system alignment (in
french), Speciality Computer Science, Panthon-Sorbonne, Paris, France.
Ewusi-Mensah, K. 1997. Critical issues in abandoned information systems development projects.
Communications of the ACM 40 (9):74-80.
Finney, S., and M. Corbett. 2007. ERP implementation: a compilation and analysis of critical success
factors. Business Process Management Journal 13 (3):329-347.
Ghosh, S. 2003. Global implementation of ERP software - Critical success factors on upgrading
technical infrastructure.
Glass, R. L. 1998. Enterprise resource planning Breakthrough and/or term problems? Database for
Advances Information Systems 29 (2):14-16.
Gmati, I. 2011. Proposition d'une mthode pour l'ingnierie d'alignement mtier : diagnostic,
volution, alternatives technologiques et dcision : La mthode DEEVA (DEsign and EVolution
of Alignment), CRI- Centre de recherche Informatique, Universit Panthon-Sorbonne, Paris,
France.
Goepp, V. 2003. Contribution la dfinition de proc"essus contingents en dveloppement de
systmes d'information: Proposition d'une dmarche oriente identification des problmescls, Gnie des Systmes Industriels, Institut National Polytechnique de Lorraine, Nancy,
France.
Gourc, D. 2006. Vers un modle gnral du risque pour le pilotage et la conduite des activits de
biens et de services, Propositions pour une conduite des projets et une gestion des risques
intgres Centre Gnie Indutriel, Ecole des mines, Albi-Carmaux, France.
Grabski, S. V., and S. A. Leech. 2007. Complementary controls and ERP implementation success.
International Journal of Accounting Information Systems 8.
Hakim, A., and H. Hakim. 2010. A practical model on controlling the ERP implementation risks
Information Systems 35 (3):204-214.
Halilem, N., and E. St-Jean. 2007. L'innovation au sein des PME : Proposition d'un cadre conceptuel
Paper read at 5me Congrs International de l'Acadmie de l'Entreprise, at Sherbrooke,
Canada.
Haumer, P., K. Pohl, and K. Weidenhaupt. 1998. Requirements elicitation and validation with real
world scenes. IEEE Transactions on Software Engineering, Special Issue on Scenario
Management 24 (12):11036-11054.
Henderson, J. C., and N. Venkatraman. 1993. Strategic alignment: leveraging information technology
for transforming organizations. IBM Systems Journal 32 (1):4-17.
148
Ho, L. T., G. Lin, and S. Nagalingam. 2009. A risk mitigation framework for integrated-enterprise
systems implementation for the manufacturing environment. International Journal of
Business Information Systems 4 (3):290-310.
Holland, C. P., and B. Light. 1999. A critical success factors model for ERP Implementation. Software
IEE 16 (3):30-36.
Holsapple, C. W., Y. M. Wang, and J. H. Wu. 2005. Empirically testing user characteristics and fitness
factors in enterprise resource planning success. International Journal of Human-Computer
Interaction 19 (3):323-342.
Hong, K. K., and Y.-G. Kim. 2002a. The critical success factors for ERP implementation: an
organizational t perspective. Information & Management 40.
Hong, K. K., and Y. G. Kim. 2002b. The critical success factors for ERP implementation: an
organizational fit perspective. Information & Management 40 (1):25-40.
Hua, J. 2009. Fuzzy Evaluation on ERP System Implementing Risk Based on Membership Degree
Transformation New Algorithm. Paper read at IEEE Second International Symposium on
Electronic Commerce and Security, at Nanchang, China
Huang, S.-M., I.-C. Chang, S.-H. Li, and M.-T. Lin. 2004. Assessing risk in ERP projects: identify and
prioritize the factors. Industrial Management and Data Systems 104 (8):681-688.
IDC. 2012. ERP and business software: A mature market that develop news growths (in french).
Ifinedo, P. 2008. Measuring enterprise resource planning (ERP) systems success: A structural
equation modeling approach. In Enterprise Information Systems-Book, edited by Y.
Manolopoulos, J. Filipe, P. Constantopoulos and J. Cordeiro, 86-97.
. 2011. Examining the influences of external expertise and in-house computer/IT knowledge
on ERP system success. Journal of Systems and Software 84 (12):2065-2078.
Iskanius, P. 2009. Risk Management in ERP Project in the Context of SMEs. Engineering Letters 17.
ISO 19439. 2006. Enterprise integration Framework for enterprise modelling
ISO/DIS 19440. 2004. Enterprise integration - Constructs for enteprise modelling.
ISO/IEC Guide 73:2002 (E/F). 2002. Risk Management Vocabulary- Guidelines for use in standards.
Jarrar, Y. F., A. Al-Mudimigh, and M. Zairi. 2000a. ERP implementation critical success factors the
role and impact of business process management. In: Management of Innovation and
Technology. In ICMIT'00 - International Conference on Management of Innovation and
Technology, 122-127.
. 2010. ERP implementation critical success factors the role and impact of business process
management. In: Management of Innovation and Technology. In ICMIT'00 - International
Conference on Management of Innovation and Technology, 122-127.
Jarrar, Y. F., A. Al-Mudimigh, M. Zairi, and Ieee. 2000b. ERP implementation critcal success factors the
role and impact of business process management.
Jian, G., J. Chuang-liang, and L. Ai-hua. 2010. An Approach for Project Risk Evaluation Based on
Linguistic Assessment Information. In ICIME 2010 : The 2nd IEEE International Conference on
Information Management and Engineering 618 - 623
Jiang, J. J., and K. G. 1999. Risks to different aspects of system success. Information & Management
36 (5):263-272.
Jing, R. Z., X. Qiu, and Ieee. 2007. A study on critical success factors in ERP systems implementation.
Jouffroy, P. 2010. ERP, mthode pratique de mise en oeuvre pour PME et PMI. Eyrolles ed. Paris.
Kaindl, H. 2000. design process based on a model combining scenarios with goals and functions. IEEE
Trans. on Systems, Man and Cybernetic 30 (5):537-551.
Kajko-Mattsson, M., and J. Nyfjord. 2008. State of Software Risk Management Practice. International
Journal of Computer Science 35 (4):451-462.
149
Kamhawi, E. M., and A. Gunasekaran. 1999. ERP systems implementation success factors: IS and
non-IS manager. International Journal of Business Information Systems 4 (6):688704.
Kavakli, E., and P. Loucopoulos. 2003. Goal Driven Requirements Engineering: Evaluation of Current
Methods In EMMSAD Velden, Austria.
Kimmis, S., and R. McTaggart. 1988. The Action Research Planner (3me dition rvise). Deakin
University Press ed. Victoria, Autralia.
King, S. F., and T. F. Burgess. 2006. Beyond critical success factors: A dynamic model of enterprise
system innovation. International Journal of Information Managemen 26:59-69.
King, W. R. 2005. Ensuring ERP implementation success. Information Systems Management 22 (3):8384.
Knoll,
K.,
and
S.
L.
Jarvenpaa.
1994.
Information technology alignment or fit in highly turbulent environments: the concept of fl
exibility. Paper read at Computer personnel research conference on Reinventing IS, at
Alexandria, Virginia, United States.
Kop, Y., H. Z. Ulukan, and T. Gurbuz. 2011. Evaluating the Failure Risk Level of an Enterprise Resource
Planning Project Using Analytic Network Process in Fuzzy Environment. Journal of MultipleValued Logic and Soft Computing 17 (4):407-423.
Kosanke, K., Vernadat F., and M. Zelm. 1999. CIMOSA: enterprise engineering and integration.
Computers in Industry 40 (2-3):8397.
Kumar, V., B. Maheshwari, and U. Kumar. 2003. An investigation of critical management issues in ERP
implementation: emperical evidence from Canadian organizations Technovation 23 (10):793807
Lapiedra, R., J. Alegre, and R. Chiva. 2011. The importance of management innovation and consultant
services on ERP implementation success. Service Industries Journal 31 (12):1907-1919.
Larousse. 1981. Le Dictionnaire de l'informatique, 242.
Lavoie, L., D. Marquis, and P. Laurin. 1996. La recherche-action :Thotie et Pratique. Presses de
l'Universit du Qubec ed.
Law, C. C. H., C. C. Chen, and B. J. P. Wu. 2010. Managing the full ERP life-cycle: Considerations of
maintenance and support requirements and IT governance practices as integral elements of
the formula for successful ERP adoption. Computers in Industry 61 (3):297-308.
Law, C. C. H., and E. W. T. Ngai. 2007. ERP systems adoption: An exploratory study of the
organizational factors and impacts of ERP success. Information & Management 44:418432.
Le Moigne, J. L. 1990. La modlisation des systmes complexes. Dunod ed. Paris, France.
Lee, J., D. Lee, and S. Kang. 2007. An Overview of the Business Process Maturity Model (BPMM) In
Advances in Web and Network Technologies, and Information Management edited by K. C.
Chang, W. Wang, L. Chen, C. A. Ellis, C. H. Hsu, A. C. Tsoi and H. Wang. Berlin, 384395.
Legoherel, P., P. Callot, K. Gallopel, and M. Peters. 2003. Dimensions psychologiques, processus de
prise de dcision et attitude envers le risque : Une tude des dirigeants de petites et
moyennes entreprises. La Revue des Sciences de Gestion, Direction et Gestion (199):51 - 72.
Leite, J. C. S., G. Rossi, F. Balaguer, A. Maiorana, G. Kaplan, G. Hadad, and A. Oliveros. 1997.
Enhancing a requirements baseline with scenarios. In 3rd IEEE International Symposium On
Requirements Engineering. Antapolis, Maryland, 44-53.
Leopoulos, V., K. Kirytopoulos, and D. Voulgaridou. 2005. ERP systems as a component of the
electronic supply chain: Classification of implementation risks. International Conference on
Computational Intelligence for Modelling, Control and Automation, 2005 and International
Conference on Intelligent Agents, Web Technologies and Internet Commerce 676 - 682
. 2006. A model for risk identification in ERP system processes. In Risk Analysis V: Simulation
and Hazard Mitigation, edited by C. A. Brebbia and V. Popov, 143-152.
150
Lequeux, J.-L. 1999. Manager avec les ERP, Progiciels de Gestion Intgr et Internet. Eidtions
d'Organisation ed. Paris.
Li, W., X. Zhou, P. Zeng, and S. Du. 2006. Analyzing the risk of ERP project: a case study of XJ group.
Edited by X. Y. Wang and J. Shen.
Light, B. 2005. Going beyond 'misfit' as a reason for ERP package customisation. Computers in
Industry 56.
Luftman, J. 2000. Assessing businessIT alignment
the Association for Information Systems 4 (14):1-50.
maturity.
Communications
of
Malhotra, R., and C. Temponi. 2010. Critical decisions for ERP integration: Small business issues.
International Journal of Information Managemen 30 (1).
Malone, T. W., and K. Crowston. 1993. The interdisciplinary study of coordination.
Mason, R. O., and I. Mitroff. 1973. A program for research on management information systems.
Management Science 19 (8):475-487.
Matuleviius, R., and P. Heymans. 2007. Visually Effective Goal Models Using KAOS In ER Workshop,
edited by J.-L. H. e. al., 265275.
MDNFC. Ministre de la dfense nationale et des forces canadiennes - dfinitions pour la gestion des
risques 2002 [cited. Available from http ://www. vcds.forces.gc. ca/dgsp/00Native/dp_
m/risk-man/risk-def_f.pdf.
Millet, P.-A. 2008. Study of the informational and organisational integration, application to ERP
systems (in french), DISP - Dcision et Informatique pour les Systmes de Production, INSA
Lyon, France.
Millet, P.-A., and V. Botta-Genoulaz. 2006. Un rfrentiel pour lalignement des systmes
dinformation aux processus logistiques. In MOSIM'06, 6me Confrence Francophone de
MOdlisation et SIMulation. Rabat, Maroc.
. 2008. Process alignment maturity in changing organisation. In ERP Systems and
Organisational Change A Socio-technical Insigh, edited by B. Grabot, Mayre, A. and Bazet.
London, .157180.
Morley, C. 2001. Gestion d'un projet systme d'information. Principes, techniques, mise en oeuvre et
outils. Dunod ed.
Morley, C., J. Hugues, and B. Leblanc. 2006. UML2 pour l'analyse d'un systme d'information, le
cahier des charges du matre d'ouvrage. Dunod, 3me dition ed. Paris, France.
Morton, N. A., and Q. Hu. 2008. Implications of the t between organizational structure and ERP: A
structural contingency theory perspective. International Journal of Information Management
28:391402.
Motwani, J., R. Subramanian , and P. Gopalakrishna 2005. Critical factors for successful ERP
implementation: Exploratory ndings from four case studies. Computers in Industry 56.
Mylopoulos, J., L. Chung, and E. Yu. 1999. From Object-Oriented to Goal-Oriented, Requirements
Analysis Communications of the ACM 42 (1).
Nah, F. F. H., and S. Delgado. 2006. Critical success factors for enterprise resource planning
implementation and upgrade. Journal of Computer Information Systems 46:99-113.
Nah, F. F. H., Z. Islam, and M. Tan. 2007. Empirical assessment of factors influencing success of
enterprise resource planning implementations. Journal of Database Management 18 (4):2650.
Nah, F. F. H., K. M. Zuckweiler, and J. L. S. Lau. 2003. ERP implementation: Chief Information Officers'
perceptions of critical success factors. International Journal of Human-Computer Interaction
16 (1):5-22.
Ojala, M., I. Vilpola, and I. Kouri. 2006. Risk in ERP Project - Case Study of IS/ICT Management
Capability Maturity Level and Risk Assessment. Paper read at Frontiers of e-Business
151
Research, Maula, M., Hannula, M., SeppfM., Tommila, J. ed, at Tampere University of
Technology (TUT) and University of Tampere (UTA).
Olson, D. L., and F. Zhao. 2007a. CIOs' perspectives of critical success factors in ERP upgrade projects.
. 2007b. CIOs perspectives of critical success factors in ERP upgrade projects. Enterprise
Information Systems 1 (1):129-138.
Panorama Consulting Group. 2012a. 2012 ERP report.
Panorama consulting group. 2012b. Lessons Learned From a Government ERP failure.
Peng, G. C., and M. B. Nunes. 2009. Surfacing ERP exploitation risks through a risk ontology. Industrial
Management & Data Systems 109 (7):926-942.
Peng , Q. 2009. Issues in Specifying Requirements for Adaptive Software Systems Vxj, Sude: Vxj
University
Perrin, A. 2006. Le transfert intra organisationnel des bonnes pratiques : quand lentreprise
joue au domino. . In AIMS XVme Confrence Internationale de Management
Stratgique. Annecy/ Genve.
Plant, R., and L. Willcocks. 2007. Critical success factors in international ERP implementations: A case
research approach. Journal of Computer Information Systems 47 (3):60-70.
Potts, C. 1997. Fitness for Use: The System Quality that Matters Most. Paper read at REFSQ'97Requirements Engineering: Foundation for Software Quality, at Barcelona, Spain.
Prakash, N., and C. Rolland. 2001. Matching ERP System Functionality to Customer Requirements.
Paper read at the 5th IEEE International Symposium on Requirements Engineering, at
Toronto, Canada.
Quellenec, C. 2007. ERP Levier de Transformation de lEntreprise. Paris: Hermes.
Ramayah, T., M. H. Roy, S. Arokiasamy, I. Zbib, and A. Z.U. 2007. International Journal of Business
Information Systems. Critical success factors for successful implementation of enterprise
reource planning systems in manufacturing organization 2 (3):276297.
Ravalison, R. B. 2006. Mise en scne des projets de systme dinformation : apports de la matrise
des risques dans les projets de systme dinformation. Speciality Industrial Engineering, INP
Toulouse, France.
Raymond, L., F. Bergeron, L. Gingras, and S. Rivard. 1990. Problematic of the computerization of the
PME (in french). Technologies de l'Information et Socit 3 (1):57-70.
Reix, R., F. Bernard, M. Kalika, and R. Frantz. 2011. Systme d'information et management des
organisations. Magnard-Vuibert ed. Paris.
Respect-IT.
A
KAOS
Tutorial
2007
[cited.
Available
http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf.
from
Rohloff, M. 2009. Case Study and Maturity Model for Business Process Management Implementation
In Business Process Management, edited by K. C. Chang, W. Wang, L. Chen, C. A. Ellis, C. H.
Hsu, A. C. Tsoi and H. Wang. Berlin, 128.
Rolland, C., and C. Salinesi. 2005. Modeling Goals and Reasoning with Them. In Engineering and
Managing Requirements, edited by A. Aurum and C. Wohlin: Springer Verlag, 189-217.
Rothenberger, M. A., M. Srite, and K. Jones-Graham. 2010. The impact of project team attributes on
ERP system implementations A positivist field investigation. Information Technology & People
23 (1):80-109.
Sakka, O. 2012. Alignement smantique entre rfrentiels d'entreprise - Application aux systmes
d'xution de la fabrication (MES), DISP - Dcision et Information pour les Systmes de
Production, INSA Lyon, Lyon, France.
152
Sammon, D., and F. Adam. 2008. Building a Common Understanding of Critical Success Factors for an
ERP Project Implementation. In Collaborative Decision Making: Perspectives and Challenges,
edited by P. Zarate, J. P. Belaud, G. Camilleri and F. Ravat, 308-318.
Santamaria-Sanchez, L., M. Nunez-Nickel, and S. Gago-Rodrguez. 2010. The role played by
interdependences in ERP implementations: An empirical analysis of critical factors that
minimize elapsed time. Information & Management 47:8795.
SAP AG. 1999. AcceleratedSAP.
Scott, J. E., and L. Kaindl. 2000. Enhancing functionality in an enterprise software package.
Information & Management 37 (3).
Shanks, G., A. Parr, B. Hu, T. Thanasankit, and P. Seddon. 2000. Differences in Critical Success Factors
in ERP Systems Implementation in Australia and China: A Cultural Analysis
Sheu, C., B. Chae, and C. L. Yang. 2004. National differences and ERP implementation: issues and
challenges Omega 32 (5):361371.
Singh, L. P., S. Singh, and N. M. Pereira. 2010. Human Risk Factors in Post-Implementation Phase of
ERP in SMEs in India. Edited by D. F. Kocaoglu, T. R. Anderson and T. U. Daim.
Soffer, P., B. Golany, and D. Dori. 2003. ERP modeling: a comprehensive approach. Information
Systems 28 (6):673690.
. 2005. Aligning an ERP system with enterprise requirements: An object-process based
approach. Information & Management 44 (8):666-680.
Soh, C., S.-S. Kien, and j. Tay-yap. 2000. Cultural fits and misfits: is ERP a universal solution?
Communication of the ACM 23 (4):47-51.
Soh, C., and M. L. Markus. 1995. How it creates business value: a process theory synthesis. Paper
read at 6th International Conference of Information Systems, DeGross, J.I., Ariav, G., Beath,
C., Hoyer, R., Kemerer, C. ed, at Amsterdam.
Somers, T. M., and K. Nelson. 2001. The impact of critical success factors across the stages of
enterprise resource planning implementations. In 34th Hawaii International Conference on
System Sciences. Hawai.
Sotiaux, Y. 2008. Management d'quipe de projet, mode d'emploi. Gereso librairie ed. Le mans.
Standards Association of Australia. 2004. AS/NZS 4360:1999, Risk management
Sumner, M. 2000. Risk factors in enterprise-wide/ERP projects Journal of Information Technology 15
(4):317-327.
Sun, A. Y. T., A. Yazdani, and J. D. Overend. 2005. Achievement assessment for enterprise resource
planning (ERP) system implementations based on critical success factors (CSFs). International
Journal of Production Economics 98 (2):189-203.
Sutcliffe, A. G., N. Maiden, S. Minocha, and M. Darrel. 1998. Supporting scenario-based requirements
engineering. IEEE Trans. Software Engineering 24 (12):1072-1088.
Swan, J., M. Newell, and M. Robertson. 1999. The illusion of best practice in information systems for
operations management. european Journal of Information Systems 8:284-293.
Tardieu, H., A. Rochfeld, and R. Colletti. 1983. La mthode Merise, Principes et Outils. Les Editions
d'Organisation ed.
Taylor, H. 2005. The move to outsourced IT projects: key risks from the provider perspective. In 2005
ACM SIGMIS CPR conference on Computer personnel research. Atlanta, Georgia, USA: ACM.
Thevenet, L. H., and C. Salinesi. 2009. Proposition de mesure de lalignement stratgique du systme
dinformation dans la mthode INSTAL. In IESI - Ingnierie d'Entreprise et de Systmes
d'Information (IESI). Toulouse, France.
153
Tiwana, A., and M. Keil. 2006. Functionality risk in software development. In IEEE transactions on
engineering management, 412-425.
Tomas, J.-L. 1999. ERP et progiciels intgrs, la mutation des systmes d'information. Dunod ed.
Paris.
Tomas, J.-L., and Y. Gal. 2011. ERP et conduite des changements - Alignement, slection et
dploiement - 6me dition Broch ed. Paris, France.
Torres, O. 1997. For an contingent approach of the specifities of the PME (in french). Revue
Internationale PME (RIPME) 10 (2):9-43.
Tournant, L., and W. Azan. 2003. Russir votre projet ERP. Afnor ed. Paris.
Trienekens, J. J. M., and P. van Grinsven. 2008. MEASURING CRITICAL SUCCESS FACTORS IN ERP
PROJECTS Results from a Case Study in a SME. Edited by J. Cordeiro and J. Filipe.
Tsai, W.-H., S.-J. Lin, W.-R. Lin, and J.-Y. Liu. 2009a. The relationship between planning & control risk
and ERP project success. In IIEEM 2009: EEE International Conference on Industrial
Engineering and Engineering Management. Jhongli, Taiwan
Tsai, W. H., P. L. Lee, Y. S. Shen, and H. L. Lin. 2012. A comprehensive study of the relationship
between enterprise resource planning selection criteria and enterprise resource planning
system success. Information & Management 49 (1):36-46.
Tsai, W. H., P. L. Lee, Y. S. Shen, C. C. Yang, and Ieee. 2009b. The relationship between ERP software
selection criteria and ERP success.
Tsai, W. H., S. J. Lin, W. R. Lin, J. Y. Liu, and Ieee. 2009c. The Relationship between Planning & Control
Risk and ERP Project Success.
Tsai, W. H., M. J. Shaw, Y. W. Fan, J. Y. Liu, K. C. Lee, and H. C. Chen. 2011. An empirical investigation
of the impacts of internal/external facilitators on the project success of ERP: A structural
equation model. Decision Support Systems 50 (2):480-490.
Tsai, W. H., Y. S. Shen, P. L. Lee, L. Kuo, and Ieee. 2009d. An Empirical Investigation of the Impacts of
ERP Consultant Selections and Project Management on ERP IS Success Assessment.
Tsai, W. H., T. S. Tsaur, Y. W. Chou, J. Y. Liu, J. L. Hsu, and Ieee. 2009e. Evaluating the Information
Systems Success of ERP Implementation in Taiwan's Industries.
Tserng, H. P., S. Y. L. Yin, M. J. Skibniewski, and M. H. Lee. 2010. Developing an ARIS-House-Based
Method from Existing Information Systems to Project-Based Enterprise Resource Planning for
General Contractor. Journal of construction engineering and management 136 (2):199-209.
Ulukan, H. Z., Y. Kop, and E. Unluyildiz. 2008. Evaluating the failure risk level of an ERP project using
fuzzy extended AHP. Edited by D. Ruan, J. Montero, J. Lu, L. Martinez, P. Dhondt and E. E.
Kerre. Vol. 1.
Umble, E. J., R. R. Haft, and M. M. Umble. 2003. Enterprise resource planning: Implementation
procedures and critical success factor. European Journal of Operational Research 146:241257.
Van Lamsweerde, A. 2001. Goal-Oriented Requirements Engineering: A Guided Tour. Paper read at
5th IEEE International Symposium on Requirements Engineering, at Toronto, Canada.
Velcu, O. 2010. Strategic alignment of ERP implementation stages: An empirical investigation.
Information & Management 47:158166.
Vernadat, F. 2002. UEML: Towards a unified enterprise modelling language. International Journal of
Production Research 40 (17):4309-4321.
Wang, E. T. G., and J. H. F. Chen. 2006. The influence of governance equilibrium on ERP project
success. Decision Support Systems 41 (4):708-727.
Wang, E. T. G., S. P. Shih, J. J. Jiang, and G. Klein. 2008. The consistency among facilitating factors and
ERP implementation success: A holistic view of fit. Journal of Systems and Software 81
(9):1609-1621.
154
Wenger, E. 1998. Communities of Practice: Learning, Meaning and Identity. Cambridge University
Press ed.
Wickramasinghe, V., and V. Gunawardena. 2010. Effects of people-centred factors on enterprise
resource planning implementation project success: empirical evidence from Sri Lanka.
Wong, A., and H. Scarbrough. 2005. Critical Failure Factors in ERP Implementation. Paper read at
PACIS 2005 - Pacic Asia Conference on Information Systems.
Wright, S., and A. M. Wright. 2001. Information system assurance for enterprise resource planning
systems: unique risk considerations. Journal of Information Systems 16 (1):99-113.
Wu, J.-H., S.-S. Shin, and M. S. H. Heng. 2007. A methodology for ERP misfit analysis. Information &
Management 44 (8):666680.
Wu, J. H. 2010. A Risk Assessment Model for Evaluating ERP Projects: a Case Study. Edited by Y.
Zhang.
Wu, Y. N., Z. J. Huang, and S. O. C. Ieee Computer. 2008. Application of Fuzzy Comprehensive
Evaluation Model Based on Variable Fuzzy Set Method in Construction Enterprises' ERP
Project Risk Evaluation.
Yahia, E. 2011. Contribution l'alignement de l'introprabilit smantique entre systmes
d'information d'entreprise: application aux systmes d'information de pilotage de
production, Automatique, Traitement du Signal et des Images, Gnie Informatique, Facult
des Sciences et Technologies, Nancy.
Yang, X. P., Q. J. Zhuang, and M. H. He. 2008. Risk Assessment Method of ERP Project Based on Risk
Matrix and AHP. Edited by J. L. Li.
Yu, E. 1995. Modeling strategic relationship fro process reegineering, Computer Science, University of
Toronto, Toronto, Canada.
Yunna, W., and H. Zhijun 2008. Application of Fuzzy Comprehensive Evaluation Model Based on
Variable Fuzzy Set Method in Construction Enterprises' ERP Project Risk Evaluation. Paper
read at ICRMEM '08 International Conference on Risk Management & Engineering
Management, at Beijing, China.
Zafiropoulos, J., K. Metaxiotis, and K. Askounis. 2005. Dynamic risk management system for the
modeling, optimal adaptation and implementation of an ERP system. Management and
computer Security 13 (3):212-234.
Zhang, L., M. K. O. Lee, and Z. Zhang. 2004. ERP systems implementation determinants and success
measures in China: A case study approach. Edited by O. Camp, J. B. L. Filipe, S. Hammoudi
and M. Piattini.
Zhang, Y. 2009. ERP Implementation Process Analysis Based on the Key Success Factors. Edited by Q.
H. Zhou.
Zhang, Z., M. K. O. Lee, P. Huang, L. Zhang, and X. Y. Huang. 2005. A framework of ERP systems
implementation success in China: An empirical study. International Journal of Production
Economics 98 (1):56-80.
Zhu, Y., and J. Chen. 2004. Strategy and risk analysis of the ERP projects in three chinese cigarette
enterprises. Edited by J. Chen.
Zhu, Y., Y. Li, W. Q. Wang, and J. Chen. 2010. What leads to post-implementation success of ERP? An
empirical study of the Chinese retail industry. International Journal of Information
Management 30 (3):265-276.
Zoukar, I. 2005. MIBE: Requirement engineering method for ERP system implementation (in french),
Computer Science, Paris I University - Sorbonne, Paris, France.
155
Annexe A Liste des publications de lauteur
Annexes
A. Liste des publications de lauteur
Publications internationales avec comit de lecture

[1]
Mamoghli, S., Goepp, V. and Botta-Genoulaz V. (2010) A decision algorithm for
ERP systems alignment, Int. J. Of Business Information System, Vol. 8, No. 1, pp 23-45.
Confrences internationales avec comit de lecture et dition dactes
[2]
Mamoghli, S., Goepp, V. and Botta-Genoulaz V., Renaud J. (2012) Contribution to
the alignment of off-the-shelf product based Information Systems: towards a model-driven
engineering, based on risk identification, Doctoral Symposium of the 6th International
Conference on Interoperability for Enterprise Systems and Applications (I-ESA12), March
20th, Valencia, Spain, Proceedings pp. 23-33.
[3]
Mamoghli, S., Goepp, V. and Botta-Genoulaz V., Renaud J. (2011) An analysis of the
project misalignment risk, 18th IFAC World Congress of the International Federation of
Automatic Control Milano 2011, August 28 September 2, Milano, Italy. CDRom Preprint
Proceedings p. 13092- 13097.
[4]
Mamoghli, S., Goepp, V. and Botta-Genoulaz V. (2010) An algorithm for the
identification of ERP systems misalignment, 3rd International conference on Information
Systems Logistics and Supply Chains (ILS10), April 14-16, Casablanca, Morocco,
Proceedings CDrom 10 p.
Autres
[5]
Mamoghli, S. (2010) Un algorithme pour lidentification des dsalignements au
niveau des systmes ERP, Session du GT EasyDim Ingnierie d'Entreprise et des Systmes
d'Information Dirige par les Modles : Conception, Intgration et Usages, Journes STP du
GDR MACS, 18-19 mars 2010, Strasbourg, France
156
Annexe B Cycle de vie du projet ERP et de lERP dans la littrature
B. Cycle de vie du projet ERP et de lERP dans la littrature
Phases
Phase avant-projet
tapes
Etude de faisabilit
(Esteves
1999)
(SAP AG
1999)
Phase de pr-implantation
Dfinition des
objectifs
stratgiques et
des besoins
Slection
du progiciel
(Deixonne
2001)
(Kumar et
al. 2003)
Adoption
(Tournant
and Azan
2003)
Plan de
gestion du
projet
(choix de
lditeur)
(Darras
2004)
(Motwani et
al. 2005)
(Aloini et al.
2007)
(Quellenec
2007)
Etude
dopportunits et
faisabilit
Lancement
Adquation
Acquisition
-
Adoption/dcision
Cadrage
Slection
Phase de postimplantation
Phase dimplantation
Intgration et
tests
Mise en
production
Implantation
Prparation du
projet
Plan des
processus
Lancement
Conception
Ralisation
Prparation finale
Ralisation de la
solution
Intgration
Choix des
processus
Utilisation
Utilisation et maintenance
Go-live
Evolution
Fin de
vie
Evolution
Fin de
vie
Support
Passage en
production
Implantation
Plan de gestion
du projet
(ressources)
Dcision de
lancement
Contrat de mise
en uvre
Stabilisation
Phases aprs projet
Paramtrage et
customisation
Prparation de
lenvironnement
informatique
Tests fonctionnels
Postimplantation
Installation pilote8
Dploiement (mme vision que (Deixonne 2001))
Pr-implantation
Implantation
Pr-implantation
Implantation
Lancement
Cadrage
Conception
Postimplantation
Postimplantation
Ralisation
Conduite de changement
Pilotage
Cet auteur propose, aprs la validation du projet ERP sur le site pilote choisi en phase avant projet , un dploiement sur les autres sites de lentreprise
157
Annexe C Mthodes dalignement et de confrontation
C. Mthodes dalignement et de confrontation
Les mthodes dalignement
Proposition de (Prakash and Rolland 2001)
Modles
La mthode de (Prakash and Rolland 2001) met en uvre les modles suivants :
-
To-be MAP correspondant au modle AS-WISHED

As-is MAP correspondant au modle AS-IS
ERP MAP correspondant au modle MIGHT-BE
Matched MAP correspondant au modle TO-BE
Outils
Les auteurs ne proposent pas doutils pour la confrontation. Elle est ralise visuellement
entre les diffrents modles confronts et sans utilisation de mesures de similarit.
Pour la construction des quatre modles, les auteurs proposent dutiliser le formalisme MAP
qui permet de reprsenter les processus sous forme de graphe orient. Les processus
reprsents dans les quatre modles sont mis en vidence selon les intentions auxquels ils sont
rattachs et les stratgies pour les atteindre. Ces buts sont formaliss sous la forme de nuds.
Les stratgies qui reprsentent les actions permettant de progresser d'une intention une autre
sont, quant elles, formalises, par les artes du graphe orient. Le graphe tant orient, la
relation de prcdence entre deux intentions doit tre respecte. De plus, une section,
correspondant, au triplet <I, S, J>, spcifie que la stratgie S permet de passer de l'intention
source I l'intention cible J. Aussi, tout modle reprsent sous la forme d'un MAP contient
les intentions Start et Stop qui dlimitent respectivement le dbut et la fin du processus
considr. Ce formalisme autorise galement le raffinement des sections. Le raffinement
modlise une section un niveau plus dtaill.
Processus dalignement
Les auteurs proposent le processus suivant :
-
Construction des modles To-be MAP, As-is MAP et ERP MAP: Selon les auteurs,
lintrt du modle As-is MAP est double. Ce modle offre, dune part, la possibilit de
faire une critique de lexistant, ce qui peut servir de base la construction du To-be
MAP. Dautre part, il permet dvaluer lcart entre lexistant et ce qui sera implant.
Confrontation des trois modles et construction progressive du modle Matched MAP :
la confrontation est tire par lun ou lautre des trois modles. Elle consiste analyser
158
le modle qui tire l'alignement. Il sagit de considrer une une chaque intention et
stratgie en partant de l'intention Start jusqu l'intention Stop en se posant la
question de savoir si ces stratgies et intentions seront modifies ou non en fonction des
deux autres modles pour les intgrer dans le Matched MAP. Soit les modles
confronts sont aligns et le modle Matched MAP contient les lments communs aux
deux modles confronts. Soit les modles ne sont pas aligns et le modle Matched
MAP est construit soit limage du modle To-be MAP, soit limage du modle
ERP MAP. Il est possible daffiner lanalyse des sections, en les raffinant avant de
lintgrer ou non dans le Matched MAP.
Vrification de la satisfaction des besoins : les besoins inclus dans le Matched MAP
obtenu est finalement confront au To-be MAP pour vrifier si les besoins de
l'entreprise sont satisfaits.
Proposition de (Darras 2004)
Modles
La construction des modles mis en uvre dans la mthode de (Darras 2004) sinscrit dans un
cadre de modlisation inspir de la norme de modlisation dentreprise (CEN ENV 40003
1991). Il est compos des deux dimensions suivantes :
-
La dimension de gnricit , base sur des mcanismes de gnralisation et de

spcialisation des dmarches orientes objet. A linstar de la dimension de gnricit
de la norme (ISO 19439 2006), elle permet de progresser de concepts particuliers des
concepts plus gnraux. Elle est galement compose de trois niveaux :
gnrique : proposition de lditeur pour toutes les entreprises
partiel : spcialisation du niveau gnrique pour un secteur dactivit
particulier : spcialisation du modle pour une entreprise particulire
La dimension d abstraction , base sur les travaux dans le domaine de lingnierie des
S.I. et utilis notamment travers la mthode MERISE (Tardieu et al. 1983). Elle fait
rfrence lutilisation des modles et est compose de quatre niveaux :
spcification mtier : concepts de la modlisation dentreprise.
spcification : besoins en termes doprations, dinformations, de ressources
ncessaires, de responsabilits et dautorits sans indiquer de prciser leur
implmentation.
conception : oprations qui seront implmentes et entits impactes par ces
oprations traduites en classes.
implmentation : rgles et moyens pour excuter les oprations.
A travers ce cadre, sont mis en uvre les modles suivants :

-
Modle particulier de lentreprise , niveaux spcification mtier et particulier

correspondant au modle AS-WISHED ;
Modle de rfrence , niveaux spcification et gnrique correspondant au modle
MIGHT-BE ;
Modle dentreprise S.I. , niveaux spcification et particulier correspondant au modle
TO-BE. A ce modle est associ un modle conceptuel . Il dcrit plus prcisment
159
chaque activit reprsente dans le modle TO-BE en dcrivant les attributs des entits
manipules . Par ce biais, il prcise les conditions dimplmentation dans un
environnement dexploitation connu tel que les capacits des ressources .
Outils
Lauteur ne propose pas doutils pour la confrontation quil appelle mise en
correspondance . Elle est ralise visuellement entre les diffrents modles confronts et
sans lutilisation de mesures de similarit.
Pour la construction des modles des niveaux de spcification et spcification mtier, lauteur
propose dutiliser la grille GRAI orient Cas dUtilisation (CU) et le diagramme dactivit du
langage UML. La grille GRAI permet de reprsenter le primtre fonctionnel et de visualiser
une cartographie des dcisions o chaque centre de dcision correspond un CU. Les centres
de dcisions reprsentent le point d'entre de la reprsentation des processus. A chaque CU de
la grille GRAI est associ un diagramme dactivit pour reprsenter le processus.
Pour le modle au niveau conceptuel, lauteur propose dutiliser le diagramme de classes
UML. Le diagramme de classes UML permet de traduire le modle d'entreprise S.I. en
modle au niveau conceptuel. A chaque activit du diagramme dactivit du modle
entreprise S.I. est associe une classe dans le modle au niveau conceptuel.
Le processus dalignement propos sinscrit dans le cadre de la Figure A- 1. Il est le suivant :
-
Construction des modle dentreprise particulier et modle de rfrence . Ces

modles sont dabord construits selon la grille GRAI orient CU puis selon le diagramme
dactivit. La grille GRAI sert de point dentre la modlisation des processus souhait
par lentreprise et des processus sous contrle de lERP. Le choix du niveau de granularit
des activits du diagramme dactivit est laiss libre. Cependant, si lentreprise souhaite
adopter les processus standards de la solution logicielle, le niveau macroscopique est
prfrable. Par contre, si le processus souhait par lentreprise est critique dans latteinte
des performances, cest--dire sil touche son cur de mtier, alors il est ncessaire de le
modliser un niveau de granularit plus fin. Lauteur prcise aussi comment les deux
modles sont construits :
sur la base dun mcanisme de spcialisation des concepts de modlisation
dentreprise - a dans le cadre de la Figure A- 1; au niveau spcification mtier,
il sagit du passage du niveau gnrique au niveau particulier.
par ce biais, les deux modles sont construits sur les mmes concepts de base.
Confrontation - mise en correspondance des modles ou encore identification des
trous fonctionnels selon lauteur - de lenchanement dactivits des deux premiers
modles tout en construisant progressivement le modle conceptuel . Plus prcisment,
la confrontation / construction progressive est ralise en deux tapes distinctes :
La mise en correspondance consiste identifier activit par activit, les
activits du modle dentreprise particulier galement prsentes dans le
modle de rfrence . Ces activits similaires sont ensuite reprsentes dans le
modle dentreprise S.I. . Puis, ce dernier est traduit en modle conceptuel .
Lauteur ne prsente pas cette traduction pas travers le cadre de la Figure A- 1.
160
Cest sur la base de ce modle que le paramtrage de la solution sera ralis - e

dans le cadre, passage de la solution logicielle, niveau gnrique et
implmentation, au Systme dInformation de lentreprise, niveau particulier et
implmentation. Ceci est fait sachant que lERP a dj t install dans
lenvironnement technique du client - c dans le cadre.
Lidentification des trous fonctionnels cest dire lidentification des besoins
rels de lentreprise non prsents dans le modle de rfrence . Ils sont
directement reprsents sur le modle conceptuel par le mcanisme
dextension de classes du diagramme de classes le composant - b dans le cadre
de la Figure A- 1. Ensuite, ils sont implments par des dveloppements
spcifiques - d dans le cadre, passage du modle dentreprise S.I. au
Systme dInformation .
Figure A- 1- Processus dalignement propos par (Darras 2004)
Identification des ressources et principe de codification : la dernire tape consiste

identifier :
Les ressources disponibles dans lentreprise : applicatives , matrielles ou
humaines .
Les rles des personnes : droits des employs de lentreprise et utilisateurs du
Systme dInformation.
Les principes de codication de lentreprise pour ses entits, par exemple, les
quatre premires lettres de lidentifiant du client correspondront au quatre
premires lettres de son nom.
161
Proposition de (Soffer et al. 2005)
Modles
La mthode de (Soffer et al. 2005) met en uvre les modles suivants :
-
Enterprise requirements correspondant au modle AS-WISHED

ERP system model correspondant au modle MIGHT-BE
Aligned process model correspondant au modle TO-BE
Outils
Pour la construction des modles, les auteurs prconisent lutilisation du formalisme OPM
(Object-Process Methodology). Ce formalisme utilise le diagramme OPD (Object-Process
Diagram) qui permet de modliser les processus et les objets lis ces processus (liens qui
indiquent si lobjet est utilis ou affect par le processus). Plusieurs possibilits sont offertes
par ce formalisme :
-
Les processus peuvent tre exprims un haut niveau gnrique et regroups en groupes
fonctionnels formant un ensemble de sous-processus. Ainsi, par exemple, le processus de
traitement des Bons de Commandes regroupe les sous-processus de rception des
marchandises et de clture des bons de commande . A ce niveau, les objets sont
galement modliss.
Puis, plusieurs options ou alternatives peuvent se prsenter aussi bien pour les
processus que les objets. Cette caractrisation des processus et objets est uniquement
valable pour le modle ERP system model qui offre plusieurs alternatives de
paramtrage. Celle-ci se fait en trois niveaux :
system configuration optionality level correspondant au niveau dexistence
dun processus. Par exemple, il sagira de statuer si, lors de la rception des
marchandises, le processus de contrle de la localisation de la marchandise
rceptionne dans les entrepts est ralis ou non.
object level correspondant au niveau dexistence dune option pour une
instance dun objet. Par exemple, si au niveau prcdent le processus de contrle
de la localisation de la marchandise rceptionne dans les entrepts est ralis, il
sagira de dfinir si lentrept spcifique X dune entreprise inclut ou non cette
option de localisation.
occurrence level correspond au niveau dexistence dune option pour une
instance dun objet utilis en temps rel dans un processus. Par exemple, il sagira
de mettre loption, accessible lutilisateur du systme. Ainsi, par exemple,
lutilisateur pourra choisir ou non de contrler la localisation dun entrept
particulier au cours de lexcution dun processus utilisant lentrept - mme si
lentrept concern a t paramtr contrl au niveau object level. Ceci est
possible en paramtrant dans linterface utilisateur, par exemple, des cases
cocher.
Les auteurs proposent de raliser la confrontation visuellement tout en fournissant des
moyens mesures de similarit. Ceux-ci sont mis en uvre travers un processus appel
162
Single Requirement Matching (SRM). Il permet de mesurer la similarit entre chaque

OPD du modle Enterprise requirements et du modle ERP system model. Deux
fonctions dont lagrgation mne un score sont utilises :
une fonction appele Relational Similarity (RS) qui mesure la similarit des
liens entre les entits (mme entit source, mme entit destination, mme type de
lien et vrification de la cardinalit,
une fonction appele Entity Similarity (ES) qui mesure la similarit de ces
entits : elle compte combien d'entits ont le mme nom et le mme type.
Le processus dalignement propos est le suivant :
-
Construction des modles Enterprise requirements et ERP system model avec le

formalisme OPM.
Confrontation matching pour lauteur - des deux premiers modles construits tout en
modifiant progressivement le modle Enterprise requirements et en vrifiant sa
faisabilit.
La Confrontation est ralise par le biais du processus de mesures de similarits
Single Requirement Matching (SRM) entre les OPD des deux modles : tous les
OPD du modle Enterprise requirements sont donc lis tous les OPD du
modle ERP system model par un score.
La modification est faite sur la base des scores maximums obtenus entre les OPD
des deux modles. Ainsi, pour chaque couple dOPD avec un score lev : il sagit
didentifier visuellement lcart reflt par cette mesure de similarit non gale 1
(par exemple : le score est gale 0,9 car une entit est prsente dans un OPD est
pas lautre) : sur la base des carts identifis, le modle Enterprise
requirements est reformul. Les reformulations possibles sont les suivantes :
splitting est une reformulation des OPD sans rien ajouter ni modifier
ni supprimer. Cette reformulation est choisie lorsquun OPD dun modle
ne trouve pas dquivalence avec un OPD de lautre modle : tous les
scores qui le relient aux OPD de lautre modles sont faibles. Mais ces
scores faibles ne refltent pas le fait que lOPD qui lui est quivalent est,
en fait, un sous-processus dun autre OPD. Ainsi, le sous-processus sera
formul dans un OPD tout seul et non comme un sous-processus.
abandonning consiste abandonner le processus considr, c'est-dire le supporter manuellement sans support de lERP SI.
mapping consiste modifier le fonctionnement du modle Enterprise
requirements pour laligner au modle ERP system model. Ces
modifications peuvent concerner les entits ou encore lalternative
souhaite par lentreprise en la remplaant par lalternative disponible au
sein de lERP. Dans ce cas, les nouveaux et les anciens processus ont les
mmes objectifs mais la manire de latteindre change. Cest donc une
nouvelle option qui est choisie.
La vrification de la faisabilit de lOPD du modle Enterprise requirements
reformul est base sur lalgorithme BUA - Bottom-Up Aggregation. Cet
algorithme consiste lier le contenu des modles (entits et processus) par des
liens logiques tel que AND, OR, XOR. Ceci permet de mettre en vidence des
contradictions ventuelles dans le modle. Pour pallier les contradictions, des
reformulations sont galement faites.
163
Les processus SRM et AUB sont ritrs jusqu obtention de modles faisables
et de la satisfaction des utilisateurs par les scores obtenus.
Construction du modle Aligned process model sur la base des lments aligns entre
les modles Enterprise requirements et ERP system model et des modifications
juges faisables du modle Enterprise requirements.
Proposition de (Zoukar 2005)
Modles
La mthode de (Zoukar 2005) met en uvre les modles suivants :
-
As-wished BM correspondant au modle AS-WISHED, o BM signifie Business

Model,
Might-be SFM correspondant au modle MIGHT-BE, o SFM signifie System
Functionnality Model,
Carte de correspondance , To-be BM et To-be SFM, correspondant au modle
TO-BE mais reprsents dans des formalismes potentiellement diffrents. En effet,
lauteur souhaite laisser lentreprise la possibilit de choisir le formalisme quelle
souhaite.
Outils
Pour la construction des modles, lauteur propose, linstar de (Prakash and Rolland 2001),
lutilisation du formalisme MAP.
La confrontation est ralise visuellement en fournissant 30 types de similarits rpartis en 2
facteurs et 4 critres :
-
Facteur intrinsque qui sintresse aux proprits des lments. Par exemple, llment
intention a comme proprit le verbe de lintention. Ce facteur est compos de deux
critres :
Critre de synonymie runit des similarits de type : le verbe de lintention
grer les produits est proche au verbe de lintention manager les articles
,
Critre dhypronymie / hypomimie runit des similarits de type : le verbe de
lintention grer le processus est hypronyme au verbe de lintention
suivre le processus .
Facteur structurel qui sintresse aux structures de composition et de lien entre
lments :
Critre compositionnel runit des similarits de type : deux cartes ont le mme
nombre dintentions,
Critre relationnel runit des similarits de type : deux intentions sont cibles
de la mme intention.
Lauteur propose un processus selon les tapes suivantes :
164
Construction des modles Might-be SFM et As-wished BM. Il sagit de dfinir

dabord les sections des MAP et en ensuite de les agrger.
La construction de Might-be SFM peut se faire par abstraction de la
documentation fournie avec le systme et de la connaissance des experts consultants, intgrateurs, diteurs - ou encore par rutilisation des modles MAP
existants dans le cas o les intgrateurs auraient dj modlis des cartes dans
dautres projets.
La construction du modle As-wished BM peut se faire partir de rien, des
dysfonctionnements dans lexistant ou de ladoption des bonnes pratiques sousjacentes lERP, provenant du modle Might-be SFM.
Plusieurs stratgies de dfinition des sections sont proposes. Par exemple, les
stratgies de regroupement et de dcomposition consistent regrouper ou
clater des sections dj dfinies pour en dfinir de nouvelles.
Confrontation ou mise en correspondance des modles Might-be SFM et Aswished BM tout en construisant progressivement la carte de correspondance entre
ces modles. Elle comporte les alternatives possibles qui seront modlises dans les To-be
(SFM et BM). Pour ce faire, lauteur propose :
Dabord, danalyser la similarit entre toutes les cartes des modles Might-be
SFM et As-wished BM par utilisation dune part, de stratgies de choix des
cartes qui sont mises en correspondance et dautre part, des mesures de
similarits. Pour chaque couple de cartes mises en correspondance, il sagit
dvaluer les similarits de facteur intrinsque puis de facteur structurel et
dagrger les deux. Le choix des cartes mettre en correspondance se fait par
stratgie top down, bottom up ou mixte. La premire stratgie consiste
confronter des cartes un niveau de granularit n choisi. Puis, si les similarits
dtectes ne sont pas satisfaites, il sagit de les confronter un niveau de
granularit n+1 et ainsi de suite. bottom up et mixte. sont appliques si la
premire nest pas satisfaisante. La stratgie bottom up consiste confronter les
cartes similaires dun niveau de granularit n-1, qui peut tre le plus bas, et de
remonter les liens daffinement : deux cartes similaires identifies permettent de
construire deux sections un niveau plus lev n. La stratgie mixte consiste
confronter une carte mtier dun niveau de granularit n aux cartes mtier de tous
les niveaux. Cette tape produit un tableau de bord des similarits : o chaque
couple de MAP confront, lune correspondant Might-be SFM et lautre ASwished BM, est associ une mesure de similarit.
Dlaborer les alternatives de correspondance sur la base du tableau de bord
obtenu. Sur cette base lentreprise peut choisir dadopter la stratgie du plus
petit commun , de la ngociation mtier ou de la ngociation systme . La
premire stratgie est mise en uvre si lentreprise souhaite mettre en place les
processus qui rpondent ses besoins et minimiser toute modification faite sur
lERP. Les deux suivantes viennent enrichir la premire. La ngociation
mtier consiste faire des dveloppements spcifiques pour rpondre aux
besoins non couverts. La ngociation systme consiste installer des
fonctionnalits juges pertinentes pour lentreprise mais non recenses dans ses
besoins. Pour laborer les alternatives de correspondance, lauteur propose des
stratgies de rflexions : identification de critres de jugement des alternatives,
valuation des alternatives selon ces critres, refus ou adoption de lalternative,
affinement.
165
Choix final des alternatives inclure dans les modles To-be SFM et To-be BM:
chaque alternative est slectionne, des critres de jugement des alternatives sont
nouveau dfinis, lalternative est value et les critres sont agrgs ; enfin lalternative
est choisie ou non.
Proposition de (Tserng et al. 2010)
La mthode propose par lauteur sintitule AHB method signifiant ARIS-house-based

method.
Modles
La mthode de (Tserng et al. 2010) met en uvre les modles suivants :
-
functions in existing system correspondant au modle AS-IS

future requirements correspondant au modle AS-WISHED
ERP modules correspondant au modle MIGHT-BE
final ERP modules correspondant au modle TO-BE
Outils
Pour la construction des modles, les auteurs proposent dutiliser le diagramme ARISHouse. Ce diagramme permet de reprsenter les modles selon les quatre vues suivantes :
-
La vue fonction qui permet de reprsenter les fonctions du S.I. telles que la gestion
commerciale ou encore la gestion financire .
La vue organisation permet de reprsenter les dpartements qui utilisent le Systme
dInformation telle que le dpartement de gestion de projet ou encore le dpartement
des finances .
La vue donnes permet de reprsenter les donnes en entres / sorties du Systme
dInformation telle que le rapport journalier , les documents de la gestion de projet .
La vue contrle permet de reprsenter les processus oprationnels excuts par le
Systme dInformation tels que reporter lactivit de planification . Elle est relie aux
lments reprsents travers les trois autres vues.
(Tserng et al. 2010) se focalisent sur des projets ERP dans lindustrie de la construction.
Celles-ci ne produisent et ne commercialisent pas des biens mais grent des projets de
construction. Lauteur considre le modle de lexistant functions in existing system comme
tant les besoins rels de lentreprise. Ainsi, il ny a pas de formulation des besoins rels
permettant la remise en cause ventuelle de lexistant. Le modle future requirements est
lui, considr comme des besoins rels additionnels au modle functions in existing
system.
166
Le processus propos est constitu des tapes suivantes :

-
Construction :
Du modle functions in existing system sur les quatre vues - fonction,
organisation, donnes et contrle - sur la base dune description et dune analyse
de lexistant.
Du modle future requirements uniquement sur trois vues - fonction,
organisation et donnes - sur la base dune description et dune analyse des
besoins supplmentaires exprims par les dpartements de lentreprise. La vue
contrle nest pas reprsente dans ce modle car les fonctions nont pas encore
t oprationnalises au sein du systme c'est--dire conus travers une
fonctionnalit du systme.
Du modle ERP modules uniquement sur trois vues fonction, donnes et
contrle - sur la base dune description et dune analyse des modules de lERP. La
vue organisation nest pas reprsente car, selon lauteur, le systme na pas
encore t mis en place dans un environnement organisationnel.
Confrontation - ou comparison - les trois modles tout en construisant progressivement
le modle final ERP modules La confrontation des trois modles se fait sur la vue
fonction et donnes . La confrontation consiste retrouver dans le modle ERP
modules les fonctions et donnes existantes dans les deux autres modles. Si ce nest pas
le cas, lquipe qui met en uvre lERP devra raliser des dveloppements spcifiques.
167
Mthodes de confrontation
Proposition de (Wu et al. 2007)
Modles
La mthode de (Wu et al. 2007) met en uvre les modles suivants :
firms requirement et goals in the enterprise correspondant tous deux au
modle AS-WISHED
best process candidate et capabilities of the candidates correspondant tous
deux au modle MIGHT-BE. Best process candidate fait rfrence un
processus issu des bonnes pratiques sous-jacentes lERP
Outils
Pour la construction des modles, les auteurs proposent d'utiliser le formalisme UML, ainsi
que des captures dcran et des tableaux :
-
Le diagramme de cas d'utilisation est utilis pour reprsenter les buts exprimant dune
part, les capacits des ERP mis en comptition pour la slection du progiciel et dautre
part, les besoins rels de lentreprise. Celui-ci est modifi de telle sorte classer les cas
dutilisation obtenu en rigid goals qui doivent absolument tre satisfaits et soft goals
qui sont des proprits dsires .
Pour lenchanement des activits : le diagramme d'activits permet de visualiser les
connexions entre activits ainsi que leurs pr-conditions et post-conditions.
Pour les sorties, l'auteur propose d'utiliser le drawing et le glossaire des donnes :
Le drawing est une capture dcran de linterface utilisateur mettant en uvre
lactivit. Celle-ci permet d'exprimer les donnes en sortie des activits sous
forme de champs .
Le glossaire de donnes est un tableau qui prcise le format et lorigine des
champs .
La confrontation est ralise visuellement en utilisant des mesures de similarit simples :
les entits confrontes sont soit quivalentes soit diffrentes. Les similarits et carts de
lenchainement des activits sont agrgs dans une matrice.
Processus de confrontation
Cette mthode liste les non-alignements identifis mais ne leur associe pas de dcision. Le
processus consiste :
-
Construire les modles goals in the enterprise et capabilities of the candidate. Ce

dernier est construit pour chaque ERP candidat
Confronter les buts du premier avec les buts du second modle, et ce pour chaque ERP
candidat tout en listant progressivement les non-alignements - les carts pour lauteur entre les modles.
Construire les modles entreprise requirements et best process candidate.
168
Confronter lenchainement des activits de chaque domaine de tout en listant

progressivement les non-alignements entre les modles.
Construire les modles entreprise requirements et best process candidate par lajout
des drawings et glossaires de donnes .
Confronter le format et lorigine des donnes en sorties reprsents sur les drawings et
glossaires des couples dactivits identifis comme alignes dans ltape 4 4me
point.
Proposition de (Millet 2008)
Modles
La construction des modles mis en uvre dans la mthode de (Millet 2008) sinscrit dans un
cadre de modlisation. Il est inspir de la norme de modlisation dentreprise (ISO 19439
2006) et est compos des trois dimensions suivantes :
-
La dimension de cycle de vie correspondant aux phases du processus dalignement au

cours desquelles sont construits les modles. Cette dimension est compose de sept phases
- cf. section 1.1.1 de ce chapitre.
La dimension de gnricit permettant de passer du niveau gnrique au niveau
particulier par particularisation de modles. Cette dimension est compose de trois
niveaux cf. section 1.1.1 de ce chapitre.
La dimension de point de vue permettant de reprsenter une perception slective dun
modle dentreprise, soulignant certains aspects particuliers de lentreprise. Cette
dimension est compose de trois vues - cf. section 1.1.1de ce chapitre.
Les auteurs reprennent les construits proposs par la norme (ISO/DIS 19440 2004). Il les
complte par les construits du mta-modle du rfrentiel SCOR tel que les construits
practices, features, metrics, mais galement par les construits du mta-modle des
objets dun ERP tels que ressources donnes , ressources interactions et ressources
programme . Il obtient ce quil appelle le mta-modle de rfrence .
A travers ce cadre, sont mis en uvre les modles suivants :
-
Modle des besoins correspondant au modle AS-WISHED. Il sagit des objectifs

spcifiques l'entreprise et bonnes pratiques susceptibles daider les atteindre . Ce
modle est construit lors des phases didentification du domaine et de dfinition des
concepts. Il sagit dun modle au niveau partiel car il est construit sur la base de
rfrentiels proches des mtiers de lentreprise et de sa typologie.
Modle de la solution correspond au modle MIGHT-BE. Ce modle est construit lors
de la phase de spcification de la conception. Il sagit dun modle au niveau partiel. Il est
obtenu partir du progiciel existant. En effet, il est construit sur la base de simulations
faites sur l'ERP en plateforme de test.
169
Outils
Les modles utiliss au cours du processus de confrontation correspondent des graphes
d'intgration reliant les objets instancis des construits du mta-modle de rfrence .
Les liens entre les objets sont de types diffrents. Ainsi, par exemple, un processus et un
vnement seront relis si le processus dclenche l'vnement ou encore un processus et une
donne seront relis si le processus utilise cette donne.
Millet associe des outils au graphe dintgration pour analyser ces liaisons. Cela lamne
dfinir des dpendances et des contraintes entre les objets qui ne sont pas visibles directement
sur le graphe. Parmi ces outils, nous pouvons citer lextraction des sous-graphes
dintgration : un sous graphe d'intgration not G (Di, Cj) de longueur n entre deux instances
Di et Cj de construits correspond tous les chemins qui relient Cj et Di ayant une longueur
infrieure ou gales n. Le sous-graphe G (Ci, D) concerne toutes les instances du construit
D. Lextraction de ces sous-graphes dintgration du graphe principal permet de faire ressortir
des problmatiques et informations intressantes dans le cadre de lalignement. Ainsi, par
exemple, un tel sous-graphe permet de savoir quelles sont les donnes pertinentes la matrise
du contexte d'une activit EAI.
Processus de confrontation
Cet auteur propose de caractriser lalignement dans diffrents projets faisant intervenir cette
notion. Il sintresse notamment aux projets ERP BP correspondant ce que nous
appelons projet ERP. Pour cet auteur les dpendances conditionnent un alignement . Ainsi
la confrontation - ou rapprochement pour lauteur - de deux modles consiste retrouver,
dans lun, les dpendances quil y a dans lautre. Si cest le cas, les deux modles sont aligns.
Plus exactement, deux modles sont aligns sur un point de vue si la structure des construits
de ce point de vue est identique - ou quasiment identique. En dautres termes, la structure
dun modle A se retrouve dans le modle B. La structure correspond lensemble des
dpendances que forment ces construits. Par exemple, deux modles peuvent tre aligns sur
le point de vue ressources. Dans ce cas, les dpendances formes par le construit features,
sur le construit IT ressource, sont identiques dans les deux modles.
Ainsi, ce sont des typologies de graphes qui sont compars entre modles. De manire
prosaque, lalignement se visualise alors par le fait que les deux graphes peuvent tre
superposs facilement, chaque construit de lun tant li un construit de l'autre, et les
dpendances dans lun tant en correspondance avec une dpendance dans l'autre .
170
Annexe D Classification des travaux sur les facteurs de risque et de succs
D. Classification des travaux sur les facteurs de risque et de succs
Liste de facteur
(risque ou succs)
Classification des
facteurs
(Holland and Light

1999)
X (succs)
X (nature)
(Sumner 2000)
X (risque)
Auteur
Influence
entre
facteurs
(Somers and Nelson

2001)
(Wright and Wright
2001)
(Hong and Kim
2002a)
(Akkermans and Van
Helden 2002b)
(Bernard et al. 2002b)
Limites un
sous-ensemble
de facteurs
X (succs)
X (succs)
X (succs)
Mode de recueil si liste de facteur

Revue de littrature
(Jarrar et al. 2000a)

(Shanks et al. 2000)
Approches de
management
X (cycle de vie)
X (risque)
7 tudes de cas de grandes entreprises

occidentales de plusieurs industries
Revue de littrature
2 tudes de cas : lun dans une entreprise
en Australie, et lautre dans une entreprise
en Chine
Revue de littrature et tudes de cas de 110
entreprises occidentales
Interviews de 30 consultants, occident
X (succs)
X
X (risque)
(Allen et al. 2002)
X (succs)
(Al-Mashari et al.
2003)
X (succs)
(Kumar et al. 2003)
X (succs)
X (cycle de vie)
Revue de littrature
4 tudes de cas dans le secteur
universitaire, UK
X (cycle de vie)
Revue de littrature
Interviews de 20 managers dentreprises
Canadiennes
171
Auteur
(Ghosh 2003)
(Nah et al. 2003)
(Umble et al. 2003)
(Amoako-Guyampah
2004)
Liste de facteur
(risque ou succs)
Classification des
facteurs
Limites un
sous-ensemble
de facteurs
X (succs)
X (succs)
X (succs)
(Huang et al. 2004)
X (risque)
(Deakins 2004)
X (succs)
(Zhu and Chen 2004)
X (succs)
(Zhang et al. 2004)
X (succs)
(Ehie and Madsen

2005)
X (succs)
(Leopoulos et al.
2005)
(Wong and
Scarbrough 2005)
(Dowlatshahi 2005)
Approches de
management
X (succs)
X (succs)
(Sheu et al. 2004)
(Motwani et al. 2005)
Influence
entre
facteurs
X (nature)
X (succs)
X (cycle de vie)
X (risque)
Revue de littrature
Revue de littrature
Perception des managers des entreprises
aux USA
Plusieurs tudes de cas dans des
entreprises orientales et occidentales
Interview de 7 experts sur la base de la
mthode Delphi - Chine
Retour dexprience sur 2 projets ERP
ayant t des succs dans des entreprises
de taille moyenne aux USA
3 tudes de cas de compagnies chinoises
de cigarettes
Analyse des modles de succs (ex :
MCLean) en fonction de cas dentreprises
chinoises
Interviews de 30 consultants issus
dentreprises de toutes tailles et industries
confondues aux USA
Analyse des modles de succs MIS
research model (1980) et celui de DeLone
& McLean's (1992) en fonction de cas
dentreprises chinoises
4 tudes de cas de grosses entreprises
occidentales
4 tudes de cas dentreprises chinoises
X (succs)
2 tudes de cas dentreprises aux USA
172
Auteur
Liste de facteur
(risque ou succs)
(Holsapple et al.
2005)
(Sun et al. 2005)
X (succs)
(Zhang et al. 2005)
X (succs)
Classification des
facteurs
Influence
entre
facteurs
(Chen et al. 2006)
X (valuation)
Revue de littrature
Retour dexprience sur 4 entreprises
chinoises utilisant dj un ERP, mme
industrie et mme taille
X (identification,
valuation,
priorisation,
traitement)
X (succs)
Interviews de fournisseurs Hong Kong

X
X (succs)
(Wang and Chen

2006)
(Ojala et al. 2006)
(Li et al. 2006)
(Nah and Delgado
2006)
(Jing et al. 2007)
Limites un
sous-ensemble
de facteurs
X (succs)
(Zafiropoulos et al.
2005)
(Taylor 2005)
(King and Burgess
2006)
Approches de
management
Revue de littrature, interviews dexperts,

tudes de cas et enqutes, entreprises
chinoises
X (cycle de vie)
X (succs)
X
X (succs)
tude de cas en Chine
X (cycle de vie)
Analyse du processus dimplantation de
lERP bas sur divers cas en Chine
X (succs)
(Plant and Willcocks

2007)
X (cycle de vie)
(Aloini et al. 2007)
X (risque)
(Law and Ngai 2007)
X (succs)
X (cycle de vie)
Interviews de 2 chefs de projet

international
3 tudes de cas dentreprises chinoises
173
Auteur
(Grabski and Leech
2007)
(Olson and Zhao
2007b)
(Finney and Corbett
2007)
(Bueno and Salmeron
2008)
(Chou and Chang
2008)
(Deng and Bian 2008)
(Yunna and Zhijun
2008)
(Capaldo et al. 2008)
(Chen and Ming
2008)
(Ifinedo 2008)
(Sammon and Adam
2008)
(Trienekens and van
Grinsven 2008)
(Ulukan et al. 2008)
(Wang et al. 2008)
(Wu et al. 2008)
(Yang et al. 2008)
(Chen et al. 2009b)
(Hua 2009)
Influence
entre
facteurs
Approches de
management
Limites un
sous-ensemble
de facteurs
Liste de facteur
(risque ou succs)
Classification des
facteurs
X (risque)
X (nature)
Revue de littrature
X (succs)
X (cycle de vie)
Revue de littrature
X (succs)
Revue de littrature
X
X (succs)
Interviews dans des entreprises Taiwan
X
X (nature)
X (valuation)
X (nature)
X (valuation)
Retour dexprience dans une entreprise
corenne ayant russi son projet ERP
X (succs)
X (valuation)
X (valuation)
X (valuation)
X (valuation)
X
X (valuation)
X (valuation)
X (nature)
X (nature)
X (valuation)
174
Auteur
Liste de facteur
(risque ou succs)
Classification des
facteurs
Influence
entre
facteurs
(Zhang 2009)
X (risque)
X (nature et cycle
de vie)
Malhotra and
Temponi 2010)
(Santamaria-Sanchez
et al. 2010)
(Velcu 2010)
(Singh et al. 2010)
(Wickramasinghe and
Gunawardena 2010)
(Wu 2010)
(Zhu et al. 2010)
Revue de littrature et tudes de cas, UK

X (succs)
X (risque)
X
X (succs)
X (succs)
X (succs)
Revue de littrature, tudes de cas et
enqutes en Chine
X (cycle de vie)
X (identification,
valuation,
priorisation,
traitement)
(Ho et al. 2009)
(Hakim and Hakim

2010)
Limites un
sous-ensemble
de facteurs
X (identification,
valuation,
priorisation,
traitement)
(Iskanius 2009)
(Peng and Nunes
2009)
(Tsai et al. 2009b)
(Tsai et al. 2009c)
(Tsai et al. 2009d)
(Tsai et al. 2009e)
Approches de
management
X (succs)
X (nature)
X (succs)
X (succs)
X (succs)
X (risque)
Interprtation qualitative des obstacles

pour les dcideurs dans les projets ERP
dindustries iraniennes et revue de
littrature
Revue de littrature et interviews dans une
PME aux USA
Interviews dans 141 entreprises en
Espagne
X
X (cycle de vie)
tude de cas dune entreprise en Inde
X (succs)
tudes de cas dentreprises au Sri Lanka

X (valuation)
X (succs)
tudes de cas dentreprises chinoises
175
Auteur
(Law et al. 2010)
Liste de facteur
(risque ou succs)
Classification des
facteurs
Influence
entre
facteurs
Approches de
management
X (succs)
X (succs)
(Kop et al. 2011)
Questionnaire adress aux utilisateurs

finaux dans des entreprises espagnoles
X (nature)
(Lapiedra et al. 2011)

(Tsai et al. 2011)
(Dezdar and Ainin
2011)
(Aloini et al. 2012a)
X (valuation)
(Aloini et al. 2012b)
X (valuation)
X (succs)
X (succs)
X (succs)
(Tsai et al. 2012)
(Chang et al. 2012)

Retour dexprience dune compagnie
chinoise sur 2 projets ERP (1 chec et 1
succs)
X (succs)
(Rothenberger et al.
2010)
(Ifinedo 2011)
(Amid et al. 2012)
Limites un
sous-ensemble
de facteurs
Questionnaire adress des managers

iraniens
Enqute auprs de 5000 grosses entreprises
Taiwan
X (succs)
X (risque)
X (succs)
Revue de littrature et questionnaire

adress des industries iraniennes ayant
chou leur projet ERP
Revue de littrature et opinion dexperts
corens
176
Annexe E Sources des facteurs de risque et de succs
E. Sources des facteurs de risque et de succs
Facteur de risque
Gestion inadquate du
non-alignement
Dnomination facteur de risque et source

Complexit des processus supporter , Ampleur de
lcart dans les fonctionnalits , Ampleur de lcart dans
les extrants du systme , Spcificits du progiciel ,
Interdpendance des processus , Mauvaise adquation
culturelle avec lditeur , Problmatiques lies laudit
et au contrle
ERP system misfit (Wong and Scarbrough 2005)
Lack of organization transforms to t the ERP system,
Mist between organization culture and ERP system,
Mist between organization structure and ERP system,
Mists between the IT and business strategies Lack of a
performance measurement system, Scope creep (Amid
et al. 2012)
Dnomination facteur de succs et source

Software configuration Monitoring and feedback (Holland and Light
1999)
System did not mirror required processes (Wright and Wright 2001)
Organizational fit of ERP (Hong and Kim 2002b)
Organizational culture (Allen et al. 2002)
Performance evaluation and management (Al-Mashari et al. 2003)
Software conguration and institutionalization (Kumar et al. 2003)
Monitoring and evaluation of performance (Nah et al. 2003)
Focused performance measures (Umble et al. 2003)
Client organizational culture (Taylor 2005)
Alignment of the processes (Sun et al. 2005)
Organizational culture change (Zhang et al. 2005)
Degree to which an ERP system matches with the current users work
styles, habits, and practices, Extent of congruence between what is
provided by ERP systems and user task requirements (Holsapple et al.
2005)
Focuses performance measure, Post implementation audit (Motwani et
al. 2005)
Compatibility of ERP package with business requirement (Law and Ngai
2007)
Software configuration (Finney and Corbett 2007)
Alignment between business processes and ERP systems (Chou and
Chang 2008)
System configuration (Zhu et al. 2010)
Organizational fit (Zhu et al. 2010)
Organizational [fit] (Chang et al. 2012)
177
Facteur de risque
Manque dexpertise /
dimplication du comit de
pilotage

Manque dengagement de la haute direction (Bernard et
al. 2002b)
Poor top management support (Wong and Scarbrough
2005)
Low top management involvement (Aloini et al. 2007)
Top managers make important decision without consulting
IT experts and system users (Peng and Nunes 2009)
Top managers do not provide sufficient support (Peng
and Nunes 2009)
Top managers make important IT decisions without
consulting IT experts and system users (Singh et al. 2010)
Top managers do not provide sufficient support to ERP
post-implementation (Singh et al. 2010)
Poor top management support (Amid et al. 2012)

Top management support (Holland and Light 1999)
Top management support, China & Australia (Shanks et al. 2000)
Top management support, Australia (Shanks et al. 2000)
Top management commitment (Jarrar et al. 2000b)
Steering committee (Somers and Nelson 2001)
Support and commitment of the top managers (Somers and Nelson 2001)
Leadership (Al-Mashari et al. 2003)
Top management support (Nah et al. 2003)
Commitment by top management (Umble et al. 2003)
Top management support (Zhang et al. 2004; Ehie and Madsen 2005)
Commitment by top management (Motwani et al. 2005)
Top management support (Zhang et al. 2005)
Top management support (Chen et al. 2006) (Nah et al. 2007)
Support and commitment of managing director and senior executives
(Law and Ngai 2007)
Top management commitment and support (Finney and Corbett 2007)
Top management involvement (Jing et al. 2007)
Active steering committee, Project sponsor from top management
(Grabski and Leech 2007)
Top management support (Olson and Zhao 2007a) (Grabski and Leech
2007; Hakim and Hakim 2010)
Leadership involvement (Zhu et al. 2010)
Top management support (Dezdar and Ainin 2011)
178
Facteur de risque
Gestion de projet
inefficace

Lack of a proper management structure (Sumner 2000)
Lack of effective project management methodology
(Huang et al. 2004)
Ineffective project management techniques, Bad
managerial conduct (Aloini et al. 2007)
Unstable managerial positions, Poor project
management (Amid et al. 2012)

ERP strategy (Holland and Light 1999)
Project management, China (Shanks et al. 2000)
Project management, (Somers and Nelson 2001)
Management, Project management (Al-Mashari et al. 2003)
Excellent project management (Umble et al. 2003)
Project management (Nah et al. 2003)
Ongoing project management (Kumar et al. 2003)
Management style (Sheu et al. 2004)
Effective project management (Zhang et al. 2004)
Project management principles (Ehie and Madsen 2005)
Effective project management(Zhang et al. 2005)
Excellent project management (Motwani et al. 2005)
Project management (Chen et al. 2006)
Project management program (Nah et al. 2007)
Project management (Olson and Zhao 2007a) (Finney and Corbett 2007)
(Jing et al. 2007)
Improve project management (Zhang 2009)
Project management (Tsai et al. 2009d)
Implementation strategy (Malhotra and Temponi 2010)
Effective Project Management (Hakim and Hakim 2010)
Project management (Zhu et al. 2010)
Project management (Tsai et al. 2011)
179
Facteur de risque
Mauvaise constitution de
lquipe projet

Manque de clart dans la dfinition des rles (Bernard et
al. 2002b)
Manque de reprsentation inter-fonctionnelle au sein de
lquipe (Bernard et al. 2002b)
Manque dexpertise gnrale (Bernard et al. 2002b)
The composition of project team members (Huang et al.
2004)
Inappropriate staffing (Huang et al. 2004)
High turnover rate of project team members (Wong and
Scarbrough 2005)
Poor project team skills, Inadequate financial
management (Aloini et al. 2007)
Lack of a full time and balanced project team (Amid et
al. 2012)

Balanced project team, China (Shanks et al. 2000)
Balanced project team, Australia (Shanks et al. 2000)
Dedication resources, (Somers and Nelson 2001)
Project team constitution (Kumar et al. 2003)
ERP team work and composition (Nah et al. 2003)
Project team selection, Roles and responsibility (Sun et al. 2005)
A great implementation team (Motwani et al. 2005)
Knowledgeable project team (Grabski and Leech 2007)
Clearly dened roles and responsibilities in project organization (Law
and Ngai 2007)
Project team: the best and brightest, Balanced team (Finney and
Corbett 2007)
group structure (Jing et al. 2007)
Team work and composition (Nah et al. 2007)
The outstanding team (Chen and Ming 2008)
Efficient project management team (Zhang 2009)
Project Team Members and its composition (Hakim and Hakim 2010)
Team structure (Malhotra and Temponi 2010)
Team empowerment and cohesion (Rothenberger et al. 2010)
Project team competence (Wickramasinghe and Gunawardena 2010)
180
Facteur de risque
Manque dexpertise /
dimplication / rsistance
au changement des
utilisateurs finaux
Formation inadquate /
insuffisante des utilisateurs
finaux

Lack of end-users involvement (Wright and Wright 2001)
Manque dexprience et de support des utilisateurs
Fail to get user support (Huang et al. 2004)
Users resistance to change (Wong and Scarbrough
2005)
Unclear Concept of the Nature and Use of the ERP system
from the Users Perspective (Wong and Scarbrough 2005)
Operational staff are reluctant to use the system (Singh
et al. 2010)
High employees resistance to change, Inadequate
employee involvement, Lack of employees morale and
motivation, Lack of a process oriented vision among
employees (Amid et al. 2012)
Insufficient training of end-users (Sumner 2000)
Inadequate training and involvement of users (Wright
and Wright 2001)
Insufficient training of end-users (Huang et al. 2004)
Lack of training (Botta-Genoulaz and Millet 2005)
Inadequate training and instruction (Aloini et al. 2007)
Lack of sufficient and continuous training (Singh et al.
2010)
Inadequate education and training (Amid et al. 2012)

Client acceptance (Holland and Light 1999)
Resistance [caused by] political structures (Allen et al. 2002)
User acceptance (Kumar et al. 2003)
Involvement of all users (Deakins 2004)
User involvement, User characteristics (Zhang et al. 2005)
user involvement (Zhang et al. 2004; Olson and Zhao 2007a)
User involvement, Develop users' project ownership (Grabski and
Leech 2007)
Customer support (Chou and Chang 2008)
Support and participation (Law et al. 2010)
Support by System User (Hakim and Hakim 2010)
User cooperation (Chang et al. 2012)
User training on software, Education on new processes (Somers and

Nelson 2001)
Training and education (Al-Mashari et al. 2003)
Extensive education and training (Umble et al. 2003)
Training (Kumar et al. 2003)
Training (Amoako-Guyampah 2004)
Education and training (Zhang et al. 2004)
Education, training, skills development of people (Sun et al. 2005)
ERP employee training (Dowlatshahi 2005) (Zhang et al. 2005)
Education and training (Chen et al. 2006)
Training (Jing et al. 2007) (Grabski and Leech 2007)
Training and job redesign (Finney and Corbett 2007)
Training and education (Olson and Zhao 2007a)
Educational activities (Chou and Chang 2008)
Value the training of system (Chen and Ming 2008)
Providing sufficient training to end-users (Hakim and Hakim 2010)
Training and education (Dezdar and Ainin 2011)
181
Facteur de risque
Slection inadquate du
progiciel

Stabilit financire de lditeur , Manque dexprience
et dexpertise de lditeur avec les contrats de PGI ,
Manque de flexibilit du systme (capacit absorber les
changements futurs) (Bernard et al. 2002b)
Inadequate selection (Aloini et al. 2007)
Poor vendors (Amid et al. 2012)
Problmes techniques
Problmatiques techniques , Problmatiques lies

linstallation et la mise en opration (Bernard et al.
2002b)
Avoid technological bottleneck (Sumner 2000)
Capability of current enterprise technical infrastructure,
lack of integration between enterprise-wide system
(Huang et al. 2004)
Poor IT Infrastructure (Wong and Scarbrough 2005)
Inadequate IT system issue (Aloini et al. 2007)
Legacy systems are not compatible with new ERP system
(Peng and Nunes 2009)

Careful package selection (Somers and Nelson 2001)
Product/vendor selection (Kumar et al. 2003)
ERP package selection (Al-Mashari et al. 2003)
Suitable software (Zhang et al. 2004)
Under-estimation of the importance of the choice ERP (Botta-Genoulaz
and Millet 2005)
ERP package selection that best fits with current business procedures
(Motwani et al. 2005)
ERP vendor quality, System quality ERP software suitability
(Zhang et al. 2005)
Selection of ERP (Finney and Corbett 2007)
Level of the supplier of the ERP (Jing et al. 2007)
Software quality (Tsai et al. 2009b)
Sufcient information on ERP Vendors, Suitable Software(Hakim and
Hakim 2010)
System vendor (Tsai et al. 2011)
Enterprise resource planning selection (Tsai et al. 2012)
IT infrastructure (Jarrar et al. 2000b)
Architecture choices (Somers and Nelson 2001)
Technical infrastructure (Ghosh 2003)
Appropriate Business and IT legacy system (Nah et al. 2003)
Infrastructure (Kumar et al. 2003)
suitable hardware (Zhang et al. 2004)
Client- technical environment (Taylor 2005)
IT infrastructure (Ehie and Madsen 2005)
Technology (Sun et al. 2005)
IT infrastructure, Legacy system consideration [for technical changes
required] (Finney and Corbett 2007)
Technology being new, Suitable Hardware (Hakim and Hakim 2010)
Transition technique (Malhotra and Temponi 2010)
182
Facteur de risque
Gestion inadquate du
changement
organisationnel

Ampleur des changements apports par le systme
Inadequate change management (Aloini et al. 2007)
Lack of change management (Amid et al. 2012)
Gestion inadquate de la
conversion des donnes
Poor data conversion (Wright and Wright 2001)

tendue du changement apport aux donnes (Bernard
et al. 2002b)
Under-estimation of data-migration risk (Botta-Genoulaz
and Millet 2005)
Inadequacy legacy system management (Aloini et al.
2007)
Outdated and duplicated data is not properly managed
(Peng and Nunes 2009)
Human errors at the time of data entry (Singh et al.
2010)
Inaccurate data (Amid et al. 2012)

the amount of organizational change required (Holland and Light 1999)
Change management (Jarrar et al. 2000b)
Change management, Australia (Shanks et al. 2000)
Change management (Somers and Nelson 2001)
Cultural and structural changes (Al-Mashari et al. 2003)
Organizational change management (Umble et al. 2003)
Organizational change (Kumar et al. 2003)
Change management culture and program (Nah et al. 2003)
Argument for change (Amoako-Guyampah 2004)
Cultural and structural changes/ readiness (Motwani et al. 2005)
Change management and transition management (Grabski and Leech
2007)
Change management, Managing cultural change, Legacy system
consideration [for organizational changes required] (Finney and Corbett
2007)
Organizational culture and change (Olson and Zhao 2007a)
Identifying and understanding the changes required (Hakim and Hakim
2010)
Change management (Malhotra and Temponi 2010)
Data accuracy, China (Shanks et al. 2000)
Data analysis and conversion (Somers and Nelson 2001)
Data accuracy (Umble et al. 2003)
Complete validation/verication of data between old and new Systems
(Kumar et al. 2003)
Data accuracy (Zhang et al. 2004)
Data (Sun et al. 2005)
Importance of data accuracy (Motwani et al. 2005)
Information quality (Zhang et al. 2005)
Accuracy of data (Chen et al. 2006)
Data conversion and integrity (Finney and Corbett 2007)
Fine data (Chen and Ming 2008)
Database conversion (Malhotra and Temponi 2010)
183
Facteur de risque
Manque dexpertise /
dimplication / absence de

Lack of business analysts (Sumner 2000)
Ineffective consulting services (Aloini et al. 2007)
Lose qualified IT/ERP experts (Peng and Nunes 2009)
Poor consultants (Amid et al. 2012)
Instabilit
organisationnelle / manque
dexpertise / dimplication
de lentreprise
Manque dexprience et dexpertise de lorganisation

avec la gestion de contrats , Intensit des conflits ,
Niveau de coopration interdpartementale , Niveau de
centralisation verticale de la prise de dcision , Manque
dexpertise de lorganisation en technologies de
linformation (Bernard et al. 2002b)
Conflict between user departments (Huang et al. 2004)
Internal conicts among departments, Governmental
structure of the organization (Amid et al. 2012)

External expertise, China (Shanks et al. 2000)
Use of consultants (Somers and Nelson 2001)
Consulting service (Ehie and Madsen 2005)
External experts (Chen et al. 2006)
ERP skills of Consultant (Law and Ngai 2007)
Involvement of internal audit (Grabski and Leech 2007)
Consultants involvement (Grabski and Leech 2007)
Consultant selection (Finney and Corbett 2007)
External support (Olson and Zhao 2007a)
ERP experience of Consultant (Law and Ngai 2007)
Service quality provided by consultants (Tsai et al. 2009e)
Consultants capabilities in organizational re-engineering (Hakim and
Hakim 2010)
Use of available experts (Hakim and Hakim 2010)
Use of Business and Technology analysts (Hakim and Hakim 2010)
Consultants (Tsai et al. 2011)
Interdepartmental communication (Somers and Nelson 2001)
Government regulation (Sheu et al. 2004)
Governance equilibrium (Wang and Chen 2006)
Departments participation, Outsider competition pressure (Jing et al.
2007)
Internal support (Olson and Zhao 2007a)
company-wide support (Zhu et al. 2010)
Coordination among various Departments (Hakim and Hakim 2010)
Authority and status of IT leader, Internal management (Lapiedra et al.
2011)
Coordination (Chang et al. 2012)
Company-wide commitment (Zhang et al. 2005)
184
Facteur de risque
Gestion inadquate de
ladaptation de lERP
Communication inefficace
au sein de lquipe projet

Insufficient discipline and standardization, Lack of
integration (Sumner 2000)
Problmatiques lies lintgration et aux interfaces ,
Problmatiques lies aux modifications (Bernard et al.
2002b)
Over-reliance on heavy customization (Wong and
Scarbrough 2005)
Specific software development and too much
customization (Botta-Genoulaz and Millet 2005)
System is not properly modified to meet new business
requirements, Different modules of the ERP system are
not seamlessly integrated (Peng and Nunes 2009)
High rate of system customization (Amid et al. 2012)
Ineffective communications (Somers and Nelson 2001)
Lack of communication and implication of the
management (Botta-Genoulaz and Millet 2005)
Ineffective communication system (Aloini et al. 2007)

Minimal customization, Australia (Shanks et al. 2000)
Minimal customization (Somers and Nelson 2001)
Extent of customization (Kumar et al. 2003)
Minimum customization (Nah et al. 2003)
System integration (Al-Mashari et al. 2003)
Configuration over customization (Deakins 2004)
Customization (Taylor 2005)
Integration of the processes (Sun et al. 2005)
No or minimal customization (Finney and Corbett 2007)
Customization (Chou and Chang 2008)
Communication (Holland and Light 1999)

Communication and Organization (Wright and Wright 2001)
Frequent communication with customers and supplier (Kumar et al.
2003)
Organizational communication (Al-Mashari et al. 2003)
Communication (Nah et al. 2003) (Amoako-Guyampah 2004)
Open information and communication policy (Motwani et al. 2005)
Enterprise-wide communication (Nah et al. 2007)
Communication (Olson and Zhao 2007a)
Open and honest [inner] communication (Jing et al. 2007)
Communication plan (Finney and Corbett 2007)
Ineffective communication (Tsai et al. 2009c)
Communication and change (Wickramasinghe and Gunawardena 2010)
Communication and coordination (Law et al. 2010)
Enterprise-wide communication (Dezdar and Ainin 2011)
185
Facteur de risque
Problme avec le chef de
projet

Lack of senior management support (Sumner 2000)
Lack of a champion (Sumner 2000)
Lack of senior management commitment to project
(Huang et al. 2004)
Poor leadership (Aloini et al. 2007)
BPR inadquat ( Business

Process Reengineering )
Failure to redesign business process (Huang et al. 2004)

Lack of re-engineering before ERP project (BottaGenoulaz and Millet 2005)
Inadequate BPR (Aloini et al. 2007)
Poor business process reengineering (Amid et al. 2012)

Presence of a champion, Australia (Shanks et al. 2000)
Project team competence, Project champion (Somers and Nelson
2001)
Project manager selection (Kumar et al. 2003)
Project champion (Nah et al. 2003)
Project champion (Chen et al. 2006)
Commitment of senior management (Li et al. 2006)
Need for the project champion/ manager to nurture and maintain a high
level of employee morale and motivation during the project (Finney and
Corbett 2007)
Project champion (Olson and Zhao 2007a) (Finney and Corbett 2007)
The strong support from the top leader s project (Chen and Ming 2008)
The senior manager support degree (Chang et al. 2012)
Business Process Re- engineering (Jarrar et al. 2000b)
Business Process reengineering (Somers and Nelson 2001)
Process reengineering (Wright and Wright 2001)
BPR (Nah et al. 2003)
Business process reengineering (Ghosh 2003)
Business process reengineering (Zhang et al. 2004)
Process engineering (Deakins 2004)
Process re-engineering (Zhang et al. 2005)
Process re-engineering (Ehie and Madsen 2005)
Exhaustive analysis of current business processes (Motwani et al. 2005)
Process redesign (Sun et al. 2005)
Business Process reengineering (Grabski and Leech 2007) (Law and
Ngai 2007) (Olson and Zhao 2007a)
BPR (Finney and Corbett 2007)
Business Process reengineering (Zhang 2009)
186
Facteur de risque
Mauvaise planification

Too tight project schedule (Wong and Scarbrough 2005)
Lack of planning post go-alive (Botta-Genoulaz and
Millet 2005)
Lack of project planning (Law and Ngai 2007)
Mauvaise gestion des

ressources financires et
matrielles
Insuffisance des ressources (Bernard et al. 2002b)

Insufficient resource (Huang et al. 2004)
Budgets and funds assigned to ERP post-implementation
are insufficient (Peng and Nunes 2009)
Project cost overruns, Project delays (Amid et al.
2012)

Project schedule and plan (Holland and Light 1999)
Vision and planning (Al-Mashari et al. 2003)
Project planning (Kumar et al. 2003)
Workable plan (Deakins 2004)
Implementation time (Dowlatshahi 2005)
Detailed implementation plan , In-depth project planning (Grabski
and Leech 2007)
Vision and planning (Finney and Corbett 2007)
Strict monitoring of the project [to guarantee that the project fulfill in
time] (Chen and Ming 2008)
Implementation strategy (Law et al. 2010)
Project procedure time (Chang et al. 2012)
A great implementation team (Umble et al. 2003)
Cost/budget (Ehie and Madsen 2005)
Cost of ERP implementation (Dowlatshahi 2005)
Making resource available (Li et al. 2006) (Grabski and Leech
2007)(Grabski and Leech 2007)(Grabski and Leech 2007)(Grabski and
Leech 2007)(Grabski and Leech 2007)
Project cost planning and management, Funds support, Budget
overrun (Tsai et al. 2009c)
Sufficient resources (Hakim and Hakim 2010)
Cost (Chang et al. 2012)
187
Facteur de risque
Difficult de travail
commun entre lentreprise
et les membres externes
(intgrateurs et / ou
consultants)
Manque dexpertise /
dimplication des
utilisateurs cls

Failure to mix internal and external personnel (Sumner
2000)
Mauvaise adquation culturelle avec lintgrateur
Failure to mix internal and external expertise
methodology (Huang et al. 2004)
Poor knowledge transfer (Wong and Scarbrough 2005)
Conicts between organization and vendors (Amid et al.
2012)
Conicts between organization and consultants (Amid et
al. 2012)
Inability to obtain full-time commitment of customers to
project management and project activities (Sumner 2000)
Insufficient internal expertise (Sumner 2000)
Manque dexpertise de lquipe avec le systme et avec
les processus (Bernard et al. 2002b)
Manque dexpertise en implantation de PGI au sein de
lquipe (Bernard et al. 2002b)
Manque dengagement de lquipe de projet (Bernard et
al. 2002b)
Lack of appropriate experience of the user
representatives, The experience of inner expertise, The
ability of inner expertise (Huang et al. 2004)
Low key users involvement (Aloini et al. 2007)
Poor key users (Amid et al. 2012)

Vendor-customer partnership (Somers and Nelson 2001)
Knowledge transfer between consultants configuring the software and
university staff (Allen et al. 2002)
Relationship with ERP and a system integration partner (Allen et al.
2002)
Close working relationship between project team and consultants
(Grabski and Leech 2007)
Consultant relationship (Finney and Corbett 2007)
Cooperation between enterprise and software company (Jing et al. 2007)
Best people full-time, Australia (Shanks et al. 2000)

Project team competence (Somers and Nelson 2001)
Internal technical personnel resources (Sheu et al. 2004)
ERP skills of in-house staff (Law and Ngai 2007)
ERP experience of in-house staff (Law and Ngai 2007)
In-house computer / IT knowledge (Ifinedo 2011)
188
Facteur de risque
Manque dexpertise de
lintgrateur
Buts stratgiques mal

dfinis
Mauvaise expression des

besoins
Communication inefficace
entre lquipe projet et le
reste de lentreprise

Manque dexprience de lintgrateur avec les contrats de
PGI (Bernard et al. 2002b)
Manque dexprience et dexpertise de lditeur avec les
processus (Bernard et al. 2002b)
Manque dexprience de lintgrateur avec les
processus (Bernard et al. 2002b)
Lack of analysts with business and technology knowledge
(Huang et al. 2004)
Inadequate IT supplier stability and performances
Ineffective strategy thinking and planning (Aloini et al.
2007)
Not clearly dened strategic goals (Amid et al. 2012)
Unclear/misunderstand requirements, Changing

requirements (Huang et al. 2004)
Gap in the requirement definition (Botta-Genoulaz and
Millet 2005)
Unrealistic expectations from top management concerning
the ERP systems (Wong and Scarbrough 2005)
Unrealistic expectations (Amid et al. 2012)
Ineffective communications with users (Huang et al.
2004)
Ineffective communication with users (Amid et al. 2012)

Ongoing vendor support (Somers and Nelson 2001)
Vendor support (Zhang et al. 2004)
Vendor top management support (Taylor 2005)
Service of the supplier of the ERP (Jing et al. 2007)
Service quality provided by ERP system vendor (Tsai et al. 2009e)
Clear goals, China (Shanks et al. 2000)

Establishing clear goals and objectives (Somers and Nelson 2001)
Clear understanding of strategic goals (Umble et al. 2003)
Clear goals (Deakins 2004)
Clear understanding goals and objectives (Motwani et al. 2005)
Clearly identified objectives (Grabski and Leech 2007)
Unclear goals (Tsai et al. 2009c)
Stability of the objectives (Hakim and Hakim 2010)
Clarity of the business model (Holland and Light 1999)
Management of expectations (Somers and Nelson 2001)
Detailed requirements specification (Grabski and Leech 2007)
Reasonable expectation with definite target (Jing et al. 2007)
Communication as a political process (Allen et al. 2002)

Communication [between users-managers and end-users] (Nah et al.
2003)
Communication [with users] (Amoako-Guyampah 2004)
Documentation and advertising ERP success (Motwani et al. 2005)
Open and honest [outer] communication (Jing et al. 2007)
Frequent communication with users (Grabski and Leech 2007)
189
Facteur de risque
Ralisation inadquate des
tests

Poor quality of testing (Wong and Scarbrough 2005)

Systems testing (Al-Mashari et al. 2003)
Testing (Kumar et al. 2003)
Testing (Nah et al. 2003)
System testing prior to implementation (Grabski and Leech 2007)
System testing (Finney and Corbett 2007)
Mauvaise gestion des

risques
Poor risk management (Amid et al. 2012)
Haut degr de complexit

du progiciel
High system complexity (Amid et al. 2012)
Gestion inadquate de la
maintenance
Problmatiques lies la maintenance (Bernard et al.

2002b)
[adoption of] implementing methods to avoid risk (Zhu and Chen 2004)
On-going risk evaluation (Li et al. 2006)
Ways to manage risk (Grabski and Leech 2007)
Risk management (Malhotra and Temponi 2010)
Complexity (Taylor 2005)
Complex architecture and high number of implementation modules
Degree of complexity (Santamaria-Sanchez et al. 2010)
Trouble shooting (Holland and Light 1999)
Troubleshooting (Nah et al. 2003)
Maintenance and support strategy and focus (Law et al. 2010)
Difficult de gestion de
laspect multi-sites
Complexit organisationnelle et niveau de dispersion

gographique (Bernard et al. 2002b)
Multi-site issue (Umble et al. 2003)
190
Annexe F Rfrences des liens rsiduels
F. Rfrences des liens rsiduels
F1
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
F18
F19
F20
F21
F22
F23
F24
F25
F26
F27
F28
F29
F2
F3
1
16
F4
2
39
49
F5
3
17
F6
4
18
F7
5
F8
6
19
F9
7
20
40
50
55
56
F10
41
51
57
58
F11
8
42
52
F12
F13
9
21
F14
F15
10
22
31
37
F16
11
23
F18
13
25
43
44
45
61
62
63
67
71
75
84
91
78
79
66
80
F20
F21
F22
F23
F24
15
27
F25
F27
F28
28
29
35
30
36
47
48
34
38
46
F26
81
82
83
89
90
64
68
85
92
86
93
69
72
87
95
94
73
76
96
98
100
101
102
109
110
104
111
116
119
120
122
F29
54
60
70
77
F19
14
26
33
53
59
65
F17
12
24
32
105
112
103
106
113
114
117
107
74
88
97
99
108
115
118
121
123
124
125
126
127
128
129
191
1 : (Holland and Light 1999; Akkermans

and Van Helden 2002b; Umble et al. 2003;
Grabski and Leech 2007; Jing et al. 2007;
Peng 2009; Singh et al. 2010)
2 : (Nah et al. 2003)
3 : (Peng 2009)
4 : (Somers and Nelson 2001; Bueno and
Salmeron 2008)
5 : (Somers and Nelson 2001; Akkermans
and Van Helden 2002b; Grabski and Leech
2007)
6 : (Aloini et al. 2007; Grabski and Leech
2007; Peng 2009; Jarrar et al. 2010)
7 : (Holland and Light 1999; Akkermans
and Van Helden 2002b; Umble et al. 2003;
Grabski and Leech 2007; Jing et al. 2007;
Peng 2009; Singh et al. 2010)
8 : (Peng 2009)
9 : (Bueno and Salmeron 2008)
10 : (Umble et al. 2003; Singh et al. 2010)
13 : (Jarrar et al. 2010)
30 : (Akkermans and Van Helden 2002b)
14 : (Zhang et al. 2005)
31 : (Somers and Nelson 2001)
15 : (Singh et al. 2010)
16 : (Al-Mashari et al. 2003; Umble et al.

2003)
33 : (Peng 2009)
34 : (Shanks et al. 2000)
17 : (Al-Mashari et al. 2003)

35 : (Peng 2009)
19 : (Umble et al. 2003; Aloini et al. 2007)
20 : (Al-Mashari et al. 2003; Umble et al.
2003)
22 : (Velcu 2010)
23 : (Umble et al. 2003)
24 : (Aloini et al. 2007)
11 : (Shanks et al. 2000; Somers and

Nelson 2001; Akkermans and Van Helden
2002b; Ehie and Madsen 2005)
28 : (Al-Mashari et al. 2003; Aloini et al.

2007)
12 : (Shanks et al. 2000)
37 :(Sumner 2000; Somers and Nelson

2001; Nah et al. 2003; Aloini et al. 2007)
38 : (Somers and Nelson 2001; Umble et
al. 2003)
39 : (Tsai et al. 2009d)
43 : (Somers and Nelson 2001; Grabski
and Leech 2007; Peng and Nunes 2009)
192
46 : (Somers and Nelson 2001; Aloini et al.

2007)
63 : (Somers and Nelson 2001; Motwani et

al. 2005)
81 : (Huang et al. 2004)
64 : (Nah et al. 2003)
48 : (Law et al. 2010)
83 :(Somers and Nelson 2001; Umble et al.

2003)
84 : (Umble et al. 2003)
85 : (Jouffroy 2010)
68 :(Kumar et al. 2003)
86 : (Sumner 2000)
69 : (Kumar et al. 2003)
70 : (Umble et al. 2003)
88: (Akkermans and Van Helden 2002b)
71 : (Peng 2009)
89 : (Ewusi-Mensah 1997)
56 : (Nah et al. 2003; Aloini et al. 2007;

Grabski and Leech 2007)
73 : (Peng 2009)
82 : (Umble et al. 2003)
92 : (Umble et al. 2003)
57 : (Shanks et al. 2000; Somers and

Nelson 2001; Nah et al. 2003)
75 :(Morton and Hu 2008)
93 : (Umble et al. 2003)
58 : (Grabski and Leech 2007)
76 : (Law et al. 2010)
59 : (Nah et al. 2003; Aloini et al. 2007;

Grabski and Leech 2007)
77 : (Huang et al. 2004)
94 : (Somers and Nelson 2001; Umble et

al. 2003) + peng
60 : (Nah et al. 2003)

78 : (Huang et al. 2004)
79 : (Sumner 2000)
96 : (Somers and Nelson 2001; Aloini et al.

2007; Law et al. 2010)
80 : (Huang et al. 2004)
62 : (Malhotra and Temponi 2010)

193
98 : (Amoako-Guyampah 2004)
115 :(Somers and Nelson 2001)
100 : (Aloini et al. 2007)
119 : (Velcu 2010)
120: (Nah et al. 2003)
121 : (Nah et al. 2003)
106 :(Sumner 2000; Somers and Nelson

2001; Nah et al. 2003; Aloini et al. 2007)
107 : (Sumner 2000; Aloini et al. 2007)
124 : (Jarrar et al. 2000a; Somers and

Nelson 2001)
108 :(Sumner 2000; Nah et al. 2003)
125 : (Law et al. 2010)

111 : (Akkermans and Van Helden 2002b;
Umble et al. 2003)

128 : (Ojala et al. 2006)
112 : (Umble et al. 2003)

194
Annexe G Dtail des variables pour les facteurs de risque du RNA
G. Dtail des variables pour les facteurs de risque du RNA
F1 : Manque dimplication / dexpertise du comit de pilotage

-
Manque dimplication : le comit de pilotage ne prend pas suffisamment en main les

problmes rencontrs durant le projet, par exemple, en organisant des runions pour en
discuter (Aloini et al. 2007; Grabski and Leech 2007; Hakim and Hakim 2010).
Manque dexpertise des membres.
Manque de soutien ou support de la direction de lentreprise (Bernard et al. 2002b; Wong
and Scarbrough 2005).
Mauvaises prises de dcisions : le comit de pilotage ne sait pas prendre de bonnes
dcisions, notamment en consultant les experts mtier de lentreprise, les experts externes
ou les utilisateurs finaux (Singh et al. 2010).
Manque de participation la direction de lentreprise : elle ne participe pas suffisant au
comit de pilotage (Bernard et al. 2002b; Wong and Scarbrough 2005).

-
Pas dutilisation de mthodes de gestion de projet.

Pas dutilisation doutils de gestion de projet.
Mthodes de gestion de projet non adquates : les mthodes utilises ne sont pas les
bonnes (Somers and Nelson 2001; Motwani et al. 2005; Aloini et al. 2007).
Outils de gestion de projet non adquates : les outils utilises ne sont pas les bons (Somers
and Nelson 2001; Motwani et al. 2005; Aloini et al. 2007).
Utilisation inadquate des mthodes de gestion de projet : les mthodes sont mal utilises
(Somers and Nelson 2001; Motwani et al. 2005; Aloini et al. 2007).
Utilisation inadquate des outils de gestion de projet : les outils sont mal utilises (Somers
and Nelson 2001; Motwani et al. 2005; Aloini et al. 2007).
Pas de respect du planning : le planning fix nest pas respect par les membres du projet.

-
Rpartition inadquate des rles et responsabilits : les rles et responsabilits des

membres de lquipe ont t mal rparties au sein de lquipe projet (Sun et al. 2005; Law
and Ngai 2007).
Comptences non quilibres : il ny a pas dquilibre au niveau des comptences interfonctionnelles ou au niveau des comptences techniques vs. comptences mtiers au sein
de lquipe projet (Bernard et al. 2002b; Kumar et al. 2003; Huang et al. 2004; Aloini et
al. 2007; Hakim and Hakim 2010; Malhotra and Temponi 2010).
Turnover des membres : les membres de lquipe ne sont pas stables et abandonnent leur
poste au cours du projet (Wong and Scarbrough 2005), pas de remplaants identifis
(Tomas 1999).
Nombre insuffisant de membres : le nombre de membres constituant lquipe a t mal
estim (Bernard et al. 2002b; Hakim and Hakim 2010).
195

-
Pas dapport dexpertise pour lentreprise : les consultants napportent pas une expertise
complmentaire lexpertise dj prsente au sein de lentreprise (Ewusi-Mensah 1997;
Grabski and Leech 2007).
Manque dimplication : les consultants externes ne suivent pas lvolution du projet de
prs et ne sen tiennent pas informs (Sumner 2000).
Manque dexpertise mtier : les consultants externes nont pas une bonne connaissance
des processus de lentreprise (Grabski and Leech 2007).
Manque dexprience : les consultants nont pas dexprience de projets dimplantation
similaires (Ewusi-Mensah 1997; Aloini et al. 2007; Grabski and Leech 2007) ou dun
domaine dactivits similaire lentreprise cliente (Ewusi-Mensah 1997; Somers and
Nelson 2001).
Manque de comptences techniques : les consultants externes nont pas une bonne
connaissance des modules de lERP qui sont mis en place (Somers and Nelson 2001;
Aloini et al. 2007) et / ou des aspects techniques de lERP (Aloini et al. 2007).
Pas de consultants externes : il ny a pas de consultant externe qui accompagne les
membres de lquipe de projet.

-
Pas de chef de projet : lentreprise na pas nomm de chef au projet.

Mauvais fdrateur : le chef de projet ne parvient pas contrler le comportement gnral,
contrler lesprit dquipe (Grabski and Leech 2007).
Pas dautorit : le chef de projet na pas dascendant sur les autres membres du projet, il
ne se fait pas couter (Somers and Nelson 2001; Umble et al. 2003; Law and Ngai 2007)
Manque de disponibilit : le chef de projet nest pas plein temps sur le projet, na pas t
ddi au pilotage du projet (19439 2006).
Pas de volont de russite : le chef de projet ne montre pas dengagement fort pour le
succs du projet (Somers and Nelson 2001; Umble et al. 2003; Huang et al. 2004;
Motwani et al. 2005; Law and Ngai 2007). Par exemple, il ne supporte pas suffisamment
laccomplissement des objectifs du projet (Sumner 2000).
Manque de participation : le chef de projet ne participe pas suffisamment au projet ERP
(Huang et al. 2004) notamment aux runions hebdomadaires.
Manque dimplication : le chef de projet norganise pas de runions rgulires
davancement du projet (Huang et al. 2004) pour rsoudre les problmes ou donner une
direction lquipe projet pour rsoudre ces problmes (Aloini et al. 2007).
Mauvais planificateur : le chef de projet narrive pas prvoir les tapes futures du projet.
Ainsi, il ne parvient pas planifier correctement le projet et en avoir une vision long
terme (Huang et al. 2004; Aloini et al. 2007)
Travail dlgu : le chef de projet dlgue le suivi de la progression du projet et les
dcisions aux consultants externes et aux intgrateurs (Ewusi-Mensah 1997; Somers and
Nelson 2001).
Manque de comptences mtiers (Somers and Nelson 2001; Umble et al. 2003).
Manque de comptences techniques (Somers and Nelson 2001; Umble et al. 2003).
196

-
Planning non raliste : les dlais fixs sont trop serrs (Umble et al. 2003; Wong and
Scarbrough 2005).
Pas de prise en compte de la prcdence des activits : la squentialit des activits nest
pas maitrise (Umble et al. 2003; Wong and Scarbrough 2005).
Planning incompatible : le planning est incompatible avec les plannings des autres projets
de lentreprise.
F9 : Mauvaise gestion ressources financires et matrielles

-
Estimation inadquate des ressources financires : lestimation des cots de lensemble du

cycle de vie du projet a t mal ralis (Bernard et al. 2002b; Aloini et al. 2007; Peng and
Nunes 2009; Hakim and Hakim 2010).
Rpartition inadquate des ressources financires : le budget pour chaque tape du cycle a
t mal rparti (Ehie and Madsen 2005).
Pas de libration des ressources matrielles : les ressources matrielles nont pas t
libres pour les mettre la disposition de lquipe projet, tels que les salles de runions,
les ordinateurs etc.
F10 : Difficult de travail commun entre lentreprise et les membres externes

-
Cultures diffrentes : lintgrateur et le client sont localiss dans deux pays culturellement
diffrents, do des modes dorganisation du travail et de fonctionnement diffrents. Cela
peut se matrialiser, par exemple, par des rapports diffrents lautorit dune manire
gnrale, ou encore par une diffrence dans lorganisation de la journe concernant, par
exemple, le droulement des runions ou mme les pauses djeuners ou caf.
Mthodologies de travail diffrentes : lintgrateur et le client ont des mthodologies de
travail diffrentes (Somers and Nelson 2001).
Dsaccords entre les membres de lquipe intgratrice : lquipe qui intgre le systme na
pas le soutien de son chef (Taylor 2005). Il ne la soutient pas, par exemple, lors de conflits
avec lentreprise cliente. Cette mauvaise symbiose au sein de lintgrateur peut se
matrialiser notamment par une qualit de service faible pour lentreprise.
F11 : Manque dexpertise / dimplication des utilisateurs cls

-
Manque dexpertise mtier : les utilisateurs cls prsentent un manque de connaissance

concernant les processus mtier de leur propre service (Somers and Nelson 2001; Umble
et al. 2003).
Manque de comptences dans la gestion de projet : les utilisateurs cls nont pas les
comptences requises (Ewusi-Mensah 1997; Aloini et al. 2007; Law et al. 2010) pour la
gestion de projet. Par exemple, ils ne savent pas animer les runions de projet qui peuvent
se solder par de fortes pressions sur les responsabilits de chacun (Umble et al. 2003).
Manque de prsence : les utilisateurs cls ne simpliquent pas suffisamment dans le
quotidien du projet. Ils ne se montrent pas disponibles (Umble et al. 2003; Aloini et al.
2007) dans le sens o, par exemple, ils ne participent pas suffisamment aux runions, ils
narrivent pas se dgager de leurs tches quotidiennes, ils ne font pas deffort pour
comprendre le travail qui leur ai demand et limportance de mettre en place un nouvel
ERP.
Travail non fait : les utilisateurs cls ne font pas le travail qui leur est demand (Aloini et
al. 2007).
197
Peu de confiance en soi : les utilisateurs cls ne se sentent pas suffisamment en confiance
et ce notamment dans la ralisation des tches qui leur sont confies dans le cadre du
projet. (Aloini et al. 2007) donnent lexemple de la tche consistant transfrer les
comptences acquises durant le projet aux utilisateurs finaux (Aloini et al. 2007).
Manque de comptences techniques : les utilisateurs cls ont peu ou pas russi gagner en
comptences techniques concernant les modules de lERP (Sumner 2000).

-
Manque dexpertise : lquipe dintgration ne dtient pas lexpertise souhaite par

lentreprise notamment pour comprendre leurs besoins (Ewusi-Mensah 1997; Sumner
2000; Law et al. 2010).
Manque dexprience : les intgrateurs nont pas suffisamment dexprience notamment
dans le type lindustrie de lentreprise cliente - agroalimentaire, pharmaceutique, du
btiment etc. (Ewusi-Mensah 1997).
Mauvaise gestion de projet : lintgrateur ne grent pas correctement les membres de
lquipe ; les runions de travail ne sont pas suffisamment prpares.

-
Pas de processus de gestion du risque (Ewusi-Mensah 1997; Somers and Nelson 2001;
Aloini et al. 2007; Grabski and Leech 2007; Malhotra and Temponi 2010).
Processus de gestion du risque partiel : le processus de gestion des risques a t
partiellement mis en place (Ewusi-Mensah 1997; Somers and Nelson 2001; Aloini et al.
2007; Grabski and Leech 2007; Malhotra and Temponi 2010).
Processus de gestion du risque non maitris : les tapes ou leur enchainement ne sont pas
respects.
Outils de gestion des risques mal utiliss ou inexistants : les outils utiliss pour mettre en
uvre les tapes du processus de gestion des risques sont mal utiliss.
F15 : BPR inadquat

-
BPR inexistant : aucune rflexion sur la pertinence ou la refonte des processus

dentreprise (Botta-Genoulaz et al. 2001).
Echec dans la redfinition des processus : les processus ont t mal redfinis (Huang et al.
2004).
Redfinition incomplte : la redfinition na pas pris en compte tous les processus de
lentreprise ncessitant un Rengineering (Amid et al. 2012) (Motwani et al. 2005).
F16 : Buts stratgiques mal dfinis

-
Dsaccord sur les buts : il y a un dsaccord sur lensemble des buts stratgiques de mise
en place du nouvel ERP (Ewusi-Mensah 1997).
Flou sur les buts : les buts ne sont pas clairs, ils nindiquent pas clairement la direction
gnrale du projet (Somers and Nelson 2001; Umble et al. 2003).
Non prise en compte de la raison de changer de S.I. : la dfinition des buts stratgiques de
lentreprise ne prend pas clairement en compte les raisons conduisant lentreprise
implanter un ERP (Umble et al. 2003).
F17a : Mauvaise expression des besoins
198
Besoins exprims faux : les besoins de lentreprise qui sont exprims ne correspondent pas
aux besoins rels.
Besoins exprims incomplets : les besoins exprims sont incomplets (Baccarini et al.
2004).
comprhensibles (Huang et al. 2004) par les intgrateurs et les consultants externes.
Pas de formalisation des besoins de haut niveau.
lentreprise est ralise sans se baser sur les problmes rencontrs dans lexistant de
lentreprise.
Besoins exprims non stabiliss (Huang et al. 2004).
Niveau de granularit non adquat : les besoins formuls pour la slection du progiciel
sont trop peu dtaills ou linverse, sont trop dtaills (Tomas 1999).
Mauvaise de prise en compte du primtre fonctionnel : la modlisation des processus
pour la slection du progiciel na pas pris en compte lensemble le primtre fonctionnel
adquat (Tomas 1999).
Manque de formalisme dans lexpression des besoins : pas dutilisation de langage de
modlisation pour la formalisation

-
Besoins exprims faux : les besoins de lentreprise qui sont exprims ne correspondent pas
aux besoins rels.
Besoins exprims non stabiliss : les besoins exprims changent tout au long du projet
(Huang et al. 2004).
Besoins exprims incomplets : les besoins exprims sont incomplets (Baccarini et al.
2004).
comprhensibles (Huang et al. 2004) par les intgrateurs et les consultants externes.
Pas de formalisation des besoins dtaills.
lentreprise est ralise sans se baser sur les problmes rencontrs dans lexistant de
lentreprise.
Manque de formalisme dans lexpression des besoins : pas dutilisation de langage de
modlisation pour la formalisation

-
Pas de slection en fonction du budget : la slection du progiciel na pas t ralise en

adquation avec le budget de lentreprise (Somers and Nelson 2001; Motwani et al. 2005).
Pas de slection en fonction des dlais : la slection du progiciel na pas t ralise en
adquation avec les dlais que lentreprise sest fixs (Somers and Nelson 2001; Motwani
et al. 2005).
Pas de slection en fonction de laspect fonctionnel : la slection du progiciel na pas t
ralise en fonction dune analyse de la couverture fonctionnelle de lERP par rapport aux
besoins fonctionnels de lentreprise (Somers and Nelson 2001; Motwani et al. 2005).
199
Pas de slection en fonction des aspects techniques : il ny a pas eu, avant la slection,
dvaluation des aspects techniques tels que : portabilit, modularit, flexibilit, scurit,
ergonomie, (Aloini et al. 2007).
Pas de slection en fonction du fournisseur : le progiciel na pas t choisi en fonction de
lexpertise ou encore de la rputation du fournisseur (Zhang et al. 2005; Tsai et al. 2009b;
Tsai et al. 2011; Amid et al. 2012).
Qualit de service du fournisseur : la comptition entre les diffrentes quipes internes au
fournisseur notamment lors du dveloppement de nouvelles versions du progiciel (Taylor
2005).

-
Diffrence de cultures : la culture lie aux fonctionnalits de lERP qui est mis en place
est trop loigne de la culture de lentreprise (Taylor 2005; Morton and Hu 2008).
Manque de modlisation des processus souhaits : les processus souhaits par lentreprise
pour lesquels il est ncessaire didentifier le non-alignement potentiel avec les processus
standards de lERP ne sont pas modliss avec minutie.
Pas de formalisation des fonctionnalits standards de lERP : les fonctionnalits standard
ne sont formalises laide dun langage de modlisation.
Mauvaise gestion des runions dadquation : ce qui doit tre confront nest pas tabli
lavance ; ce qui a t tabli nest pas respect.
Pression sur la prise de dcision : les dcisions sont prises sous pression car il y a des
tensions entre les membres de lentreprise et lintgrateur.
Dcisions prises la lgre : les personnes responsables de la prise de dcision relative
aux processus mettre sous contrle de lERP ne ralisent pas limportance de cette prise
dcision.
Pas de prise en compte de lintgrit de lintgration : lordre de mise en place des
modules et les dcisions concernant ces modules nont pas tenu compte de lintgrit de
leur intgration (Aloini et al. 2007) (Sumner 2000). Linterdpendance entre processus
que ce soit au sein dun module ou entre diffrents modules (partage dinformation, de
ressources acteurs etc.) nest pas pris en compte dans la prise de dcision face au nonalignement (Bernard et al. 2002b).
F20 : Gestion inadquate de ladaptation de lERP

-
Pas danalyse de la ncessit dadapter en fonction de lintrt de lentreprise : il ny a pas

eu danalyse de lintrt dadapter lERP versus dadopter les processus standards de
lERP en termes, par exemple, de relation avec ses clients, defficacit etc. (Somers and
Nelson 2001; Hong and Kim 2002a; Morton and Hu 2008).
Pas danalyse des cots dadaptation : la prise de dcision dadapter lERP ne prend en
compte les cots engendrs (Somers and Nelson 2001; Wright and Wright 2001).
Pas de gestion de lintgrit de lintgration : limpact de ladaptation de lERP sur
lintgrit de son intgration na pas t gr (Hong and Kim 2002a; Taylor 2005).

-
Pas destimation de la complexit des modules : lentreprise na pas estim la complexit

des modules mettre en place. En effet, cette complexit est analyser et relativiser en
fonction des modules mis en place. Ainsi, les modules dit value-chain modules tels que
les modules de production et de distribution sont plus complexes implanter que les
200
modules dits business-support modules tels que les modules de comptabilit et de

gestion des ressources humaines (Santamaria-Sanchez et al. 2010).
Pas de prise en compte de la complexit des modules : la complexit des modules na pas
t prise en compte dans leur mise en place.
201
Annexe H Confrontation des processus associs aux buts non satisfaits par lERP
H. Confrontation des processus associs aux buts non

satisfaits par lERP
Processus associ au but Achieve Qualit traite
Figure A- 2- Vue fonctionnelle associe au but Achieve Qualit Traite

AS-WISHED,
sortie
AS-WISHED,
sortie
Vues dobjet
FicheQualit saisie
(1)
FicheQualit saisie
(2)
Attributs
idFicheQualit, idDemande, idProduit dsignationProduit, contact,
date
descriptionProblme, quantitPicesfAffectes, dfautToutProduit
(oui / non), dfautPdtMemeFamille (oui / non), causeHumaine,
causeMatire, causeMachine, pbMaintenance (oui / non),
pbProcessusFab (oui, non), quand, pourquoi
dtectionProcessusFab (oui / non), dtectionPrduitFini (oui / non),
dtectionAvtExpdition (oui / non), raisonNonDtection
dtectionProcessusFab (oui / non), dtectionPrduitFini (oui / non),
dtectionAvtExpdition (oui / non)
repragePicesOk
(oui
/
non),
actionsStockEnCours,
actionsStockMagasin, actionsAutresStocks
dtectionProcessusFab (oui / non)
AS-WISHED,
FicheQualit saisie
sortie
(3)
AS-WISHED,
FicheQualit
entre
AS-WISHED,
FicheQualit saisie
sortie
(4)
AS-WISHED,
FicheQualit
entre
AS-WISHED,
FicheQualit saisie actionsProcessusFab, actionsMachine
sortie
(5)
Tableau A- 1 - Attributs des vues dobjets pour le processus associ au but Achieve Qualit traite
Les activits du processus associ ce but ne sont prsentes dans aucune des versions
Vintgrateur et Ventreprise du modle TO-BE. Il nest donc pas support par le S.I. base dERP.
202
Nous ne le modlisons pas dans le modle TO-BE fonctionnel. Par contre, la dcision prise a
t le support manuel (D4) du processus. Lexistant a influenc cette dcision, puisque
cela est dj le cas dans lexistant. Linterview du PDG de la socit nous a confirm que
cette dcision a t prise inconsciemment.
Compte tenu de cette dcision prise, cela nous amne conseiller un complment la
conduite de changement (D6) pour faire face au non-support par le S.I ERP du processus
souhait.
Il aurait t possible deffectuer un dveloppement spcifique dans lERP (D4) en ajoutant
du code au code source de lERP. Cela aurait permis de crer un nouvel objet dentreprise
pour la fiche qualit et de modifier lcran par lajout dun nouvel onglet. Celui-ci aurait
permis lutilisateur de saisir les informations concernant cette fiche - que ce soit concernant
les informations de dtection des problmes ou de plan daction immdiate ou dfinitive.
Egalement, des Workflows - avertissement par mail, par exemple - auraient pu tre mis en
place afin davertir les services concerns des actions qui leurs sont attribues. Par exemple,
loprateur aurait t averti dun produit dfectueux dans le magasin. Nous aurions galement
conseill lassociation de cette dcision celle de complment la conduite de
changement (D6) pour mettre jour la documentation associe ces dveloppements
spcifiques.
La dcision deffectuer un dveloppement spcifique au niveau du code source de lERP est
coteuse et peut perturber lintgrit de lintgration de lERP dautant plus quil sagit l de
plusieurs attributs. Cependant, cela aurait pu reprsenter un intrt pour lentreprise. Le
processus manuel de ce processus entrane une absence de traabilit notamment concernant
les ventuelles modifications des processus de production ou de maintenance. Ainsi, sans
historique, lerreur pourrait donc se reproduire. Cela occasionne une perte de temps tant au
niveau de la saisie de linformation qu celui de lavertissement des services concerns.
203
Achieve accord obtenu
Figure A- 3- Vue fonctionnelle associe au but Achieve Accord obtenu

AS-WISHED,
entre
AS-WISHED,
sortie
Vues dobjet
RapportExpertise
Attributs
responsable (facturable / garantie)
Devis saisi
idDevis, sav (oui / non), pices, quantitPice, activits,

dureActivits, transport, coutPrvuPices, coutPrvuActivits,
coutTransport
Tableau A- 2 - Attributs des vues dobjets pour le processus associ au but Achieve Accord obtenu
Les activits associes ce processus ne sont prsentes dans aucune des versions du modle
TO-BE. Laccord dun client pour une ventuelle dpense de sa part est gnralement faite via
le devis. Ainsi, il a t dcid de supporter ce processus via lutilisation du devis sans le faire
au titre dune demande SAV. Ce processus est donc modlis dans le modle TO-BE
fonctionnel mais sans lattribut sav pour la vue dobjet Devis . Cette dcision a t
prise inconsciemment. De mme, lobjet en entre RapportExpertise nest pas modlis
car il na pas t implant au sein de lERP lors de la confrontation du processus associ au
but Achieve Responsabilit identifie .
204
Achieve Demande SAV analyses
Figure A- 4- Vue fonctionnelle associe au but Achieve Demandes analyses

Vues dobjet
Attributs
AS-WISHED,
marge saisie
idMarge, dateDbutCalcul, dateFinCalcul
sortie
AS-WISHED,
Consommations
idConsommation, dateEffectue, quantitRelle,
entre
montantConsomm,
AS-WISHED,
Facture
idFacture, sav (oui / non), montantFacture, dateFacture
entre
AS-WISHED,
marge
dateDbutCalcul, dateFinCalcul
entre
AS-WISHED,
Marge calcule
Marge, dateCalcul
sortie
Tableau A- 3 - Attributs des vues dobjets pour le processus associ au but Achieve Demande SAV
analyse
TO-BE. La dcision d abandon (D5) a t prise inconsciemment. Cela nous amne
conseiller, conjointement un complment la conduite de changement (D6) pour faire
face cet abandon. Ce processus nest donc pas modlis dans le modle TO-BE fonctionnel.
Nous sommes, ici, en prsence de loccurrence du rsultat indsirable associ au RNA. La
dcision deffectuer un dveloppement spcifique dans lERP (D2) aurait pu tre prise.
Lobjet Marge avec ses attributs aurait t ajout. Cette dcision aurait engendr des cots
pour lentreprise et une perturbation potentielle de lintgrit de lintgration de lERP.
Cependant, calculer les marges ralises grce aux demandes SAV aurait permis davoir une
meilleure visibilit analytique. Nous aurions galement conseill lassociation de cette
205
Maintain Intervention lheure
Figure A- 5- Vue fonctionnelle associe au but Maintain Intervention lheure

Vues dobjet
Attributs
AS-WISHED,
PlanningIntervention
actions, dateActions
sortie
modifi
AS-WISHED,
PlanningIntervenant
sortie
modifi
Tableau A- 4 - Attributs des vues dobjets pour le processus associ au but Maintain Intervention
lheure
TO-BE. Le support manuel (D4) du processus a t choisi inconsciemment. Le processus
nest pas modlis dans le modle TO-BE fonctionnel. Do la dcision conjointe dun
complment la conduite de changement (D6) pour faire face au non-support par le S.I
ERP du processus souhait.
Un dveloppement spcifique dans lERP (D2) aurait t possible par lajout de lignes de
codes. Plus exactement, cela aurait consist identifier automatiquement le dcalage dune
intervention en retard par lexcution du processus de rservation de ressources. Egalement,
un Workflow aurait pu tre mis en place - une alerte mail, par exemple - pour avertir le
responsable du dcalage ventuel. Ce dveloppement spcifique est coteux et pourrait
perturber lintgrit de lintgration de lERP. Lintrt pour lentreprise aurait t dtre plus
efficace. Ne pas identifier un retard peut engendrer des erreurs de planning et modifier le
planning gnral des interventions. Nous aurions galement conseill lassociation de cette
206
Achieve Commande achat envoye
Figure A- 6- Vue fonctionnelle associe au but Achieve Commande achat envoye

Vues dobjet
CommandeAchat
saisie
Attributs
AS-WISHED,
idCommande, sav (oui / non)
sortie
....
..... : attributs dune commande dachat standard
Tableau A- 5 - Attributs des vues dobjets pour le processus associ au but Achieve Commande achat
envoye
Les activits associes ce processus sont prsentes dans la version Vintgrateur mais pas la
version Ventreprise du modle TO-BE. La mise en place de ce processus a ncessit deffectuer
un dveloppement spcifique dans lERP (D2) par lajout de lattribut sav lobjet
CommandeAchat . Cet attribut peut prendre les valeurs oui ou non permettant donc
de faire le lien avec la commande SAV. Ce processus est donc modlis dans le modle TOBE fonctionnel. Cette dcision nous conduiyt prconiser conjointement un complment
la conduite de changement (D6) pour mettre jour la documentation relative ce
dveloppement spcifique.
207
Annexe I Confrontation des processus associs aux buts quivalents
I. Confrontation des processus associs aux buts quivalents
Figure A- 7- Vue fonctionnelle du modle AS-WISHED confront pour le processus associ au but
Figure A- 8- Vue fonctionnelle du modle MIGHT-BE confront pour le processus associ au but
AS-WISHED,
sortie
MIGHT-BE,
sortie
Objets
Facture cre
Attributs
idFacture, sav (Oui / Non)
...
.... : attributs facture standard
Facture cre
idFacture
...
.... : attributs facture standard
Tableau A- 6 - Attributs des vues dobjets pour les processus associs au but Achieve Facture envoye
des modles AS-WISHED et MIGHT-BE
Dans le modle AS-WISHED, lactivit transformer la commande client en facture est

marque en vert car un refus du client implique que lintervention na pas lieu et quil ny
a donc pas de facturation.
208
Activits
La premire activit est aligne, nous confrontons ses entres / sorties.
La deuxime activit est aligne mais elle na pas dentres / sorties.
Entres / sorties
Lobjet dentreprise MailAccord en entre de lactivit transformer la commande client
en facture est uniquement prsent dans le modle AS-WISHED. Cela fait ressortir
lexistence dun nud de dcision non dcompos. Lactivit nest excute que si le mail
concernant laccord du client a t reu suite ltablissement du devis. Ce dernier processus
a t implant. Ainsi, il nest pas utile de confronter lobjet MailAccord .
Un attribut en sortie est align : idFacture . Il est prsent dans les versions Vintgrateur et
Ventreprise du modle TO-BE. Il a donc t paramtr en toute connaissance de cause. Nous le
modlisons dans le modle TO-BE fonctionnel.
Un attribut en sortie est non-satisfait : sav . Il nest prsent dans aucune des versions du
modle TO-BE. Il a t abandonn (D5) inconsciemment par lentreprise. Un complment
la conduite de changement (D6) est ncessaire pour faire face cet abandon.
209
AS-WISHED,
sortie
Objets
CommandeClient
saisie
MIGHT-BE,
sortie
CommandeClient
saisie
Attributs
idCommande, sav (Oui / Non)
...
.... : attributs commande standard
idCommande
...
.... : attributs commande standard
Tableau A- 7 - Attributs des vues dobjets pour les processus associs au but Achieve Commande
enregistre des modles AS-WISHED et MIGHT-BE
Activits
La premire activit est aligne, nous confrontons ses entres / sorties.
La deuxime activit est aligne mais la vue dobjet en sortie na pas dattributs, elle est
uniquement enregistre activit atomique denregistrement.
Entres / sorties
Un attribut en sortie est align : idCommande . Il est prsent dans les versions Vintgrateur et
Ventreprise du modle TO-BE. Il a donc t paramtr en toute connaissance de cause. Nous le
modlisons dans le modle TO-BE fonctionnel.
Un attribut en sortie est non-satisfait : sav . Il a fait lobjet dun dveloppement spcifique.
Un attribut a t ajout lobjet Commande et lcran a t modifi par lajout dun
champ permettant de prciser si la commande cre est lie ou non une demande SAV. Cet
attribut nest prsent que dans la version Vintgrateur du modle TO-BE. La dcision a t prise
inconsciemment et nous modlisons lattribut dans le modle TO-BE fonctionnel. De plus, un
complment la conduite de changement (D6) afin de mettre jour la documentation
relative ces dveloppements spcifiques est prconis.
210
AS-WISHED,
sortie
MIGHT-BE,
sortie
Objets
ContratService saisi
Attributs
idContratSe, idProduit, prestationsPrdfines,
conditionsFacturation, tarif, prolongation (oui, / non),
priodicitIntervention
ContratService saisi
idContrat, type (service), idProduit, numClient, nomClient,

interlocuteur, dateSouscription, dateFin, pravisRsiliation,
frquenceRenouvellement, renouvellementTacite (oui / non),
frquenceRvaluation, mthodeRvaluation,
supportRvaluation, frquenceFacturation, mthodeFacturation,
pravisFacturation, conditionPaiement, litigesAccepts,
tiersPayeur, rgimeTaxe, clauses
Tableau A- 8 - Attributs des vues dobjets pour les processus associs au but Achieve Contrat service
cr des modles AS-WISHED et MIGHT-BE
211
Il ny a rien concernant les contrats de service dans la version Ventreprise du modle TO-BE
fournie par lentreprise. Cela signifie que toutes les dcisions prises pour ce processus ont t
prises inconsciemment.
Activits
La premire activit est aligne. La vue dobjet en sortie na pas dattributs, elle est
uniquement cr - activit atomique de cration.
La deuxime activit est aligne, nous confrontons ses entres / sorties.
Pour la troisime activit, qui est enregistre, il en est de mme que la premire.
Entres / sorties
Un attribut est non-satisfait : periodicitIntervention . Comme lindique la version
Vintgrateur du modle TO-BE, il a t dcid deffectuer un dveloppement spcifique dans
lERP (D2). En effet, un attribut supplmentaire lobjet dentreprise ContratService a
t ajout. Cet ajout sest accompagn de la modification de lcran par lajout dune liste
droulante permettant de choisir entre diffrentes priodicits de gnration automatique des
demandes de service au titre de la garantie en mois, annes, etc. Nous conseillons, prsent,
lentreprise lassociation de cette dcision celle de complment la conduite de
changement (D6) afin de mettre jour la documentation relative ce dveloppement
spcifique.
5 attributs sont aligns : prestationsPrdfines et tarif du modle AS-WISHED aligns
lattribut clauses du modle MIGHT-BE. Ils ont en effet le mme sens. Les attributs
prolongation et periodicitRenouvellement sont aussi considrs comme aligns. Il en
est de mme pour les attributs type et idContrat aligns idContratSe ; et pour
idProduit align idProduit . Le jugement de lexpert du domaine fonctionnel est ici
important afin de dterminer cette quivalence. Ils sont tous prsents dans la version Vintgrateur
du modle TO-BE. Ils sont tous paramtrs.
17 dattributs ont t dcouverts : numClient , nomClient , interlocuteur ,
dateSouscription ,
dateFin ,
pravisRsiliation ,
renouvellementTacite ,
frquenceRvaluation ,
mthodeRvaluation ,
supportRvaluation ,
frquenceFacturation ,
mthodeFacturation ,
pravisFacturation ,
conditionPaiement , litigesAccepts , tiersPayeur , rgimeTaxe . Ils sont tous
prsents dans la version Vintgrateur du modle TO-BE et ont donc tous t paramtrs. Nous
conseillons, prsent, lentreprise de prendre la dcision dun complment la conduite
de changement (D6) pour organiser, notamment, un complment de formation sur
lensemble de ces nouveaux concepts.
Le modle TO-BE fonctionnel est mis jour avec ces 3 activits et 23 attributs.
212
Achieve Intervention Planifie
Achieve Intervention Planifie
213
AS-WISHED,
sortie
AS-WISHED,
sortie
AS-WISHED,
sortie
AS-WISHED,
sortie
MIGHT-BE,
sortie
MIGHT-BE,
sortie
Objets
PlanningIntervenant
saisi
PlanningIntervention
saisi
Intervention saisie
OrdreMission gnr
Attributs
idPlanningIntervenant, action, dateActions
idPlanningIntervention, action, dateActions
idIntervention, idIntervenant, adresse, descriptif, numProduit,
idOM, planSite, descriptionActions, procsVerbalClient,
rapportDplacement
PlanTravail saisi
idPlanTravail, dateDbut, dateFin, semaine, familleComptence,

numClient, idRessource, idDemande
Intervention saisie
idIntervention, idDemande, numClient, idProduit, interlocuteur,
dateD but, dateFin, sous-trait (oui / non), idRessource,
complmentInfo, dateCration, origineCration,
responsableOuverture, adresseClient
Tableau A- 9 - Attributs des vues dobjets pour les processus associs au but Achieve Intervention
planifie des modles AS-WISHED et MIGHT-BE
Activits
Pour la troisime activit, qui est enregistre, il en est de mme que la premire.
Entres / sorties
-
Vues dobjets PlanTravail vs. PlanningIntervention et PlanningIntervenant
La vue dobjet PlanTravail est quivalente aux vues dobjets PlanningIntervention et

PlanningIntervenant .
2 attributs sont aligns : les identifiants du planning dintervention et du planning
dintervenant sont quivalents, respectivement, lidentifiant de lintervenant et lidentifiant
de lintervention de la vue dobjet PlanTravail . Il sagit dun filtre sur les plannings pour
afficher soit le planning dune intervention, soit lensemble des plannings dinterventions
dun intervenant donn. Lattribut dateDbut est align lattribut dateActions . Ces
attributs sont dans les deux versions du modle TO-BE. Lentreprise a dcid de les
paramtrer. Cependant, il faut noter que la partie ddie au plan de travail nest pas dtaille
dans ces deux versions du modle TO-BE. Il y a uniquement une capture de lcran utilisateur
sans explications avec juste une mise en avant des avantages lis au plan de travail - exemple :
cest un outil privilgi pour la mise en uvre dun travail dquipe .
Un attribut est non-satisfait : actions des objets dentreprise PlanningIntervention et
PlanningIntervenant . Le planning offert par lERP ne permet pas de visualiser les actions
faire. Cet attribut nest prsent dans aucune des deux versions du modle TO-BE. La
dcision prise inconsciemment par lentreprise a t de ne pas le supporter. Cela nous amne
214
conseiller un complment la conduite de changement (D6) pour faire face cet abandon
Effectuer un dveloppement spcifique dans lERP (D2) aurait pu tre envisag en
ajoutant lattribut action . Bien que ncessitant un investissement, cette modification aurait
permis davoir une vision de lensemble des actions relies une intervention sur le plan de
travail. Nous aurions galement conseill lassociation de cette dcision celle de
complment la conduite de changement (D6) afin de mettre jour la documentation
relative ce dveloppement spcifique.
4 attributs sont dcouverts : dateFin , semaine , familleComptence , numClient .
Ils sont prsents dans les deux versions du modle TO-BE. Il a t dcid de les paramtrer en
toute connaissance de cause.
-
Vues dobjets Intervention
6 attributs sont aligns : idIntervention avec idIntervention ; idIntervenant avec

idIntervenant ; adresse avec adresseClient ; descriptif et actions tous deux
avec complmentInfos , numProduit avec idProduit et dateActions avec
dateDbut . Ces attributs sont prsents dans les deux versions du modle TO-BE et ont t
paramtrs en toute connaissance de cause.
8 attributs sont dcouverts : idDemande , numClient , interlocuteur , dateFin ,
sous-tait et ses attributs, dateCration , origineCration , responsableOuverture
ne sont pas aligns, ils sont uniquement prsents dans le modle MIGHT-BE. Ils sont prsents
dans les deux versions du modle TO-BE et ont t paramtrs en toute connaissance de
cause.
Pour tous les attributs dcouverts et paramtrs, nous conseillons un complment la
conduite de changement pour organiser, notamment, un complment de formation sur ces
nouveaux concepts.
Le modle TO-BE fonctionnel est mis jour avec 3 activits et 22 attributs.
Activits
Les trois dernires activits, savoir gnrer un ordre de mission , enregistrer lordre de
mission et envoyer lordre de mission lintervenant , ne sont prsentes dans aucune des
versions Vintgrateur et Ventreprise du modle TO-BE. Pour ces activits, lentreprise a pris
inconsciemment la dcision de ne pas les implanter au sein de lERP. Nous sommes en
prsence de loccurrence du rsultat indsirable associ au RNA. La dcision deffectuer un
dveloppement spcifique dans lERP (D2) aurait pu tre prise. Cela aurait consist en
lajout des attributs de la vue dobjet OM - planSite , descriptionActions ,
procsVerbalClient et rapportDplacement - lobjet dentreprise CompteRendu
qui existe dj en standard. Cela aurait galement t accompagn dun dveloppement
spcifique pour lcran afin de permettre lutilisateur de saisir les attributs de lordre de
215
mission, mais galement celle du rapport correspondant. Cela aurait reprsent un cot et la
potentialit dune perturbation de lintgrit de lintgration de lERP. Cependant, lintrt
pour lentreprise aurait t dtre plus efficace dans lorganisation des tches faire durant
lintervention. Nous aurions galement conseill lassociation de la dcision de
dveloppement spcifique dans lERP (D2) celle de complment la conduite de
changement (D6) afin de mettre jour la documentation relative au dveloppement
spcifique.
216
AS-WISHED,
sortie
MIGHT-BE,
sortie
Objets
Consommations
mises jour
OrdreMission
complt
Attributs
quantitPiceRelle, dureActivitRelle, coutRelPice,
coutRelActivit
rapportIntervenant, procsVerbal, signatureElectroniqueClient
MIGHT-BE,
Consommations
dateEffectue, lieuEffectu, quantitRelle, montantConsomm,
sortie
mises jour
facturation (oui / non), devise, pointDbits, infosComplmentaires
MIGHT-BE,
Intervention
compteRendu
sortie
complte
MIGHT-BE,
Intervention
statut : cltur
sortie
clture
MIGHT-BE,
Demande
statut : cltur
sortie
clroture
Tableau A- 10 - Attributs des vues dobjets pour les processus associs au but Achieve Intervention
clture des modles AS-WISHED et MIGHT-BE
Activits
La premire activit est aligne, nous confrontons ses entres / sorties :
Entres / sorties
-
La vue dobjet Consommation
2 attributs sont aligns : quantitPiceRelle et dureActivitRelle tous deux aligns

quantitiRelle qui runit tous les types de consommations cest--dire de pices et
dactivits. CotRelPice et CotRelActivit sont tous deux aligns lattribut
montantConsomm qui runit les cots aussi bien des activits que des pices. Ces
attributs sont prsents dans les deux versions Vintgrateur et Ventreprise du modle TO-BE. Ils ont
donc t paramtrs en toute connaissance de cause.
5 attributs sont dcouverts : dateEffectue , lieuEffectu , facturation et ses attributs,
devise , infosComplmentaires . Ils sont prsents dans les deux versions Vintgrateur et
Ventreprise du modle TO-BE. Ils ont donc t paramtrs en toute connaissance de cause.
Un attribut est dcouvert pointDbits . Il na pas t paramtr et ce, en toute
connaissance de cause. Cela est inscrit dans les versions Vintgrateur et Ventreprise du modle TOBE.
Activits
La deuxime activit est aligne : complter lordre de mission du modle AS-WISHED
avec faire le compte rendu du modle MIGHT-BE. Dans le modle AS-WISHED, le
terme complter est utilis car lOM est cens avoir t cr lors de la planification de
lintervention. Dans ce cas, il nest pas rellement complt, mais les informations relatives
lintervention sont saisies sur lOM qui est utilis pour la premire fois. Il ne sagit pas
rellement dun OM mais lide est quivalente faire un compte rendu.
Nous confrontons les entres / sorties de cette activit.
217
Entres / sorties
-
Les vues dobjet Intervention et Demande du modle MIGHT-BE
2 attributs sont dcouverts : statut des deux objets. Ils sont dans les deux versions du
modle TO-BE. Lentreprise a dcid de les paramtrer en toute connaissance de cause.
-
La vue dobjet OM du modle AS-WISHED
Une vue dobjet nest pas aligne : la vue OM .

Par contre, un attribut de cette vue dobjet est align : rapportIntervenant qui est align
compteRendu de la vue dobjet Intervention . Pour juger de cette quivalence, le
jugement de lexpert du domaine est ncessaire. Cet attribut est prsent dans les deux versions
du modle TO-BE. Il a donc t paramtr en toute connaissance de cause.
2 attributs ne sont pas aligns procsVerbal et signatureElectroniqueClient . Ils sont
uniquement dans le modle AS-WISHED. Ils ne prsents dans aucune des deux versions du
modle TO-BE. Il a t dcid ne pas les implanter. Cette dcision a t prise inconsciemment
par lentreprise. Cela nous amne conseiller, prsent, lentreprise un complment la
conduite de changement pour faire face cet abandon.
Activits
La dernire activit du modle AS-WISHED est aligne avec la deuximre alternative du
modle MIGHT-BE concernant la clture simultane de lintervention et la demande. Nous
confrontons les entres / sorties.
Entres / sorties
Il y a dcouverte de deux attributs concernant le statut de lintervention. Ils ont t
paramtrs en toute connaissance de cause.
Activits
3 activits du modle MIGHT-BE sont dcouvertes : elles concernent la premire alternative clture non immdiate - consistant clturer la demande et lintervention lune aprs
lautre. Cette alternative permet de basculer sur le processus associ au but Achive Solution
enregistre .Lentreprise a dcid de galement cette deuxime alternative. Elle nest pas
prsente dans les versions Vintgrateur et Ventreprise du modle TO-BE. Son paramtrage nous a
t communiqu par lintgrateur. Cette dcision a t prise inconsciemment.
Le modle TO-BE a t mis ajour au fur et mesure.
Nous conseillons galement, prsent, lentreprise, pour tous les attributs dcouverts et
paramtrs, de prendre la dcision dun complment la conduite de changement pour
organiser, notamment, un complment de formation sur lensemble de ces nouveaux concepts.
218
Achieve Suivi client cr
219
AS-WISHED,
sortie
MIGHT-BE,
sortie
Objets
SuiviClient saisi
Attributs
idSuiviProduit, idProduit, numSrie, nomenclaturePices, idContratGa,
idContratSe
ParcClient cr
idParcClient, numSrie, idProduit, adresse, commentairesLocalisation,

quantit, familleCommercialeProduit, dateMiseService,
typeImplantationFinale (utilisateur final / revendeur / grossiste), prt (oui /
non), dateInstallation, numClientFinal, nomClientFinal, prixVente,
prixAchat, dateVente, dateAchat, deviseVente, deviseAchat, dateDbutPrt,
dateFinPrt, prixReprise, deviseReprise, idContrat, catgorieContrat
(service / garantie), dateFinContrat
MIGHT-BE,
ParcClient
typeImplantationFinale (utilisateur final / revendeur / grossiste), prt (oui /
entre
non)
Tableau A- 11 - Attributs des vues dobjets pour les processus associs au but Achieve Parc client / Suivi
client cr des modles AS-WISHED et MIGHT-BE
Ce processus est uniquement prsent dans la Vintgrateur du modle TO-BE. Ainsi toutes les
dcisions le concernant ont t prises inconsciemment par lentreprise.
Activits
uniquement cr activit atomique de cration.
Il en est de mme pour la deuxime activit que la premire qui, elle, est enregistre.
Entres / sorties
La vue dobjet en entre de lactivit remplir les informations sur le suivi produit dans les
deux modles montre la possibilit de dcomposer lactivit en nud de dcision . Elle
nest pas confronte. Cette dcomposition concerne la saisie des attributs idContratGa et
idContratSe dans le modle AS-WISHED et lattribut catgorieContrat dans le modle
MIGHT-BE. Il en est de mme pour la vue dobjet ParcClient ayant pour attribut
typeImplantationFinale .
5 attributs sont aligns : idSuiviProduit avec idParcClient ; idProduit avec
idProduit ; numSrie avec numSrie et enfin idContratGa et idContratSe
tous deux aligns avec idContrat et catgorieContrat ayant pour valeurs possibles
service et garantie .
1 attribut est non-satisfait : nomenclaturePices . Il nest prsent dans aucune version du
modle TO-BE. Il na donc pas t implant. Le dveloppement spcifique au niveau du code
source de lERP aurait t envisageable en ajoutant lattribut lobjet dentreprise
ParcClient . Le cot et la potentialit dune perturbation de lintgrit de lintgration de
lERP auraient d tre valus face lintrt davoir la visibilit sur la nomenclature. Nous
aurions galement conseill lassociation de cette dcision celle de complment la
220
conduite de changement afin de mettre jour la documentation relative ce dveloppement

spcifique.
21 attributs sont dcouverts : lintgrateur nous a confirm quils taient tous paramtrs
mme si seul un attribut est prsent dans la version Vintgrateur du modle TO-BE. Nous
conseillons, prsent, lentreprise de prendre la dcision dun complment la conduite
de changement pour organiser, notamment, un complment de formation sur lensemble de
ces nouveaux concepts.
Le modle TO-BE fonctionnel est mis jour avec les 26 attributs et la vue dobjet
ParcClient .
221
AS-WISHED,
sortie
MIGHT-BE,
entre
MIGHT-BE,
sortie
Objets
Consommations
saisies
Attributs
idConsommation, numPice, quantitPice, activit, dureActivits,
transport, coutPrvuPices, coutPrvuActivits, coutTransport
ArticleSAV
numPice, numComposant, typeConso (fraisMO / pices /

fraisMission), units (pices / heures), quantit, stock (oui / non)
idConsommation, numComposant, typeConso (fraisMO / pices /
fraisMission), units, quantit, siteStockConso
Consommations
saisies
Tableau A- 12 - Attributs des vues dobjets pour les processus associs au but Achieve Consommations
renseignes des modles AS-WISHED et MIGHT-BE
Activits
La premire activit est aligne la diffrence prs que les consommations sont lies la
demande dans le modle AS-WISHED et lintervention dans le modle MIGHT-BE. Le
moment de renseigner ces consommations change. Le jugement de lexpert du domaine sur
cette quivalence joue un rle important. Nous considrons que cest quivalent et nous
confrontons les entres et sorties. Nous confrontons ses entres / sorties.
La deuxime activit est aligne mais la vue dobjet en sortie na pas dattributs, elle est
Entres / sorties :
-
Vue dobjet articles SAV
Cette vue dobjet est dcouverte. Il traduit un nud de dcision non dcompos.
Cependant, contrairement aux autres vues dobjet en entre des autres activits, celle-ci est
confronte.
Lattribut stock prenant les valeurs oui et non signifie que si la quantit est
spcifie et si le composant est gr sur stock, une sortie de stock est prvue
automatiquement. Lattribut siteStockConso de la vue dobjet Consommations sera
ainsi saisi automatiquement. Cet attribut est prsent dans les deux versions Vintgrateur et
Ventreprise du modle TO-BE et est donc paramtr en toute connaissance de cause.
2 attributs numPice et numComp sont prsents dans les deux versions du modle TOBE. Ces attributs sont paramtrs en toute connaissance de cause.
3 autres attributs qui permettent la saisie automatique des units et des types de
consommations ne sont dans aucune version du modle TO-BE. Cependant, aprs discussion
avec lintgrateur, nous savons quils ont t paramtrs sans que lentreprise nen ait
conscience. Lintrt de ce paramtrage est la mmorisation pralable dans la base de donnes
des articles SAV de certaines informations qui seront ainsi saisies automatiquement lors de la
saisie de chaque composant consomm - lattribut numComposant . Ceci apporte
lentreprise efficacit et prcision.
222
- Vue dobjet Consommations

6 attributs sont aligns :
Dabord les attributs idConsommation , pices et activits aligns avec
typeConso et numComposant . En, effet, la seule diffrence est que pour la main
duvre (MO) et la mission dans le modle MIGHT-BE, il ny a pas lieu dindiquer de quoi il
sagit - dans le sens quelle MO exactement ou quelle mission - contrairement au modle ASWISHED o cest possible. Alors que pour le composant consomm, il est possible, dans le
modle MIGHT-BE dindiquer le numro du composant concerne. Egalement,
quantitPice et dureActivits sont aligns quantit et units . Lensemble
des attributs aligns sont dans les versions Vintgrateur et Ventreprise du modle TO-BE.
Lentreprise a donc dcid de les paramtrer en toute connaissance de cause.
4 attributs sont non-satisfaits : transport , coutPrvuPices , coutPrvuActivits ,
coutTransport . Ils ne sont prsents dans aucune des deux versions du modle TO-BE. La
dcision de ne pas les implanter a t prise inconsciemment. Nous sommes donc en prsence
de la survenue du rsultat indsirable associ au RNA. La dcision deffectuer un
dveloppement spcifique au niveau du code source de lERP aurait pu tre envisage en
ajoutant les attributs cots et transport prenant les valeurs oui et non lobjet
dentreprise Consommations . En prvoyant les cots et en y incluant les transports,
lentreprise aurait pu avoir une meilleure vision des futures charges que va impliquer
lintervention lie la demande.
Le modle TO-BE fonctionnel est mis jour avec les 2 activits et 12 attributs.
Nous conseillons, prsent, lentreprise, pour tous les attributs dcouverts et paramtrs, de
prendre la dcision dun complment la conduite de changement pour organiser,
notamment, un complment de formation sur lensemble de ces nouveaux concepts.
223
AS-WISHED,
sortie
Objets
ContratGarantie saisi
Attributs
idContratGa, idProduit, dure, dateDpart, clauses,
priodicitIntervention
MIGHT-BE,
ContratGarantie saisi
idContrat, type (garantie), idProduit, numClient, nomClient,
sortie
interlocuteur, dateSouscroption, dateFin, crditPoint
Tableau A- 13 - Attributs des vues dobjets pour les processus associs au but Achieve Contrat service
cr des modles AS-WISHED et MIGHT-BE
Lensemble des dcisions concernant ce but ont t prises inconsciemment. En effet, il ny a

rien concernant les contrats de garantie dans la version Ventreprise du modle TO-BE.
Activits
224

Il en est de mme pour la deuxime activit que la premire qui, elle, est enregistre.
Entres / sorties
2 attributs sont non-satisfaits : clauses et periodicitIntervention . Contrairement au
second, le premier nest pas prsent dans la version Vintgrateur du modle TO-BE. Il na donc
pas t paramtr. La dcision deffectuer un dveloppement spcifique dans lERP aurait
pu tre prise en ajoutant un attribut lobjet ContratGarantie . Cela aurait pu tre
accompagn de la modification de lcran pour laisser lutilisateur saisir les clauses. Lintrt
aurait t daugmenter la prcision de la relation contractuelle avec le client. Nous pensons
que cet ajout de code naurait pas perturb lintgrit de lintgration et naurait pas t
coteux. Nous aurions galement conseill lassociation de cette dcision celle de
complment la conduite de changement afin de mettre jour la documentation relative
ce dveloppement spcifique. Pour lattribut periodicitIntervention , la dcision a t de
procder un dveloppement spcifique dans lERP par lajout dun attribut
supplmentaire lobjet dentreprise ContratGarantie . Cela a t associ la modification
de lcran par lajout dune liste droulante permettant de choisir la priodicit de gnration
automatique des demandes de service. Il sagit dune des seules situations de non-alignement
identifie par lintgrateur. Son absence dans la version Ventreprise du modle TO-BE montre
que les membres de lentreprise ntaient pas au courant. De plus, nous navons pas trouv de
rapport dvaluation concernant lintrt, lintgrit de lintgration ou le cot ventuel
engendr par cette dcision. Nous conseillons, prsent, lentreprise, lassociation de cette
dcision celle de complment la conduite de changement afin de mettre jour la
documentation relative ce dveloppement spcifique.
4 attributs sont aligns. Ils sont prsents dans la version Vintgrateur du modle TO-BE et ont
donc tous t paramtrs.
4 attributs sont dcouverts : numClient , nomClient , interlocuteur , crditPoint .
Les trois premiers sont prsents dans la Vintgrateur du modle TO-BE et ont donc t
paramtr. Le dernier ne la pas t et cela est prcis dans cette version. Nous conseillons,
prsent, lentreprise de prendre la dcision dun complment la conduite de
changement pour organiser, notamment, un complment de formation sur lensemble de ces
nouveaux concepts.
Le modle TO-BE a t mis jour, au fur et mesure, avec 3 activits et 10 attributs.
225
Annexe J Confrontation des processus associs aux buts dcouverts
J. Confrontation des processus associs aux buts dcouverts
Achieve Solution archive
Figure A- 23- Vue fonctionnelle associe au but Achieve Solution archive

Vues dobjet
Attributs
MIGHT-BE,
FihcheSolution
idSolution, dateCration, responsablecCation, titreDemande,
sortie
saisie (1)
idDemande, descriptionDemande
MIGHT-BE,
FihcheSolution
descriptionSolutionEmploye, motsCls
sortie
saisie (2)
Tableau A- 14 - Attributs des vues dobjets pour le processus associ au but Achieve Solution archive
Achieve Ressources rserves
Figure A- 24- Vue fonctionnelle associe au but Achieve ressources rserves
226
Vues dobjet
Attributs
MIGHT-BE,
RservationRessources idRservationRessource, idRessource, dateDbut, dateFin,
sortie
saisie
heureDbut, heureFin, responsableRservation
MIGHT-BE,
RservationRessources idRservationRessource, idRessource, dateDbut, dateFin,
sortie
heureDbut, heureFin
Tableau A- 15 - Attributs des vues dobjets pour le processus associ au but Achieve Ressources
rserves
Les activits des processus associs ces buts sont prsentes dans les versions Vintgrateur et
Ventreprise du modle TO-BE. Les processus ont donc t tous deux paramtrs et ce, en toute
connaissance de cause de lentreprise. Nous avons mis jour le modle TO-BE fonctionnel de
ces deux processus. Nous conseillons conjointement un complment la conduite de
changement (D6) pour organiser, notamment, un complment de formation sur ces
processus.
Achieve Activits demandes horodates
Figure A- 25- Vue fonctionnelle associe au but Achieve demandes horodates

Vues dobjet
Demande horodate
Attributs
MIGHT-BE,
tempsHorodat
sortie
Tableau A- 16 - Attributs des vues dobjets pour le processus associ au but Achieve Demande
horodate
Les activits du processus associ ce but ne sont prsentes dans aucune des deux versions du
modle TO-BE. Il nest donc pas paramtr. Cependant, lintgrateur nous a affirm que cette
dcision a t prise en toute connaissance de cause. Selon lintgrateur, lhorodatage des
demandes est surtout utile pour les entreprises qui offrent des services par tlphone, ce qui
nest pas le cas du partenaire industriel. Il nest donc pas modlis dans le modle TO-BE.
227
Achieve Historique Facturation Contrat Service mis jour Achieve Demande

contrat service valide , Achieve Contrat rsili et Achieve contrat cltur .
Figure A- 26 - Vue fonctionnelle, du processus associ au but Achieve Historique facturation contrat mis
jour
Attributs
idHistoriqueFacturation, dateEnvoiFacture,
montantTHProchaineFacture, dateFactureValide,
montantHTFactureValide, dateFactureEcheance,
montantTTCFactureEcheance, numEchance, dateRglement,
montantTTCRglement, numRglement, pointsMobiliss,
pointsConsomms, pointsrestants
Tableau A- 17 - Attributs des vues dobjets pour le processus associ au but Achieve Historique
facturation contrat mis jour
MIGHT-BE,
sortie
Vues dobjet
HistoriqueFacturation
Figure A- 27 - Vue fonctionnelle du processus associ au but Achieve Demande garantie valide
MIGHT-BE,
sortie
MIGHT-BE,
sortie
Vues dobjet
DemandeGarantie
saisie
DemandeGarantie
valide
Attributs
idDemande, idProduit, numClient, numSrie, quantit, dateAchat,
prixAchat, dateEnregistrement
dateValidation
Tableau A- 18 - Attributs des vues dobjets pour le processus associ au but Achieve Demande garantie
valide
228
Figure A- 28 - Vue fonctionnelle, processus associ au but Achieve Contrat rsili

Vues dobjet
Attributs
MIGHT-BE,
Contrat rsili
Etat : rsili
sortie
Tableau A- 19 - Attributs des vues dobjets pour le processus associ au but Achieve Contrat rsili
Figure A- 29 - Vue fonctionnelle du processus associ au but Achieve Contrat cltur

Vues dobjet
Attributs
MIGHT-BE,
Contrat cltur
tat : cltur
sortie
Tableau A- 20 - Attributs des vues dobjets pour le processus associ au but Achieve Contrat cltur
Les activits des processus associs ces buts ne sont prsents dans aucune des versions
Vintgrateur et Ventreprise du modle TO-BE. Ces 4 processus ne sont pas implants dans le S.I.
ERP. Ces dcisions ont t prises inconsciemment. Laccs au client de la clture ou de la
rsiliation de son contrat amliore sa relation avec lentreprise car, par ce biais, celle-ci lui
offre davantage de services. Lhistorique de la facturation aurait galement t intressant
pour lentreprise notamment pour amliorer la traabilit de la facturation. Ces processus ne
sont pas modliss dans le modle TO-BE fonctionnel.
229
Annexe K Dtail des variables des facteurs identifis et des pratiques conseilles, priode
dadquation
K. Dtail des variables des facteurs identifis et des

pratiques conseilles, priode adquation
Facteur manque dexpertise / dimplication des utilisateurs cls (F11)
La variable manque dexpertise mtier a t identifie comme avre. En effet, lors dune
runion, afin de statuer sur le processus associ la planification du transport, les utilisateurs
cls prsents durant la runion nont pas t en mesure den connatre le fonctionnement.
Nous aurions conseill lentreprise les 7 pratiques de gestion suivantes :
-
P5 : Slectionner les utilisateurs cls en fonction de critres dexprience, de

comptences, dintgration, dadaptation et de motivation. Adapt selon le contexte en :
reconsidrer les utilisateurs cls et en slectionner dautres si ncessaires.
P8 : Etablir le plan de formation des utilisateurs cls. Adapt selon le contexte en : pallier
au manque dexpertise mtier des utilisateurs cls prsents par des formations.
P18 : Mettre en place le processus dynamique en spiral de mise en confiance des membres
de lquipe projet.
P19 : Appliquer la rgulation dquipe, en prenant une pause dans les activits
oprationnelles pour parler de lquipe elle-mme.
membre de lquipe. Adapt selon le contexte en : dterminer par crit, pour les
utilisateurs cls nouvellement slectionns, leur rle et responsabilits.
P25 : Librer officiellement les membres du projet de leurs tches quotidiennes.
P26 : Organiser des exercices de travail en quipe.
Nous aurions ainsi permis lentreprise de slectionner dautres utilisateurs cls ou de former
ceux dj prsents dans lquipe projet, ou mme les deux la fois par les pratiques P5 ou P8.
Les autres pratiques auraient permis aux utilisateurs cls de se sentir plus laise et mieux
intgrs au sein de lquipe projet, mais aussi de prendre conscience de leur poids dans cette
quipe. Cela aurait indirectement eu un impact sur la qualit de leurs interventions.
Facteur problme avec le chef de projet (F7)
La variable pas de chef de projet a t identifie comme avre.
Nous aurions conseill lentreprise les 4 pratiques de gestion suivantes :
-
P4 : Nommer un chef de projet en fonction des critres de lgitimit, de charisme et de

comptences. Nous aurions bien entendu conseill dappliquer cette pratique ds le dbut
du projet mais il est tout fait possible de nommer un chef de projet au cours du projet si
cela na pas dj t fait.
P15 : Disposer dun chef de projet reconnu comme tant linterlocuteur principal pour
prendre les dcisions qui sont bloquantes tant sur les aspects techniques que mtiers.
P17 : Etablir la relation ad hoc entre le chef de projet et chacun des acteurs du projet pour
faire avancer le projet.
230
dadquation
membre de lquipe. Adapt selon le contexte en : dterminer par crit, pour le chef de
projet nouvellement slectionn, son rle et sa responsabilit.
P24 : Tenir le chef de projet au courant de tout ce qui sest pass durant le projet, grce
une procdure formelle. Adapt, selon le contexte, en : dfinir une procdure formelle
pour tenir au courant le nouveau chef de projet.
P25 : Librer officiellement les membres du projet de leurs tches quotidiennes que nous
aurions adapt pour le chef de projet.
Ces pratiques auraient permis de nommer un chef de projet et de le mettre, ds sa nomination,

dans les meilleures conditions de travail pour son nouveau rle - relation ad hoc avec les
autres membres, libration officielle de ses tches quotidiennes, rles et responsabilits
dfinies, etc. Les pratiques P18, P19 et P26, galement associes ce facteur, nauraient pas
eu lieu dtre conseilles ce moment-l. Elles permettent davantage de pallier le manque de
comptences dun chef de projet dj prsent dans lquipe.
Facteurs gestion de projet inefficace , mauvaise constitution de lquipe projet et
mauvaise gestion des risques (F2, F3, F14)
Les variables processus de gestion de projet partiel , pas de processus de gestion des
risques et rpartition inadquate des rles et responsabilits ont t identifies comme
avres. En effet, notre partenaire industriel na mis en uvre aucune technique de gestion de
projet ni de processus de gestion des risques. De plus, nous avons observ des difficults
matriser les ressources humaines affectes au projet - chef de projet et utilisateurs cls. Ainsi,
les rles et responsabilits des membres de lquipe nont pas t clairement dfinis.
Notamment, aucune personne na t dsigne pour tre le coordinateur des runions ou
encore rdiger les comptes rendus de runion.
Pour la constitution de lquipe nous aurions conseill la pratique P22 concernant la
dtermination par crit des rles et responsabilits de chaque membre de lquipe.
Pour la gestion des risques, nous aurions conseill la pratique P30 - mettre en place un
processus de gestion des risques.
Pour la gestion de projet, nous aurions conseill les pratiques :
-
P11 : Organiser de courtes runions dinformation hebdomadaires de lquipe projet pour

rendre compte des runions du comit de pilotage, avec un compte rendu rdig
rapidement aprs la runion.
P17, P19 et P20 : concernant les mthodes de gestion adopter notamment pour amliorer
la qualit du travail en quipe - rgulation dquipe etc. - et dj conseilles pour les
facteurs relatifs aux membres de lquipe.
Pour la gestion de projet, nous avons jug que la pratique P16 - Choisir ds le dbut du projet,
un mode de pilotage adapt - avait dj t mise en place. De plus, ce moment du projet, les
dlais semblaient respects et ne faisaient pas lobjet de discussions.
231
dadquation
Facteurs manque dexpertise / dimplication du comit de pilotage , mauvaise gestion des

ressources financires et matrielles , mauvaise planification temporelle du projet ,
difficult de travail commun entre lentreprise et les membres externes et manque
dexpertise de lintgrateur (F1, F8, F9, F10, F12)
Ces facteurs nont pas t identifis comme avrs. Le planning dadquation semblait raliste
car il tait jusqu ce moment-l respect sans difficults. Il tait galement compatible avec
les autres projets de lentreprise puisque la prcdence des activits semblait tre respecte.
Lensemble du comit de pilotage a sembl investi durant la priode dadquation.
Lintgrateur a donn limpression davoir lexprience et lexpertise ncessaires. Le travail
entre notre partenaire industriel et lintgrateur ne semblait pas poser de problme. Enfin,
nous interprtons cela davantage comme un manque dexprience de notre partenaire
industriel dans la gestion de projet qui a in fine adopt les techniques de travail de
lintgrateur.
Facteur gestion inadquate de ladaptation de lERP (F20)
Les variables pas danalyse de la ncessit dadapter en fonction de lintrt de
lentreprise , pas danalyse des cots dadaptation ont t identifies comme avres. En
effet, les dcisions dadapter ont t prises sur le tas sans aucune analyse. La philosophie
du partenaire industriel tait de profiter de la mise en place de lERP et donc de lopportunit
de rpondre au maximum ses besoins.
Nous aurions conseill les 4 pratiques de gestion suivantes :
-
P12 : Organiser des runions de validation des demandes dadaptation de lERP en

fonction des critres denjeux conomiques, des critres fonctionnels et budgtaires.
P14 : Identifier, en fonction de la nature de la dcision, les membres du projet ayant du
poids sur celle-ci.
P15 : Disposer dun chef de projet reconnu comme tant linterlocuteur des dcisions
bloquantes tant sur les aspects techniques que mtiers.
P23 : Etablir ds le dbut du projet la philosophie concernant ladaptation de lERP et sen
tenir jusqu la fin du projet, adapt selon le contexte en : dterminer une philosophie
claire et prcise concernant les adaptations.
Toutes ces pratiques auraient permis damliorer les conditions de prise de dcision
concernant ladaptation de lERP. Cela aurait amen pallier au manque danalyse qui est
ncessaire pour prendre ce type de dcision. Pour ce facteur nous considrons quil aurait
fallu mettre en place la pratique P21 ds le dbut du projet - ne pas inclure dans le contrat
forfaitaire les ventuelles adaptations de lERP. Cette pratique ne peut plus tre mise en
uvre ce stade du projet.
Facteur haut degr de complexit du progiciel (F21)
Aucune variable na t identifie pour ces facteurs.
232
Annexe L Dtail des variables des facteurs identifis et des pratiques conseilles, priode de retour
sur adquation
L. Dtail des variables des facteurs identifis et des

pratiques conseilles, priode de retour sur adquation
Facteurs gestion de projet inefficace , mauvaise constitution de lquipe projet et
mauvaise gestion des risques (F2, F3 et F14)
Malgr la mise en place de la pratique P20 - compte rendu des runions - le facteur
concernant la gestion de projet na pas t trait. La pratique P20 na pas palli au problme
li aux mthodes et outils de gestion non utilises. Une variable supplmentaire a mme t
observe - concernant le planning projet non respect.
Les mmes variables ont galement t observes pour les facteurs lis la constitution de
lquipe - malgr la mise en place partielle de la pratique P22 uniquement pour les consultants
externes - et la gestion des risques.
Nous aurions donc conseill, pour lensemble de ces facteurs, les mmes pratiques que pour la
priode dadquation.
Facteur problme avec chef de projet (F7)
Il ny a pas eu dvolution de ce facteur au cours du projet.
Facteur mauvaise planification temporelle du projet (F8)
La variable planning non raliste a t identifie comme avre. Il sagit dun nouveau
facteur. En effet, le consultant externe a souvent soulev que les plannings tablis taient
trop serrs .
Nous aurions donc conseill la pratique P33 consistant tablir finement le planning .
Facteur difficult de travail commun entre lentreprise et les membres externes (F10)
Ce facteur navait pas t identifi comme avr durant la priode dadquation alors quil la
t durant la priode dadquation bis. Durant cette priode, la variable mthodologies de
travail diffrentes a t identifie comme avre. En effet, pour certains travaux, il ny a pas
eu de comprhension entre les utilisateurs cls et les intgrateurs. Ces derniers ne se sont pas
suffisamment mis au niveau des utilisateurs cls pour leur expliquer le travail faire. De
mme les utilisateurs cls, eux, nont pas os demander ce quils ne comprenaient pas. Ainsi,
par exemple, certaines informations ncessaires aux intgrateurs nont pas t fournies sous la
forme souhaite. Un autre exemple est la diffrence de vocabulaire employ entranant une
incomprhension entre intgrateurs et utilisateurs cls. Tel fut le cas, par exemple, pour les
termes stock de scurit et stock mini .
La pratique P11 - organiser des runions hebdomadaires du comit de pilotage - avait dj t
conseille pour le facteur li la gestion inadquate du projet lors de la priode dadquation.
233
Annexe L Dtail des variables des facteurs identifis et des pratiques conseilles, priode de retour
sur adquation
Elle a t mise en place spontanment par lentreprise. Mais cela na pas suffi, mme
indirectement, pour traiter ce facteur de difficult de travail commun. Nous aurions conseill
lentreprise de continuer appliquer la pratique P11 mais aussi les pratiques de gestion
suivantes : les pratiques P18 - mettre en place le processus dynamique de mise en confiance
des membres de lquipe projet -, P19 - appliquer la rgulation dquipe - et P26 - organiser
des exercices de travail en quipe.
Facteur manque dexpertise / dimplication des utilisateurs cls (F11)
Deux variables supplmentaires ont t identifies comme avres :
-
manque de prsence : de nombreuses dcisions, notamment concernant les

emplacements dans les sites de la socit ou les codes comptables ou encore les zones de
stockage, ont t prises sans la prsence des utilisateurs cls.
travail non fait : les utilisateurs ont eu beaucoup de peine faire le travail qui leur tait
demand - notamment pour la dfinition des catgories darticles ou des comptes
statistiques des articles. Etant donn notre prsence importante durant cette priode, nous
avons t amens pousser ces utilisateurs cls faire le travail demand puis le
vrifier. Ainsi, mme si un travail tait demand pendant les runions et accept par les
utilisateurs, un rappel tait ncessaire pour quil soit rellement accompli.
Nous aurions nouveau conseill les mmes pratiques : P5 - slection des utilisateurs cls -,
P8 - plan de formation des utilisateurs cls -, P18 - processus de mise en confiance -, P19 rgulation dquipe - P22 - attribution des rles et responsabilit des utilisateurs cls -, P25 libration tches quotidienne - et P26 - exercice de travail en quipe.
Facteur gestion inadquate de ladaptation de lERP (F20)
Malgr la mise en place de la pratique P12 - organiser des runions de validation des
demandes dadaptation de lERP en fonction des critres denjeux conomiques, des critres
fonctionnels et budgtaires - et la mise en place partielle de la pratique P16 - disposer dun
chef ce projet reconnu comme tant linterlocuteur des dcisions bloquantes tant sur les
aspects techniques que mtier -, ce facteur na pas pu tre trait. Les mmes variables ont t
observes. Pour la pratique P16, il sagissait du consultant externe et non du chef de projet.
La pratique P23 - tablir ds le dbut du projet la philosophie concernant ladaptation de
lERP et sen tenir jusqu la fin du projet - aurait d galement tre mise en place.
Il en est de mme pour la pratique P14 - identifier, en fonction de la nature de la dcision, les
membres du projet ayant du poids sur celle-ci.
Facteurs mauvaise gestion des ressources financires et matrielles et haut degr de
complexit du progiciel (F9 et F21)
Ces deux facteurs savrent encore une fois non avrs.
234
Annexe M Liste de Figures
M. Liste de Figures
Figure 1- Vision systmique du S.I., inspire des travaux de (Le Moigne 1990)......................6
Figure 2- Distinction entre systme informatique et S.I. (Morley et al. 2006) ..........................8
Figure 3- Croissance du march franais des ERP de 2011 2015 (inspir de (IDC 2012)).....9
Figure 4- Domaines traditionnellement couverts par les ERP, inspir de (Botta-Genoulaz and
Millet 2006) ............................................................................................................ 10
Figure 5- Echecs des projets ERP, enqute du (Panorama Consulting Group 2012a)............. 11
Figure 6- Phase de pr-implantation du projet ERP ............................................................... 13
Figure 7- Phase dimplantation du projet ERP ...................................................................... 14
Figure 8- Phase de post-implantation du projet ERP ............................................................. 15
Figure 9- Cycle de vie dun projet ERP................................................................................. 15
Figure 10- SAM - Strategic Alignment Model - inspir des travaux de (Henderson and
Venkatraman 1993)................................................................................................. 16
Figure 11- Schmatisation des situations dalignement et de non-alignement ........................ 18
Figure 12- Espace doccurrence et des effets du RNA, inspir des travaux de (Gourc 2006) . 21
Figure 13- Droulement du projet ERP de la socit X ......................................................... 24
Figure 14- La spirale de la recherche / action issue des travaux de (Kimmis and McTaggart
1988) dans (Lavoie et al. 1996) ............................................................................... 25
Figure 15- Instanciation de la dmarche recherche / action nos travaux de thse ................ 26
Figure 16- Stratgies de traitement du risque en fonction de la dimension et de linstant ....... 30
Figure 17- Dimensions de la norme (ISO 19439 2006) ......................................................... 32
Figure 18- Diagramme de classes des construits de la vue fonctionnelle (norme ISO 19440) 41
Figure 19- Diagramme de classes des construits de la vue informationnelle lis au construit
activit dentreprise (norme ISO 19440).................................................................. 41
Figure 20- Diagramme de classes des construits de la vue de ressources lis au construit
Figure 21- Diagramme de classes des construits de la vue organisationnelle lis au construit
Figure 22- Processus dalignement dans la littrature............................................................ 50
Figure 23- Evolution du nombre de contribution de 1999 2011 .......................................... 54
Figure 24- Evolution du type de contribution entre 1999 et 2012 .......................................... 55
Figure 25- Proportion de chaque type de contribution ........................................................... 55
Figure 26- Phase de rflexion de la dmarche de recherche / action ...................................... 68
Figure 27- Processus dalignement macroscopique ............................................................... 70
235
Figure 28- Pattern Achieve Request Satisfied de KAOS (Respect-IT 2007)......................... 76

Figure 29- Lien entre le construit activit dentreprise et les construits vue dobjet et objet
dentreprise ............................................................................................................. 79
Figure 30- Illustration de lintrt de la modlisation des interdpendances au niveau de la vue
fonctionnel .............................................................................................................. 80
Figure 31- Structure dune activit atomique ........................................................................ 81
Figure 32- Structure et dcomposition dune activit atomique agrge ................................ 82
Figure 33- Structure et dcomposition dune activit dcomposable en nud de dcision
............................................................................................................................... 82
Figure 34- Structure et dcomposition dune activit dcomposable en activits atomiques
lies par des nuds d union ............................................................................... 83
Figure 35- Prise de dcision sur la vue fonctionnelle ddie aux processus associs aux buts
non satisfaits ........................................................................................................... 86
Figure 36- Enchanement des activits de confrontation / prise de dcision pour la vue
fonctionnelle des processus associs aux buts quivalents ....................................... 87
Figure 37- Prise de dcision sur la vue fonctionnelle ddie aux processus associs aux buts
dcouverts............................................................................................................... 88
Figure 38- Enchanement des activits de confrontation / prise de dcision pour la vue
informationnelle ...................................................................................................... 89
Figure 39- Principes de la mthode Model Driven - ERP Alignment ............................... 91
Figure 40- Dmarche suivie pour la slection de facteurs de risque influenant le RNA........ 94
Figure 41- Classement des facteurs de risque par rapport au cycle de vie du projet ERP ....... 95
Figure 42- Variables des facteurs de risque ........................................................................... 98
Figure 43- Stratgies de traitement des facteurs de risque ................................................... 105
Figure 44- Application des contributions notre cas dtude : phases dactions, observations
et rflexion de la dmarche recherche / action ....................................................... 107
Figure 45- Dmarche suivie pour lapplication de la mthode Model Driven - ERP
Alignment au module SAV ................................................................................ 109
Figure 46- Vue intentionnelle du modle AS-WISHED ...................................................... 111
Figure 47- Vue intentionnelle du modle MIGHT-BE ........................................................ 112
Figure 48- Dcomposition de lactivit agrge saisir les informations concernant le rapport
dexpertise ......................................................................................................... 114
Figure 49- Dcomposition en nud de dcision de lactivit renseigner le responsable . 114
Figure 50 Illustration de linterdpendance de processus................................................... 115
Figure 51- Vue fonctionnelle associe au but Achieve Responsabilit identifie ........... 116
Figure 52- Dcisions prises pour les processus associs aux buts non satisfaits par lERP... 117
Figure 53- Vue fonctionnelle du modle AS-WISHED pour le processus associ au but
Achieve Demande enregistre ......................................................................... 118
236
Figure 54- Vue fonctionnelle du modle MIGHT-BE pour le processus associ au but
Achieve Demande enregistre ......................................................................... 118
Figure 55- Modle TO-BE fonctionnel construit lissue de lensemble des dcisions
associes au but Achieve Demande enregistre (1 / 2) ..................................... 120
Figure 56- Dcisions sur les attributs et activits uniquement prsents dans le modle ASWISHED .............................................................................................................. 122
Figure 57- Dcisions prises pour les attributs non aligns, uniquement prsents dans le modle
MIGHT-BE et associs des activits alignes entre les modles ......................... 122
Figure 58- Dcisions prises pour les attributs aligns des activits alignes entre les modles
AS-WISHED et MIGHT-BE................................................................................. 123
Figure 59- Vue fonctionnelle du modle MIGHT-BE pour le processus associ au but
Achieve Contrat renouvel .............................................................................. 123
Figure 60- Modle TO-BE fonctionnel construit lissue des trois processus confronts dans
lapplication (1 / 2) ............................................................................................... 124
Figure 61- Dcisions prises pour les processus associs aux buts dcouverts ...................... 124
Figure 62- Dmarche suivie pour lapplication a posteriori de lapproche Risk-Factor
Driven - ERP- Alignment ................................................................................... 128
Figure 63- Proportion de facteurs influenant le RNA identifies a posteriori pour la priode
dadquation ......................................................................................................... 133
Figure 64- Pratiques les plus conseilles durant la priode dadquation ............................. 133
Figure 65- Proportion des pratiques mises en place entre les deux priodes sur celles qui
auraient t conseilles.......................................................................................... 138
Figure 66- Evolution des pratiques les plus conseilles entre les deux priodes ................... 138
237
Annexe N Liste des tableaux
N. Liste de Tableaux
Tableau 1- Dfinition de la notion de risque dans la littrature.............................................. 19

Tableau 2- Dfinition des construits de la vue fonctionnelle (ISO/DIS 19440 2004) ............. 33
Tableau 3- Dfinition des construits de la vue informationnelle (ISO/DIS 19440 2004) ........ 34
Tableau 4- Dfinition des construits de la vue de ressources (ISO/DIS 19440 2004) ............. 34
Tableau 5- Dfinition des construits de la vue organisationnelle (ISO/DIS 19440 2004) ....... 35
Tableau 6- Classifications des buts dans la littrature............................................................ 37
Tableau 7- Analyse des langages de modlisation de la vue intentionnelle ............................ 38
Tableau 8- Analyse des mthodes dalignement et de confrontation diriges par les modles 45
Tableau 9- Panel des dcisions issues de la littrature ........................................................... 51
Tableau 10- Liste et analyse des facteurs de risque ............................................................... 59
Tableau 11- Les dcisions et leurs variantes.......................................................................... 73
Tableau 12- Dcision D6 associes aux autres dcisions ....................................................... 91
Tableau 13- Matrice des liens rsiduels des facteurs de risque influenant le RNA ............... 97
Tableau 14- Liste des pratiques de gestion .......................................................................... 102
Tableau 15- Matrice des liens pratiques de gestion / facteurs de risque influenant le RNA 104
Tableau 16- buts non satisfaits par SAGE X3 ..................................................................... 110
Tableau 17- Buts dcouverts............................................................................................... 110
Tableau 18- Buts quivalents .............................................................................................. 113
Tableau 19- Attributs des vues dobjets pour le processus associ au but Achieve
Responsabilit Identifie .................................................................................... 114
Responsabilit Identifie .................................................................................... 115
Responsabilit identifie .................................................................................... 116
Tableau 22- Attributs des vues dobjets pour les processus associs au but Achieve
Demande enregistre des modles AS-WISHED et MIGHT-BEActivits .......... 119
Tableau 23- Modle TO-BE fonctionnel construit lissue de lensemble des dcisions
associes au but Achieve Demande enregistre (2 / 2) ..................................... 121
Tableau 24- Attributs des vues dobjets pour le processus associ au but Achieve Contrat
renouvel .............................................................................................................. 123
Tableau 25- Modle TO-BE fonctionnel construit lissue des trois processus confronts dans
lapplication (2 / 2) ............................................................................................... 124
Tableau 26- Dcision D6 prise conjointement aux autres dcisions durant lapplication...... 126
238
Annexe N Liste des tableaux
Tableau 27- Identification et traitement des facteurs de la priode dadquation ................. 130
Tableau 28- Identification et traitement des facteurs pour la priode de retour sur adquation
............................................................................................................................. 136
239
Sarra MAMOGHLI
Alignement des Systmes

dInformation base de
progiciel, vers une ingnierie
dirige par les modles centre
identification des risques
Rsum
Dans le contexte actuel de comptition exacerbe, les Systmes dInformation des Petites et Moyennes Entreprises se
basent de plus en plus sur des progiciels tels que les ERP - Enterprise Resource Planning. Compte tenu de laspect
standard de ceux-ci, il est ncessaire de grer lalignement entre les besoins rels de lentreprise et les fonctionnalits
standards de lERP. Pour ce faire, nous le considrons sous langle des risques en dfinissant le Risque de NonAlignement (RNA). Sur la base dun tat de lart du management des risques dans les projets, nous proposons de le
traiter selon deux stratgies complmentaires doptimisation anticipatives : lune agissant sur son effet et lautre, sur son
occurrence. Notre tat de lart des mthodes dingnierie dirige par les modles, moyen pour mettre en uvre la
premire stratgie, montre que les processus dalignement permettant didentifier le non-alignement, dvaluer son effet
et dy pallier restent trop macroscopiques pour traiter rellement le RNA. Notre tat de lart sur le management des
facteurs de risque, moyen pour mettre en uvre la seconde stratgie, met en avant des lacunes au niveau des outils
permettant didentifier et traiter les facteurs agissant sur le RNA. Pour rpondre notre problmatique, nous proposons,
dabord, la mthode Model Driven - ERP Alignment permettant de (1) guider finement lidentification du nonalignement sur la base de la norme de modlisation dentreprise ISO 19440 ; (2) dvaluer son effet et (3) dy associer les
dcisions adquates. Elle prend galement en compte le niveau de granularit des activits ainsi que leurs
interdpendances. Nous proposons galement lapproche Risk-Factor Driven - ERP Alignment . Elle consiste en une
dmarche didentification et de traitement des facteurs de risque (FR) sur la base des outils suivants : variables des FR,
matrice des liens rsiduels entre FR, classification des FR en fonction du cycle de vie du projet ERP et matrice FR /
pratiques de gestion. Ce travail tant co-financ par la Rgion Alsace et une PME de la Rgion Strasbourgeoise, nous
avons adopt une dmarche de recherche / action qui a, entre autres, permis dappliquer et valider nos contributions.
Mots cls : ERP, alignement, projet ERP, risque, management du risque, facteurs de risque
Rsum
In the current context of fierce competition, the Information Systems of SME are increasingly based on off-the-shelf
products like the ERP - Enterprise Resource Planning - systems. As this kind of system offers a generic solution, the
alignment between the companys real needs and the ERP standard functionalities must be ensured. Therefore, we
propose to define the so called Misalignment Risk (MR). Our literature review on project risk management leads us to
propose two complementary strategies to manage the MR allowing its optimization: the first one works on the effect of
the MR and the second one, on its occurrence. Our analysis of the model driven engineering methods, allowing the
implementation of the first strategy, shows that: the alignment processes proposed to identify the misalignment, to
evaluate its effect and to mitigate it are too macroscopic. Concerning the means to implement the second strategy, we
highlight the weaknesses of the tools proposed to support the identification and treatment of the risk factors influencing
the MR. We thus propose, firstly the Model Driven - ERP Alignment method allowing (i) the identification of the
alignment and misalignment situations in a detailed manner and on the basis of the ISO 19440 norm, (ii) the evaluation
of its effect and (iii) its association to adequate decisions. The granularity level and the interdependencies of the
processes activities are also taken into account. Secondly we propose the Risk-Factor Driven - ERP Alignment
approach. It consists in the proposition of a process allowing the identification and treatment of risk factors (RF)
influencing the MR. to succeed in following tools are set up: RF variables, RF residual link matrix, RF life cycle
classification and RF / management practices matrix. As this work is supported by both the Region Alsace and a SME
located near Strasbourg, we follow an action / research approach. It allowed us to apply and validate our contributions.
Keywords: ERP, alignment, ERP project, risk, risk management, risk factors
240

Mamoghli Sarra 2013 ED269

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mamoghli Sarra 2013 ED269

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIT DE STRASBOURG

COLE DOCTORALE Mathmatiques, Sciences de lInformation et de

pour obtenir le grade de : Docteur de luniversit de Strasbourg

Alignement des Systmes dInformation

Professeur, INSA de Strasbourg

Professeur, Ecole centrale de Lille

AUTRES MEMBRES DU JURY :

Table de Matires Gnrale

Chapitre 1 Introduction ...................................................... 1

Systmes dInformation et ERP .............................................................................5

Vision instrumentaliste ................................................................................................... 5

Systmes ERP .................................................................................................8

Echec de projet ERP et alignement ................................................................ 11

Problmatique scientifique ................................................................................... 12

Systmes dInformation dentreprise ...............................................................5

Cycle de vie du projet ERP ............................................................................ 13

Problmatique du Risque de Non-Alignement ............................................... 19

PME et ERP .................................................................................................. 21

Chapitre 3 Etat de lart pour le traitement du Risque de

Mthodes dingnierie dirige par les modles .................................................... 31

Processus dentreprise ................................................................................... 31

Prsentation des mthodes dingnierie dirige par les modles ..................... 43

Conclusion et mise en perspective par rapport au cas dtude ........................ 51

Management des facteurs de risque ..................................................................... 52

Analyse des contributions .............................................................................. 53

Approches de management des facteurs de risque .......................................... 65

Conclusion du chapitre ......................................................................................... 68

Chapitre 4 Model Driven - ERP Alignment .................... 69

Prsentation gnrale de la mthode .................................................................... 69

Six dcisions ..................................................................................................................... 73

Activits du processus dalignement par vue de modlisation ............................ 75

Vue macroscopique du processus dalignement ............................................. 69

Vue intentionnelle ......................................................................................... 76

Vue fonctionnelle .......................................................................................... 78

Vue informationnelle ..................................................................................... 88

Synthse du chapitre ............................................................................................. 90

Chapitre 5 Risk-Factor Driven - ERP Alignment ........... 93

Facteurs de risque influenant le RNA ................................................................ 93

Facteurs de risque de ltape dadquation ..................................................... 94

Outils didentification des facteurs de risque ...................................................... 97

Outil de traitement des facteurs de risque ......................................................... 101

Mise en uvre de la dmarche travers les outils............................................. 103

Synthse du chapitre ........................................................................................... 106

Chapitre 6 Application un cas dtude ........................107

Mthode Model Driven - ERP Alignment .................................................... 108

Dmarche .................................................................................................... 108

Conclusion de lapplication de Model Driven - ERP Alignment ............. 126

Approche Risk-Factor Driven - ERP Alignment ......................................... 127

Dmarche .................................................................................................... 128

Conclusion de lapplication ......................................................................... 139

Chapitre 7 Conclusions et perspectives ..........................141

Liste des publications de lauteur....................................................................... 156

Cycle de vie du projet ERP et de lERP dans la littrature............................... 157

Mthodes dalignement et de confrontation....................................................... 158

Sources des facteurs de risque et de succs ........................................................ 177

Rfrences des liens rsiduels ............................................................................. 191

Confrontation des processus associs aux buts quivalents .............................. 208

Confrontation des processus associs aux buts dcouverts ............................... 226

Liste de Figures ................................................................................................... 235

Liste de Tableaux ................................................................................................ 238

Ce mmoire est organis en 5 chapitres :

didentifier finement les situations dalignement et de non-alignement entre les modles

Chapitre 2 Contexte de recherche et problmatique

Chapitre 2 Contexte de recherche et