Mécanismes de transfert de connaissances en - Archipel

Transcription

UNIVERSITÉ DU QUÉBEC À MONTRÉAL
MÉCANISMES DE TRANSFERT DE CONNAISSANCES EN PHASE
POST-IMPLANTATION D'UN SYSTÈME ERP:
UNE ÉTUDE EXPLORATOIRE
MÉMOIRE
PRÉSENTÉ
COMME EXIGENCE PARTIELLE
DE LA MAÎTRISE EN GESTION DE PROJET
PAR
MATHIEU COURCHESNE
JUILLET 2014
UNIVERSITÉ DU QUÉBEC À MONTRÉAL
Service des bibliothèques
Avertissement
La diffusion de ce mémoire se fait dans le respect des droits de son auteur, qui a signé
le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles
supérieurs (SOU-522 - Rév.01-2006). Cette autorisation stipule que «conformément à
l'article 11 du Règlement no 8 des études de cycles supérieurs, [l 'auteur] concède à
l'Université du Québec à Montréal une licence non exclusive d'utilisation et de
publication de la totalité ou d'une partie importante de [son] travail de recherche pour
des fins pédagogiques et non commerciales . Plus précisément, [l 'auteur] autorise
l'Université du Québec à Montréal à reproduire, diffuser, prêter, distribuer ou vendre des
copies de [son] travail de recherche à des fins non commerciales sur quelque support
que ce soit, y compris l'Internet. Cette licence et cette autorisation n'entraînent pas une
renonciation de [la] part [de l'auteur] à [ses] droits moraux ni à [ses] droits de propriété
intellectuelle. Sauf entente contraire, [l 'auteur] conserve la liberté de diffuser et de
commercialiser ou non ce travail dont [il] possède un exemplaire. »
REMERCIEMENTS
J'aimerais tout d'abord remercier mon directeur de recherche, Sylvain Goyette, qui
m'a proposé, à l'automne 2012, de participer à un projet de recherche sur la phase
post-implantation des systèmes ERP. Cette proposition m'offrait un sujet de mémoire
qui était aligné avec mes intérêts et un terrain de recherche pour la collecte de
données. L'encadrement qu'il m'a offert tout au long de ma démarche fut d'une
grande aide pour le chercheur néophyte que j'étais. En plus de l'impact important sur
le livrable que vous avez présentement entre les mains, cet encadrement a permis
d'éliminer ou du moins réduire les doutes auxquels j'ai eu à faire face .
Je tiens aussi à remercier les membres de mon jury, Y gal Bendavid et Luc Cassivi,
sachant que leur horaire du temps est très chargé et que c'est leur intérêt pour la
recherche qui les a poussés à accepter. J'aimerais aussi remercier Brian Hobbs et
Hélène Sicotte du corps professoral de la maîtrise en gestion de projet de l'UQAM
qui m'ont transmis leur passion pour la gestion de projet et qui m'ont aidé à
développer une rigueur scientifique.
La liste de personnes qui m'ont aidé directement lors de la rédaction de mon mémoire
est assez courte. Ma propension à vouloir toujours me débrouiller seul explique un
peu cette situation. Par contre, je sais que plusieurs personnes de mon entourage
auraient accepté sans réfléchir de contribuer au processus si j ' avais fait la moindre
petite .demande.
J'aimerais remercier tous ceux qui m'ont encouragé lorsque j'ai décidé de mettre un
terme à ma première carrière professionnelle pour retourner aux études. Ceux qui ont
vu cela comme un geste courageux qui me permettrait d'atteindre de nouveaux
11
objectifs et non comme un cuisant échec. Finalement, j ' aimerais remercier mes
proches; collègues, amis, famille et dulcinée, qui ont enduré mes sauts d'humeur qui
se manifestaient parfois lors des périodes importantes de stress.
TABLE DES MATIÈRES
LISTE DES FIGURES .. ..... ..... ....... ... .... .. ... ... ......... ... ...... ..... ..... .. ....... .... ........................ ... .. vi
LISTE DES TABLEAUX .. ..... ... .... .... .......... .. .... .... ...... .. ............ .. .. .. ....... .......................... . vii
RÉSUMÉ ........ ..... ... ... ... ......... .... .... ............ .... ............... .. ..... ................. .. .. ...... ........... .... .. . viii
INTRODUCTION ............... .. ..................... .. .. .... ....... ... ... .. .. ....... ... ..... ... ... ................... ....... . 1
CHAPITRE I
REVUE DE LITTÉRATURE .......................... ...... ... .. ........... ............... .. .. ......... ....... .......... .. 5
1.1 · Les systèmes ERP .............. ..... ......... ..... ........ ...... .......... .. .... .......................... ...... ......... 5
1.1.1
La phase post-implantation ........................ .. ... ... .................................. .... .. .... 9
1.1.2
Activités de support et activités d' évolution en phase post-implantation ....... 12
1.2 La gestion de proj et ...... ...... ............................................ ................... .......... ..... .......... 14
1.2.1
Projet: une définition ....................... ..... ..... ..... ....................... .. .......... ...... ... 15
1.2.2
Cycle de vie d'un projet .... .... .... ............... .. .................... ,..... .. ........ ....... .... .. 16
1.2.3
Leçons apprises ................... .. ................. ... .. ..... .......... ........... ........... .... ... .. .. 17
1.3 Transfert de connaissances .. ....... ....................................................... .. .................. ... .. 18
1.3 .1
Les mécanismes de transfert de connaissances ........................................ ..... 20
1.3 .2
Classification des mécanismes ... ... .. .. ............................. ............. ........ ......... 28
1.3.3
Facteurs facilitants et banières au transfert de connaissances ........... .... .. .. .... 30
1.4 Transfert de connaissances lors des projets d'évolution ERP ............... ... .. ...... .. .. .. ....... 32
1.4.1
Équipe projet et équipe support dans un environnement ERP ....................... 33
1.4.2
Les connaissances techniques et fonctionnelles des systèmes ERP .. ............. 34
CHAPITRE II
CADRE D'ANALYSE .. .... ..................................... ............. ... ............ ......... ...................... 37
CHAPITRE III
MÉTHODOLOGIE DE RECHERCHE ............................... ............. .. .. ...... ......... ............... 42
3.1 Approche de la recherche ......... ........ ... .... ................. .. ..................... .. ......................... 42
3.2 Échantillonnage .......................................................................................................... 43
3.3 Collecte de données .. ... ..... .......... ................................................................................ 44
3.4 Analyse des données ................................................................................................... 46
3.5 Fiabilité et validité externe ......... .......... ... .. ... .. .. .. ... .. ....... .................... .. ..................... .. 47
lV
CHAPITRE IV
DESCRIPTION DES CAS .. .............. .... ......... .. .. .... .. ........ .... .. .. .................... .. ........ .. .. ....... . 49
4.1 Organisation A ... ... ................. .. ..... .............. ...... ..... .. ...... .. ...... .. .. ............. ............ ... .... 49
4.1.1 Les répondants ......... ..... .... .... ...... .................... .. ... ......... .. ......... ... ......... .... ..... ..... 50
4.1.2 Structure d'exploitation du système intégré .... .. .... ........ ................ .. ............ ........ 50
4.1.3 La phase d' investigation .......... ........ .. .. .... .............. .. ...... .. .... .... .. ....................... . 55
4.1.4 La phase planification .. ...... ........ .. .. .. ...... .. .. .............. .... ................ .. .... .. ...... .. .. .... 55
4.1.5 La phase de réalisation .. .. .. .. .... .... .. ............................ .. ...................... .. ............... 57
4.1.6 La phase des tests d'acceptation .. .......... ...... ... ... ... .. .. .... .. .. .. ... ......... ............. ....... 57
4.1. 7 La phase de mise en production ... ... .... ...... ... .............. .. .............. ............. .... ..... .. 58
4.1.8 La phase post-implantation .. .. .. .... .. .. .. .. .... ................ .... .... .. ...................... .. ...... .. 59
4.2 Organisation B ........... .... .. .. : ... ... ........ .. ............ .. ...... .. ....... ........ .. ... ...... ... .. .. ..... .... .. ..... 60
4.2 .1 Les répondants ...... .... ........... ......... ....... .. ........ ... ... .... ... ...... ... .... .......... ..... ... .... .. .. 61
4.2. 2 Structure d'exploitation du système intégré .. .. ........ .......... ........ .. .. .. .. .. .. .. .. .. ....... . 62
4.2.3 La phase d'identification .. ............................. .. ......... ... ... ....... ....... ......... .. ... ....... . 67
4.2.4 Les phases de conception préliminaire, conception détaillée et de tests .. .. .... .... .. . 68
4.2.5 La phase de mise en production .. ..................... ...... .............. .... .... .. .. .................. 69
4.2 .6 La phase post-implantation ........ .. .......... .................. .... .................. .. ........ .......... 69
4.3 Organisation C ......... ... ......... .............. ..... ... .. .. ..... .. ... ....... ....... ..... .. ...... .. .. ......... ... .. ..... 70
4.3 .1 Les répondants ....... .. ... .... ..... .. ....... ... ........................ ........... ... ........ ....... .. ........ .. . 71
4.3 .2 Structure d'exploitation du système intégré ..... .. ....... ... ......... .. ....... .... .... ... .. .... ... . 73
4.3.3 La phase d' analyse préliminaire .......... .. .. .... ...... ............ ...... .. .... .. .............. .... ..... 78
4.3.4 Les phases de développement et de tests intégrés .... .. .. .... .. .. .. .. .... .. .. ...... ........ .. ... 79
4.3 .5 La phase des tests d'acceptation .... ...... .............................. .. ...... .. .......... .. .. .. .. ..... 79
4.3.6 La phase de mise en production .......... .. .. .......... .............. .. .... .. .. .................. .. .. ... 80
4.3 .7 La phase post-implantation .... .. ............ .. ........ ............ .. .... .. ............ .. .. .. .. .. .... .... .. 81
CHAPITRE V
COMPARAISON DES CAS ...... ..... ... ... .. ...... ............ ... ...... .... .. .. .... ... .... .. .. ...... ...... ... ... .. ..... 82
5.1 Structure d'exploitation du système ERP ........ .. ............ .... .............. .. .... .. .. ........ ........ .. 82
5.1.1 La centralisation de la structure d' exploitation .. .. .... .. ........ .. .. .... ........ .. .. .. .. .. ....... 85
5.1.2 La localisation des ressources ................ .. .. .. .... .. .. .. ................ .... .... .. .... .. .... ...... .. 86
5.1.3 L'assignation des ressources TI.. ...... .... .. ........... .......................... .. .......... .. .. .. .. .. . 89
- - - - - -- - - - -- - -
v
5.2 Les projets d'évolution ERP .......... ... .. .. .......... .. ... ............ ..... ......... ...... .... ..... .. .. .. ........ 92
5.2.1 Le rôle de l'intégrateur principal ...... .. ................ ...... .. .......... .. ..... ... .................... 93
5.2.2 La phase post-implantation des projets d'évolution ERP ... ......................... .. ...... 96
5.3 Les mécanismes de transfert de connaissances formels ... ........................... .. .. ... .......... 99
5.3.1 Transfert de connaissances techniques : équipe support vers équipe projet.. ....... 100
5.3.2 Transfert de connaissances techniques : équipe projet vers équipe support... .... .. 101
5.3.3 Transfert de connaissances fonctionnelles: équipe support vers équipe projet .... 102
5.3.4 Transfert de connaissances fonctionnelles : équipe projet vers équipe support ... 104
5.3. 5 Les facteurs de choix des mécanismes de transfert de connaissances formels ..... 106
5.3.6 Efficacité des mécanismes de transfert de connaissances formels .. ... .. .. ... .. ....... 108
5.4 Les mécanismes de transfert de connaissances informels ........... ...... ..... .... .......... .. ..... 109
5.4.1 Influence de la structure organisationnelle sur les interactions sociales .. .. .. ....... 112
5.5 Comparaison du cadre d'analyse avec les résultats obtenus ........................ ........... ..... . 114
CONCLUSION ........ .. .............. .... ..................................... .. ..... ...... .. ... .... ..... ..... ..... ...... ..... 118
Les contribu ti ons .... ....... ....... .. .......................... ... .. ............... .... ... ...... .. .................. .. ... ....... 118
Les limites de la recherche ........... ... .. .... ......... ........ ............ ... ....... .................. .. ........... ... ... 119
Pistes pour recherches futures .. ...... .... ...... ... ... ......... .. ..... .................................... .. .. .. .. ... .. ... 120
ANNEXE A: GUIDE D'ENTREVUE- GESTIONNAIRE DE PROJET ................. .... .... 123
ANNEXE B: GUIDE D'ENTREVUE -MEMBRE DE L'ÉQUIPE TI ...... ... .. .................. 124
ANNEXE C: GUIDE D'ENTREVUE- CLIENT INTERNE .. .. ................................ .. ..... 126
ANNEXE D : GUIDE D'ENTREVUE- GESTIONNAIRE DE PORTEFEUILLE .. ......... 128
RÉFÉRENCES .............. .. ........................... ..... ....... ........ ...................................... .. .......... 130
-
-
LISTE DES FIGURES
Figure
Page
1.1
Les activités de maintenance ERP ............. . .................... ...... ..... . .... .
13
1.2
Effort potentiel par activités de maintenance ...... ......... .... .. .. .... . ....... . .
14
1.3
Classification des mécanismes de transfert. .... . .......... .. . . ...... ... .......... .
29
1.4
Degré relatif d 'atteinte et de richesse des mécanismes . ...... ..... ... . .......... .
29
2.1
Cadre d'analyse ... .. ... ....... .. . ...... .. .... ..... ........... . ...... .... .... .... ... .... .
38
2.2
Le cycle de vie d'un système ERP . ..... . .... . . .... ............. .. ... ....... .... .. . . .
40
4.1
Processus de transfert de connaissances entre l'équipe projet et l'exploitation
de l'organisation A .. ....................... .. . ... ... . . .. .. ......... ................... .
54
Processus de transfert de connaissances entre l' équipe projet et l'exploitation
de l'organisation B ......................... . . ... . . .. . .. ............ ................... .
66
Processus de transfert de connaissances entre l' équip e projet et l' exploitation
de l'organisation C .... . ...... . . ......... ... .................... ........ . . . .... ..... .. . .
77
5.1
Structure d'exploitation du système ERP de l'organisation A ... ....... . ..... ... .
83
5.2
Structure d'exploitation du système ERP de l'organisation B .. ... .. . ........... .
83
5.3
Structure d'exploitation du système ERP de l'organisation C ....... ... ..... .... .
84
5.4
Comparaison des structures d'exploitation ERP .............. ... ...... . . ......... .
84
5.5
Mécanismes de transfert de connaissances formels par organisations .......... .
100
4.2
4.3
LISTE DES TABLEAUX
Tableau
Page
1.1
Catégories des sujets abordés par la littérature ERP .. .. .. ........ .. ..... .. . . . . .
8
1.2
Contribution des auteurs concernant la phase post-implantation ERP . ..... .
10
1.3
Phase du cycle de vie de la gestion de la connaissance . .. . . . .. . . ... . . .. . . ... .. .
19
1.4
Les mécanismes de transfert de connaissances . ... ..... . . .. .... . ..... .... . . ..... .
21
1.5
Les barrières au transfert de connaissances .. . ..... .......... . . . . . . . . ... .. . ..... ..
32
3.1
Les stratégies d'interprétation de données ... . .. .. . ... . . . ... . . . .... . .. .. .. .. . . .. .
46
4.1
Les activités et mécanismes de transfert de connaissances de
l'organisation A . ........... ... .... .. .. . . . ... . .. . ....... . .. . ....... . . .. ... . . ..... . .. . .
53
4.2
l'organisation B . .... . . . ..... . ........ ... .. .. .... .. ...... .. . ... . ... ............ . . .. .. .
65
4.3
l' organisation C . . . .. ...... .. . ...... .. ... .. ... .... ...... . . .. ... . ..... . ... . .. . .. ... . .. .
76
5.1
Utilisation par les organisations des mécanismes proposés dans le cadre
d'analyse initial. .. ..... . .... . ........ .. . . .. .... . . ... . . .. ...... ................. . ... . .
115
RÉSUMÉ
Plusieurs organisations décident d'implanter un système ERP (Enterprise Resource
Planning) afin d'améliorer _la gestion de leur entreprise. Malheureusement, les
résultats ne sont pas toujours au rendez-vous. En plus du taux d'échec alarmant lors
de l'implantation initiale, plusieurs organisations se rendent compte que les
performances obtenues à la suite de cette implantation ne sont pas celles qui étaient
espérées. Lors de la phase de post-implantation, une série de projets évolutifs doivent
être exécutés afin de s'assurer que le système soit et reste aligné avec les besoins
d'affaires de l'entreprise. Ces projets peuvent être des ajouts de module et de
fonctionnalités par les utilisateurs du système ou des mises à jour du système par les
fournisseurs. En parallèle de cette dynamique d'évolution, les fonctionnalités en
opération nécessitent la mise en place d'une structure de support pour régler les
anomalies et pour effectuer des améliorations mineures aux systèmes.
Ainsi, tout au long du cycle de vie du système ERP, des connaissances techniques et
fonctionnelles liées au système sont créées au niveau des projets et du support. Dans
cette optique, il doit y avoir un transfert des connaissances entre les équipes de projet,
de nature temporaire, et les équipes de support, de nature permanente.
Cette recherche vise donc à comprendre comment les organisations réussissent à
transférer et gérer leurs connaissances foncti01melles et techniques du ERP entre les
équipes de projet et l'équipe de support dans une dynamique d'évolution. À l'aide
d'entrevues semi-directives centrées, une étude de cas multiples au sein de trois
organisations fût conduite.
L'analyse des données a permis de mieux comprendre les échanges entre les équipes
de projet et l'équipe de support, tant au niveau des connaissances fonctiom1elles que
techniques. Plus spécifiquement, cette recherche a mis en lumière le rôle des
différents mécanismes de transfert de connaissances en fonction de la nature des
informations et de l'objectif des transferts. Enfin, cette recherche a confirmé
l'importance de la structure d' exploitation du système ERP sur l'applicabilité des
mécanismes du transfert de connaissances.
Mots clés : système ERP, progiciel de gestion intégré, mécanismes de transfert,
transfert de connaissances, post-implantation, structure organisationnelle.
INTRODUCTION
Le taux d' adoption par les organisations des progiciels de gestion intégrés (PGI),
mieux connu sous leur appellation anglaise Enterprise Resource Planning (ERP), est
élevé. Selon Liang et al. (2007), 70% des moyennes et grandes entreprises ont
implanté un tel système. Les revenus du marché mondial du ERP ont été estimés à 65
milliards de dollars US en 2010 (Madapusi et D'Souza, 2012). La définition d 'un
système ERP diffère d'un auteur à l'autre. Pour Gable et al. (2001 p.352), il s' agit
d' « un système informatique visant à intégrer la gamme complète des processus
d'affaires de l'entreprise dans le but de présenter une vision holistique de l'entreprise
via un seul système et une seule infrastructure informatique ». D' autres auteurs
prennent en considération la possibilité que ce ne soit pas toutes les fonctions de
l' entreprise qui soient intégrées (Gattiker et Goodhue, 2005), du moins pas en une
seule étape (McGinnis et Huang, 2007).
L' idée de pouvoir réunir tous les processus de l'entreprise en un seul système
informatique motive les
organisations à implanter un système ERP. Cependant,
l' implantation d 'un tel système demande d ' importants investissements fmanciers et
beaucoup d' efforts de la part des ressources impliquées (S aatçioglu, 2009) . Le taux
d' échec des implantations de ce type de système est alarmant. Dans un article paru
en 2000, Davenport (2000) mentionnait que 90% des projets d'implantation ERP
dépassaient les délais ou le budget initial et que 67% de ces projets étaient considérés
comme des expériences négatives ou des échecs. Selon un rapport publié par
Panorama Consulting Solutions (2013), la situation ne s' est pas améliorée depuis . Un
sondage réalisé en 2012 dans le cadre de ce rapport, révèle des dépassements de coûts
de l'ordre de 53% du budget initial et des délais représentants 60% de la durée
estimée initialement. Ce rapport révèle aussi que 60% des entreprises sondées
considèrent avoir obtenu 50% ou moins des bénéfices espérés. De plus, plusieurs
2
systèmes ERP sont abandonnés peu après leur implantation (Scott et Vessey, 2002).
Ces échecs peuvent provenir de la sous-utilisation du système au début de la phase de
post-implantation (Chou et al., 2014). Parmi les organisations qui n'abandonnent pas
leur système, 25% sont affectées par de faibles performances lors de la phase de postimplantation (Muscatello et Parente, 2008). Une autre raison qui explique ces
abandons et ces faibles performances est qu'une grande majorité d'organisations
croient que l'implantation initiale du système ERP représente une fmalité en soi
plutôt qu'une étape du cycle de vie de ce système. Les systèmes ERP implantés
restent rarement statiques, plusieurs activités d'amélioration sont généralement
requises pour assurer la longévité de ces dispendieux systèmes (Jones et Priee, 2004).
L'installation d'un ERP sera donc suivie de plusieurs initiatives relatives à
l'évolution du système (Hirt et Swanson, 2001). Selon Gable et al. (2001), l'évolution
d'un ERP est constituée de multiples itérations, telles des révisions, des
réimplantations ou des mises à jour. Pour certaines organisations, l'implantation des
modules doit être graduelle pour tenir compte des défis liés à l'intégration
(Rothenberger et al., 2010). Ultimement, l'enjeu premier de l'évolution des ERP est
de s'assurer que ce dernier soit aligné sur les besoins d'affaires présents et futurs de
l'organisation (Hirt et Swanson, 2001). On peut donc constater qu'un des facteurs de
succès des ERP repose sur 1' intégration de ces différentes initiatives d'évolution pour
atteindre un alignement stratégique optimal.
Plusieurs auteurs (See Pui Ng et al., 2002 ; Wenrich et Ahmad, 2009) considèrent
toutes les activités exécutées en phase post-implantation comme étant des activités de
maintenance peu importe que ce soit des initiatives d ' évolution ou des activités de
support. En effet, Wenrich et Ahmad (2009) ont identifié que certaines activités de
maintenance ERP doivent être gérées comme des projets pour être réussies. En
contrepartie, on reconnaît que le support des ERP demande une structure permanente
pour répondre aux besoins continuels des usagers. Ainsi, les organisations doivent
3
intégrer des initiatives d'évolution de nature temporaire, tout en supportant la solution
globale. McGinnis et Huang (2007) mentionnent que le succès des équipes de projet
repose sur leurs connaissances de 1' environnement actuel du ERP, ainsi que · des
activités d'évolution et de support qui s'y rattachent. Ils mentionnent aussi que pour
soutenir efficacement les usagers, le groupe de support a besoin de connaître la
nature des décisions relatives à l'évolution du ERP, ainsi que des raisons qui
expliquent ces décisions. L ' adoption d'un mode de gestion par projet pour accomplir
certaines initiatives d'évolution rend la gestion des connaissances plus ardue, car
l'équipe du projet est habituellement dissoute à la suite de la clôture du projet
(Lindner et Wald, 2011).
La problématique d ' intégration des activités de gestion des solutions ERP se situe
entre autres au niveau de la gestion des connaissances. D'une part, nous avons besoin
d'un transfert des connaissances actuelles vers les projets d' évolution et d'autre part,
nous avons aussi besoin du retour de connaissances des projets pour effectuer le
support continu du ERP. La nature des connaissances est également importante pour
gérer un ERP. En effet, on trouve des connaissances fonctimmelles liées aux
processus d' affaires de l' entreprise en plus des connaissances teclmiques du système
(Gallagher et al. , 2012). La gestion des connaissances constitue donc un processus
critique pour la pérennité des systèmes ERP (McGinnis et Huang, 2007).
En tenant compte de la problématique de transfert de connaissances présentée dans la
section précédente, la recherche à comme objectif de comprendre comment les
organisations réussissent à transférer et gérer leurs connaissances fonctionnelles et
techniques du ERP entre les équipes de projet et l'équipe de support. Quatre sousquestions se rattachent à cette question principale :
•
Quels sont les mécanismes de transfert de connaissances utilisés par les
organisations ?
4
•
À quelles phases des projets d'évolution s'effectue le transfert de
connaissances?
•
Dans quelle direction s'effectue le transfert de connaissances (équipe projet
vers équipe support et/ou équipe support vers équipe projet)?
•
Quels sont les éléments qui influencent le transfert de connaissances?
La présente recherche est composée de six chapitres. Le premier chapitre présente
une revue de la littérature existante sur les différents thèmes exposés dans la
problématique de recherche. Ce chapitre abordera les fondements théoriques
concernant les systèmes ERP, la gestion de projet et le transfert de connaissances. Le
chapitre II propose un cadre d'analyse permettant de bien positionner les éléments qui
seront considérés lors de la collecte de données et lors de l'analyse de ces données.
Le chapitre III présente la méthodologie utilisée dans le cadre de cette recherche. Il
explique l'approche utilisée, ainsi que les choix relatifs à l' échantillonnage, à la
collecte de données et à l'analyse des données. Les trois organisations participant à
cette recherche seront présentées au chapitre IV. Une description détaillée des
répondants, de la structure d'exploitation du système ERP et du processus de transfert
de connaissances est présentée pour chacune des organisations. Dans le chapitre V,
une comparaison est effectuée entre les trois différents cas étudiés. Cette comparaison
inter-cas permet de faire ressortir et d'analyser les principaux éléments du processus
de transfert de connaissances, ainsi que les principaux éléments qui influencent ce
transfert. Finalement, le chapitre VI présente les contributions, les limites de la
présente recherche et propose des pistes pour de futures recherches.
CHAPITRE I
REVUE DE LITTÉRATURE
1.1 Les systèmes ERP
Plusieurs auteurs proposent des définitions différentes de ce qu'est un système ERP,
car cette application est modulaire (Tomas, 2007). En plus des définitions énumérées
en introduction, on peut ajouter celle de Salmeron et Lopez (20 10), qui stipulent
qu 'un ERP est un logiciel unique qui permet l' intégration complète des flux
d'information en provenance des différentes fonctions de l'entreprise à l'aide d'une
base de données unique accessible via une interface et un canal de communication
unifiés. Tomas (2007) utilise deux dimensions pour comparer les ERP, soit le degré
d'intégration et la couverture opérationnelle.
Le degré d'intégration «définit la
capacité à fournir à l'ensemble des acteurs de l'entreprise une image unique, intègre,
cohérente et homogène de l'ensemble de l' information dont ils ont besoin pour jouer
pleinement leur rôle » (Tomas, 2007 p.11 ). Tandis que la couverture opérationnelle
« défmit la capacité de fédérer l'ensemble des processus de l'entreprise dans chacun
des domaines qui la constitue, et ce, dans une approche transversale qui optimise sa
productivité» (Tomas, 2007 p.11 ). Le degré d'intégration et la couverture
opérationnelle peuvent évoluer tout au long du cycle de vie des ERP en fonction des
modifications apportées au système. Ces deux dimensions permettent de situer les
définitions de système ERP proposées par les différents auteurs. Certaines défmitions
suggèrent que le degré d'intégration et la couverture opérationnelle doivent être total
(Gable et al. , 2001 ; Salmeron et Lopez, 2010), tandis que d'autres tiennent compte
6
du fait que ces deux dimensions peuvent se situer à différents mveaux selon
l'organisation (Gattiker et Goodhue, 2005 ; McGinnis et Huang, 2007). Bien que ces
deux dimensions peuvent varier d'une entreprise à l' autre, pour qu'il soit considéré
intégré, le système doit provenir d'un concepteur unique, garantir 1'unicité de
l' information en offrant un accès intégral à la base de données à chaque module,
offrir une mise à jour en temps réel de toute information modifiée, peu importe le
module d'où provient cette modification, offrir une traçabilité globale des opérations
de l'entreprise et couvrir au minimum une fonction de l' entreprise (Tomas, 2007).
Une revue de la littérature concernant les articles publiés sur les systèmes ERP entre
2003 et 2004, a permis à Botta-Genoulaz et al. (2005) de classer les sujets abordés par
ces articles en six catégories qui offrent un bon aperçu des sujets de préoccupation
des chercheurs intéressés par les ERP. Ces six catégories sont l'implantation du
système, l'optimisation du système, la gestion à l'aide du système ERP, le logiciel
ERP, la gestion de la chaîne d'approvisionnement à l'aide du système ERP et les
études de cas. La catégorie implantation du système conceme les différentes étapes
liées à l'implantation du système, les problèmes liés à ces étapes, les conditions de
réussite et les raisons qui expliquent les échecs. Cette catégorie s'intéresse aussi aux
facteurs socioculturels qui interfèrent avec le processus d'implantation et à
l'alignement du système avec les processus d'affaires de l'entreprise. La catégorie
gestion à l'aide du système ERP, rassemble les articles qui s'intéressent aux systèmes
ERP en tant qu ' outil de gestion. Les thèmes abordés par cette catégorie sont la
stratégie d ' adoption du système, l' impact de ce demier sur l' organisation, la
contribution du ERP à la performance de l' organisation, ainsi que les meilleures
pratiques en gestion et leur relation avec le système ERP . La catégorie suivante, le
logiciel ERP, englobe tout ce qui touche au domaine informatique et au traitement de
l' information. Les sujets liés à cette catégorie sont l' architecture du système, les
langages informatiques et les normes d'intégration, les bases de données, la
7
configuration du système et l'utilisation combinée d 'un système ERP avec d 'autres
technologies informatiques. La catégorie gestion de la chaîne d'approvisionnement à
l'aide du système ERP, concerne l'utilisation d'un système ERP dans un contexte
d'interaction entre plusieurs entreprises. Elle aborde l'intégration entre différentes
technologies informatiques et la contribution du système ERP à la coopération à
l' intérieur de la chaîne d 'approvisionnement. La catégorie des études de cas
s'intéresse aux publications dont l'approche méthodologique est l'étude de cas. La
grande majorité d'entre elles abordent les raisons expliquant le succès ou l'échec de
l'implantation et les problèmes d'adaptation des utilisateurs envers le nouveau
système. L 'optimisation du système est la catégorie qui représente le plus grand
intérêt pour la présente recherche. L'optimisation du système prend en considération
le fait que le processus d ' implantation ne se termine pas immédiatement après la mise
en fonction du nouveau système. Cette catégorie met l'emphase sur le retour sur
investissement que doit apporter la mise en place d 'un système ERP en portant
attention à l'utilité du système, la satisfaction des usagers et 1'obtention d'un avantage
concurrentiel. Les projets d'évolution ERP en phase post-implantation se retrouvent
donc dans cette catégorie.
Schlichter et Kraemmergaard (2010) ont publié une autre revue de littérature basée
sur les travaux de Botta-Genoulaz et al. (2005). Ces auteurs sont partis des six
catégories de Botta-Genoulaz et a1.(2005) desquelles ils ont retiré la catégorie des
études de cas, considérant que ce n 'était pas une catégorie de recherche, mais plutôt
une méthode. Ils ont aussi ajouté trois nouvelles catégories de recherche pour un total
de huit (tableau 1.1). Ces nouvelles catégories sont l'étude des ERP, les ERP et
l'éducation et l'industrie et le marché des ERP. L'étude des ERP cherche à
déterminer comment devraient être étudiés les systèmes ERP. Cette catégorie propose
des cadres de recherche, ainsi qu 'un agenda de recherche. La catégorie ERP et
l'éducation, s'intéresse à la formation et l'éducation liées aux systèmes ERP, à savoir
8
Tableau 1. 1
Catégories des sujets abordés par la littérature ERP
(adapté de Botta-Genoulaz et al. (2005) et Schlichter et Kraemmergaard (2010))
Catégorie
Auteurs
Optimisation du système
Orlikowski et Barley (2001)
Ng et al. (2002)
Nicolaou (2004)
Staehr (2010)
Kumar et al. (2003)
Jones et al. (2004)
Wei et al. (2005)
Ngai et al. (2008)
Dezdar et Sulaiman (2009)
Implantation du système
La gestion à l'aide du système ERP
Le logiciel ERP
La gestion de la chaîne d'approvisionnement
à l'aide du système ERP
L'étude des ERP
Les ERP et 1' éducation
L'industrie et le marché des ERP
Kumar et al. (2002)
Gattiker & Goodhue (2004)
Mauldin & Richtermeyer (2004)
Falk (2005)
Huq et al. (2006)
Volkoff (2003)
Choi et al. (2004)
Kim (2004)
Zhang et al. (2006)
Liu et al. (2002)
Verwijmeren (2004)
Chen et Chen (2005)
Lenny Koh et al. (2006)
O 'Leary (2002)
Botta-Genoualez et al. (2005)
Sutton (2006)
Esteves et Bohorquez (2007)
Nielson (2002)
Bradford et al. (2003)
Antonucci et al. (2004)
Boyle (2007)
Bennett et Timbrell (2000)
Ekanayaka et al. (2002)
Tarafdar et Roy (2003)
Kostopoulos et al. (2004)
9
comment inclure cela dans les programmes universitaires. La catégorie l'industrie et
le marché des ERP englobe tout ce qui est en lien avec le marché des ERP tel que
l' évolution du marché, les parts de marché par fournisseur et le taux d'adoption par
industrie.
La littérature scientifique concernant les systèmes ERP a connu une croissance
significative lors des dernières années (Botta-Genoulaz et Millet, 2005 ; Schlichter et
.Kraemmergaard, 2010). Bien que la grande majorité des publications s'intéressent à
la phase d'implantation, on dénote un intérêt grandissant pour la phase postimplantation (Botta-Genoulaz et al., 2005). Cet intérêt est souligné par la catégorie
optimisation du système présente dans les deux revues de littérature. Tout comme la
présente recherche, cette catégorie s'intéresse à la phase post-implantation des
systèmes ERP.
1.1.1
La phase post-implantation
La phase post-implantation débute lorsque le système ERP est disponible aux
utilisateurs et se termine lorsque le système cesse d'être utilisé, c'est donc dire
jusqu'à la fm de son cycle de vie (Yu, 2005). Les auteurs qui s'intéressent à la phase
post-implantation du système ERP font pratiquement tous le même constat; il y a peu
de littérature qui s'intéresse à cette dernière (Gable et al., 2001 ; Ifinedo et al., 2010;
Law et al. , 2010 ; Wenrich et Ahmad, 2009). Plusieurs sujets sont traités par les
auteurs qui s'intéressent à cette phase (tableau 1.2). See Pui Ng et al. (2002) traitent
des activités de maintenance des systèmes ERP. Ils proposent une définition claire de
la maintenance ERP. Selon les auteurs, les taxonomies actuellement utilisées pour
expliquer la maintenance des logiciels ne permettent pas de décrire suffisamment la
10
Tableau 1. 2
Contribution des auteurs concernant la phase post-implantation ERP
Auteurs
Contribution
Gable et al. (200 1)
Facteurs impactant la gestion de la maintenance
Gallagher et al. (20 12b)
Importance des mécanismes de coordination
horizontale lors de la phase post-implantation
Hirt et al. (200 1)
Distinction entre la maintenance des logiciels
traditionnels et la maintenance des systèmes ERP
Law et al. (20 10)
Importance de planifier la phase post-implantation
Mcginnis et Huang (2007)
La gestion des connaissances et l'amélioration
continue en tant que facteurs de succès
Nah et al. (2001)
Identification des activités de maintenance ERP
Salmeron et Lopez (20 10)
Risques liés à la maintenance des ERP
See Pui Ng et al. (2002)
Nouvelle taxonomie des activités de maintenance
ERP
Volkoffet al. (2004)
Le rôle de l'utilisateur expert dans les activités de
transfert
maintenance ERP. Ils proposent donc une nouvelle taxonomie, orientée sur les
bénéfices, qui permet de mieux représenter les activités de maintenance ERP. Hirt et
Swanson (2001) abondent dans le même sens en révélant que les rôles et relations
lors de la maintenance d'un système ERP diffèrent substantiellement de la
maintenance de logiciels traditionnels, et ce en raison de la nature des connaissances
requises. Gable et al. (200 1) s' intéressent aux facteurs qui ont un impact sur la
gestion de la maintenance, tels que la source du logiciel, la source du support,·
l'organisation et le contexte environnemental. Leur étude analyse ces facteurs du
point de vue de quatre parties prenantes différentes; les utilisateurs, le fournisseur
logiciel, les consultants externes et l'organisation. Nah et al. (200 1) identifient les
différentes activités de maintenance qui surviennent à la suite à l'implantation d'un
système ERP, les catégorisent tout en établissant leur fréquence relative.
. 11
De leur côté, Law et al.
(2010) démontrent que les organisations qui négligent
d'incorporer les éléments liés à la phase post-implantation, lors des phases précédent
l'implantation, risquent de mettre en péril les opérations normales et les activités
journalières de l'entreprise suite à l'implantation. Gallagher et al. (2012) mettent
l'emphase sur l'importance des mécanismes de coordination horizontale en phase
post-implantation. Leur étude cherche à identifier les facteurs qui affectent le choix
de la structure de support mise en place par l' organisation. McGinnis et Huang (2007)
stipulent que le succès d'un système ERP passe par la gestion des connaissances et
l'amélioration continue.
Les connaissances relatives au système ERP
sont
primordiales en phase post-implantation étant donné que le système ne restera pas
statique, mais évoluera constamment. Volkoff et al. (2004) étudient le transfert de
connaissances entre l' équipe de développement et les utilisateurs fmaux suite à la
mise en opération du système ERP. Leur publication met en lumière le rôle de
l'utilisateur expert dans les activités de transfert. Pour leur part, Salmeron et Lopez
(20 10) se concentrent sur les risques liés à la maintenance du ERP. Les auteurs
stipulent que l'étape cruciale de la maintenance est celle où l'on reçoit, identifie,
classe et priorise les demandes de modification.
La maintenance du ERP semble être un sujet important pour les auteurs qm
s'intéressent à la phase post-implantation (Gable et al., 2001 ; Hirt et Swanson, 2001
; Law et al., 2010 ; Nah et al. , 2001). La maintenance du ERP inclut plusieurs
activités. La prochaine sous-section permettra de faire une distinction entre les
différents types d ' activités.
12
1.1.2 Activités de support et activités d'évolution en phase post-implantation
Il y a plusieurs types d ' activités qui ont lieu en phase post-implantation d'un système
ERP . Certains auteurs considèrent comme étant de la maintenance, toutes les activités
touchant le système ERP à partir de son implantation jusqu' à ce qu ' il soit retiré de la
production (See Pui Ng et al. , 2002 ; Wenrich et Ahmad, 2009). Nah et al. (2001)
proposent trois catégories principales d' activités de maintenance; soit
corrective,
adaptative et de perfectionnement. La maintenance corrective sert à corriger les
erreurs en lien avec le design et le code. La maintenance adaptative vise à répondre
aux besoins changeants des utilisateurs, tandis que les activités de perfectionnement
cherchent à améliorer l'efficacité des processus, à améliorer la performance du
système et à mieux répondre aux besoins des clients. Une étude menée par le
Conference Board (Peterson et al. , 2001) sur les tendances ERP énumère sept
activités de maintenance; soit la mise à niveau du logiciel, la personnalisation du
logiciel pour réduire l'écart avec les processus d' affaires, les changements liés à la
modification des processus d'affaires, l' ajout de fonctionnalités, la formation, le
support usager et l' implantation d'un nouveau département ou d 'une nouvelle usine.
Toujours selon cette étude, les mises à jour sont considérées comme étant l' activité de
maintenance la plus difficile à exécuter. See Pui Ng (2001) propose une
représentation graphique des activités de maintenance du système ERP (Figure 1.1 ).
Cette énumération met en lumière le rô le joué par le fournisseur du logiciel dans les
activités de maintenance. En fait, c'est ce qui distingue la maintenance de logiciel
traditionnel et la maintenance de système ERP (Law et al. , 201 0). Le fournisseur du
logiciel peut contribuer au support en offrant son expertise à l' organisation. Il peut
aussi agir en guise d'initiateur des activités de maintenance en offrant des correctifs
ou des mises à niveau du logiciel. Il faut comprendre que les activités de maintenance
représentent un important revenu pour les fournisseurs de logiciel ERP, revenu pour
lequel ils portent un grand intérêt surtout depuis la saturation du marché (Gable et al. ,
2001). Tomas (2007) mentionne deux types d'activités de maintenance, soit le
13
support interne et le support externe . Le support externe est encadré de façon stricte
par un contrat de support liant le fournisseur et l' organisation. Ce type de contrat est
très détaillé au niveau des coûts et du rôle et responsabilités du fournisseur ,
responsabilités qui peuvent résulter en un accès limité au fournis seur lors de la phase
post-implantation. Toujours selon Tomas, le support interne vise trois objectifs
principaux; soit « limiter l'accès au support extérieur fourni par l' éditeur, augmenter
la connaissance [du] ERP à l'intérieur de l'entreprise [et] répondre aux questions des
employés en prenant en compte le contexte et les spécificités des unités
opérationnelles » (Tomas, 2007 p.239).
Maintenance
1
1
1
•
Client ERP
Requête int erne
Initiat eu r:
...
Fou rn iss eu r ERP
Requ êt e externe.
1
,j..
Type d' activités:
Amélioration
1
,j..
Il
Co rrectro n
1
1
,j..
___i_
___i_
Suppo rt
usager
Correcbf
syst ème
Il Mtse à jourj
Figure 1. 1 Les activités de maintenance ERP (adapté de See Pui Ng (2001))
Le fait que les auteurs ne fassent pas de distinction entre les activités de support et les
activités d'évolution démontre 1' intérêt pour la présente recherche. Certaines des
activités de maintenance, énumérées précédemment,
peuvent être considérées
davantage comme des activités d'évo lution. Une recherche empirique a permis
d' identifier les activités qui sont considérées comme de l'évo lution (Botta-Genoulaz
et Millet, 2005). Ces activités sont le déploiement d'une nouvelle fonction,
l'optimisation des outils actuels, l'implantation d 'une nouvelle version, l' implantation
de solutions d'affaires intelligente et le déploiement sur d'autres sites de
1'organisation. Certaines actions correctives peuvent être vues comme étant le
14
prolongement de l'implantation initiale (McGinnis, 2011). En fait, plusieurs
organisations implantent leur système ERP de façon modulaire (Nicolaou et
Bhattacharya, 2006), c'est-à-dire que les fonctions de l'entreprise sont implantées
progressivement. Light (200 1) offre une représentation visuelle de 1' effort requis
selon le type d'activités de maintenance (figure 1.2), qui va de l' ajout d'un nouveau
rapport à la modification d'une fonctionnalité. L'ajout de fonctions ou les mises à
niveaux peuvent représenter un effort considérable qui demande un suivi et contrôle
important au niveau des coûts, de l'allocation des ressources et de l'échéancier
(Wenrich et Ahmad, 2009). Selon les auteurs, la rédaction d'un plan d'affaires peut
s'avérer nécessaire lorsque ces activités sont de grandes envergures. Ces
considérations s'apparentent fortement à la défmition qu ' est fait d'un projet. Il
devient donc pertinent de parcourir la littérature existante en gestion de projet.
Nouveau
Rapport
M od ffic.ation
Rappo rts/Affichage
Ex l:stants
Faible
A.utomatis ati:on
Ajo ut
M odif icat io n
d' un processus
Fonctionnal.ité
Fonctionna lité
Effort de maint enance pot ent ieli
Él'evé
Figure 1. 2 Effort potentiel par activités de maintenance (adapté de Light (200 1))
1.2 La gestion de projet
La recherche en gestion de projet est en constante évolution. D'un domaine dominé
par les praticiens dans les années 70 et par les associations professimmelles dans les
15
années 80, la recherche en gestion de projet a évolué en termes de qualité et de
rigueur depuis les 20 dernières années (Turner, 2010). L'absence de théorie intégrée à
la gestion de projet s'explique par la nature multidisciplinaire du domaine (Smyth et
Morris, 2007). Cette situation fait en sorte qu'un assortiment éclectique de théories et
de concepts est proposé à la communauté en gestion de projet, résultant parfois en
confusion de la part des professionnels (Smyth et Morris, 2007).
1.2.1
Projet : une définition
De nombreuses définitions existent pour expliquer ce qu'est un projet. Le Project
Management Institute (PMI, 2008) le définit comme « un effort temporaire exercé
dans le but de créer un produit, un service ou un résultat unique », tandis que le
British Standards Institute (BS, 2000) le défmit comme « un ensemble unique
d'activités coordonnées, avec un point de départ et un point d'arrivée définis, mené
par un individu ou une organisation dans l'optique d 'atteindre des objectifs de
performance spécifiques en respect de l'échéancier, des coûts et des critères de
performance établis ». Bien que véridiques, ces définitions sont plutôt limitatives.
Premièrement, la définition du PMI ne tient pas compte des projets multisites et elle
ne tient pas compte des projets qui produisent une série de résultats de façon
séquentielle (Bower et Walker, 2007). De plus, les projets sont de plus en plus
complexes et diversifiés, ce qui rend difficile de cadrer l'ensemble des projets dans
une seule et unique définition (May lor et al. , 2006).
La perspective selon laquelle une attention particulière doit être portée à l' action lors
de l'exécution d'un projet, fait tranquillement place à une nouvelle perspective
voulant que l' attention soit aussi portée sur l'apprentissage et la connaissance (Reich
et al., 2008). Cette perspective sort des limites du triangle de fer de la gestion de
16
projet qui porte son attention exclusivement sur l'échéancier, les coûts et la portée
(Atkinson, 1999). Elle stipule que « durant les projets, la connaissance doit être
transférée, intégrée, créée et
exploitée afm de créer de la valeur pour
l'organisation »(Reich et al. , 2008 p.4).
1.2.2
Cycle de vie d'un projet
Chaque projet est découpé en plusieurs phases. Le corpus des connaissances en
management de projet (PMBOK) du Project Management Institute (PMI, 2008)
propose quatre phases génériques, soient le démarrage de projet, l'organisation et
préparation, l'exécution du travail et la clôture du projet. Plusieurs auteurs proposent
différentes terminologies pour identifier les phases d'un projet. Qu 'il s'agisse des
phases de conceptualisation, planification, exécution et clôture (Pinto et Prescott,
1990) ou des phases de germination, de croissance, de maturité et de métamorphose
(Turner, 1999), le cycle de vie du projet se termine toujours par une phase de clôture
qui consiste en majeure partie en la livraison du ou des livrables (Jugdev et Müller,
2005). Le nombre et le nom des phases peuvent différer d'une industrie à l'autre.
Pour l' industrie du développement logiciel, nous allons généralement parler de
conceptualisation, de développement, de tests et de déploiement (Jugdev et Müller,
2005).
À travers leur théorie des organisations temporaires, Lundin et Sôderholm (1995)
proposent leur propre terminologie des différentes phases du cycle de vie d'un projet.
Il s'agit
de la phase entrepreneuriale, la phase de fragmentation, la phase de
l' isolation planifiée et la phase de clôture institutionnalisée. Nous porterons une
attention particulière à la phase de clôture institutionnalisée, phase durant laquelle
l'organisation temporaire se recouple avec l'organisation permanente. Ce recouplage
17
implique un transfert entre les membres de l'équipe projet et l'organisation. C'est ce
pont entre l'organisation temporaire et l'organisation permanente qui permet de créer
un lien entre les différents projets et les opérations de l'entreprise (Lundin et
Soderholm, 1995). Dans le contexte évolutif d'un système ERP, cette situation se
reflète par le transfert de connaissances entre les équipes projet et le support ERP.
1.2.3
Leçons apprises
La littérature en gestion de projet discutant du transfert de connaissances entre les
différents projets de l'organisation est abondante. Les auteurs qui abordent le sujet
parlent généralement de leçons apprises. Le concept de leçons apprises implique
normalement des discussions entre les membres de l'équipe projet, suite à la clôture
de ce dernier, afin de réfléchir à ce qui s'est bien déroulé lors du projet et ce qui s'est
moins bien déroulé (Julian, 2008). Le résultat de ces discussions est par la suite
documenté et généralement conservé dans une base de données accessible à toutes les
équipes de projet (Newell et al., 2006). Selon Newell (2004), ces leçons apprises
devraient être axées sur les connaissances relatives au processus de gestion de projet.
Pour l'auteur, le fait de baser les leçons apprises sur les connaissances produit est une
erreur en soi, car la connaissance produit est unique. Son argumentaire repose sur les
nombreuses définitions de projet qui stipulent que le résultat est unique à chaque
projet. Il n'est donc pas très utile de partager cette connaissance d 'un projet à l'autre
vu la différenciation des produits. Il met l'emphase sur la connaissance relative aux
processus qui est davantage apte à être réappliquée d'un projet à l'autre.
La littérature sur les leçons apprises n'est donc pas pertinente à la présente recherche,
car cette recherche porte sur le transfert de connaissances liées au produit et non sur
18
les connaissances liées aux processus de gestion de projet. La prochaine section
présentera la littérature existante sur le transfert de connaissances.
1.3 Transfert de connaissances
Le transfert de connaissances est une composante de la gestion des connaissances
(Sedera et Gable, 201 0). Donc, avant de défmir le transfert de connaissances, il faut
défmir ce qu'est la connaissance et ce qu'est la gestion de la connaissance.
La connaissance est un processus dynamique, qui permet de transposer certaines
croyances personnelles en une vérité partagée (adapté de Nonaka et al. , 2000 p.3).
Selon les auteurs, la connaissance est dynamique, car elle est créée par une interaction
entre individus. Elle est spécifique au contexte, car elle dépend d'un lieu et d'un
moment. Elle implique aussi un aspect humain, car elle est liée à l' interprétation des
individus. Plusieurs auteurs catégorisent la connaissance en deux types, soit explicite
et tacite (Al-Mashari et al., 2003 ; Lee et Lee, 2000 ; Nonaka et al. , 2000 ; Vandaie,
2008). La connaissance explicite est exprimable via un langage formel, elle est facile
à codifier, à transférer et à conserver (Nonaka et al. , 2000). La connaissance tacite est
personnelle et difficile à codifier, elle est profondément ancrée dans les actions,
procédures, routines, valeurs et émotions (Nonaka et al. , 2000).
«La gestion de connaissance est un processus de capture de l' expertise co llective de
l'organisation à partir de sources multiples (base de données, document, personne) et
d'utilisation de cette base de connaissance au profit de l'organisation» (Sedera et
Gable, 2010 p.3). Les différentes phases du cycle de vie de la gestion de la
connaissance diffèrent d'un auteur à l'autre. Argote (1999) parle de partage, de
génération, d' évaluation et de combinaison. Davenport et Prusak (1998) énumèrent
19
les phases de détermination des besoins, de capture, de distribution et d 'utilisation,
tandis que Szulanski (1996) parle d'initiation, d'implantation, d'accélération et
d'intégration. En se basant sur ces différentes appellations, Sedera et Gable (2010)
regroupent les activités de gestion de la connaissance en quatre phases (tableau 1.3).
La première phase, celle de l'acquisition/ création/ génération, englobe tout ce qui est
lié au processus de création de la connaissance. Cette com1aissance peut être créée par
les ressources internes de l' organisation ou peut être acquise de l' externe en faisant
appel à des spécialistes. La phase de rétention/ entreposage/ capture consiste à
conserver la connaissance dans un référentiel de connaissance s quelconque afin de
permettre à cette connaissance de perdurer dans le temps. La troisième phase, celle du
partage/ transfert/ diffusion, implique l'utilisation de canaux de transfert formels ou
informels qui permet de distribuer la connaissance au sein de l'organisation. La phase
d 'application/ utilisation fait référence à l'utilisation de la connaissance par le ou les
individus auxquels elle a été transférée.
Tableau 1. 3
Phase du cycle de vie de la gestion de la connaissance
(adapté de Sedera et Gable (2010))
Phase
1
Activités
Acquisition 1 Création 1 Génération
2
Rétention 1 Entreposage 1 Capture
3
Partage 1Transfert 1 Diffus ion
4
Application 1 Utilisation
20
Pour Szulanski (1996), le transfert de connaissances est un « échange dyadique de
connaissances organisationnelles entre une source et un récipient dans lequel
l'identité du récipient importe». Cette définition regroupe les activités de la phase 3
du cycle de vie proposé par Sedera et Gable (voir tableau 1.3). D'autres défmitions du
transfert de connaissances font référence à la dernière phase de ce cycle de vie, c'està-dire l'application et l'utilisation. C'est le cas de Argote et Ingram (2000), qui
défmissent le transfert de connaissances comme un « processus via lequel une unité
(groupe, département ou division) est affectée par l'expérience d'une autre unité ».
C'est aussi le cas de Singley et Anderson (1989), pour qui le transfert de
connaissances est l'acquisition de la connaissance dans une situation donnée et son
application dans une autre. Pour effectuer le transfert de connaissances, il faut utiliser
des mécanismes de transfert. Ces mécanismes seront présentés dans la prochaine
sous-section.
1.3.1
Les mécanismes de transfert de connaissances
Les mécanismes de transfert sont les mécanismes formels et informels servant à
partager, intégrer, interpréter et appliquer les c01maissances qui sont ancrées dans les
individus ou les groupes d'individus, et ce afin d'améliorer la performance de
l'organisation (Boh, 2007). Il y a beaucoup d'études qui s'intéressent au transfert de
connaissances, mais très peu qui s ' intéressent aux mécanismes utilisés (Jasimuddin,
2007 ; Persson, 2006). La littérature existante a quand même permis d'identifier
plusieurs mécanismes de transfert (tableau 1.4).
21
Tableau 1. 4
Les mécanismes de transfert de connaissances
Mécanisme
Source
Mouvement de personnel
Galbraith ( 1994)
Almeida et Kogut (1999)
Gruenfeld, Martorana et Fan (2000)
Système de gestion des
connaissances
Bradley et Gao (2007)
Chen et al. (2009)
Merminod et Rowe (2012)
Zhen et al. (2012)
Analyse post-projet
Goffm et Koners (2011)
Formation
Moreland et Myaskovsky (2000)
Communauté de pratique
Davenport et Hall (2002)
Duguid (2005)
Interaction un à un
Jasimuddin et Zhang (2009)
Mentorat
Swap et al. (200 1)
Métaphores et histoires
Srivastva et Barrett (1988)
Engstrom (2003)
Réseau social
Cross et al. (200 1)
Stratégie de réplication
Conférence
Galbraith (1990)
Winter et Szulanski (2001)
Appleyard (1996)
Appleyard (1996)
Publication scientifique
Appleyard (1996)
Alliance inter-organisationnelle
Lars son et al. ( 1998)
Systèmes et outils informatiques
Chai, Gregory et Shi (2003)
Règles et procédures
Rapports et manuels
Courtier du savoir
Utilisateur expert
Bolzmann (2013)
Meyer (20 10)
Volkoff, Elmes et Strong (2004)
Structure organisationnelle
Chen et Huang (2007)
Mécanismes horizontaux
Galbraith ( 1973)
Gallagher et al. (2012)
Brevet
22
Les types de mécanismes sont nombreux et diversifiés (Argote et al., 2000). Le
mouvement de personnel est un mécanisme qui consiste à transférer un employé à un
autre département (Galbraith, 1994) ou à une autre division ou filiale de l'entreprise
(Almeida et Kogut, 1999; Gruenfeld et al., 2000). Selon Galbraith (1994 p.46-47), le
mouvement de personnel améliore les habiletés de communication des ressources
impliquées et leur permet de bâtir un solide réseau de contacts au sein de
l'organisation. La communication interdépartementale est plus efficace lorsque la
ressource communique avec un département auquel elle a déjà appartenu. Cette
ressource sait à qui s'adresser au sein de son ancien département, elle sait quoi leur
dire et comprend la réalité auquel ce groupe est confronté.
La littérature concernant le développement de nouveaux produits (DNP) propose
certains mécanismes de transfert. Le mécanisme le plus souvent mentionné est le
système de gestion des connaissances (Bradfield et Gao, 2007 ; Chen et al., 2009 ;
Merminod et Rowe, 2012 ; Zhen et al., 2013). Ce mécanisme fait référence à un
système informatique centralisé qui emmagasine, structure et offre l'accès aux
connaissances de l'organisation (Van Nguyen, 2002). Dans le cadre du DNP, les
connaissances traitées par ce type de système sont majoritairement axées sur les
produits développés. Certains auteurs (Bradfield et Gao, 2007 ; Chen et al., 2009)
font référence à l'ontologie du produit, c'est-à-dire ses propriétés, lorsqu'ils parlent
de ces connaissances. Un autre mécanisme proposé pour le DNP est l'analyse postprojet (Goffm et Koners, 2011). Ce mécanisme consiste à tenir des rencontres
formelles en fm de projet entre les membres de l'équipe, dans le but d'identifier les
leçons apprises qui pourraient être utiles pour le futur. Ce type de mécanisme est
davantage utilisé pour les connaissances liées aux processus de gestion de projet que
pour les connaissances liées au produit (voir sous-section 1.2.3), ce qui réduit l' intérêt
pour ce mécanisme pour la présente recherche.
23
La formation, un autre mécanisme, permet de transférer des connaissances ciblées à
des ressources ciblées. Une étude a démontré que le fait de former de manière
individuelle ou en groupe n'a pas d'impact direct sur la performance de la formation
(Moreland et Myaskovsky, 2000). La communauté de pratique est défmie comme un
groupe flexible de professionnels partageant un intérêt commun qui interagissent pour
atteindre un objectif commun, celui de créer un bassin commun de connaissances
(Jubert, 1999 p.166). L'interaction un à un consiste en l'échange de connaissances
entre deux individus. Le mentorat implique une relation entre un mentor et un
mentoré. Le mentor est une personne qui possède une base approfondie de
connaissances sur laquelle il s'appuie pour enseigner et guider son mentoré (Swap et
al. , 2001). Les métaphores et histoires permettent d'articuler des expériences qui ne
peuvent être exprimées autrement (Srivastva et Barrett, 1988). Le réseau social fait
référence à toutes les relations interpersonnelles qu 'un individu développe au sein de
son entreprise ou dans sa vie personnelle (Cross, 2001 ).
Galbraith (1990) s'est intéressé au transfert de technologie en étudiant l'habileté à
répliquer rapidement et efficacement les technologies de fabrication détenues par
l'organisation, d'une installation à l'autre. Winter et Szulanski (2001) se sont aussi
intéressés à cette stratégie de réplication. Cette stratégie, parfois appelée l'approche
« Mcdonald's », consiste à répliquer un modèle d'affaires ou d'opérations à différents
points de vente. Ce type de transfert est d'une portée très large et met l'emphase sur
les capacités dynamiques de l'organisation. En se penchant sur le transfert de
connaissances dans l' industrie des semi-conducteurs, Appleyard (1996) a identifié
certains mécanismes qui permettent un transfert public de la connaissance. Elle a
séparé ces mécanismes en deux catégories distinctes. La première catégorie englobe .
les mécanismes qui donnent un accès limité, tels que les brevets, tandis que la
deuxième catégorie est constituée des mécanismes qui donnent un accès sans
restriction, tels que les conférences et les publications scientifiques. Larsson et al.
(1998) se sont intéressés aux alliances inter-organisationnelles en tant que mécanisme
24
de transfert. Leur étude fait ressortir l'importance de la relation pour ce type de
mécanisme. Les mécanismes de transfert incluent aussi les systèmes et outils
informatiques, les règles, les procédures, les rapports et les manuels utilisés par
l'organisation (Chai et al., 2003).
Il y a des mécanismes qui demandent à certains individus de jouer un rôle particulier.
C' est le cas du courtier du savoir (knowledge broker) et de l'utilisateur expert (power
user). Le courtier du savoir agit en guise de médiateur entre les différents individus
au sein de l'organisation ou du réseau. Il permet de créer un lien entre ceux qui
possèdent la connaissance et ceux qui recherchent cette connaissance (Holzmann,
2013). Il doit donc faire le pont entre deux mondes différents, tout en résistant aux
dogmes entretenus par ces derniers (Meyer, 2010). Pemsel et Wiewiora (2013)
proposent d 'utiliser le bureau de projet comme courtier du savoir dans les
organisations orientées projet. Ces auteurs parlent cependant du transfert de la
connaissance liée à la gestion des projets et non de la connaissance créée durant ces
projets. L'utilisateur expert consiste à former une ressource via, sa participation active
à la création de la nouvelle connaissance et à lui demander de transférer par la suite
cette connaissance à ses collègues (Volk:off et al. , 2004). En fait, l'utilisateur expert
regroupe deux mécanismes de transfert, soit la formation et le mouvement de
personnel.
La structure organisationnelle m1se en place par l'entreprise est aussi considérée
comme un mécanisme de transfert de connaissances. Cheng et Huang (2007)
catégorisent les structures organisationnelles en se basant sur trois éléments; la
formalisation, la centralisation et l'intégration. La formalisation se traduit par le degré
de standardisation du travail et du niveau d'encadrement des employés basé sur les
règles et procédures de l'entreprise. Un niveau de formalisation élevé peut entraver la
spontanéité et la flexibilité nécessaire à l' innovation. La centralisation se reflète par
25
une structure où les décisions sont pnses à un mveau hiérarchique élevé. Une
structure
centralisée
crée un
environnement non participatif et réduit
la
communication. L'intégration fait référence au lien inter-relationnel qui lie les
différents départements de l'organisation dans le cadre des activités de celle-ci.
Gallagher et al. (2012) se sont intéressés au choix de structure mise en place en phase
post-implantation d'un système ERP. Ils avancent qu'un dilemme existe entre
l'utilisation d'une structure centralisée, dont la définition diffère de celle mentionnée
précédemment (Chen et Huang, 2007), et d'une structure décentralisée. La structure
centralisée consiste à former une équipe permanente de support regroupant les
utilisateurs experts, tandis que la structure décentralisée se résume à retourner les
utilisateurs experts dans leur département respectif en éliminant tout lien avec les
ressources TI de l'organisation qui s' occupent du système ERP. En plus de
1' expertise technique, détenue par les experts TI et les consultants externes, le support
nécessite aussi une expertise fonctionnelle, détenue par les utilisateurs experts
(Wenrich et Ahmad, 2009). Cependant, les utilisateurs experts qui ont participé au
projet représentent souvent des ressources importantes pour leur département
respectif (Gallagher et Vickie Coleman, 2012) . Cette situation soulève un débat
concernant le rôle post-projet des utilisateurs experts. Hirt et Swanson (2001)
affirment que les utilisateurs experts ne devraient pas retourner à leur département ,
car leur présence est requise pour le support. Selon Gallagher et al. (2012), plusieurs
organisations optent pour une structure hybride qui consiste à retourner les
utilisateurs experts à leur département, mais en maintenant un lien avec l'équipe TI
qui s' occupe du support ERP.
En guise de structure centralisée, des auteurs proposent la mise sur pied d 'un centre
de compétences regroupant les utilisateurs experts sélectionnés pour leurs
compétences autant techniques que fonctionnelles (Baskerville et al., 2006 ; Tomas,
26
2007). Plusieurs tâches peuvent être exécutées par ces centres de compétences telles
la résolution des problèmes journaliers, le suivi des modifications, la formation
spécifique, l'amélioration continue des processus opérationnels,
la recherche
d'opportunités afin d'augmenter la productivité et la recherche d'explications aux
situations exceptionnelles (Tomas, 2007 p.272). Galbraith (1994) émet quelques
réserves envers les structures de type centralisé. Selon lui, les employés centraux
peuvent se désintéresser des départements qu'ils desservent et peuvent ne pas
ressentir le sentiment d'urgence dans certaines situations où ils devraient.
En plus de la structure organisationnelle permanente, il y a d'autres mécanismes de
transfert qui sont liés à 1' aspect structurel de l'entreprise. Il s'agit des mécanismes
horizontaux. Ces mécanismes permettent d'adapter la structure organisationnelle au
transfert de connaissances. Les mécanismes horizontaux sont des superpositions
structurelles au modèle de gouvernance existant. Ils servent à faciliter la
collaboration, la coordination et la communication entre les différentes fonctions de
l'organisation (Gallagher et al., 2012). Une relation positive rut démontrée entre
l'utilisation des mécanismes horizontaux et le transfert de connaissances (Gupta et
Govindarajan, 2000). Galbraith (1973) énumère trois formes de mécanismes
·horizontaux qui affectent la capacité de transfert de la connaissance. Il s'agit du rôle
de liaison, de l'équipe temporaire et de l'équipe permanente. Les individus qui sont
mandatés d'un rôle de liaison s'occupent de 1' identification de 1' information
pertinente et de sa transmission au sein des différents départements de l'organisation.
Ce rôle s'apparente beaucoup à la défmition du courtier du savoir mentionnée
précédemment (Holzmann, 2013). Les équipes temporaires et permanentes sont des
mécanismes qui facilitent davantage le transfert de connaissances que le mécanisme
de liaison. La création de liens sociaux entre les différents membres de l' équipe
explique que le transfert est facilité au sein de l' équipe et même au sein des autres
divisions. Comparativement aux équipes temporaires, les équipes permanentes
27
permettent une meilleure mobilisation des ressources en rapport avec la tâche à
accomplir. Ce type d'équipe augmenterait aussi la capacité des ressources à intégrer
leurs apprentissages passés à leurs agissements actuels (Persson, 2006). Cependant, à
force d'être éloignés de leur département respectif, les membres de l'équipe
permanente se détachent du milieu de travail pour lequel ils détiennent une expertise,
expertise qui leur a valu d'être sélectionnés dans 1' équipe permanente (Persson,
2006). Selon Hedlund (1994), il est préférable de confectionner des équipes
temporaires au sein d'un bassin de ressources stable, plutôt que des équipes
permanentes avec un bassin de ressources changeant.
Certains auteurs se sont intéressés aux facteurs qui affectent le choix du ou des
mécanismes de transfert de connaissances. Pour Chai et al. (2003), le choix du
mécanisme dépend de la nature de la connaissance (tacite ou explicite) et la
dépendance de la connaissance à son contexte. Jasimuddin (2007) affirme pour sa
part que le choix du mécanisme dépend de trois variables, soit le statut des personnes
impliquées, le lien relationnel et la distance. Une plus grande emphase sera mise sur
le processus de transfert si la requête provient d'un membre de la haute direction. Le
choix sera aussi différent selon la force du lien relationnel qui lie la source et le
récipient. Le choix dépendra également de la distance séparant la source et le
récipient. Il ne sera pas le même si la source et le récipient sont situés côte à côte que
s'ils sont situés sur des continents différents. Il est plus difficile d'interagir face à face
lorsqu 'une distance géographique sépare la source et le récipient. C' est pourquoi la
préférence pour les mécanismes liés aux technologies de l' information, tels que le
courriel, augmente avec la distance. Chaque type de mécanisme possède des attributs
spécifiques qui auront des conséquences sur l'efficience du transfert de connaissances
interdépartemental (Persson, 2006) .
1
28
Les mécanismes proposés dans cette sous-section peuvent être regroupés ou classés
selon
certains
attributs.
La
prochaine
sous-section
présentera
différentes
classifications de mécanismes proposées par certains auteurs.
1.3 .2
Classification des mécanismes
Les mécanismes de transfert de connaissances peuvent être classés selon différentes
caractéristiques. Hansen et al. ( 1999) les classent en deux catégories en se basant sur
l'approche utilisée, c'est-à-dire l'approche personnalisée et l'approche codifiée.
L'approche personnalisée englobe les mécanismes qui demandent une interaction
face à face, tandis que l'approche codifiée réunit les mécanismes qui permettent de
bien codifier la connaissance et qui pour lesquels la technologie joue un grand rôle
(Hansen et al. , 1999).
Boh (2007), enrichit la classification initiale de Hansen et al. en y ajoutant deux
dimensions pour en faire une matrice à quatre quadrants (figure 1.3). Ces deux
dimensions sont l'individualisation et l'institutionnalisation. Elles permettent de
différencier les mécanismes qui servent au transfert de connaissances au niveau
individuel de ceux qui servent au niveau collectif. Basé sur cette classification, Boh
(2007) émet deux propositions. Premièrement, les mécanismes codifiés seraient utiles
pour les organisations qui font face à des problèmes récurrents, tandis que les
mécanismes personnalisés le seraient pour les organisations qui font face à des
problèmes uniques. Deuxièmement, les mécanismes institutionnalisés sont plus
appropriés pour les grandes organisations dispersées géographiquement, tandis que
les mécanismes individualisés le sont plus pour les petites organisations co-localisées.
Chai et al. (2003) classent les mécanismes selon leur degré d'atteinte et de richesse
(figure 1.4). Le degré d'atteinte fait référence au nombre d'individus que le
29
mécanisme permet d'atteindre, tandis que le degré de richesse fait référence à la
quantité d' information transférée, la possibilité de personnalisation de cette
information et le degré d'interaction entre la source et le récipient.
lnd ividua ltsé
ro
c
c
Institutionnalisé
-Bouche à oreiUe
- Post -mo rtem
-Résea u personnel
-Cent re de support
-Réun fon de la haut e
direction
0
Vl
.._
(!)
Q_
-Partage de docu ments
-Basede don nées
info rmels
- Foru m
- Mét hodologie
st an dard isée
Figure 1. 3 Classification des mécanismes de transfert (Adapté de Bob (2007))
Élev é
'~
bO
Q)
0
Bas
Ba s
Degré d'atteinte
Élevé
Figure 1.4 Degré relatif d'atteinte et de richesse des mécanismes (adapté de Chai et
al.(2003))
30
Jusqu'à maintenant, cette section nous a permis de comprendre ce qu'est le transfert
de connaissances, quels sont les mécanismes de transfert disponibles et comment il
est possible de classifier ces mécanismes. Nous allons conclure cette section en
présentant les facteurs facilitants et les barrières au transfert de connaissances. Il faut
tenir compte de ces deux éléments lors du choix de la structure d' exploitation du
système ERP et lors du choix des mécanismes utilisés.
1.3.3
Facteurs facilitants et barrières au transfert de connaissances
Le processus de transfert de connaissances est souvent difficile et consomme
beaucoup de temps de la part des ressources impliquées (Szulanski, 2000). Plusieurs
auteurs se sont intéressés aux facteurs qui impactent le transfert de connaissances.
Dong-Gil et al. (2005) classent ces facteurs en trois catégories; les facteurs liés à la
connaissance, les facteurs communicationnels et les facteurs de motivations. Les
facteurs liés à la connaissance sont la capacité d 'absorption du récipient, la
compréhension partagée entre la source et le récipient et la relation existante entre la
source et le récipient. Les facteurs communicationnels incluent la compétence
d'encodage de la source et de décodage du récipient, ainsi que la crédibilité de la
source telle que perçue par le récipient. Les facteurs de motivations sont la motivation
intrinsèque et extrinsèque de la source et du récipient. Xu et Ma (2008) utilisent des
facteurs similaires, mais les catégorisent d 'une autre façon. Les auteurs classent les
facteurs selon s'ils sont liés à la connaissance transférée, à la source, au récipient ou
au contexte. Les facteurs liés à la connaissance transférée sont l' ambiguïté causale,
c'est-à-dire à quoi servira la connaissance pour le récipient, et la dimension tacite de
la connaissance. Les facteurs liés à la source sont la capacité d'encodage et la volonté
de transférer. Les facteurs liés au récipient sont la capacité de décodage, la vo lonté
d'acquérir et la capacité d'absorption. La relation existante entre la source et le
31
récipient, les activités de transfert et la priorité du projet sont les facteurs liés au
contexte. Le modèle de recherche de Xu et Ma a été bâti dans une optique projet,
c'est la raison qui explique que la priorité du projet soit un facteur énuméré. Les
activités de transfert font référence aux mécanismes de transfert utilisés.
Les barrières au transfert avancées par différents auteurs sont fortement liées aux
facteurs qui impactent ce transfert. Szulanski (2000) propose huit barrières au
transfert. Volkoff et a1.(2004) reprennent les mêmes barrières et les classent selon
qu'elles soient liées à la connaissance, à la source, au récipient ou au contexte
(tableau
1.5).
On
y retrouve
l'ambiguïté
causale
qm
fait
référence
à
l'incompréhension du récipient face aux retombées qu'apportera la connaissance
obtenue de la part de la source. La connaissance non prouvée est une barrière qui
surgit lorsque la connaissance ne démontre pas assez de valeur. Le manque de
motivation de la part de la source ou de la part du récipient fait référence à la
réticence de l'un ou de l'autre à partager ou à acquérir des connaissances. La source
qui n'est pas perçue comme étant crédible résulte d'un manque de confiance envers
l'expertise de celle-ci. Le manque de capacité d'absorption de la part du récipient fait
référence au fait qu'acquérir des connaissances nécessite des c01maissances
préexistantes. Une autre barrière est le manque de capacité de rétention de la part du
récipient. La rétention est nécessaire pour être en mesure d'institutionnaliser la
connaissance acquise. Les deux dernières barrières sont en lien avec le contexte qui
entoure le transfert de connaissance, il s' agit du contexte organisationnel stérile et la
relation ardue. La première surgit lorsque la structure ou les processus ne sont pas
appropriés, tandis que la deuxième décrit une communication personnelle difficile
entre la source et le récipient.
32
Tableau 1. 5
Les barrières au transfert de connaissances
(adapté de Szulanski (2000) et Volkoff(2004))
Source
Barrière
Connaissance Ambiguïté causale
Connaissance non prouvée
Source
Récipient
Contexte
Manque de motivation de la
part de la source
Source non perçue comme
crédible
Manque de motivation de la
part du récipient
Manque de capacité
d'absorption de la part du
récipient
Manque de capacité de
rétention de la part du
récipient
Contexte organisationnel
stérile
Relation ardue
Description
Incompréhension face aux retombées
qu'apportera la connaissance
La connaissance ne démontre pas
assez de valeur
Source réticente à partager ses
connaissances
Manque de confiance envers
1' expertise de la source
Récipient réticent à acquérir des
connaissances
Acquisition de la connaissance
nécessite des com1aissances
préexistantes
La connaissance acquise doit être
institutionnalisée
Structure ou processus non appropriés
Communication personnelle difficile
entre la source et le récipient
1.4 Transfert de connaissances lors des projets d'évo lution ERP
Certaines activités d'évolution du système ERP nécessitent la constitution d'une
équipe projet pour être réalisés (voir sous-section 1.1.2). Un processus de transfert de
connaissances devra être mis en place entre cette équipe projet et l'équipe permanente
de support (McGinnis et Huang, 2007). Ce transfert de connaissances aidera à la
réalisation du projet et à la pérennité du système. Les sous-sections subséquentes
33
concernent la constitution des deux équipes (projet et support) et la connaissance qui
est partagée entre ces deux équipes.
1.4.1
Équipe projet et équipe support dans un environnement ERP
Le projet d'implantation initiale d'un système ERP, ainsi que les projets d'évolution
nécessitent la collaboration de plusieurs intervenants. Les équipes formées pour ces
projets sont habituellement composées de membres internes et de membres externes à
l'organisation (Baskerville et al., 2006). Les membres internes regroupent des experts
en technologie de l'information et des représentants des différentes fonctions
affectées par le nouveau système ou par les changements apportés au système actuel,
tandis que les membres externes sont des représentants du fournisseur ERP ou des
consultants détenant une expertise du système impliqué (Baskerville et al., 2006).
Différentes terminologies sont utilisées pour nommer les ressources en provenance
des différentes fonctions de l'entreprise qui sont assignées à de tels projets. Les deux
termes qui reviennent le plus souvent sont l'utilisateur expert (power user)
(Baskerville et al., 2006 ; Volkoff et al., 2004) et l'expert en la matière (subject
matter expert) (Gallagher et Vickie Coleman, 2012 ; Hirt et Swanson, 2001). Dans le
cadre de cette recherche, le terme utilisateur expert sera utilisé pour désigner ces
ressources. L'utilisateur expert contribue aux projets par les connaissances
fonctionnelles qu'il détient concernant les processus d'affaires de son département
(Gallagher et Vickie Coleman, 2012 ; Volkoff et al., 2004).
Par exemple,
l'implantation d'un module financier nécessitera la collaboration d'utilisateurs
experts du département de la comptabilité. En participant à différents projets en lien
avec le système ERP, ces utilisateurs experts vont assimiler des connaissances
techniques qui feront d'eux des experts ERP auprès des différents utilisateurs de leur
département respectif (Volkoff et al., 2004). Lorsque les projets impliquent plus d'un
34
département ou plus d'une fonction de l'entreprise, les équipes projets deviennent
trans-fonctionnelles et nécessitent la coopération d'utilisateurs experts des différents
départements impliqués (Tomas, 2007).
La composition de l'équipe permanente de support dépend de la structure mise en
place par 1' organisation (voir sous-section 1.3 .1). Elle contiendra nécessairement des
experts TI de l'organisation, auxquels pourraient s'ajouter des utilisateurs experts.
Cette équipe de support conservera le contact avec les consultants externes liés à
l'entreprise par un contrat de maintenance (Tomas, 2007). Selon Ha et Ahn (2013), le
niveau de collaboration et de communication entre les différentes ressources affectées
à l'exploitation du système ERP est un facteur qui impacte la performance du système
lors de la phase post-implantation. Le lien reliant les projets d'évolution et le support
du système ERP rend nécessaire la mise en place d'un processus de transfert de
connaissances constitué d'activités de transfert se déroulant aux différentes phases du
projet. La connaissance transférée peut être de différents types, cela sera le sujet de la
prochaine sous-section.
1.4.2 Les connaissances techniques et fonctionnelles des systèmes ERP
Lors de la présentation du sujet de recherche, nous avons identifié deux types de
connaissances, soit les connaissances techniques et fonctionnelles. La présente
section permettra d'aborder en profondeur ces deux composantes. L'expertise et
l'expérience liées aux fonctionnalités du système et sa configuration,
les
connaissances techniques, se retrouvent normalement à 1' externe, tandis que les
connaissances liées aux processus d'affaires, connaissances fonctionnelles, se
retrouvent au sein même de l'organisation (Hirt et Swanson, 2001).
35
Ces deux types de connaissances sont confrontés et combinés lors des projets liés au
système ERP pour faire en sorte que le système réplique correctement les processus
d'affaires de l'entreprise (Baskerville et al., 2006). Baskerville et al. (2006) parlent
de divergence et de convergence pour expliquer ce phénomène particulier. Les
experts TI possèdent les connaissances techniques, tandis que les utilisateurs experts
possèdent les connaissances fonctionnelles. Ces deux types de connaissances sont
divergents et une convergence s'impose. C'est-à-dire que les experts TI doivent en
apprendre davantage sur les processus d'affaires et que les représentants fonctionnels
doivent en apprendre davantage sur l'aspect technique de l'application (Baskerville et
al., 2006). Hirt et Swanson (2001) abondent dans le même sens, en mentionnant que
l'implantation d'un système ERP demande plus que des compétences en analyse de
système et en programmation. Cela demande des connaissances des processus
d'affaires et une expertise en lien avec les fonctionnalités offertes par l'application et
les configurations possibles.
Gable et al. (200 1) énumèrent plusieurs types de connmssances en lien avec le
système ERP; les processus d'affaires, la configuration du ERP, le design
organisationnel, la culture de l'organisation, l'architecture et l'infrastructure TI, la
gestion de projet et les ressources liées à ces projets, ainsi que les décisions clés
reliées au système et leur explication. De cette liste, seulement la configuration du
ERP et l'architecture et l'infrastructure TI sont des connaissances techniques, les
autres types de connaissances sont des connaissances fonctionnelle s. Tomas (2007
p.239) énumère différentes composantes de l' infrastructure d'un système ERP faisant
partie des connaissances techniques;
la plate-forme matérielle,
le système
d' exploitation, la base de données et le réseau de télécommunication.
La revue de littérature a permis de bien situer la phase post-implantation d'un
système ERP et de différencier les activités de support et les activités d'évolution.
36
Elle a démontré la nécessité de gérer certaines activités d'évolutionen mode projet.
L'importance du transfert de connaissances, lors de l'intégration des initiatives
d'évolution avec l'exploitation courante du système ERP, fut aussi démontrée. Les
mécanismes de transfert de connaissances existants furent présentés et le rôle de la
structure d'exploitation du système ERP dans le processus de transfert de
connaissances fût abordé. Le prochain chapitre propose un cadre d'analyse construit à
partir des principaux éléments exposés lors de cette revue de littérature.
CHAPITRE II
CADRE D'ANALYSE
Dans ce chapitre, un cadre d'analyse est proposé afm d'encadrer la collecte de
données et de déterminer les éléments qui seront analysés suite à cette collecte (figure
2.1 ). Ce cadre est bâti à partir de la littérature existante sur les systèmes ERP, la
gestion de projet et le transfert de connaissances. Il vise à offrir une orientation pour
les prochaines étapes de la recherche, bien que son contenu puisse être modifié
ultérieurement selon les données obtenues sur le terrain.
Le cadre proposé met l'emphase sur les changements apportés au système ERP suite
à la réalisation de différents projets qui font évoluer le système ERP (ERP à ERP*).
Ces projets d'évolution peuvent être de différentes natures (voir sous-section 1.1.2).
Ils sont constitués de quatre phases. Les quatre phases sélectionnées proviennent de
l'industrie du développement logiciel (Jugdev et Müller, 2005) . Ces phases sont la
conceptualisation, le développement, les tests et le déploiement. Ces phases
spécifiques à l' industrie du développement logiciel, dont font partie les systèmes
ERP, ont été préférées aux phases plus génériques proposées par le Project
Management Institute (voir sous-section 1.2. 2).
Les deux acteurs du modèle sont l' équipe projet et l' équipe support Le premier
s' occupe de la réalisation du projet d' évolution, tandis que le deuxième s' occupera de
supporter les ajouts ou modifications apportés au système suite à la clôture du projet.
La composition des deux équipes est décrite en détail à la sous-section 1.4. 1. Le cadre
38
St ructure d' exploitation du système ERP
Proj et d'évo lution
Équipe projet
Conceptualisation- Développement- Tests - Déploiement
Maint enance- Équipe suppo rt
Po5t-implantat ion
Figure 2. 1 Cadre d'analyse
d'analyse spécifie que
l'équipe support travaille continuellement en post-
implantation_ Donc, l'équipe support s'occupera du système ERP à partir de son
implantation initiale jusqu'à la fin de sa durée de vie utile_
Le transfert de connaissances entre ces deux équipes est le point central du cadre
d' analyse_ Basé sur la revue de littérature, il est possible de dire que la connaissance
transférée sera fonctionnelle et technique _Les connaissances fonctionnelles sont liées
aux processus d' affaires, tandis que les com1aissances techniques sont liées aux
fonctionnalités du système et à la configuration de ce dernier (voir sous-section
L4 _2)_ Cependant la direction du transfert, c'est-à-dire de l'équipe support vers
l'équipe projet ou de l'équipe projet vers l'équipe support, ainsi que la phase du
projet à laquelle le transfert a lieu n'ont pu être établies par la revue de littérature_Ces
39
deux éléments feront donc partie des éléments analysés dans le cadre de cette
recherche.
Un autre élément important qui sera analysé sera les mécanismes de transfert utilisés
par les organisations pour effectuer ce transfert de connaissances entre les deux
équipes. Plusieurs mécanismes de transfert ont été énumérés dans la revue de
littérature (sous-section 1.3.1). Parmi les mécanismes énumérés, nous avons extrait
ceux qui pouvaient convenir à un environnement d'exploitation d'un système ERP.
Ces mécanismes sont la communauté de pratique, le courtier du savoir, la
documentation, la formation, l'interaction un à un, le mentorat, le mouvement de
personnel, le réseau social, le système de gestion des connaissances et l'utilisateur
expert. Parmi ces dix mécanismes, seule la documentation ne fait pas partie des
mécanismes extraits lors de la revue de littérature. En fait, il a été décidé de regrouper
les mécanismes « rapports et manuels » et « systèmes et outils informatiques » en une
catégorie plus large appelée « documentation ». Cette décision filt prise, car la
méthode utilisée pour créer et distribuer la documentation importe peu dans le cadre
de cette recherche. Ce qui importe davantage, c'est de savoir si une documentation
existe au sein des organisations et quel est le contenu de cette documentation.
La revue de la littérature a permis d' identifier deux caractéristiques de l'organisation
qui pourraient avoir un impact significatif sur le transfert de connaissances. Il s'agit
de la structure d'exp loitation du système ERP et le rôle de l'intégrateur principal,
c'est-à-dire le consultant qui possède une expertise avancée relative à la nouvelle
solution qui
sera développée
par l'équipe projet.
Bien que la structure
organisationnelle soit considérée par certains auteurs comme étant un mécanisme de
transfert en tant que tel (Chen et Huang, 2007), il a été décidé de plutôt la considérer
comme étant une caractéristique influençant le transfert. C'est la raison qu i explique
pourquoi la structure organisationnelle et les mécanismes horizontaux, qui sont des
éléments de la structure, n'ont pas été retenus comme mécanisme, bien qu 'ils fussent
40
mentionnés dans la revue de
littérature (sous-section
1.3 .1). La structure
d'exploitation du système ERP sera analysée en se basant sur le dilemme existant
entre une structure centralisée et une structure décentralisée (Gallagher et al., 2012).
Ce dilemme est expliqué en détail à la sous-section 1.3 .1. Le rôle de l' intégrateur
principal sera analysé vu l' importance de la connaissance qu' il possède (voir soussection 1.4.2). Cette connaissance doit être transférée à l'organisation avant que
l' intégrateur principal quitte l'entreprise. Il sera intéressant de connaître les méthodes
utilisées par les organisations pour s' assurer que ce transfert s'effectue de manière
adéquate.
Bien que le cadre d'analyse mette l'emphase sur un seul projet d'évolution, il faut
considérer qu ' il y aura une multitude de projets qui feront évoluer le système ERP
tout au long de son cycle de vie (figure 2.2). La fi gure 2.2 permet de mieux visualiser
l'aspect permanent de l'équipe support et l' importance du transfert de connaissances
entre les équipes projet et l' équipe de support.
Figure 2. 2 Le cycle de vie d'un système ERP
41
Cette recherche portera donc une attention particulière à des caractéristiques liées à
l'organisation, c'est-à-dire la structure d'exploitation ERP et le rôle de l'intégrateur
principal, et à des caractéristiques liées aux activités de transfert de connaissances,
c'est-à-dire le type de connaissance (fonctionnel ou technique), la direction du
transfert, la phase où se déroule le transfert et les mécanismes utilisés. La
méthodologie de recherche utilisée est expliquée en détail dans le prochain chapitre.
CHAPITRE III
MÉTHODOLOGIE DE RECHERCHE
3.1 Approche de la recherche
Suivant une approche qualitative, cette recherche est de nature exploratoire. Ce type
de recherche «porte sur des sujets dont la pertinence ne semble pas faire problème,
mais [qui] ont été peu ou pas explorés »(Gagnon, 2012 p.l5).
La recherche est axée sur une étude de cas multiples, « l'étude de cas multiples vise à
tirer des conclusions d 'un ensemble de cas »(Gagnon, 2012 p.41). Le fait d'avoir plus
d'un cas étudié permet d'effectuer une comparaison inter-cas qui permet à son tour de
faire ressortir les tendances et disparités entre les cas (Eisenhardt, 1989). De plus,
Miles et Huberman (1991) affirment que les études de cas multiples offrent au
chercheur une compréhension plus profonde des résultats. L'étude de cas est utile
lorsque le chercheur veut étudier un phénomène dans son contexte réel, surtout si la
distinction entre le phénomène et le contexte n'est pas clairement défmie (Yin, 1981).
Yin (1994) énumère trois conditions préalables à l'utilisation de l'étude de cas. Elles
concernent le type de la question de recherche et sa formulation (le comment, le
pourquoi ou le quoi), le degré de contrôle sur le comportement ou l'événement étudié
et l' accent sur le contemporain. Pour que l'utilisation de l'étude de cas soit pertinente,
il faut que la problématique de recherche comporte des éléments non expliqués, que
les données puissent être collectées sans manipuler les sujets ou les événements
étudiés et que les données accessibles au moment de la collecte soient toujours
43
pertinentes (Gagnon, 2012 p.16-17). L'unité d ' analyse de la recherche est au niveau
des organisations, et l'ensemble de la méthodologie a été établi en fonction de ce
niveau d'analyse.
3.2 Échantillonnage
Selon Eisenhardt (1989), la sélection des cas doit être orientée vers une population
spécifique
et
théorique,
il
faut
écarter
les
échantillonnages
probabilistes.
L'échantillon théorique n'est pas un échantillon statistiquement représentatif de la
population, il s'agit plutôt de sélectionner l' échantillon basé sur des critères de
potentiels de découverte, d' objectif de recherche et de variété maximale (Eisenhardt,
1989). Dans le cadre de cette recherche, un échantillon de convenance est utilisé au
niveau des organisations sélectionnées. Cela s'explique par la difficulté d' avoir accès
à des données, qui sont généralement de nature confidentielle. Une initiative de la
Chaire de gestion de projet de l'UQAM a perinis d'accéder à des organisations, qui
ont un intérêt pour le sujet ainsi qu 'une volonté de partager leurs informations
organisationnelles. Ces organisations répondent aux critères minimums de sélection
établis pour cette recherche, c'est-à-dire qu'ils ont implanté un système ERP
constitué au minimum de trois modules, que l' implantation initiale remonte à au
moins deux ans et qu 'une portion importante du support du système est effectué à
l' interne.
Les répondants qui participent à la collecte de données ont été sélectionnés lors de
discussion entre les responsables du projet de recherche et la personne ressource
identifiée pour chaque organisation. Les répondants sélectionnés se devaient de bien
connaître le processus de transfert de connaissances entre l'équipe projet et l'équipe
support dans le cadre des projets d'évolution. De plus, quatre profils de répondants
44
ont été identifiés pour maximiser la collecte de données, soit les gestionnaires de
projet, les membres de l'équipe TI, les clients internes et les gestionnaires de
portefeuille de projet. Les quatre rôles sélectionnés à titre de répondant l'ont été dans
l'optique de recourir à de multiples sources d' information afm de permettre une
triangulation des données recueillies (Gagnon, 2012).
Ainsi, trois organisations ont participé à la recherche pour un total de gu mze
entrevues. Le nombre d 'entrevues a été établi en fonction de la saturation sémantique
et la saturation théorique des données (Romelear, 2005). La saturation sémantique
émerge lorsque les nouveaux entretiens
«gu ' on conduit n'apportent plus de
descripteurs ou de modalités différents de ce qui a été obtenu par les anciens
entretiens» (Romelear, 2005 p.l 05). La saturation théorique des données est présente
« si chaque descripteur identifié dans un entretien est replacé dans le cadre d'une
théorie ou d'un modèle, qui peuvent être ceux du chercheur ou venir de la littérature »
(Romelear, 2005 p.106).
3.3 Collecte de données
Les données peuvent être collectées à partir de plusieurs sources. Yin (1994) en
énumèrent six relatives à l'étude de cas; les documents, les archives, les entrevues,
l'observation directe, l'observation participante et les artéfacts. Ces sources sont
complémentaires et le fait d'en utiliser plus d'une résulte en une meilleure précision
et offre des conclusions plus justes. Toujours selon Yin (1994), la collecte de données
repose sur trois assises; des sources multiples, une base de données formelle et le
maintien d'une chaîne d'évidence. Les sources multiples permettent une triangulation
de l'information afm de renforcir la validité de la recherche. La base de données
formelle offre l' accessibilité aux données à tous les chercheurs qui voudraient faire ge
45
quelconques vérifications. Le maintien d'une chaîne d'évidence permet de démontrer
la cohérence et les circonstances du cheminement de la co Becte de données de la
première à la dernière étape. Eisenhardt (1989) met l'emphase sur les gains que peut
retirer le chercheur en commençant l'analyse des données .avant la fin de la collecte.
Cette technique permet d'adapter les outils de collecte, par exemple le guide
d'entrevue, en fonction des nouveaux thèmes qui émergent. Deux sources de données
ont été sélectionnées pour cette recherche, soit les documents et les entrevues. Les
documents sont composés principalement d'outils de travail interne.
Les entrevues furent semi-directives centrées et ont été d'une durée moyenne
d'environ quatre-vingt-dix minutes chacune. L ' approche d'entrevue semi-directive
centrée permet au répondant de s'exprimer, dans le langage qui est sien, sur un sujet
défini au début de l'entrevue (Romelear, 2005). L'intervieweur, pour sa part, dirige le
répondant à l'aide de reformulations et de relances afm de s'assurer que tous les
thèmes du guide d'entrevue ont été abordés (Romelear, 2005). Lors de ces entrevues,
l'observation et l'écoute active ont été pratiquées par le chercheur. L'écoute active
s'effectue lorsque « le chercheur tient compte de ce [que les participants] disent, mais
aussi de la façon dont ils le disent et de ce qu 'ils ressentent en le disant » (Gagnon,
2012 p.59). Les entrevues ont été enregistrées sur support électronique, et la
transcription du contenu des enregistrements a été effectuée par des ressources
spécialisées.
Au début de chaque entrevue, des explications ont été transmises au répondant au
sujet de la nature et des objectifs de la recherche et une entente de confidentialité a
été signée entre le répondant et le chercheur. Il y a trois versions du guide d'entrevue,
soit une pour chaque profil de répondants (voir annexe A à D) . Ces versions ont la
même structure, mais diffèrent légèrement de manière à être mieux adaptées à la
réalité du répondant. Peu importe la version, le guide est découpé en quatre sections.
46
La première section concerne la thématique et la séquence d'entrevue. La deuxième
section aborde le rôle du répondant dans l'organisation et celui qu'il a joué dans le
processus de transfert de connaissances. La troisième section demande au répondant
de décrire ce processus. Dans la quatrième section, le répondant transmet des
renseignements sur sa formation et sur ses expériences antécédentes permettant de
mettre en perspective sa compréhension du processus.
3.4 Analyse des données
L'analyse des données est basée sur les stratégies d'interprétation des données
présentées par Langley (1999) (tableau 3.1). Parmi les sept stratégies proposées, deux
ont été utilisées dans le cadre de cette recherche, soit la stratégie narrative et la
stratégie de visualisation graphique. La stratégie narrative vise la construction d 'une
histoire détaillée à partir des données primaires. Cette stratégie permet de structurer
les données collectées, afin d'offrir une vision éclairée du cas analysé, et facilite le
Tableau 3. 1
Les stratégies d'interprétation de données (adapté de Langley (1999))
Stratégie
Point d'ancrage
Forme d'interprétation
Stratégie narrative
Temps
Histoire, sens, mécanismes
Stratégie quantitative
Evénements, résultats
Routines, mécanismes
Stratégie de modèles
alternatifs
Stratégie de théorie
Théories
Mécanismes
Catégories d'incidents
Sens, routines
Stratégie de
visualisation graphique
Evénements, séquence
Routines
Stratégie de délimitation
temporelle
Stratégie synthétique
Phases
Mécanismes
Processus
Prédiction
47
travail d'analyse. La stratégie de visualisation graphique consiste à utiliser des
matrices ou des graphiques afm de représenter l'information. Cette stratégie est un
complément à la stratégie narrative. Elle permet de représenter graphiquement le
processus facilitant la mise en lumière des similitudes et des différences.
Un exercice de codification préalable à l' analyse des données a été effectué à partir
des transcriptions des entrevues. Miles et Huberman ( 1991) affirment gu ' il existe
trois types de codes; descriptifs, interprétatifs et conceptuels. Les codes descriptifs
sont des codes bruts représentant le ou les mots précis utilisés par le répondant. Les
codes interprétatifs sont basés sur la connaissance du contexte de la part du
chercheur, connaissance qui se développe au fur et à mesure que la collecte avance.
Les codes conceptuels sont établis à partir des concepts existants ou nouveaux qui
émergent suite à l'interprétation des données. Le logiciel Atlas.ti a été utilisé comme
support à l'exercice de codification.
Comme mentionnée précédemment, l'analyse des données a été effectuée de manière
itérative avec la collecte de données. Ces données ont été analysées par cas dans un
premier temps, ce qui permet de faire ressortir les routines uniques à chaque cas avant
de tenter de les généraliser (Eisenhardt, 1989 p.540). Dans un second temps, une
analyse inter-cas a été effectuée. Cette analyse a permis d ' identifier les similitudes et
les différences entre les trois cas.
3.5 Fiabilité et validité externe
Différents moyens furent m1s en place pour assurer la fiabilité, c'est-à-dire la
«constance des observations et réplication des résu ltats » (Gagnon, 2012 p.21 ), et la
validité, soit la «justesse et exactitude des résultats par rapport à la réalité » (Gagnon,
48
2012 p.21), des résultats. Pour la fiabilité, les données ont été conservées à leur état
brut et la stratégie de collecte est publicisée avec les résultats (Gagnon, 2012). En ce
qui concerne la validité, les cas sélectionnés sont pertinents à la recherche, les
données sont présentées de façon honnête et une triangulation des données a été
effectuée (Gagnon, 2012).
Les résultats ont été présentés aux répondants en guise de validation supplémentaire
dans le cadre d'un atelier regroupant les membres de l'équipe du projet de recherche
et des représentants des différentes organisations qui participent au projet.
CHAPITRE IV
DESCRIPTION DES CAS
Dans le cadre de cette recherche, trois organisations ont été sélectionnées pour la
collecte de données. Ces trois organisations sont des entreprises canadietmes qui
évoluent dans le secteur public. Les modules ERP utilisés par ces organisations
proviem1ent soit du fournisseur Oracle ou du fournisseur SAP.
4.1 Organisation A
L 'organisation A est une organisation municipale, qui emploie environ 30 000
employés et possède un budget annuel de près de cinq milliards de dollars. Le
fournisseur de ERP Oracle fût sélectionné par l'organisation A. L 'exploitation de ce
dernier a débuté en 2006. Les modules exploités touchent trois domaines d'affaires de
l'entreprise, c'est-à-dire les fmances, les ressources humaines et l'approvisiotmement.
Chaque année, le fournisseur Oracle regroupe les correctifs recommandés en une
mise à jour appelée Recommended Co llection Patchs (RCP). En 2010, l'organisation
a effectué l'installation de plusieurs RCP en retard. Cette migration a duré environ un
an et a coûté plusieurs millions de dollars. Suite à cette initiative, il a été convenu que
les RCP seraient dorénavant installés chaque automne, et que les différents projets
relatifs au système intégré devraient réduire au minimum les persom1alisations.
50
Présentement, trois projets d'évolution majeurs sont en cours sur le ERP . Il s'agit de
la mise
en place des
modules de
traitement
de
la paie, des
modules
d 'approvisionnement avancés et des modules de gestion des budgets.
4.1.1 Les répondants
Quatre répondants de l'organisation A furent rencontrés dans le cadre de cette étude
de cas. Le premier répondant est le chef de programme des systèmes administratifs et
chef du centre d' expertise et de soutien, communément appelé le CES. C ' est lui qui a
mis en place le CES en 2007. Anciennement pilote inter-module, le deuxième
répondant est chef d' équipe du CES depuis près de deux ans. Il est un point de
contact important entre le CES et les domaines d ' affaires. Il est aussi responsable du
déploiement technique de la solution pour le système intégré. Le troisième répondant
est un chef de projet pour les projets d'envergure TI. Il s 'occupe de toutes les
applications financières associées au système intégré. Il travaille en gestion de projet
depuis plusieurs années. Le dernier répondant est directeur de l'information financière
et du contrôle interne. Il est le représentant de la fonction finance pour tout ce qui à
trait au système intégré.
4.1.2 Structure d ' exploitation du système intégré
L'exploitation du système intégré de l'organisation A s'effectue conjointement entre
les différents domaines d'affaires et le centre d'expertise et de soutien (CES). Le CES
fût mis en place en 2007, suite à l'implantation initiale du système intégré. Ce centre
emploie environ 45 personnes à temps plein. Il est composé de pilotes d'affaires, de
pilotes inter-modules, de développeurs, d'administrateurs de système, d'une équipe
51
de communication, d'une équipe de formation, d'un chef d'équipe et du chef du CES.
Les pilotes d'affaires jouent le rôle de représentant pour les différents domaines
d'affaires qui utilisent le système intégré.Ces pilotes font physiquement et
hiérarchiquement partie du CES, mais les domaines d'affaires sont responsables du
fmancement de ces postes. Ainsi, c'est le CES qui attribue les tâches aux pilotes
d'affaires, qui sont pour la plupart d'anciennes ressources clés des domaines
d'affaires. Ils ont donc amené avec eux une connaissance approfondie des processus
d'affaires de leur secteur et ils ont conservé un bon réseau de relation avec les
différents intervenants du domaine d'affaires. Leur expertise sur le système intégré a
été acquise à travers les différentes implantations de l'organisation ou lors de
l'utilisation intensive des modules implantés. Les pilotes inter-modules travaillent de
concert avec les pilotes d'affaires. Ils s'occupent du déploiement technique de la
solution et de la paramétrisation du système. Ils traduisent les besoins d'affaires en
spécifications techniques qui seront distribuées aux développeurs. Les développeurs
sont les ressources qui effectuent les personnalisations de système qui nécessitent de
la programmation. Ils peuvent aussi développer des interfaces entre le système ERP et
d'autres systèmes informatiques de l'organisation. Ils possèdent des connaissances
purement techniques. Pour leur part, les administrateurs de système sont responsables
de la sécurité et des accès au progiciel intégré. L'équipe de communication s'assure
de transmettre l'information concernant les livrables à venir aux différents utilisateurs
qui seront affectés, tandis que l'équipe de formation est responsable du matériel de
formation qui sera distribué ou présenté aux utilisateurs fmaux. Ces deux équipes
sont en relation avec les utilisateurs fmaux et non les ressources de l'exploitation. Le
chef d 'équipe, responsable du déploiement technique de la solution, joue un rôle de
coordonnateur entre les différentes ressources du CES et maintient un contact
constant avec les domaines d'affaires. Le chef du CES est responsable de tout ce qui
se rattache au système intégré. Il gère autant le support que les projets d'évolution du
ERP.
52
Les ressources du CES peuvent travailler autant en exploitation qu'en mode projet.
En fait, l'objectif est de faire alterner les différentes ressources entre les deux modes
. afm de créer et de conserver une synergie entre l'exploitation et l'évolution du
système intégré. Le CES préconise aussi une synergie des connaissances entre les
modules en assignant des spécialisations multiples à chaque ressource. Ainsi, bien
que responsable de certains modules, chaque ressource connaît d'autres modules et
peut servir comme ressource de rechange. Cette stratégie vise à mettre en place une
relève pour l'ensemble des modules du progiciel et permet une meilleure intégration
lors de la conception de solution inter-module.
Le processus de transfert de connaissances entre l'équipe projet et l'équipe de support
de l'organisation A comprend plusieurs activités se déroulant lors des différentes
phases du projet. Ces activités, ainsi que les mécanismes de transfert utilisés, sont
énumérés au tableau 4.1. Le processus de transfert de connaissances est représenté
graphiquement à la figure 4.1.
53
Tableau 4. 1
Les activités et mécanismes de transfert de connaissances de l'organisation A
Phases
Mécanismes
Investigation
Intégrer les connaissances des
domaines d'affaires
Investigation
Interaction informelle
Constituer l'équipe projet
Planification
Créer et maintenir à jour la
documentation
Planification
Réalisation
Tests d'acceptation
Documentation
Partager ses connaissances et
valider contenu (ressources du
CES)
Intégrer les ressources
additionnelles prêtées au projet
Présenter les futurs livrables
Planification
Réalisation
Interaction formelle
Réalisation
Tests d'acceptation
Tests d' acceptation
Mise en production
Post-implantation
Mouvement de pers01mel
Former les ressources du CES
(facultatif)
Transférer le registre des points
en suspens
Dissoudre l'équipe projet
Mise en production
Formation
Post-implantation
Documentation
Post-implantation
Activité
Constituer l'équipe
d' investigation
1!:
0
~0
~
·'o
.
~
~
.. !"''-V'~
Pt~ d10t~ oU<
IIA<A·~""''(""'
l'>f': I'+$'.J(I""t::(;>IÔ.,...,
Figure 4. l Processus de transfert de connaissances entre l'équipe prqj et et l' exploitation de l' organisation A
u
"'!"
!;
"'
-~~
aŒ
v
;;
"
"!
fi
..:r
'5
""
"'
l
~-M!"•'l rv'lo;: "" Il(! ~ "'"' ~
'"~~te-~ >"l:stiJ<; I ~r</tl-,,"''!'
~"' ' '~ ~ J~.,,,,u.,
Vl
.+:-
55
4.1.3 La phase d'investigation
Tous les projets TI de l'organisation débutent par une phase d'investigation. Au cours
de cette phase, l'équipe de projet est limitée. C'est une équipe de prospection, qui
étudiera et proposera différentes solutions pour répondre aux besoins du client. Si la
connaissance n'est pas disponible au sein de l'organisation, l'entreprise fera appel à
des experts externes, qui s'occuperont de supporter et de former les ressources
internes. L'équipe de prospection sera normalement constituée d'un chef de projet, de
pilotes d'affaires et d'un chef pilote d'affaires. Ces ressources, provenant du CES,
amènent avec eux leurs connaissances liées au système intégré. Ces mêmes
ressources discutent par la suite avec les domaines d'affaires afm d' intégrer les
connaissances manquantes liées aux processus d'affaires. Les mécanismes de
transfert utilisés lors de cette phase sont le mouvement de personnel et l' interaction
informelle. Le mouvement de personnel survient lorsque les ressources du CES se
joignent à l'équipe projet. L' interaction informelle est utilisée lors de l'intégration des
connaissances en provenance des domaines d'affaires.
4.1.4 La phase planification
La deuxième phase du projet, tel qu ' illustrée à la figure 4.1, est la phase de
planification. Cette phase débute lorsque la solution proposée est acceptée. Lors de
cette phase, le noyau de l'équipe d'exécution est formé. De nouvelles ressources en
provenance du CES et des domaines d'affaires se joignent ou remplacent les
membres de l'équipe d' investigation, amenant avec eux de nouvelles connaissances.
Cette équipe est généralement composée d'un gestionnaire de projet TI dédié, appuyé
d'un représentant des domaines d ' affaires dédié pour la direction du projet. Le reste
56
de l'équipe est composé d'employés associés à l' administration du projet (ex. PCO),
de ressources techniques et fonctionnelles du CES (pilotes d'affaires, pilotes intermodules, développeurs, administrateurs de système) et de ressources des domaines
d'affaires affectées au projet.
Le nombre de ressources du CES et des domaines d'affaires affectées au projet
fluctue en fonction des besoins du projet et des besoins d'exploitation. Ainsi,
certaines ressources seront affectées au projet à temps plein, alors que d'autres seront
présentes sporadiquement. Les ressources affectées à temps plein ne font plus de
support quotidien, mais elles agissent comme personne-ressource lorsque des
questions pointues surgissent. Les ressources du CES assignées au projet et celles qui
restent en mode support ont l'obligation formelle d' interagir entre elles, et ce de
façon continue. Cette interaction permet aux ressources du support de partager leurs
connaissances et de valider le contenu de la phase planification. L 'organisation A
tente de conserver un ratio de deux employés internes pour un employé externe dans
ses projets d'évolution. Ainsi, l'ajout de ressources externes est généralement utilisé
pour remplacer les ressources en mode support du CES et les ressources des
domaines d'affaires qui sont affectées au projet, surtout dans le cas des projets qui
s'étirent sur plusieurs années.
La méthodologie de l'organisation A exige la création d'une documentation de projet
qui sera maintenue à jour tout au long de cette phase et des phases subséquentes du
projet. Cette documentation touche davantage les aspects techniques du projet, mais
elle touche aussi les processus d'affaires. Ces derniers sont illustrés visuellement à
l'aide de l'application Visio. Cette documentation est disponible en tout temps pour
les ressources de l'exploitation et celles des domaines d'affaires. Il n'y a donc pas le
besoin de faire un transfert officiel en fin de projet. Le mouvement de personnel, la
documentation et l'interaction formelle sont les trois mécanismes utilisés en phase de
planification. Le mouvement de personnel est utilisé lors de la constitution de
57
l'équipe projet, la documentation lors de la création et de la mise à jour de celle-ci et
l'interaction formelle lors des contacts entre l'équipe projet et les autres membres du
CES.
4.1.5 La phase de réalisation
Lorsque la phase de planification est complétée, le projet passe à la phase de
réalisation. Lors de cette phase, les effectifs de l'équipe de projet seront
progressivement augmentés en fonction des efforts nécessaires. En plus de contribuer
à l'avancement du projet, ces ressources en provenance de l'exploitation acquièrent
des connaissances importantes liées aux futurs livrables. Durant cette phase, la
documentation sera maintenue à jour et les ressources du CES qui ne sont pas
affectées au projet continueront de partager leurs connaissances et de valider le
contenu du projet. Lors de cette phase, les mécanismes de transfert utilisés sont la
documentation,
le
mouvement
de
personnel
et
l' interaction
formelle.
La
documentation est maintenue à jour. Le mouvement de personnel survient lorsque le
CES et les domaines d'affaires prêtent des ressources de manière sporadique au
projet. L'interaction formelle se réalise lors du partage de connaissances et de la
validation du contenu du projet par les ressources du CES qui ne font pas partie de
l'équipe projet.
4.1.6 La phase des tests d'acceptation
La phase des tests d 'acceptation suit la phase de réalisation. Comme on peut le voir
dans le graphique illustrant le processus de transfert de cmmaissances (figure 4.1), les
58
activités de transfert de la phase des tests d'acceptation sont très similaires à phase de
réalisation. Le nombre d'effectifs prêtés au projet atteint son point culminant lors des
tests d' acceptation. La mise à jour de la documentation se poursuit lors de cette
phase. L' interaction entre l'équipe projet et les autres ressources du CES se poursuit
également, mais la nature de l'interaction change. À partir de cette phase, les
membres de l'équipe projet présentent, petit à petit, les futurs livrables aux membres
du CES qui sont en mode support. Cela permet aux ressources du support d'intégrer
graduellement les connaissances liées à ces futurs livrables. Les mécanismes de
transfert utilisés lors de cette phase sont la documentation, le mouvement de
personnel et l'interaction formelle. La documentation continue d'être maintenue. Le
mouvement de personnel s'effectue lors du prêt de ressources sporadiques et
l'interaction formelle survient lorsque l'équipe projet présentent les futurs livrables
aux ressources du CES qui évoluent en mode support.
4.1.7 La phase de mise en production
Lorsque les tests d'acceptation se sont révélés satisfaisants et que l'approbation de
poursuivre à l'étape suivante a été obtenue, les livrables sont mis en production.
Durant cette phase, l'interaction se poursuit toujours entre l'équipe projet et les autres
ressources du CES, ce qui permet à l'équipe projet de continuer à présenter les futurs
livrables aux autres ressources du CES. Il est possible qu'une formation formelle soit
offerte aux ressources de l' exploitation juste avant la mise en production. Cette
situation peut surgir lorsque plusieurs membres de l'exploitation ont peu ou pas
participé au projet et que ces derniers considèrent que l'interaction avec l'équipe
projet n'a pas permis un transfert de connaissances satisfaisant. Les deux mécanismes
de transfert utilisés lors de cette phase sont la formation offerte par les ressources de
59
l'équipe projet et l'interaction formelle imposée entre les ressources projet et les
ressources support du CES .
4.1.8 La phase post-implantation
Lorsque les livrables sont implantés, le projet passe en phase post-implantation.
Durant cette phase, l' équipe de projet restera en place et s'occupera du support de la
nouvelle solution implantée. La durée de cette phase diffère d'un projet à l' autre,
mais elle dure généralement entre trois et six mois . Lors de cette phase, l'interaction
entre l'équipe projet et les autres ressources du CES se poursuit et concerne
principalement, comme pour les deux phases précédentes, la présentation des futurs
livrables par les membres de l'équipe projet. La durée de la phase est principalement
dictée par le nombre et l'importance des points en suspens. Lorsque les points en
suspens ont un impact négligeable sur l'utilisation du système, le registre des points
en suspens est transféré aux employés responsables de l'exploitation, car ce sont eux
qui prennent le relais. Ensuite, l'équipe de projet est dissoute et les ressources
retournent à leurs assignations permanentes dans le CES ou dans les différents
domaines d'affaires. Trois mécanismes de transfert sont utilisés lors de cette phase
fmale ; soit le mouvement de personnel, la documentation et l'interaction formelle. Le
mouvement de personnel survient lorsque les membres de l'équipe projet retournent
dans leur département respectif suite à la dissolution de l'équipe de projet. La
documentation est représentée par le transfert du registre des points en suspens et
l' interaction formelle est présente lors des échanges imposés entre les membres de
l'équipe projet et les autres ressources du CES.
60
4.2 Organisation B
L'organisation B est une entreprise du secteur public qui fournit des services de
transports collectifs à une ville canadienne d' envergure. Elle compte environ 9 000
employés. Les modules . ERP utilisés par cette organisation proviennent du
fournisseur SAP. Elle a implanté ces premiers modules en l'an 2000. Il s 'agissait des
modules financiers FI (comptabilité fmancière) et CO (contrôle de gestion). Depuis,
le système intégré est en constante évolution et plusieurs modules ont été ajoutés. Le
dernier module à avoir été implanté est le module PS (gestion de projets) pour lequel
la transition n'était pas encore tout à fait complétée au moment des entrevues.
La stratégie de l'organisation est de tenter de garder le système le plus «vanille»
possible, c'est-à-dire d'essayer de limiter les personnalisations de système. La
tactique est de présenter les fonctionnalités de l' application aux secteurs d'affaires et
d' identifier ce qui manque aux processus proposés plutôt que d'adapter l' application
en fonction des processus d'affaires existants. L'évolution technologique de
l' application est une priorité pour l'organisation, qui a mis en place une stratégie de
mises à jour bisannuelle. Chaque mise à jour réquisitionne un grand nombre de
ressources fonctionnelles et techniques pour une période pouvant aller jusqu 'à six
semaines. Pendant cette période, la majorité des demandes de changement et des
projets d'évolution sont en arrêt.
Initialement axée sur l'aspect fmancier, vu la nature des premiers modules implantés,
l'attention principale de l'organisation s'est déplacée avec le temps vers des secteurs
opérationnels, ce qui a eu un impact sur l'évolution du système. Présentement, les
efforts sont dirigés davantage vers l'entretien des actifs et la chaîne logistique. Le
nombre grandissant de secteurs d'affaires intégrés au système ERP, ainsi que
61
l'augmentation du nombre de modules en exploitation expliquent la croissance du
nombre de ressources affectées à la gestion du système intégré.
Dans le cadre de l'étude de l'organisation B, six répondants furent rencontrés. Le
premier répondant est le chef de la division intégration SAP. En plus de diriger les
concepteurs, il siège aux différents comités de pilotage pour les projets affectant le
système ERP. Il est à l'emploi de l'organisation B depuis près de trente ans. Il a
débuté au sein de l'entreprise comme conseiller en encadrement de système pour un
secteur d'affaires. Il a ensuite été transféré au service informatique où il a participé à
l'implantation initiale du ERP. Il travaille sur ce système depuis. Le deuxième
répondant est le chef de section SAP solution. Faisant partie de la division intégration
SAP, il est en charge des responsables des différents modules du système. Il joue
aussi un rôle important lors de la transition entre les projets et l'exploitation. Il
travaille pour l'organisation B depuis douze ans, dont plusieurs en tant que chef de
section SAP solution. Le chef de division des projets TI fût aussi rencontré. Bien que
récemment arrivé au sein de l'organisation étudiée, il possède plusieurs années
d'expérience à titre de gestionnaire de projet. Le quatrième répondant est un chef de
projet évoluant dans la division des projets TI. Il travaille sur des projets liés à des
systèmes ERP du fournisseur SAP depuis quinze ans. Il est à l'embauche de
l'organisation B depuis presque dix ans.
Les deux derniers répondants proviennent des secteurs d'affaires. Le premier est le
chef de division processus système et opérations comptables. Il est responsable de
l'encadrement de système pour tous les gestionnaires du secteur fmance,
ce qui
implique une collaboration avec la division intégration SAP. Il travaille pour
62
l'entreprise depuis plus de vingt-cinq ans. Le dernier répondant est chef d'une
division liée à l'ingénierie et l'infrastructure. Cette division ne possède pas de
conseillers en encadrement de système, c'est donc ses ressources opérationnelles qui
collaborent avec la division intégration SAP. Il est à l'embauche de l'organisation
depuis moins de deux ans et c'est la première fois qu'il est impliqué dans des projets
liés à un système ERP.
4.2.2 Structure d'exploitation du système intégré
La structure qui encadre l'exploitation et l'évolution du système intégré de
l'organisation B implique plusieurs acteurs. Le point central de cette structure est la
division intégration SAP. Cette division est responsable de la pérennité du système.
Elle s'assure du respect de 1' architecture et assure une vigie dans le but d'optimiser
l' évolution du système. Les concepteurs dépendent directement du chef de cette
division. Ces concepteurs sont responsables de l'architecture du système et s'assurent
que toutes les modifications apportées à ce dernier respectent les lignes directrices de
la division. Ils sont donc impliqués dans toutes les activités qui impactent le système
ERP et jouent le rôle de gardien de la solution. Cette division inclut aussi le groupe
infrastructure, c'est-à-dire les ressources qui s'occupent de l'administration du
système et de l'administration de la base de données, ainsi que le secteur SAP
solution. Ce secteur est responsable de l'exploitation du système. Il compte près
d'une vingtaine de ressources, parmi lesquelles se trouvent les responsables de
module. Un responsable de module est une personne qui a développé une expertise
pour un module particulier du système ERP. Il est celui qui collabore avec les
représentants du secteur d'affaires propriétaire du module pour tout ce qui concerne
les demandes de support ou de modification. Ces responsables, aussi appelés
analystes
prmc1paux,
possèdent
des
connaissances
autant
techniques
que
63
fonctionnelles pour le module qui leur est attitré. Ils s'occupent de la configuration et
du développement. Le développement complexe est cependant délégué à des
analystes du secteur qui possèdent une expertise spécifique pour ce type d 'activité. La
division intégration SAP regroupe donc les administrateurs du système, les
administrateurs de l'entrepôt de données, les concepteurs, les responsables de module
et toutes les ressources qui effectuent le développement et la configuration du
système, excepté les administrateurs de la sécurité.
Du côté client, la structure diverge selon le secteur d'affaires. Certains secteurs
possèdent des conseillers en encadrement de système, tandis que d 'autres n 'en
possèdent pas. Ces conseillers font le pont entre les opérations et la division
intégration SAP et servent aussi de personnes ressources pour les opérations lorsque
des modifications au système sont mises en exploitation. Ces ressources, bien que
rattachées à leur secteur d'affaires respectif, collaborent de manière étroite avec les
responsables de module et les concepteurs. Leur expertise est davantage axée sur les
connaissances fonctionnelles, soit les processus d'affaires, comparativement aux
concepteurs et responsables de module dont les connaissances sont davantage axées
sur l'aspect technique, dont la configuration et la programmation. Il existe une zone
de collaboration entre ces différentes ressources pour laquelle les responsabilités ne
sont pas clairement défmies. Cette zone correspond aux connaissances logicielles,
c'est-à-dire aux fonctionnalités offertes par le système. Ces fonctionnalités couvrent à
la fois des aspects techniques et fonctionnels. Dans le secteur finance, une division
entière a été mise en place pour assurer le pont entre la division intégration SAP et les
différents gestionnaires du secteur. Chacun de ces gestionnaires se voit attribuer un
conseiller en encadrement avec lequel il communique pour toutes questions et
demandes relatives au système intégré. Lorsque que les secteurs ne possèdent pas de
conseillers en encadrement de système, les ressources de la division intégration SAP
discutent directement avec le personnel responsable des opérations pour toute
question relative à l'exploitation. Dans ces secteurs, les ressources désignées pour
64
collaborer avec les gens de l'exploitation sont considérées comme des utilisateurs
experts. Le système intégré de l'organisation B est donc exploité par les ressources de
la division intégration SAP en étroite collaboration avec les ressources désignées par
les différents secteurs d'affaires, dont les conseillers en encadrement et les utilisateurs
experts.
Lorsque les efforts requis et la complexité d'une demande de changement dépassent
les balises associées au support, cette dernière est redirigée vers la division des
projets TI. Cette division joue le rôle de bureau de projet pour tous les projets TI de
l'organisation, ce qui inclut donc les projets touchant le ERP. Elle devient
responsable de l'évolution du système ERP lorsque la décision est prise de
transformer une demande de changement en projet. Le processus de transfert de
connaissances lié à l'exécution d 'un projet au sein de l'organisation B est constitué de
plusieurs activités. Elles sont énumérées au tableau 4.2. Ce tableau contient aussi les
mécanismes de transfert utilisés lors de ces activités. Le processus de transfert de
connaissances est représenté graphiquement à la figure 4.2.
65
Tableau 4. 2
Les activités de .transfert de connaissances liées aux projets ERP de l'organisation B
Activité
Intégrer les connaissances
des ressources de
1' exploitation
documentation
Interagir avec les ressources
de l'exploitation
(comité de pilotage)
Transférer la documentation
liée au projet
(incluant le journal des
points en suspens)
Former les ressources de
l'exploitation
Assistance de la part du
consultant principal
Phases
Identification
Mécanismes
Identification
Conception préliminaire
Conception détaillée
Tests
Conception préliminaire
Conception détaillée
Tests
Documentation
Mise en production
Documentation
Mise en production
Post-implantation
Formation
Post-implantation
t
0
t~$?1.
Figur e4. 2 Processu s de transfert de connaissances entre l' équipe projetetl' exploitation de l' organisationB
V>
~
~
"0
~
~
.5
:~~
0 · .t'
.2
c c:
3;
,g
~
y5
~
Ç:.OI&Ç~~lf'
V1U~-~I.:(fi~
lt~H -t!':'4t'ilto.u"e>Ctt
0'1
0'1
67
4.2.3 La phase d'identification
La phase initiale des projets d'évolution ERP est la phase d'identification. Lors de
cette phase, un chef de projet en provenance de la division des projets TI est affecté
au projet. La première activité de transfert de connaissances qui a lieu est
l'intégration de connaissances. Lors de cette activité, des discussions ont lieu entre le
chef de projet et les différents secteurs impliqués dans le projet. Les concepteurs de la
division intégration SAP partagent leur savoir sur les modules et l'architecture du
système, tandis que les conseillers en encadrement de système et les experts du ou des
secteurs d'affaires concernés partagent leurs connaissances liées aux processus
d'affaires. L'activité suivante est la constitution de l'équipe projet. Cette équipe est
formée à partir de ressources qui sont prêtées par la division intégration SAP et par
les secteurs d'affaires impliqués dans le projet suite à une négociation entre le chef de
projet et ces divisions. La collaboration entre les concepteurs, les responsables de
module et les conseillers en encadrement, qui existe en mode exploitation, est
transposée dans le projet. Selon les besoins et les disponibilités, certaines ressources
sont assignées à temps plein sur le projet, tandis que d'autres le sont à temps partiel.
Ces ressources amènent avec eux leur bagage de connaissances afin d'en faire
profiter l'équipe projet. Il y a également une embauche de consultants lorsque les
ressources nécessaires ne sont pas disponibles ou que l'expertise recherchée n'existe
pas au sein de l'organisation. L'aspect évolutif lié aux projets ERP fait en sorte qu'il
y a pratiquement toujours au moins un consultant par projet. Ces derniers sont
embauchés par la division intégration SAP. Ainsi, les mécanismes de transfert utilisés
lors de cette phase initiale sont l' interaction informelle et le mouvement de personnel.
Le premier est utilisé lors de l'intégration des connaissances, tandis que le deuxième
survient lors de la constitution de l' équipe projet.
68
4.2.4 Les phases de conception préliminaire, conception détaillée et de tests
Durant les phases de conception préliminaire, de conception détaillée et de tests, une
documentation est créée et maintenue à jour par l'équipe projet. Parmi les documents
créés se trouve une liste des processus créés ou modifiés par le projet, les documents
de conception et d'architecture, ainsi que la charte de projet. Le comité de pilotage
rencontre l'équipe de projet régulièrement lors de ces phases. Ce comité de
supervision de projet est constitué de représentants de l'équipe projet, de
représentants de la division intégration SAP et de représentants du ou des secteurs
d'affaires impliqués dans le projet. Le consultant principal embauché pour le projet,
lorsqu'il y a embauche de consultants, fait aussi partie de ce comité. Le chef de la
division intégration SAP siège normalement à chaque comité de pilotage. Lors de ces
rencontres, les ressources de l'exploitation sont informées de ce qui a été fait jusqu'à
maintenant dans le projet et la teneur des livrables prévus. Il y a ensuite discussion
entre les ressources de l'exploitation et les représentants de l'équipe projet. Ces
interactions portent en majeure partie sur le transfert de connaissances, afin de
s'assurer que l'exploitation sera à l'aise avec le futur déploiement. La participation du
chef de section SAP solution à ce comité augmente vers la fm des projets. Sa
présence vise à s'assurer que la transition vers l'exploitation est bien encadrée. Il y a
donc deux mécanismes de transfert qui sont utilisés lors de ces trois phases. Il s'agit
de la documentation et de l'interaction formelle. La documentation est utilisée lors
de la création et le maintien de la documentation liée au projet. L' interaction formelle
survient lors des rencontres du comité de pilotage.
69
Tel qu'illustré à la figure 4.2, il y a deux activités de transfert de connaissances lors
de la phase de mise en production. Premièrement, les documents maintenus tout au
long du projet sont transférés à la division intégration SAP. En plus de ces
documents, une passation s'effectue au niveau du journal des points en suspens.
Chaque point en suspens est expliqué en détail à la division intégration SAP, car ces
points relèveront de cette division lorsque l' équipe projet sera dissoute. Les membres
de l'équipe projet participent activement au transfert de connaissances. Les
concepteurs, les conseillers en encadrement et les utilisateurs experts qui ont pris part
au projet transfèrent leur savoir aux différentes ressources de l'exploitation. Ce
transfert peut se faire par une interaction un à un ou par des séances de formation
formelles. Le consultant principal contribue aussi au transfert vers l'exploitation,
selon l'entente qu ' il a signée. Les séances de formation formelles sont préconisées
dans le cadre de ce transfert, dans la mesure où le consultant possède l'aisance pour le
faire. Lorsque ces activités de transfert sont complétées et que les livrables sont mis
en production, le projet passe à la phase de post-implantation. Les mécanismes de
transfert de connaissances utilisés lors de la phase de mise en production sont la
documentation, la formation et l'interaction informelle. La documentation est utilisée
lors du transfert des documents vers l'exploitation, la formation lors des séances
offertes aux ressources de l' exploitation et l'interaction informelle lorsque le transfert
vers l'exploitation ne s'effectue pas via une séance de formation forme lle.
Durant cette phase, le rôle des membres de l'équipe projet est de supporter les
nouveaux livrables en exploitation. La durée de la phase de post-implantation diffère
70
selon les projets. Elle est d'une durée minimale de trois mois pour les projets
d'envergure. Le transfert de connaissances est l'un des critères de clôture des projets.
Lorsque le comité de pilotage juge que le transfert de connaissances est adéquat, il
donne son aval à la dissolution de l'équipe projet. C'est donc dire que les membres de
l'équipe projet retournent dans leur secteur respectif, amenant avec eux les
connaissances acquises lors de la réalisation du projet. Pour certains projets, le
consultant principal peut rester au sein de 1' organisation pour une certaine période de
temps suivant la dissolution de l'équipe. Durant cette période, il porte assistance aux
ressources en exploitation. Le mouvement de personnel est le seul mécanisme de
transfert de connaissances utilisé dans cette phase fmale. Le retour des ressources
dans leur division d ' origine lors de la dissolution de l'équipe projet et l'assistance
offerte par le consultant aux ressources du support sont considérés comme deux
activités utilisant le mouvement de personnel.
4.3 Organisation C
L'organisation C est une entreprise canadienne publique dans le secteur de l'énergie.
Elle emploie plus de 20 000 employés répartis sur près de 150 sites. La solution ERP
mise en place par l'organisation C provient du fournisseur SAP. Le premier module a
été implanté en 1998. L'évolution du système fut constante et l'organisation utilise
présentement plusieurs modules offerts par SAP, dont le module fmancier FICO, le
module de gestion d ' entrepôt WM, le module de gestion du matériel MM, le module
de gestion de projet PS et le module de gestion des ressources humaines HR.
La stratégie de mise en production des modifications apportées au système ERP a
changé de manière drastique depuis l'implantation initiale. Au départ, les mises en
production de changements au système pouvaient se faire tous les jours. Maintenant,
71
il n'y a que quatre livraisons de prévues par année, c'est-à-dire une à tous les trois
mois. Tout changement au système doit donc être planifié et intégré à l'une de ces
livraisons. La semaine avant une livraison est appelée « semaine rouge », cette
semaine en est une de validation et de stabilisation. C'est donc dire qu'il n'y a plus
d'ajouts possibles à la livraison prévue. En plus des quatre livraisons, il est possible
d'implanter des correctifs d'anomalies une fois semaine et les implantations en
urgence sont possibles en tout temps. Les mises à jour du système provenant du
fournisseur sont implantées une fois par année, normalement au mois de novembre.
Cette opération nécessite l'effort de plusieurs ressources et ce pour plusieurs
semames.
L'organisation tente de minimiser les personnalisations du ERP. Ainsi, pour qu'une
personnalisation soit permise, elle doit être justifiée. Les personnalisations réclamées
par une grande majorité d'utilisateurs seront normalement acceptées. Par le passé,
l'organisation a déjà fait affaire avec des consortiums externes pour qu 'ils s'occupent
de migrations importantes du système ou d' implantation de nouveaux modules.
Cinq répondants de l'organisation C furent rencontrés pour cette étude de cas. Le
premier répondant est le chef technologie pour les solutions corporatives finances et
RH. Il travaille pour le directeur solutions intégrées SAP à la direction principale des
technologies de l'information (DPTI) et il est responsable des ressources de l'équipe
«transformé », qui travaillent en collaboration avec la vice-présidence ressources
humaines (VPRH) et la vice-présidence comptabilité et contrôle (VPCC) et ses
clients. Il a fait le saut en gestion de systèmes intégrés il y a près de vingt ans. En plus
d'avoir travaillé pour SAP Canada, il a été à son compte pendant douze ans, ce qui lui ·
72
a permis d'effectuer des mandats pour plusieurs grandes entreprises canadiennes. Le
deuxième répondant est le chef comptabilité de gestion des systèmes à la VPCC. Il
est donc responsable, assisté par son équipe, de recueillir les besoins concernant les
modules fmances pour l'ensemble de l'entreprise et de les traduire en langage
technique pour la DPTI. Il est à l'emploi de l'organisation C depuis environ dix ans.
Il occupe son poste actuel depuis un an. Il a précédemment travaillé six ans sur les
modules financiers au sein de la DPTI et pendant trois ans comme analyste d'affaires
pour une division de l'entreprise. Ce poste d'analyste était très similaire à celui qu'il
occupe présentement,
sauf qu'il concernait une
seule division plutôt que
l'organisation entière. Un des clients représentés par la VPCC fût aussi rencontré. Il
s'agit du responsable de l'équipe évolution des systèmes pour le volet fmancier de la
division A. Il représente donc le client pour les projets qui touche sa division. Il a
participé à l'implantation initiale du ERP au sein de l'organisation C et travaille en
étroite relation avec le système intégré depuis, c'est-à-dire une quinzaine d'années.
Le quatrième répondant est le responsable de l'aspect performance et mesure à la
VPRH. Il s'occupe de tout ce qui touche l'évolution des processus. Il travaille donc
en collaboration avec le groupe TI. À titre de consultant, il a participé à la migration
initiale des anciens systèmes RH de l'organisation vers SAP. Il fût par la suite engagé
comme employé par l'entreprise. Il a travaillé sur les modules ressources humaines
pour la DPTI jusqu 'à ce que la VPRH décide de rapatrier les connaissances
processuelles au sein de son unité. Il évolue au sein de la VPRH depuis ce temps,
c'est-à-dire depuis près de cinq ans. Le dernier répondant est conseiller d'affaires et
systèmes au centre de services partagés (CSP) de la division B. Il s'occupe de la
planification du portefeuille de projets TI pour ce centre. Lorsque son département est
impliqué, à titre de client, dans des projets touchant le système intégré, il agit à titre
de pilote fonctionnel pour s'assurer que les livrables soient conformes à la vision du
centre. Il est à l'emploi du CSP de la division B depuis près de cinq ans.
73
4.3.2 Structure d'exploitation du système intégré
L'exploitation du système intégré de l'organisation C relève du directeur solutions
intégrées SAP, qui lui relève de la DPTI. Le directeur solutions intégrées SAP
possède une vision globale de l'évolution du système. Une restructuration récente de
la DPTI a abouti en une séparation claire des ressources informatiques affectées au
ERP. Elles font maintenant soit partie de l'équipe «transformé» ou de l'équipe
«exploité », exception faite des ressources liées à l'infrastructure; base de données,
sécurité, etc. L'équipe «transformé» est constituée d'analystes fonctionnels,
d'architectes et de développeurs. Les analystes fonctionnels effectuent 1' analyse
technique des besoins et certaines paramétrisations. Les architectes s'assurent que les
livrables prévus respecteront l'architecture TI du système en place, tandis que les
développeurs s'occupent de la programmation requise par les personnalisations
demandées. Il faut cependant noter que pour certains secteurs d'affaires, autres que
finance et ressources humaines, les analystes fol}ctionnels peuvent se retrouver
directement dans le secteur d'affaires plutôt que dans l'équipe TI. La plupart des
analystes fonctionnels de l'équipe «transformé» ont déjà travaillé pour un des
secteurs d'affaires de l'organisation. Ils possèdent donc des connaissances accrues
pour un secteur en particulier, en plus d'avoir développé des aptitudes de
configuration dans SAP. L'équipe «transformé» est responsable de tout ce qui
touche l'évolution du système intégré, du projet à la petite demande de correctif. Elle
est aussi responsable des mises à jour planifiées et des migrations. «L'équipe
exploité », pour sa part, se trouve dans le secteur exploitation applicative, toujours
sous la responsabilité du directeur solutions intégrées SAP. Cette équipe est séparée
physiquement de l'équipe «transformé». Elle est la première ligne de support au
niveau des TI et s'occupe des anomalies de système, ainsi que de certaines mises à
jour non planifiées. Par contre, aussitôt qu'une anomalie requiert un correctif, la
demande est transférée à l'équipe «transformé». De plus, l'équipe «exploité» peut
74
faire appel à l'équipe «transformé» lorsque le support nécessite une expertise
particulière.
Du côté client, la VPCC et la VPRH exploitent les modules du système ERP reliés
aux secteurs d'affaires qu'ils desservent. La VPCC s'occupe des modules financiers,
tandis que la VPRH s'occupe des modules RH. La VPCC et la VPRH encadrent les
ressources qui utilisent ces modules pour tout ce qui touche l'aspect fonctionnel; la
saisie de données, le fonctionnement des processus, etc. La VPCC s'occupe aussi du
traitement de certaines opérations transactionnelles massives liées à la paie
(ex. augmentation de salaire, vacances, etc.). Ces deux départements servent
d'intermédiaire entre le client et la DPTI pour tout ce qui concerne les modifications
au système intégré. Ils s'assurent que le besoin est réel et qu' il respecte la logique du
processus concerné. Ils traduisent par la suite la demande en langage technique, pour
ensuite la transmettre à la DPTI. Par contre, tout ce qui touche l'aspect technique du
système intégré est sous la responsabilité de la DPTI, que ce soit pour le support ou
pour les demandes de changements. Le point de contact pour la VPCC et la VPRH à
la DPTI est différent selon s'il s'agit d'exploitation ou de transformation. Il existe une
légère exception à la séparation du fonctionnel et du technique entre la VPCC et la
DPTI. Les ressources qui s'occupent de l'exploitation fonctionnelle des modules
fmanciers, par exemple les fms de mois, se retrouvent au sein de la DPTI.
L'équipe évolution des systèmes pour le volet financier de la division A est
représentée par la VPCC auprès de la DPTI. Les demandes doivent donc transiter par
la VPCC, qui à son tour les transmet à la DPTI, qui elle, s 'occupe de l' exécution.
Lors des projets, il se peut que ce client travaille directement avec la DPTI. Lorsque
cette situation survient, les membres de la VPCC participent quand même au projet. Il
faut mentionner que ce ne sont pas tous les domaines d'affaires qui possèdent un
intermédiaire entre leur domaine et la DPTI.
Par exemple, le centre de services
partagés de la division B mandate directement la DPTI pour l'exploitation des
75
modules dont il est propriétaire. Le nombre limité de ressources employées par ce
centre explique cette situation.
Une équipe projet est formée pour chaque projet d'évolution concernant le système
intégré. L 'organisation tente de conserver un ratio de 50/50 pour ce qui a trait à la
répartition des ressources internes et externes au sein du projet. D'un point de vue
général, les différents clients (VPCC, VPRH ou équipe évolution des systèmes) sont
impliqués davantage dans les projets qu'en mode exploitation. Le transfert de
connaissances entre les membres de l'équipe projet et les ressources de l'exploitation
s'effectue à travers une multitude d'activités (tableau 4.3). Ces activités se déroulent
à différentes phases du projet. Elles sont représentées graphiquement à la figure 4.3.
76
Tableau 4. 3
Les activités de transfert de connaissances liées aux projets ERP de l'organisation C
Activité
Phases
Mécanismes
Analyse préliminaire
Interagir avec les domaines
d'affaires
Analyse préliminaire
Développement
Tests intégrés
Tests d'acceptation
documentation
Développement
Tests intégrés
Tests d'acceptation
Tests d'acceptation
Documentation
Présenter la solution qui sera
implantée
Tests d'acceptation
Formation
Transférer la documentation liée
au projet
Mise en production
Documentation
Former les ressources de la DPTI
Mise en production
Formation
Transférer le carnet de
commandes
(liste des anomalies)
Post-implantation
Documentation
Post-implantation
Post-implantation
Post-implantation
Intégrer les ressources
additionnelles prêtées au projet
Assistance de la part du
consultant principal
Supporter la nouvelle solution
implantée
(par les domaines d'affaires)
~-
Figure 4. 3 Processus de transfert de cœmaissances entrer équipe projet et 1' exploitation de 1' organisation C
8
-~
""~c
~
l
....
·~
o.. -
!.,of
.2_
..t
ltt
""~
J
liit
wc
1;;:::;.
l3
'~
~
~
l
fm t ~ro.t:nkn
-J
-J
78
4.3.3 La phase d'analyse préliminaire
Chaque projet de l'organisation C commence par une phase d'analyse préliminaire.
L'équipe projet est formée au début de cette phase. Cette équipe est normalement
constituée d'un chargé de projet, d'intégrateurs (consultants externes), de
développeurs, d'architectes, d'analystes fonctionnels, d'analystes d'affaires, de
représentants du client et de responsables de la formation. La plupart de ces
ressources sont prêtées à l'équipe projet par l'équipe« transformé», ainsi que par les
domaines d'affaires concernés. Ces ressources amènent avec eux leurs connaissances
respectives. Aucune ressource de l'équipe « exploité» n'est affectée au projet. Le
chargé de projet est fourni par la DPTI pour la grande majorité des projets. Il se peut
cependant que le projet n'ait pas de chargé de projet de la DPTI, par exemple les
projets financiers et RH de moins de 100 jours, qui sont sous la responsabilité des
clients (VPCC ou VPRH). Les domaines d'affaires déterminent l'implication dans le
projet de leurs ressources respectives selon l'ampleur de celui-ci. C'est donc dire que
les ressources peuvent être affectées à temps plein sur le projet ou à temps partiel.
Ces ressources continuent d'interagir avec leur secteur respectif tout au long du
projet. Ces interactions peuvent se faire par l'entremise de rencontres statuaires. Par
ces interactions, ces ressources restent à l'affût de ce qui se passe dans leur domaine
d'affaires. Ces interactions permettent aussi à ces ressources de partager les
connaissances liées à ce qui se déroule dans le projet. Les mécanismes de transfert de
connaissances utilisés dans cette phase sont le mouvement de personnel et
l'interaction informelle. Le mouvement de personnel survient lors de la constitution
de l'équipe et les interactions informelles se manifestent lorsque les membres de
l'équipe projet communiquent avec les ressources de leur département respectif
79
4.3.4 Les phases de développement et de tests intégrés
Les phases qm suivent la phase d'analyse préliminaire sont la phase de
développement et la phase des tests intégrés. Les activités de transfert de
connaissances qui se déroulent lors de ces phases sont identiques. Premièrement, une
documentation est créée et maintenue. La documentation technique est sous la
responsabilité des membres de l'équipe informatique, tandis que la documentation
des processus d'affaires est sous la responsabilité des ressources provenant des
domaines d'affaires. L'interaction entre les membres de l'équipe projet et leur secteur
respectif se poursuit également lors de ces deux phases.
Deux mécanismes de
transfert de connaissances sont utilisés lors de ces phases, soit la documentation et
l'interaction informelle. Le premier est utilisé lors de la création et du maintien de la
documentation, tandis que le deuxième est utilisé lors des contacts entre les membres
de l'équipe projet et les membres de leur département respectif
4.3.5 La phase des tests d'acceptation
Tel que démontré à la figure 4.3 , les activités de transfert des deux phases
précédentes se déroulent aussi lors de la phase des tests d'acceptation, c'est -à-dire la
mise à jour de la documentation et l'interaction des membres de l'équipe projet avec
leur secteur respectif. Deux nouvelles activités s'ajoutent à celles-ci. Des ressources
en provenance des domaines d'affaires, qui ne font pas partie de l'équipe projet,
participent aux tests d'acceptation. Cette activité leur permet de se familiariser avec
les nouveaux livrables qui seront mis en production. Ces mêmes livrables sont
présentés de manière formelle aux ressources désignées par les domaines d'affaires.
Ces ressources doivent confirmer par la suite que le transfert de connaissances a été
effectué. Sans cette confirmation, les livrables ne peuvent aller en production.
80
Cependant, pour certains projets, le domaine d'affaires peut signaler qu'il ne
considère pas nécessaire de tenir une présentation formelle pour le transfert. Il y a
donc quatre mécanismes de transfert utilisés lors de cette phase. La documentation et
l'interaction formelle sont utilisées dans le même contexte que les deux phases
précédentes. À ces deux mécanismes s'ajoutent le mouvement de personnel et la
formation. Le mouvement de personnel est utilisé lorsque des ressources
supplémentaires intègrent le projet pour participer aux tests et la formation est utilisée
lorsque la solution qui sera implantée est présentée aux personnes désignées.
Lorsque l'approbation est obtenue, les nouveaux livrables sont mis en production. À
cette phase, l'équipe projet transfère la documentation technique aux ressources de
l'équipe «transformé» qui ne sont pas sur le projet et à l'équipe «exploité». Elle
transfere également la documentation des processus d'affaires aux domaines
d'affaires concernés. Le consultant principal partage ses connaissances aux
ressources du support via une séance de formation. Il est aussi demandé aux
ressources de l'équipe projet provenant de la DPTI de former au minimum une
ressource de l'équipe «transformé » qui n'a pas participé au projet et une ressource
de l'équipe «exploité ». Ce transfert, lorsqu ' il a lieu, se fait de manière informelle
entre les ressources concernées. Les trois mécanismes de transfert qui sont utilisés à
cette phase sont la documentation, la formation et l'interaction informelle. La
documentation est utilisée lors du transfert de celle-ci vers les différentes ressources
du support. La formation est utilisée lorsque le consultant principal transfère ses
connaissances aux ressources du support et l'interaction informelle est utilisée
lorsque les
ressources en provenance de la DPTI, qui ont participé aux projets,
transfèrent leurs connaissances à leurs collègues.
81
Suite à l'implantation des nouveaux livrables, le projet passe en phase postimplantation. L'équipe projet effectue le support lié à ces nouveaux livrables durant
la période couvrant le premier cycle d'exploitation. Le premier cycle d'exploitation
est complété lorsque toutes les nouvelles fonctionnalités ont été utilisées au moins
une fois. Lorsque le premier cycle est complété, l'équipe projet transfere le carnet de
commandes, c'est-à-dire la liste des anomalies restantes, à l'équipe« exploité». Suite
à ce transfert, l'équipe projet est dissoute et les ressources sont retournées dans leur
département respectif, amenant avec elles leurs nouvelles connaissances acquises. À
partir de ce moment, le support est effectué par l'équipe «exploité» et par les
·domaines d'affaires. Toutefois, les membres de l'équipe «exploité» peuvent
demander l'assistance des membres de l'équipe «transformé», dont ceux qui ont
participé au projet. Pour ce qui est des domaines d'affaires, le support aux usagers est
normalement effectué par les ressources qui étaient membres de l'équipe projet et
cela jusqu'à ce que les autres ressources du domaine soit à l'aise de le faire. Il faut
aussi mentionner que l'intégrateur principal reste habituellement de deux à trois
semaines après la dissolution de l'équipe pour prêter assistance à ceux qui le
réclament, que ce soit l'équipe «transformé», l'équipe «exploité» ou les domaines
d'affaires. Deux mécanismes de transfert de connaissances sont utilisés lors de cette
dernière phase. Le mouvement de personnel est utilisé pour trois activités différentes,
c'est-à-dire lors du retour des membres de l'équipe projet dans leur département
respectif, lorsque le consultant principal porte assistance aux ressources du support
après la dissolution de l' équipe projet et lorsque les anciennes ressources de l'équipe
projet en provenance des domaines d'affaires supportent les utilisateurs fmaux.
L'autre mécanisme utilisé est la documentation, et ce lors du transfert du carnet de
commandes.
CHAPITRE V
COMPARAISON DES CAS
Dans ce chapitre, les trois études de cas sont comparées et analysées afin de mettre en
lumière les éléments qui constituent le transfert de connaissances et les éléments qui
influencent le processus de transfert de connaissances. Tel que mentionné dans le
chapitre II portant sur le cadre d'analyse, les principaux éléments qui seront analysés
sont la structure d'exploitation du système ERP, le rôle de l'intégrateur principal, la
phase post-implantation des projets d'évolution ERP, les mécanismes formels et les
mécanismes informels utilisés.
5.1 Structure d'exploitation du système ERP
La structure d'exploitation m1se en place diffère d'une organisation à l'autre.
L'organisation A a regroupé
ses ressources
techniques et
ses ressources
fonctionnelles dans son centre d 'expertise et de soutien (figure 5.1). Ce centre
correspond à la défmition d'un centre de compétences proposée par Baskerville et al.
(2006) . Les ressources techniques de l'organisation B sont situées dans la division
intégration SAP, qui fait aussi office de centre de compétences. Cependant, ce centre
ne correspond pas tout à fait à la définition de Baskerville et al. (2006), dû au fait que
les ressources fonctionnelles ne font pas partie de cette division. Elles sont situées
dans les domaines d' affaires qui utilisent le système intégré (figure 5.2). Tout comme
l'organisation B, les ressources fonctionnelles de l' organisation C sont situées dans
83
les domaines d'affaires. Les ressources techniques de cette organisation sont sous la
responsabilité du département TI. Elles sont cependant séparées en deux secteurs, soit
le secteur «transformé» et le secteur« exploité» (figure 5.3). Le premier s'occupe
des projets d'évolution et des modifications au système, tandis que le deuxième
s'occupe du support et de la gestion des petites anomalies.
Ressources
ted1rüques
Ressources
f onctïonnelles
Figure 5. 1 Structure d'exploitation du système ERP de l'organisation A
Unitéd'affa iresl
~.
Ressources
fonctionnelles
Unitéd'affaires2 ~ ..
Ressources
techniques
(
)
Ressources
fonctionnelles
Unité d'affaires N ..
Ressources
f onctionnelles
Figure 5. 2 Structure d'exploitation du système ERP de l'organisation B
84
..1
/-1
..l
Dépa rte me ntTI
Tra nsformé
l
Ressou rces
tech niques
~
..l
~
Exploité
dédiées
un it é d'affaires 1
Ressources
t echniques
Resso urces
techniques
dé di ô!~s
unité d~affa.ires 2
unité d'affak es 2
d.édié-es-
d@diées
unité d'affaires N.
Ressou rces
fonctio nnelles
"
Il'
À
Unit é d'affaires 2 ~
Ressou rces
f onctionnelles
déd iées
•
AUnitéd'affairesN .. JI
Ressources
te chniqu es
...
./
'\:
'!'-
Ressources
techniques
unit-é d'affa5t~s 1
Ressources
techniques
..Ù • pt'
li!
Unité d'affaires 1
~
dédiées
un itè d'affaires N.
\..
....
..
Ressources
f onctionnelles
/
Figure 5. 3 Structure d'exploitation du système ERP de l'organisation C
Lors de la collecte de données, trois éléments de la structure d'exploitation ayant une
influence sur le processus de transfert ont été identifiés, soit la centralisation de la
structure, la localisation des ressources et l'assignation des ressources TI. Ces trois
caractéristiques se retrouvent dans le tableau comparatif de la figure 5.4.
Organisation A
Organisation B
Organisation C
Structure de
sup port
Cen tr aJi.~ée
Hybride
Hybride
Localisation des
ressources
Resso urces tec hniq ues
•e t fonction ne ll·es
intégrées
Resso urces tec hn iq ues et
fonction ne lies séparées
physiquement
Resso urces techni q ueset
fonctionne Il es sépa rées
physiquement
Assignation des
re ssources Tl
P-artage projet et
su pp.ort
Partage projet et
su pp.ort
Séparation projet et
su pport
Figure 5. 4 Comparaison des structures d'exploitation ERP
1
85
5.1.1 La centralisation de la structure d'exploitation
La première caractéristique repose sur la défmition offerte par Gallagher et al. (2012).
Selon les auteurs, la structure centralisée consiste à former une équipe permanente de
support regroupant les utilisateurs experts, tandis que la structure décentralisée se
résume à retourner les utilisateurs experts dans leur département respectif en
éliminant tout lien avec les ressources TI qui s'occupent du système ERP.
L'organisation A est de type centralisé, car toutes les ressources liées à l'exploitation
du ERP sont regroupées en un seul et même département. Pour les organisations B et
C, la structure d'exploitation est hybride. En effet, en plus de leur structure TI
centralisée, ces organisations ont mise en place des départements fonctionnels dédiés
à l'exploitation du système ERP pour les fonctionnalités plus matures du progiciel. Il
existe cependant une dynamique différente pour les autres secteurs, où ce sont les
ressources fonctionnelles en provenance des opérations, qui participent de manière
sporadique aux projets d'évolution ou au support du système.
Pour certains secteurs, il s'agit de ressources opérationnelles qui ont été assignées au
système ERP, et ce de manière sporadique. Ces ressources ne font pas partie de la
structure de support permanente, elles tiennent plutôt le rôle d'utilisateurs experts.
Ces secteurs plus petits ou moins matures sont dans une situation précaire au niveau
du transfert de connaissances. En effet, ces ressources sont les seules à posséder
certaines des connaissances fonctionnelles concernant le ERP pour leur secteur. Le
fait qu'elles soient des ressources opérationnelles peut faire en sorte qu'il soit
impossible d ' interagir avec elles lorsqu'un transfert de connaissances est nécessaire.
C'est pourquoi Hirt et Swanson (2001) avancent que les utilisateurs experts ne
devraient pas retourner dans leur département respectif, car leur présence est requise
pour le support. Un départ subit d'une de ces ressources serait encore plus
problématique, car cela pourrait résulter en une perte de connaissances fonctionnelles.
86
Le responsable de l'équipe évolution des systèmes pour le volet fmancier de la
division A de l'organisation C résume bien cette situation:
[ ... ] Il y a un gros risque. Comme là cette personne-là a quitté l'entreprise
[ ... ] Et là on se ramasse avec un petit laps de temps de seulement 2 semaines
où ... Bien il reste 2, 3 semaines, où elle a fait ce qu'elle a pu pour former
quelqu'un d'autre, mais c'est à recommencer ou à peu près [ ... ] Ça, c'est le
risque quand il y a juste une personne qui le sait.
Cette situation précaire est cependant mitigée par la zone de collaboration existante
entre les ressources techniques et fonctionnelles. Cette collaboration fait en sorte que
les ressources techniques fmissent par détenir une partie des connaissances
fonctionnelles du ERP. Dans le cas d'un départ subit, les ressources techniques
peuvent donc transférer une quantité de connaissances fonctionnelles à la ou les
ressources nouvellement affectées, ce qui permet de pallier en partie à la perte de
connaissances. Le chef de la division intégration SAP de l'organisation B illustre
cette situation :
[ ... ] tu sais la zone hybride que je vous parle, où il y a deux équipes qui
assurent cette connaissance-là, bien s'il y en a un qui part, qui s'en va à sa
retraite ou qui est muté, bien il y a comme un .. . Il y a une autre équipe qui est
capable de compenser. Et ça nous a dépannés autant d'un bord que de l'autre,
par le passé.
5 .1.2 La localisation des ressources
La deuxième caractéristique est la localisation des ressources, qui définit le choix des
organisations relativement à l'emplacement des différentes ressources dans
l'organisation. Dans l'organisation A, les ressources techniques et fonctionnelles sont
localisées dans le même espace physique, qui est situé dans le département TI. Pour
87
les organisations B et C, les ressources techniques sont localisées avec le département
TI et les ressources fonctionnelles sont à proximité de leurs clientèles desservies.
Le choix d ' intégrer les ressources techniques et les ressources fonctionnelles en une
même localisation ou de les séparer physiquement est la caractéristique qui impacte le
plus les organisations au niveau du transfert de connaissances. Le fait de regrouper
toutes les ressources en un seul endroit permet une certaine flexibilité des ressources,
car elles ne sont pas dédiées à une unité d'affaires en particulier. Cela permet aussi de
renforcer le lien relationnel qui existe entre les unités d ' affaires, facilitant du coup le
transfert de connaissances, particulièrement au niveau de l'intégration des modules
(Chen et Huang, 2007). Le chef de programme des systèmes administratifs et chef du
CES de l' organisation A explique son choix d'intégrer ses ressources :
[ . .. ]On a gardé cette façon de faire là, parce que ça a fait ses preuves de 1.
Puis de 2. Moi ce que j'en dis, de le scinder en deux, ça me coûterait plus
cher, ça me prendrait plus de ressources, puis je perdrais en efficacité, j'en
.
.
sms convamcu.
Les unités d'affaires peuvent être réfractaires à l' idée de regrouper les ressources
fonctionnelles dans un centre de compétences. Elles ont l'impression de perdre le
contrôle sur leurs ressources. Cette réaction risque de surgir dans les unités d'affaires
qui possèdent un plus grand nombre de ressources fonctionnelles concernées par
l' intégration. E lles se disent qu 'elles risquent de perdre en efficacité étant donné que
ces ressources pourront être assignées à des tâches liées à d 'autres unités d'affaires. Il
faut donc tenir compte de cette situation lorsqu'on réfléchit à regrouper les ressources
techniques et fonctionnelles dans un centre unique. Le chef de la division intégration
SAP de l'organisation B explique bien le sentiment de certaines unités d'affaires :
[ ... ] en ayant les analystes fonct ionnels, ils ont une autonomie sur ces
ressources-là, qu'ils n'ont pas quand ils sont à l' informatique ou dans un
centre de compétences. Proximité des besoins d'affaires, fait que regarde à
88
tous moments, ils peuvent changer une priorité, dire : « Regarde, il y a du
nouveau puis j'ai besoin de toi, viens-t'en! » [ ... ] Quand on leur parle de
réunir ça dans un centre de compétence, ouf! Là c'est parce que les ressources
deviennent corporatives.
Une faiblesse reprochée à l' intégration des ressources est la décom1exion des
ressources fonctionnelles avec les unités d'affaires. Galbraith (1994) parle du risque
de désintéressement des ressources pour les unités d'affaires desservies et la perte du
sentiment d'urgence dans les situations qui le requiert. Ce qui inquiète davantage en
ce qui concerne le transfert de connaissances, c'est le niveau de connaissances
fonctionnelles des ressources intégrées. À force d 'être éloignés des unités d'affaires,
les membres du centre de compétence se détachent du milieu de travail pour lequel ils
détiennent une expertise, expertise qui leur a valu d'être sélectionnés pour faire partie
du centre de compétence (Persson, 2006). Lors de la rétroaction sur les résultats , les
organisations B et C ont mentionné que cette structure avait été utilisée lors de
l'implantation initiale. Cependant, ils ont décidé de réorganiser leur structure
d'exploitation en retournant les ressources fonctionnelles dans les unités d'affaires
voyant l'effritement des connaissances fonctionnelles détenues par ces ressources.
Par contre, il y a aussi certains désavantages à localiser les ressources fonctionnelles
dans les unités d'affaires. Le premier désavantage est le manque de versatilité de ces
ressources. Elles sont confmées à travailler sur les modules du ERP qui sont liés à
leur unité d 'affaires. Cela pose aussi problème au niveau de l'intégration des modules
ERP lorsqu 'un projet d'évolution touche plus d'une unité d' affaires. Les ressources
fonctionnelles des différentes unités doivent collaborer afin de mener le projet à
terme. Cette collaboration ne peut être optimale étant donné que ces ressources
possèdent peu ou pas de connaissances concernant les modules utilisés par les autres
unités d 'affaires. Le choix de localiser les ressources fonctionnelles dans les unités
d'affaires peut aussi créer un certain déséquilibre entre ces unités. Le nombre de
ressources fonctionnelles dédiées au système ERP diffère d'une unité à l'autre selon
89
l'importance de l'unité d'affaires au sein de l'organisation et son degré de maturité.
Un nombre restreint de ressources peut affecter l'efficacité des projets et du support.
Le chef de la division intégration SAP de l'organisation B partage son point de vue
sur cette situation :
[ ... ] Ce que les autres secteurs n'ont pas nécessairement, c'est qu'il n'y en a
pas autant qu'aux finances. Finances, ils sont grayés mur à mur, je pense
qu'ils en ont cinq ou six. Fait qu'ils sont vraiment solides. Il y a d'autres
secteurs où ça ne ferait pas de tort s'il y en avait plus.
5.1.3 L'assignation des ressources TI
L'assignation des ressources TI est la troisième caractéristique de comparaison des
structures d'exploitation, qui traite de la gestion des projets et des activités de support
par les organisations, tant au niveau des ressources techniques que des ressources
fonctionnelles. Les organisations A et B utilisent leurs ressources fonctionnelles et
techniques pour leurs activités de support et leurs projets. L'organisation C, de son
côté, se distingue par une assignation différente entre ses ressources fonctionnelles et
ses ressources techniques. En effet, l'assignation des ressources fonctionnelles est
identique aux organisations A et B. C'est au niveau des ressources techniques que
celle-ci a décidé de séparer ses activités de support de ses projets avec la création de
deux équipes distinctes (équipe «exploité »vs équipe «transformé »).
Le transfert de connaissances est plus efficace lorsque le travail des ressources TI est
partagé entre les projets et le support. Ces ressources absorbent une plus grande
quantité de connmssance vu la diversité des assignations. Cette diversité
d'assignation permet à ces ressources de comprendre le besoin de connaissances
auquel font face les autres ressources TI étant donné qu'elles sont confrontées aux
90
deux réalités. Cela influence positivement la collaboration entre elles et renforce le
lien relationnel. Ces raisons font en sorte que ces ressources sont plus enclines à
partager leurs connaissances, tel que le mentionne le chef d'équipe du CES de
l'organisation A :
[ ... ] Le plus grand avantage, c'est le transfert de connaissances. [ .. .] C'est la
contribution des personnes qui proviennent du CES, au choix de solutions au
mode projet. C'est-à-dire on garde une certaine harmonie, on garde une
certaine vie commune, si j ' ose dire, entre ce qui est projet, versus ce qui est
production.
Parmi les organisations à l'étude, seule l'organisation C a décidé de séparer
clairement les ressources TI affectées au projet et les ressources TI affectées au
support (équipe « transformé » et équipe « exploité »). La majorité des répondants de
cette organisation ne trouvaient pas d'avantage à cette manière de faire et les
désavantages semblent nombreux. L'efficacité des ressources affectées au support
dépend largement du transfert de connaissances effectué par les ressources affectées
aux projets, transfert qui n'est pas optimal pour l'organisation C (voir section 5.3).
Cela fait en sorte qu'il existe une dépendance malsaine des ressources en support
envers les ressources qui ont travaillé sur les projets, cela est expliqué par le
conseiller d'affaires et systèmes pour la division B de l'organisation C :
[ ... ] je trouve que l'exploitant, il perd un peu de connaissances, il perd une
expertise et quand viennent des problématiques, il est beaucoup plus à la
merci des gens qui ont participé au projet que lui, il n'a pas pu acquérir cette
connaissance-là.
La relation entre les deux groupes de ressources est ardue dans ce contexte. Les
ressources en support ont parfois l'impression que l'équipe projet s'empresse de faire
basculer les projets vers l'exploitation afm de transférer la responsabilité des
anomalies restantes. De son côté, les ressources assignées au projet trouvent qu'elles
doivent épauler trop souvent les ressources en support. Les clients internes de
91
l'organisation ne sont pas épargnés par les conséquences de cette séparation des
ressources. Au lieu d'avoir une seule personne contact au département TI, les clients
doivent communiquer avec un intervenant différent selon si la fonctionnalité
problématique est toujours sous la responsabilité de l'équipe projet ou si elle a été
transférée à l'équipe support. Le responsable de l' équipe évolution des systèmes pour
le volet financier de la division A de l'organisation C mentionne que le fait d'avoir
deux intervenants cause un dédoublement de l'information et augmente les risques de
perte de connaissances :
[ ... ] la perte de connaissances puis la difficulté de ... [ . .. ] d'avoir à reexpliquer des choses que tu as déjà expliquées dans le contexte. [ .. .] Donc
c'est laborieux, à ce niveau-là, de changer de personne de soutien, à moins
que la personne de base n'était pas bonne. Là, des fois, ça peut être un
soulagement. Mais ça, c'est plus rare qu 'on a [cette] situation.
Chaque organisation à un objectif particulier qu 'il vise à atteindre par la structure
mise en place. L'organisation A vise une meilleure intégration entre les modules
ERP. Le chef de programme des systèmes administratifs et chef du CES explique
bien la vision de l'organisation :
[ . .. ]Un système intégré c'est ça que ça veut dire. C'est un condo dans le fond,
il faut que tu le gères comme un condo et non pas individuellement et les
choix que tu fais peuvent avoir des répercussions sur les autres domaines.
L'obj ectif visé par l'organisation B est une meilleure interaction et collaboration entre
l' exploitation et les clients internes. En séparant les ressources techniques en deux
équipes distinctes, l'organisation C vise la spécialisation de ces ressources TI et
surtout à s'assurer que les ressources assignées au projet ne soient pas retardées par
des problèmes de support.
92
Chaque organisation doit porter une attention particulière à certains aspects du
processus de transfert de connaissances selon la structure d'exploitation choisie. Pour
l'organisation A, il faut porter une attention au transfert entre les ressources
fonctionnelles du centre d'expertise et de soutien et les domaines d'affaires. Étant
donné que ces ressources sont séparées physiquement des domaines d'affaires, il faut
s'assurer que leurs connaissances fonctionnelles soient à jour. L'organisation B et C
doivent pour leur part s'assurer que les ressources fonctionnelles situées dans les
domaines
d'affaires
transmettent
une
quantité
suffisante
de
connaissances
fonctionnelles aux ressources techniques situées dans le département TI. Les
ressources techniques n'ont pas besoin d'une connaissance fonctionnelle pointue,
mais ils doivent posséder un certain niveau de connaissances afm de bien comprendre
la raison d'être des modifications apportées au système et des fonctionnalités déjà en
place (Baskerville et al., 2006). Enfin, l'organisation C doit aussi porter une attention
au transfert de connaissances
entre les ressources techniques de 1' équipe
«transformé» et celles de l'équipe «exploité» dans l'optique de réduire la
dépendance de l'équipe« exploité» vis-à-vis l'équipe« transformé».
Cette section démontre que certains choix liés à structure d'exploitation du système
ERP, tels le niveau de centralisation, la localisation des ressources et l'assignation des
tâches aux ressources TI, ont une influence sur le processus de transfert de
connaissances.
5.2 Les projets d'évolution ERP
Les données recueillies sur le terrain ont permis d' identifier deux éléments liés au
déroulement des projets d'évolution ERP qui sont en relation avec le transfert de
connaissances. Le premier élément est le rôle attribué à l'intégrateur principal au sein
93
du projet. Cet élément influence le transfert de connaissances entre l'équipe projet et
l' équipe support. Le deuxième élément, qui lui est influencé par le transfert de
connaissances, est la phase post-implantation des projets d'évolution ERP.
5.2.1 Le rôle de l' intégrateur principal
Il a été démontré, lors de la description des cas, que les trois organisations étudiées
embauchent plusieurs ressources externes dans le cadre des projets d'évolution. Le
ratio de ressources internes et externes et les tâches attribuées aux ressources externes
diffèrent d'une organisation à l' autre. Elles peuvent travailler sur le projet ou
remplacer les ressources de l'exploitation assignées au projet. Cependant, cette
section concerne spécifiquement l' intégrateur principal, c'est-à-dire le consultant qui
possède une expertise avancée relative à la nouvelle solution qui sera développée
dans le cadre du projet.
Pour l'organisation A, l'intégrateur principal assigné à un projet d'évolution joue un
rôle de formateur. Sa participation au sein du projet est de nature passive. Cette
situation vise à répondre aux exigences de l'entreprise qui stipulent que les projets
doivent être gérés à l' interne. Le chef de projet pour les projets d'envergure TI illustre
bien cette situation :
[ .. .] C' est important de comprendre qu'il n' y a aucun consultant externe qui
gère, qui dirige des projets ici [ ... ]. Donc c'est un mot d'ordre là, ce sont des
cadres de [l'organisation A] qui dirigent des projets ici.
C'est donc dire que l'intégrateur principal transfère ses connaissances aux experts de
l'organisation dès le début du projet. Ces experts devront maîtriser cette connaissance
pour être en mesure de réaliser le projet. L'intégrateur restera membre de l'équipe
projet tout au long de sa réalisation, mais il ne tiendra pas de rô le actif Étant donné
94
que le transfert vers les ressources internes de 1' entreprise s'effectue en début de
projet, l'intégrateur principal ne participera pas au transfert de connaissances vers les
ressources du support. Ce sont les ressources internes de 1' entreprise, membres de
l'équipe projet, qui s'en occuperont. Le rôle de l'intégrateur principal pour
l'organisation A est expliqué par le chef d'équipe du CES :
[ ... ] C'est donc le consultant, il travaille day-to-day [ . .. ] à expliquer à 1'expert
de [l'organisation A] ou au pilote de [l'organisation A], si vous voulez
comment fonctionne 1' application, etc. Donc il fait de 1' apprentissage [ .. .]
C'est-à-dire, en plus de proposer une solution, le consultant si vous voulez,
instinctivement, fait ce qu'on appelle de l'apprentissage aux pilotes de
[l'organisation A].
Il ne faut pas oublier que l'organisation A tente d'avoir le plus de ressources internes
à l'intérieur de l'équipe projet. Elle préfère se servir des consultants pour remplacer
les ressources internes provenant du support qui sont affectées au projet, réduisant
ainsi le ratio de consultant dans le projet. Cette méthode de faire démontre
l'importance pour l'organisation de conserver un contrôle sur le déroulement du
projet et sur la connaissance qui s'y rattache.
Le rôle de l'intégrateur principal dans les projets d'évolution de l'organisation C est
complètement à l'opposé du rôle rempli par ce dernier dans les projets de
l'organisation A. Pour l'organisation C, l'intégrateur principal joue un rôle actif au
sein des projets d'évolution. Bien souvent, c'est la ressource la plus impliquée dans le
projet si l'on se base sur le temps alloué au projet. Il peut même être responsable du
projet dans certains cas. En fait, il est même arrivé que l'entreprise sous-traite des
projets en entier à des firmes externes. Cette pratique est cependant rare dans le cas
du ERP. Vu le rôle actif qu'il joue lors de la réalisation du projet, 1' intégrateur n'est
pas en mesure de transférer adéquatement ses connaissances aux ressources internes
de l'entreprise pendant le projet. L'impossibilité d'effectuer un transfert adéquat en
cours de projet est mentionnée par le conseiller d'affaire et systèmes de la division B :
95
[ .. . ] Pour que tu puisses être en mesure de faire un transfert de connaissances
très adéquat, il faudrait être assis tout le temps avec la firme , mais si on est
assis toujours avec la firme, on les empêche de développer, donc on n'avance
pas dans le projet.
C'est donc dire que le transfert vers les ressources du support en fln de projet doit se
faire en partie par l' intégrateur principal. Dans son contrat, il y a une clause de
formation des employés internes qui est incluse. Cette clause s'explique par
l'importance de cette connaissance pour le support futur de la solution implantée. Ce
transfert s'effectue soit avant la mise en production ou lors de la phase de postimplantation. Le fait que ce transfert s'effectue dans un laps de temps restreint et qu'il
ne soit pas fait de manière continue tout au long du projet fait en sorte que la qualité
du transfert et la rétention de la connaissance n'est pas aussi élevé que pour la
méthode de transfert utilisée par l'organisation A.
Le degré d'implication de l'intégrateur principal au sein de l'organisation B se situe
entre l' implication de celui de l'organisation A et de celui de l'organisation C.
Comme l'organisation C, l'intégrateur principal joue un rôle actif au sein des projets
de l'organisation B. Par contre, contrairement à l'organisation C, l'intégrateur
principal ne peut être responsable du projet. En fait, il peut y avoir cogestion avec une
ressource interne, mais il ne peut gérer le projet seul. La raison principale qui
explique la participation active de l'intégrateur et ses responsabilités importantes au
sein du projet est le manque de ressources internes disponibles. Dans certaines
situations, le département TI de l'organisation B peut se faire imposer des projets
sans qu'une évaluation des capacités ait été réalisée au préalable. Ce contexte oblige
le projet à se doter avec des ressources externes et à donner un rô le important à
certaines de ces ressources. Tout comme l' organisation C, une clause de formation est
incluse dans le contrat de l' intégrateur principal et ce transfert s'effectue en fm de
projet ou en phase post-implantation.
96
Le chef d'une division qui agit à titre de client du système ERP considère que
l'organisation B à une forte dépendance envers l'intégrateur principal avec cette
manière de faire, favorisant du coup une approche similaire à celle de 1' organisation
A:
[ ... ] Son implication était primordiale, parce que c'était vraiment la
connaissance. C'est peut-être un des points faibles[ ... ] que je pourrais dire du
côté TI, c'est qu'il n'y avait pas ... Ils n'ont pas développé de relève en cours
de projet, il aurait dû y avoir dès le départ, une personne affiliée avec
[l'expert] externe, pour s'assurer d'avoir cette connaissance-là.
La décision relative au rôle attribué à l'intégrateur principal ne dépend pas seulement
de l'impact que cette décision aura sur le transfert de connaissances. Cependant, il est
évident que ce choix influence le processus de transfert de connaissances, que ce soit
sur la qualité, sur le moment ou sur la durée du transfert. Cette décision pourrait
même influencer la durée de la phase post-implantation. Ce point sera abordé dans la
prochaine sous-section.
5.2.2 La phase post-implantation des projets d'évolution ERP
Le cadre d'analyse proposé au chapitre II découpe chaque projet d'évolution en
quatre phases, c'est-à-dire la conceptualisation, le développement, les tests et le
déploiement. Ces quatre phases furent mentionnées par les trois organisations
étudiées lors de la collecte de données. Les appellations étaient différentes, mais la
teneur était la même. Cependant, il y a une phase supplémentaire qui fût mentionnée
également par les trois organisations et qui ne se retrouve par dans le cadre d'analyse
initiale. Il s'agit de la phase de post-implantation. Cette phase commence après le
déploiement de la nouvelle solution et se termine lors de la dissolution de l'équipe
97
projet. Le chef d'équipe du CES de 1' organisation A énumère une des raisons qui
explique l'existence de cette phase :
[ ... ] Ils ont une connaissance de ce qui a été déployé, ils comprennent, je
dirais, toute la logique de l'ERP, donc c'est un petit peu les premiers experts
qui réagissent sur la matière, étant donné qu'ils ont participé au mode projet.
[ ... ] Donc c' est clair, qu'il n'y a pas ce qu'on appelle un eut-off où c'est-àdire on passe directement du projet à la production. Ça, ça n'existe pas, c'est
trop risqué, je dirais, pour des applications ou du ERP assez complexe.
Durant cette phase, les membres de l'équipe projet supportent la nouvelle solution
implantée. Il y a donc un changement de rôle pour ces membres, passant du mode
projet vers le mode support. La durée de cette phase varie d'une organisation à l'autre
et d'un projet à l'autre, mais elle dure en moyenne entre un et trois mois. Il y a
plusieurs éléments qui influencent la durée de cette phase de transition entre l'équipe
projet et l'équipe support. Premièrement, il y a les anomalies qui surgissent suite au
déploiement de la solution. Une certaine négociation existe au niveau de ces
anomalies, l' équipe projet va normalement s'engager à régler les anomalies majeures
avant de transférer vers l'équipe support. Le fait de conserver l'équipe projet en place
offre aussi un accès facile aux ressources qui ont participé au projet. Si l' équipe projet
est dissoute, ces ressources risquent de se voir assigner de nouvelles tâches ou être
assignées à un nouveau projet, réduisant ainsi leurs disponibilités pour le support de
la nouvelle solution. Un autre élément est l' impact budgétaire pour les différents
domaines d 'affaires . Pour certaines organisations, le support s'effectue à frais fixe, ce
qui n'est pas le cas pour les projets. Il est donc avantageux pour les domaines
d'affaires que la phase de post-implantation ne s' éternise pas. En plus des anomalies
restantes, de la disponibilité des ressources et l'impact budgétaire, le transfert de
connaissances est un élément qui a une influence importante sur la durée de la phase
post-implantation. Avant de mettre un terme à cette phase, il faut s'assurer que les
ressources du support sont à l'aise avec la nouvelle solution implantée étant donné
98
qu'elles s'occuperont du support après cette phase. Le chef technologie pour les
solutions corporatives fmances et RH (équipe «transformé») de l'organisation C
illustre bien la dualité qui existe entre l'équipe «exploité» qui veut maintenir
l'équipe projet tant que les anomalies majeures ne sont pas corrigées et que le
transfert de connaissances n'est pas complété et les domaines d'affaires qui veulent
basculer en mode support pour réduire les coûts :
[ .. . ] Puis le client lui, il pousse fort pour que ça s'en aille à l' exploité là. Ils
paient déjà un montant fixe [pour] ça. Fait que lui il a tout ... C'est lui qui
nous pousse souvent. [ .. . ] Puis nous autres, bien à l'interne [(équipe
«exploité»)], eux autres, ils poussent pour qu'on le garde.
L'influence du transfert de connaissances sur la durée de la phase de postimplantation diffère d'une organisation à l'autre. L' influence est moindre pour
l'organisation A étant donné que l'intégrateur principal partage ses c01maissances en
début de projet (voir sous-section 5.2.1) et que le transfert se fait de manière continue
tout au long du projet (voir sous-section 4.1.3 à 4.1.8). Dans l'organisation B, les
ressources du support ont leur mot à dire en ce qui concerne la dissolution de l'équipe
projet. Elles donnent leur aval seulement si elles considèrent que le transfert de
connaissances est adéquat. La situation est différente pour l'organisation C. Les
domaines d'affaires donnent leur consentement à la mise en production de la solution
implantée, mais pas à la dissolution de l'équipe. Cela veut dire que ces domaines ne
d01meront pas leur aval au déploiement s' ils considèrent qu ' ils ne sont pas à l'aise
avec la nouvelle solution. En phase post-implantation, il reste donc seulement les
préoccupations de l'équipe «exploité». L'influence de cette équipe est moindre, ce
qui fait en sorte que parfois l'équipe projet sera dissoute sans qu'un transfert adéquat
soit effectué. Cela explique en partie la dépendance de l'équipe «exploité» vis-à-vis
l'équipe« transformé».
99
Le transfert de connaissances a donc une influence sur la durée de la phase de postimplantation, à un degré différent selon l'organisation. Cela veut donc dire qu ' il peut
arriver que tous les autres critères de dissolution de l' équipe projet soient complétés,
mais que l'équipe projet reste en place afm de compléter le transfert de connaissances
vers les ressources de l' équipe support.
5.3 Les mécanismes de transfert de connaissances formels
Cette section vise à identifier les mécanismes formels utilisés par les différentes
organisations étudiées. Les mécanismes seront analysés selon le type de connaissance
transféré (fonctionnel ou technique) et le sens du transfert (équipe support vers équipe
projet ou équipe projet vers équipe support). Les mécanismes utilisés par les
organisations sont identifiés à la figure 5.5 . Lors de la description des structures
d ' exploitation de chaque organisation, une distinction fût faite entre les ressources
techniques et les ressources fonctionnelles (section 5.1). Il faut comprendre que les
ressources techniques ne doivent pas posséder seulement des connaissances
techniques et que les ressources fonctionnelles ne doivent pas posséder seulement des
connaissances fonctionnelles . Bien que chaque ressource possède son expertise, une
convergence doit s'effectuer entre les deux types de connaissances (Baskerville et al. ,
2006). C'est donc dire que les ressources techniques do ivent connaître sommairement
les processus d ' affaires et que les ressources fonctionnelles doivent avoir des notions
de base sur l'aspect technique du système ERP. Ainsi, lorsque l'on parle du transfert
d'un type de connaissance en particulier, il ne faut pas conclure que cela concerne
seulement un type de ressources. En se fiant à la figure 5.5, on s'aperçoit que les
mécanismes utilisés par les trois organisations sont assez similaires. Cependant, les
organisations se distinguent par la manière d'utiliser ces mécanismes et l' efficacité
qui en résulte.
100
Connaissances
Sensdu
transfert
Techniq ues
Support
vers
Projet
• Non-app licable
•Non--app lkab.l e
•Non--app licab le
Projet
·•Documentat ion
•Documentation
•Documentat ion
ve rs:
•rlliouv<em<entd<e
pe,rsonne l ->retour
• Mouvement de
personnel->retour
des ressources
Support
FonctionneHes
Mécanismes
Organisation A
des ressnurœs
Mécanismes
Organisation B
Mécanismes
Organisation C
Su pport
vers
Projet
•Mouv.em:ent:d-:
• Momtement de
· ~uvt:men t
personne l
• tnteract1o·n
personnill
personnel
Projet
vers
Support
• Mouvement de
•Mouvement de
•Mouvement de
parsonnel ->retou r
d:e:s r.essou.rc..-es
personnel ->retour
des ressources
• 1nte ractio n
personnel -> retour
des ressources
•Formation donnée par
l' i ntégrateur pri ncipal
•interacti on
de
• Formation don née par
l' intégrateur princi pal
Figure 5. 5 Mécanismes de transfert de connaissances formels par organisations
5.3 .1 Transfert de connaissances techniques : équipe support vers équipe projet
Lors de la réalisation des entrevues, aucune des organisations étudiées n'a mentionné
de mécanismes qui étaient utilisés dans le cadre du transfert de connaissances
techniques vers l'équipe projet. Nous nous attendions à ce qu'un tel transfert
s'effectue en début de projet. Cette situation s'explique probablement par la nature
évolutive des projets liés au système ERP. Pour ce type de projet, l'expertise liée aux
nouvelles fonctionnalités se retrouve normalement à l'extérieur de l'entreprise (Hirt
et Swanson, 2001). C'est donc l'intégrateur principal, en tant que membre de l'équipe
projet, qui amène avec lui cette connaissance. L'équipe projet a donc accès à cette
connaissance, mais ce n'est pas le résultat d'un transfert de la part de l'équipe
support. Il faut noter que le transfert qui s'effectue à l' intérieur même du projet
dépasse les limites du cadre d'analyse de
ce~te
recherche.
101
5.3.2 Transfert de connaissances techniques : équipe projet vers équipe support
Les trois organisations ont mentionné l'importance de transférer les connaissances
techniques créées lors de la réalisation d'un projet d'évolution vers les ressources de
l' équipe support. Les propos du chef de projet pour les projets d'envergure TI de
l'organisation A démontrent cette importance :
[ .. . ]Ma job, c'est de l'exploitation, mais si j'ignore complètement les projets,
je ne suis pas au courant de ce qui se fait, je ne sais pas quelles technologies
sont là-dedans, c'est sûr que ça ne marche pas. [ . .. ] Il faut que tu sois au
courant de qu'est-ce qui se passe dans ton environnement.
La documentation est l'un des mécanismes utilisés par les organisations pour
effectuer ce type de transfert (voir figure 5.5). Ce mécanisme est utilisé par les trois
organisations. La documentation est créée et maintenue à l' aide de différents outils
informatiques (logiciel de traitement de texte, logiciel de représentation visuelle, etc.)
et est partagée à l'aide des technologies de l'information (courriel, partage de
dossiers, etc.). À ce niveau, les répondants de l'ensemble des organisations ont
critiqué son côté parfois trop technique et le manque de rigueur lorsqu ' il est temps de
maintenir cette documentation à jour. L'organisation A est plus rigoureuse au niveau
de la qualité et de la mise à jour de la documentation que les deux autres
organisations. Ce suivi sévère s'explique par l' importance de la documentation aux
yeux du chef de programme des systèmes administratifs et du CES de cette
organisation. Le directeur de l'information financière et du contrôle interne de
l' organisation A illustre cette situation :
[ . .. ] mais si jamais un jour ça change, puis qu'il n'y a pas de suivi et de
documentation, à long terme tu te tires dans le pied. Ça, par contre, [le chef de
programme des systèmes administratifs et du CES], il est très, très
respectueux de ça. Et même souvent il en demande plus que les gens peuvent
en fournir. Beaucoup de consultants externes sont habitués d'aller vite, puis
d'essayer de bâcler. Mais [il] les rattrape, il y a un minimum à faire.
102
L'organisation A offre un accès direct à sa documentation aux ressources du support
aussitôt qu'elle est créée, c'est-à-dire durant la réalisation du projet, tandïs que les
organisations B et C transfèrent la documentation en fin de projet.
Pour l'organisation A et B, la connaissance technique est aussi transférée à l' aide du
mouvement de personnel. Ainsi, certaines ressources du support sont désignées pour
faire partie de l'équipe projet. Lorsque l'équipe projet est dissoute, ces ressources
retournent dans leur équipe de support amenant avec elles les nouvelles
connaissances techniques absorbées lors de la réalisation du projet. Ce mécanisme
n'est pas utilisé par l'organisation C, car les ressources techniques de l'équipe
«exploité», équipe qui s'occupe du support du système, ne participent pas à la
réalisation des projets.
5.3.3 Transfert de connaissances fonctionnelles: équipe support vers équipe projet
Les connaissances fonctionnelles existantes au sein de l'organisation doivent être
transférées de l'équipe support vers l'équipe projet. Cependant, les organisations ont
mentionné unanimement qu'elles ne cherchent pas à connaître en détail les processus
d'affaires actuels qui seront remplacés par la nouvelle solution qui sera implantée. Le
chef de la division intégration SAP de l'organisation B explique pourquoi cela n 'est
pas nécessaire :
[ ... ] La situation actuelle, je n'ai pas besoin de la maîtriser dans le total, je
viens d'en proposer une nouvelle qui est une solution standard SAP. Je vais te
la présenter et toi tu vas m'identifier quels sont les écarts par rapport à ce que
toi tu vis et [ce] que tu ne peux pas accepter de changer.
103
Par contre, il est primordial pour le projet de détenir certaines connaissances
fonctionnelles qui permettront de s'assurer que la nouvelle solution proposée
répondra aux besoins d'affaires de l'organisation et que les changements apportés
n'affecteront pas d'autres fonctionnalités du système ERP. Pour effectuer le transfert
de l'équipe support vers l'équipe projet, les trois organisations utilisent le mouvement
de personnel. Il peut s'agir d'assignation à temps plein ou d'assignation à temps
partiel. Les ressources du support qui sont sélectionnées pour faire partie de l'équipe
projet à temps plein délaissent leurs activités de support pour la durée complète du
projet, tandis que les ressources du support assignées à temps partiel participent de
manière sporadique au déroulement du projet tout en continuant de supporter
l'application. L'organisation A utilise majoritairement l'assignation à temps plein,
tandis que l'organisation B etC utilisent davantage l'assignation à temps partiel. Bien
que ce mouvement de personnel en provenance de l'équipe support peut aussi
impliquer des ressources techniques, seules les ressources fonctionnelles participent
au transfert de connaissances fonctionnelles vers l'équipe projet. Ce type de transfert
s'effectue davantage en début de projet, car cette connaissance revêt une plus grande
importance au moment de la conceptualisation de la nouvelle solution. Par contre, il
faut tenir compte du fait que le système intégré ne restera pas statique pendant toute
la durée du projet. Il évoluera soit par des activités de support ou des demandes de
changement. L'équipe projet doit être informée de ces changements, car certains
d'entre eux pourraient avoir un impact sur la nouvelle solution implantée. Ce transfert
devient encore plus important pour les projets qui s'échelonnent sur plusieurs années.
C'est donc dire que le transfert de connaissances fonctionnelles vers l'équipe projet
peut avoir lieu à tout moment lors de la réalisation du projet. Cette situation est
expliquée par le chef d'équipe du CES de l'organisation A :
[ ... ] Je peux avoir un projet qui évolue dans le temps, par exemple, sur trois
années, mais ma production, elle progresse, elle évolue. Donc à ce niveau-là,
ce qu'il faut faire, c'est qu'il faut que les gens qui font le projet aient
104
connaissance ou bien soient conscients de l'impact de la modification ou de
l'évolution de la production par rapport à leur projet.
L'organisation A utilise aussi l'interaction comme mécanisme pour ce type de
transfert. Une obligation formelle d ' interaction entre les membres de l'équipe projet
et les ressources qui sont restées en mode support existe au sein du CES. Cette
interaction s'effectue de façon continue tout au long du projet et son contenu diffère
selon les phases à laquelle elle a lieu. Lors des phases de planification et de
réalisation, cette interaction permet aux ressources du support de partager leurs
connaissances fonctionnelles avec les membres de l'équipe projet tout en validant le
contenu de ce projet.
5.3.4 Transfert de connaissances fonctionnelles : équipe projet vers équipe support
Les connaissances fonctionnelles sont importantes pour la pérennité du système ERP.
Les ressources qui s'occupent du support de ce système ont besoin de comprendre les
changements apportés par les projets d'évolution, et ce afin de s'assurer que le
support effectué respecte la nature première de la nouvelle solution implantée. Le
chef de la division intégration SAP de l'organisation B démontre l'importance de ce
transfert :
[ . .. ] C'est facile pour un programmeur ou un configurateur [ ... ] d'aller lire le
programme puis de voir qu'est-ce que ça fait. Mais ce qui est plus difficile
c'est d'avoir le background sur le pourquoi[ ... ] Quand il y a des demandes de
changement,[ ... ] il faut que tu comprennes qu 'est-ce qui est déjà en place, le
lien avec le besoin[ ... ] C'est cette notion de compréhension, de .maîtrise du
besoin d'affaires et de la solution business qui doit être basculée aux gens de
1' entretien.
105
Différents mécanismes de transfert sont utilisés par les organisations afin d'effectuer
ce type de transfert (figure 5.5). Le mouvement de personnel est utilisé par les trois
organisations. En participant aux activités du projet, les ressources de 1' équipe
support absorbent une quantité de connaissances fonctionnelles gu ' elles ramèneront
avec elles lors de leur retour en mode support. L ' organisation A utilise l'assignation à
temps plein, ainsi que l'assignation à temps partiel. C'est-à-dire qu 'en plus des
ressources du support prêtées pour la durée totale du projet, il y a des ressources
supplémentaires prêtées sporadiquement à l'équipe projet à différentes phases du
projet. Le nombre de ressources du support prêtées atteint son apogée lors de la phase
des tests d'acceptation. L'organisation B utilise majoritairement l'assignation à temps
partiel avec une concentration plus élevée des efforts juste avant la mise en
production. Cette présence vise en grande partie à s'assurer que le transfert de
connaissances se fera de manière fluide et que les membres de l'équipe support seront
prêts à supporter le système lorsque la transition aura lieu. Dans le cas de
1' organisation C, ce sont les ressources fonctio1melles du support en provenance des
domaines d' affaires qui sont assignées à temps partiel au projet. Ces ressources et
leur domaine d' affaires respectif bénéficieront de cette connaissance, ce qui n'est pas
le cas pour les ressources techniques de l'équipe « exploité ». Il n'y a aucun
mécanisme formel qui assure un transfert de connaissances fonctionnelles vers
1' équipe « exploité ».
Pour ce type de transfert, l'organisation A et B utilisent aussi l'interaction comme
mécanisme. Au sein de l'organisation A, tel que stipulé dans la sous-section
précédente (5 .3.3), les ressources du CES membres de l'équipe projet et les
ressources qui sont restées en support interagissent sur une base régulière, et ce tout
au long du projet. À partir de la phase de réalisation, cette interaction permet aux
membres de l'équipe projet de présenter, petit à petit, la so lution qui sera implantée
aux ressources du support. Ce transfert permet de préparer les ressources du support
en vue de réaliser une transition en douceur. L'interaction au sein de l'organisation B
106
survient lors des rencontres du comité de pilotage. En plus des ressources clés de
l' équipe projet, plusieurs ressources du support participent à ces rencontres. Une
partie importante de ces rencontres sert à transférer les connaissances fonctionnelles
vers l'équipe support pour que cette équipe soit à l'aise avec le futur déploiement.
Un autre mécanisme utilisé par les organisations B et C est la formation. Cette
formation est donnée par l'intégrateur principal. Tel que mentionné à la sous-section
5.2.1, l'intégrateur principal joue un rôle actif dans les projets d'évolution de ces
deux organisations. Cela l'empêche de partager ses connaissances aux membres de
l'équipe projet lors de la réalisation du projet. Il transfere donc directement aux
ressources du support vers la fm du projet. Ce mécanisme n'est pas utilisé par
l'organisation A étant donné que l'intégrateur principal partage ses c01maissances en
début de projet avec les membres de l'équipe projet qui eux, transfèrent aux
ressources du support via 1' interaction.
5.3.5 Les facteurs de choix des mécanismes de transfert de connaissances formels
Le choix du mécanisme de transfert de connmssances dépend de la nature de la
connaissance (tacite ou explicite) et la dépendance de cette connaissance au contexte
(Chai et al., 2003). La revue de littérature a permis de déterminer que la connaissance
tacite est plus difficile à transférer que la connaissance explicite. L'utilisation de la
documentation comme principal mécanisme pour transférer les connaissances
techriiques, de nature explicite, démontre justement cette facilité à codifier ce type de
connaissance. Par contre, tel que le mentionne le chef pour les projets d'envergure TI
de l'organisation A, ce n'est pas les connaissances techniques qui représentent la plus
grande préoccupation, mais bien les connaissances fonctionnelles :
107
[ ... ] le défi est rarement technologique, c'est vraiment quand tu connais ta
business, [que] tu as une longueur d'avance. C'est vraiment là le nerf de la
guerre. [ .. .] De comprendre les processus d'affaires, comprendre ton client,
puis comment tu vas faire pour donner un meilleur service.
Les connaissances fonctionnelles, de nature plus tacite, sont plus difficiles à transférer
que les connaissances techniques. La connaissance tacite est difficile à codifier, car
elle est profondément ancrée dans les actions, procédures, routines, valeurs et
émotions (Nonaka et al., 2000). La richesse de la connaissance fonctionnelle et le lien
important qui l'unit à son contexte rendent pratiquement impossible l' utilisation de la
documentation pour le transfert de ce type de connaissance. L' importance du contexte
est mentionnée par le conseiller d'affaires et systèmes pour la division B de
l'organisation C :
[ ... ] du côté client, c'est extrêmement difficile, parce que c'est justement ton
contexte d'utilisation de ce qui est en place qui te permet de donner les
enlignements pour la nouvelle solution dont on a besoin.
La richesse et la complexité des connaissances fonctionnelles expliquent pourquoi les
trois organisations étudiées accordent une plus grande importance au mouvement de
personnel qu 'aux autres mécanismes pour le transfert de ce type de connaissances.
Selon la classification de Chai et al. (2003) (voir sous-section 1.3 .2), le mouvement
de personnel est le mécanisme qui a le degré le plus élevé de richesse. Toutefois, il a
aussi le plus petit degré d'atteinte. Le chef de la division intégration SAP de
1' organisation B illustre bien cette particularité associée aux connmssances
fonctionnelles :
[ ... ] c'est les ressources qui vont être affectées sur le projet qui 1' amènent
dans leur cerveau là. On n'a pas beaucoup de documentation qu'une équipe de
projet nowhere arriverait puis récupérerait.
108
5.3.6 Efficacité des mécanismes de transfert de connaissances formels
Selon les propos recueillis lors de la collecte de données, les mécanismes formels mis
en place par les organisations A et B semblent permettre un transfert de
connaissances adéquat, assurant une saine exploitation du système ERP. Il ne faut pas
considérer que le transfert de connaissances est parfait pour autant. Pour
l'organisation B, certains reproches sont formulés de la part des ressources
fonctionnelles du support qui sont situées dans les domaines d'affaires. Les deux
reproches majeurs sont le temps accordé au transfert de cmmaissances et le fait que
certaines informations ne soient pas transférées. Deux répondants de l'organisation B
illustrent ces reproches :
[ ... ] là ils sont obligés d'aller rush, rush, sur un autre projet parce qu'ils sont
en retard, fait que là ils n'ont plus le temps pour venir donner du transfert de
connaissances. (chef de division processus système et opérations comptables organisation B)
[ .. . ] On s'est aperçu de certains processus qui avaient été implantés qu 'on
n'était pas vraiment au fait, en détail, de ces choses-là. Fait que je dirais que la
communication, c'était une des faiblesses, si on veut, à l'intérieur de la
division pour vraiment bien ajuster les besoins, puis informer le monde là.
(chef d'une division liée à 1'ingénierie et l'infrastructure - organisation B)
La situation est quelque peu différente pour l'organisation C. Les mécanismes de
transfert formels ne sont pas satisfaisants pour assurer un transfert adéquat. Les
ressources qui sont le plus affectées par ce manque de mécanismes formels sont les
ressources de l'équipe «exploité» du département TI (voir figure 5.3 pour la
structure d'exploitation de l'organisation C). Aucun mécanisme supplémentaire n'a
été mis en place pour tenir compte du fait que ces ressources ne participent pas aux
projets d'évolution. Le chef comptabilité de gestion des systèmes à la VPCC de cette
organisation mentionne le fait que les ressources de l'équipe «transformé »
109
n'accordent pas une grande importance au transfert vers l'équipe « exploité », surtout
qu'il n 'y a pas de mécanismes formels qui les y obligent :
[ ... ] ils n'ont pas intérêt eux autres à passer deux semaines à transférer de
l'expertise à l'équipe « exploité ». Eux autres, c'est de faire des projets leur
job. Fait que l' expertise qui se transfere là, c'est [apprend] donc sur le tas, ça
va aller bien.
Cette situation a des répercussions sur le support offert par les ressources de l'équipe
« exploité » aux domaines d' affaires. Le responsable de l'équipe évolution des
systèmes pour le volet financier de la division A de l'organisation parle de cette
problématique :
[. .. ] C'est des nouvelles personnes qui font l'évolution. Donc tout est plus
long, plus laborieux, ce n'est pas la qualité des personnes qui est en cause,
c'est la connaissance qu ' ils n'ont pas acquise. Avec une personne, ça serait
extrêmement rapide, parce qu 'elle se rappellerait du background de : « Ah!
oui, je l'avais fait comme ça, j 'ai juste ça à changer [ça]. ». Là, il faut qu 'elle
se réapproprie la solution au complet.
Afin de pallier aux lacunes des mécanismes formels en place ou pour enrichir le
transfert de connaissances, les organisations utilisent aussi des mécanismes informels.
Ces mécanismes seront analysés dans la prochaine section.
5.4 Les mécanismes de transfert de connaissances informels
La grande majorité de la connaissance ne peut être entreposée dans un ordinateur, car
cette connaissance réside dans le cerveau des individus (Ajmal et Koskinen, 2008).
Cette affrrmation explique l'importance de l'interaction interpersonnelle dans le
processus de transfert de connaissances. Bien ·qu'elle puisse être encadrée de manière
forme lle, une grande partie de cette interaction se fait de manière informelle.
110
L'interaction un à un et l'utilisation du réseau social sont les deux mécanismes
informels qui sont utilisés par les organisations étudiées. En fait, ces deux
mécanismes sont . complémentaires, car les interactions informelles se déroulent
majoritairement à l'intérieur du réseau social des personnes impliquées. L'existence
des réseaux sociaux .au sein des organisations est mentionnée par certains
répondants :
[ ... ] Parce que si on est en mode production et qu'on a un chum et une
collègue qui est en mode projet, dès qu'il y a un changement majeur. Ah! On
lève la main, on l'avise. (chef d'équipe du CES - organisation A)
[ ... ] ces liens-là ne se perdent pas. Pas quand tu les construis au quotidien, un
coup de téléphone, ça prend 15 minutes, une demi-heure, tu viens de sauver
des gens qui sont en vacances chez eux, ils se font appeler parce que c'est
rendu que le monde se connaît personnellement. (le responsable de l'aspect
performance et mesure à la VPRH - organisation C)
Les organisations A et B utilisent les mécanismes informels en guise de complément
aux mécanismes formels mis en place par l'organisation. Ces mécanismes servent à
partager davantage d'informations afin de rendre le transfert plus efficace.
L'utilisation que l'organisation C fait des mécanismes informels est différente des
deux autres organisations. Ces mécanismes lui permettent de remédier à l'inefficience
des mécanismes formels. Le conseiller d'affaires et systèmes pour la division B de
cette organisation illustre cette situation :
[ . .. ] C'est vraiment du ad hoc, c'est vraiment : « Tu as un problème? Bien,
viens me voir! ». C'est toujours : «Tu as un problème, tu viens me voir. ».
Fait que tu apprends beaucoup à essai/erreur, essai/erreur.
Les propos collectés sur le terrain ont démontré l'importance du réseau social des
ressources occupant des positions névralgiques au sein de la structure d'exploitation
du système ERP de l'organisation C. Par exemple, le chef comptabilité de gestion des
systèmes à la VPCC de cette organisation a travaillé six ans au sein de la DPTI et
111
trois ans comme analyste d'affaires pour une division de l'entreprise. Le réseau qu'il
a créé au cours de ces années lui sert grandement dans son travail quotidien vu son
rôle d'entremetteur entre la DPTI et les unités d'affaires qu'il représente. La
communication
interdépartementale
est
plus
efficace
lorsque
la
ressource
communique avec un département auquel elle a déjà appartenu (Galbraith, 1994). Ce
même répondant a fait allusion aux liens sociaux que les ressources de son équipe ont
conservés de leurs assignations antérieures :
[ ... ] si je parle plus précisément de l'équipe RH paie, il y a des gens qui ont
déjà travaillé à la DPTI, au groupe technologie. Ils ont déjà été configurateurs,
il y en a là-dedans qui ont déjà programmé.
Le responsable de l'équipe évolution des systèmes pour le volet financier de la
division A de l'organisation C, client de la VPCC, a aussi travaillé par le passé pour
la DPTI. Ces ressources ont développé un lien relationnel fort avec d'autres
ressources qui participent à l'exploitation du système ERP. Ces liens jouent un rôle
important dans le transfert de connaissances. C'est donc dire que pour l'organisation
C, l'efficacité du transfert de connaissances dépend en partie des réseaux sociaux des
ressources en place. Le départ d'une ou plusieurs de ces ressources pourrait avoir des
conséquences fâcheuses sur le transfert de connaissances.
Bien qu'ils n'en soient pas autant dépendants que l'organisation C, les liens
relationnels revêtent aussi une importance dans le processus de transfert de
connaissances pour les organisations A et B. L'importance du lien relationnel lors du
transfert de connaissances n'est pas un élément qui fût étudié en profondeur lors de la
revue de littérature. Suite aux résultats obtenus sur le terrain, des recherches
supplémentaires ont été effectuées. Ces recherches ont permis de découvrir de la
nouvelle littérature utile à cette analyse (Ajmal et Koskinen, 2008 ; Chen et Huang,
2007 ; Li, 2005). Li (2005) mentionne que la relation entre la source et le récipient a
une grande influence sur le transfert de connaissances au sein de l'organisation. Les
112
données recueillies ont permis de découvrir que cette relation a une plus grande
influence lors de l'utilisation de mécanismes informels que lors de l'utilisation de
mécanismes formels. Cela s'explique par le fait qu'il n'y a aucune obligation de
transfert dans le cas des mécanismes informels. Une ressource est plus encline à
partager ses connaissances à une personne avec qui elle entretient un lien relationnel
fort qu 'à une personne avec qui elle a un lien relationnel faible. La mise en place de
mécanismes formels peut pallier au manque de motivation causé par un lien
relationnel faible, ce qui est positif pour le transfert de connaissances, sachant que le
manque de motivation de la part de la source ou du récipient est une barrière au
transfert (voir sous-section 1.3.3).
5.4.1 Influence de la structure organisationnelle sur les interactions sociales
Selon Chen et Huang (2007), les interactions sociales sont influencées par le climat
organisationnel et la structure organisationnelle. Pour les organisations étudiées, la
structure organisationnelle joue un rôle important dans le développement du lien
relationnel. Elle peut favoriser le développement d'un lien fort ou nuire au
développement de ce lien. En nous fiant aux barrières au transfert énumérées par
Szulanski (2000), nous pouvons considérer que la structure organisationnelle de
l'organisation C n'est pas appropriée pour le transfert. Le principal problème de cette
structure est le mur existant entre l'équipe «transformé» et l'équipe «exploité ». Ce
mur fait en sorte que la relation entre les deux groupes de ressources est ardue. La
relation ardue est une autre barrière au transfert mentionnée par Szulanski (2000). Le
chef comptabilité de gestion des systèmes à la VPCC de cette organisation démontre
que les deux groupes de ressources impliqués ne considèrent pas leur relation comme
étant harmonieuse :
113
[ ... ] Tandis que quand tu fais de l'évolution puis que tu es poigné avec tu
t'arranges pour qu'il n'y ait pas trop d 'anomalies. Fait qu 'eux autres
[(l'équipe «exploité »)] , ils vont dire : «Aïe! Ils pellettent des anomalies! »,
ça donne des conflits entre les groupes. [ .. .]Puis eux autres [(l 'équipe
« transformé »)], c'est ça, ils se font dire : « Regarde, ce que vous avez fait,
c'est de la merde, on est poigné avec. ». Puis là, il faut le corriger, puis le
client n'est pas content.
Selon Li (2005), la vision partagée est un déterminant important pour un transfert de
connaissances efficace. La vision partagée est un concept qui fait référence aux
valeurs et objectifs communs et à une compréhension mutuelle dans une relation
collaborative, c'est cette vision qui permet la coordination entre la source et le
récipient. La relation ardue existante entre l' équipe « transformé» et l'équipe
«exploité» empêche celles-ci de partager une telle vision. La structure d'exploitation
du ERP de l' organisation B tente d 'encourager l'établissement d'une vision partagée
entre les ressources techniques et les ressources fonctionnelle s en mettant l'emphase
sur la zone de collaboration qui unit les deux groupes de ressources. Bien qu'elle vise
la collaboration, cette zone amène aussi parfois des conflits. Cette situation est
expliquée par le chef de la division intégration SAP de cette organisation :
[ . .. ] Cette zone-là, elle est partagée entre les deux. Mais on a chacun notre zone,
très technique, c'est nous, très processus, c'est eux. C'est la zone du milieu qui
donne parfois lieu, dépendamment des caractères, des personnalités, dans un
monde idéal, ça serait main dans la main, collaboration totale, mais [ ... ] il y en a
que c'est. .. « Ne touche pas à mes affaires. », puis c'est silo pas mal. [ .. .] Fait
que quand on p oigne des personnalités comme ça, il y a des fr ictions.
Les répondants de l'organisation A n'ont pas signalé de problème par rapport à la
relation existante entre les différentes ressources impliquées dans le transfert de
connaissances. Le fait que les ressources techniques et fonctionnelles soient localisées
dans le même département contribue nécessairement à ce climat plus sain.
114
Cette section termine la comparaison des trois cas. La prochaine section servira à
comparer le cadre d'analyse proposé au chapitre II avec les résultats obtenus suite à
l'analyse des organisations étudiées dans le cadre de cette recherche.
5.5 Comparaison du cadre d'analyse avec les résultats obtenus
Dans cette section, le cadre d'analyse proposé au chapitre II sera comparé aux
résultats obtenus et analysés dans ce chapitre. Le cadre d'analyse proposé vise
davantage à encadrer la collecte et l' interprétation des données plutôt que de tenter de
prédire les résultats. Il y a donc peu de changement à effectuer au cadre initial pour
qu'il soit conforme à l'analyse qui a été faite des résultats. En fait, un seul
changement devrait être apporté au cadre d'analyse (figure 2.1), ce changement est
l'ajout de la phase post-implantation aux phases des projets d'évolution. Cette phase
commence après le déploiement de la nouvelle solution et se termine lorsque l' équipe
projet est dissoute (voir sous-section 5.2.2). Elle dure en moyenne d'un à trois mois.
Le transfert de connaissances peut avoir une influence sur la durée de cette phase.
C'est-à-dire que l'équipe projet pourrait être maintenue en place tant que le transfert
de connaissances n'est pas complété.
Il n'est pas surprenant de voir que le cadre d'analyse révisé contient peu de
modifications par rapport au cadre d'analyse initial vu l' objectif visé par ce dernier.
Cependant, cette recherche a permis d'analyser en détail chacun des éléments inclus
dans le cadre. L ' approche qualitative utilisée lors de cette recherche apporte une
richesse à l'analyse des données grâce à la contextualisation du processus de transfert
de connaissances au sein des organisations étudiées.
115
Dans le chapitre II, certains mécanismes de transfert ont été identifiés, comme étant
des mécanismes qui pouvaient convenir à un environnement d'exploitation d'un
système ERP. Les données recueillies ont démontré qu'effectivement certains de ces
mécanismes étaient utilisés, mais aussi que d'autres ne l'étaient pas. Le tableau 5.1
identifie les mécanismes utilisés et ceux qui ne le sont pas. Cinq des dix mécanismes
proposés sont utilisés par les organisations. La documentation, l'interaction un à un,
le mouvement de personnel et le réseau social sont utilisés par les trois organisations,
tandis que la formation est utilisée seulement par les organisations B et C. Le
mouvement de personnel est le mécanisme formel le plus utilisé pour le transfert de
connaissances, suivi de la documentation (voir section 5.3). Le réseau social et
l'interaction un à un sont les deux mécanismes informels utilisés par les organisations
(voir section 5.4).
Tableau 5. 1
Utilisation par les organisations des mécanismes proposés
dans le cadre d'analyse initial
Mécanisme
Communauté de pratique
Courtier du savoir
Organisation qui l'utilise
Aucune
Aucune
Documentation
les trois organisations
Formation
Organisations B et C
Interaction un à un
Mentorat
Aucune
Réseau social
Système de gestion des
connaissances
Aucune
Utilisateur expert
Aucune
116
La formation est surtout utilisée par l'intégrateur principal pour transférer ses
connaissances aux ressources du support. Bien que considéré comme des mécanismes
non utilisés, la communauté de pratique et l'utilisateur expert ont été mentionnés par
certaines organisations. Par contre, ces mécanismes servaient au transfert de
connaissances vers les utilisateurs finaux et non entre l'équipe projet et l'équipe
support. Le courtier de savoir, le mentorat et le système de gestion des connaissances
sont des mécanismes qui ne sont pas utilisés par les organisations étudiées. Aucune
mention de ces trois mécanismes n'a été faite par les organisations lors de la collecte
de données. Ces mécanismes furent présentés aux répondants lors de la présentation
des résultats suite à l'analyse des données. Bien que certains de ces mécanismes ne
fussent pas connus des répondants, il ne semblait pas y avoir d' intérêt à les utiliser
dans le futur, même après les avoir expliqués. Finalement, tous les mécanismes
mentionnés par les organisations lors de la collecte de données avaient été identifiés
dans la revue de littérature (voir sous-section 1.3 .1) et proposés dans le cadre
d' analyse initial (voir chapitre Il). C'est donc dire que cette recherche n' a pas permis
d' identifier de nouveaux mécanismes.
Certains éléments liés à l'organisation et aux activités de transfert furent identifiés au
chapitre II comme des éléments à analyser. L'importance des deux caractéristiques
liées à l' organisation, c'est-à-dire la structure d'exploitation ERP (voir section 5.1) et
le rôle de l'intégrateur principal (voir sous-section 5.2.1), dans le processus de
transfert de connaissances a été démontrée. Les éléments liés aux activités de
transfert, soit le type de connaissance transférée (fonctionnel ou technique), la
dire.ction du transfert et la phase du projet à laquelle le transfert s'effectue, furent pris
en considération lors de la description des cas (chapitre IV) et lors de 1' analyse des
données (présent chapitre). Cela a permis de faire quelques constatations.
Premièrement, le transfert des connaissances fonctionnelles demande plus d'effort
que les connaissances techniques, car la richesse des informations associées au
contexte est très importante. Deuxièmement, les mécanismes formels sont utilisés
117
pour transférer les deux types de connaissances dans les deux directions (équipe
projet vers équipe support et équipe support vers équipe projet), exception faite du
transfert de connaissances techniques de l'équipe support vers l'équipe projet.
Finalement, bien que des activités de transfert de connaissances se déroulent à toutes
les phases des projets d'évolution, elles sont davantage présentes lors des phases
d'ouverture et de fermeture de ces projets.
La conclusion de cette recherche sera présentée dans le prochain chapitre. Il inclura
les contributions et les limites de la présente recherche, ainsi que les possibilités pour
les recherches futures.
CONCLUSION
Dans ce chapitre, seront exposées les contributions théoriques et pratiques qm
résultent de l'analyse des données recueillies sur le terrain et de la comparaison de
celles-ci avec le cadre d'analyse proposé en début de recherche. Par la suite, les
limites et les pistes futures de recherche seront présentées.
Les contributions
La principale contribution théorique de cette recherche est d'offrir une meilleure
compréhension du transfert de connaissances qui se déroule entre l'équipe projet et
l'équipe support dans un environnement d'exploitation d'un système ERP. Cette
recherche a également permis de mieux comprendre le rôle joué par certains éléments
dans le processus de
transfert de connaissances. L'importance de la structure
d'exploitation du système ERP dans ce processus a été démontrée. La structure a un
impact sur le choix et l'efficacité des mécanismes formels. Elle peut aussi influencer
l'efficacité des mécanismes informels en offrant un environnement propice au
développement d'un lien relationnel fort entre les ressources impliquées dans le
transfert. Finalement, la structure choisie peut augmenter ou diminuer le risque de
perte. de connaissances. Dans le contexte spécifique de l'exploitation d'un système
ERP, le rôle assigné à l'intégrateur principal au sein des projets d'évolution influence
le processus de transfert de connaissances entre l'équipe projet et l'équipe support
(voir sous-section 5.2.1). Les résultats obtenus ont aussi permis de découvrir
l' importance de la phase de post-implantation pour . les projets d'évolution et
l' influence du transfert de connaissances sur cette phase.
119
Pour ce qui est des mécanismes de transfert, cette recherche a confirmé que le choix
du mécanisme dépendait en grande partie du type de connaissances transférées (voir
sous-section 5.3.5). Les mécanismes utilisés par les organisations étudiées sont
similaires, mais des différences importantes existent au niveau de leur mise en
application et de l'efficacité qui en découle. L'utilisation des mécanismes informels
peut différer d'une organisation à l'autre. Certaines organisations les utilisent comme
compléments aux mécanismes formels, tandis que d'autres les utilisent pour remédier
à l'inefficience des mécanismes formels (voir section 5.4). Cette recherche a
démontré l'importance du lien relationnel pour une utilisation efficace des
mécanismes informels (voir sous-section 5.4.1).
L'approche exploratoire de cette recherche a permis d'identifier plusieurs éléments
dont devraient tenir compte les dirigeants d'organisations qui possèdent un système
ERP ou qui projettent en implanter un. Ces éléments sont le choix de la structure
d'exploitation, le rôle de l'intégrateur principal et le choix des mécanismes formels.
Les résultats obtenus pourraient convaincre certains de ces dirigeants de modifier leur
manière actuelle d'exploiter leur système ERP. Ils pourraient aussi contribuer à
améliorer la planification de la phase post-implantation du système ERP pour les
organisations qui préparent l'implantation d'un tel système. Ces dirigeants devraient
tenir compte de l'importance du lien relationnel dans le processus de transfert de
connaissances lors du choix de la structure d'exploitation et lors de la constitution de
l'équipe support et des équipes de projets.
Les limites de la recherche
Toute recherche comporte ses limites. Ces limites sont majoritairement liées aux
choix méthodologiques qui sont faits. La première limite de cette recherche vient de
120
l'approche choisie. L 'approche qualitative privilégie la richesse des données au
détriment de la généralisation. Le nombre restreint d'organisations sélectionnées pour
cette étude peut être considéré comme une limite, bien que le nombre de répondants
ait permis d'atteindre une saturation sémantique et théorique des données pour
chaque organisation. Un nombre plus élevé aurait pu permettre d'augmenter la
validité des résultats. La dispersion géographique des organisations sélectionnées,
ainsi que le secteur dans lequel elles évoluent sont aussi limitatifs. Le fait que ces
organisations soient toutes d'origine canadienne empêche l'isolement des éléments
qui sont liés à des facteurs culturels. De plus, il n ' est pas possible d'affirmer que les
résultats obtenus sont valides pour les organisations du secteur privé étant donné que
l'échantillon ne contient que des organisations du secteur public.
Pistes pour recherches futures
Cette recherche exploratoire pourrait être précurseur à plusieurs recherches
subséquentes. Premièrement, une étude portant sur des organisations du secteur privé
permettrait de comparer les résultats avec ceux du secteur public. Il serait aussi
intéressant d 'étudier le transfert de connaissances entre l'équipe support et l'équipe
projet dans un contexte différent que l' exploitation d'un système ERP. Ces nouvelles
recherches permettraient de vérifier si le secteur et le contexte ont une influence sur le
choix des mécanismes de transfert.
Une recherche longitudinale portant sur le même sujet que la présente recherche
permettrait d'analyser les changements apportés au processus de transfert de
connaissances tout au long du cycle de vie du système ERP, soit de l' implantation
initiale jusqu'à sa fm de vie utile. Il serait pertinent d ' observer l'évolution des
organisations au cours des années futures , plus spécialement pour 1' organisation A,
121
en sachant que l'organisation B et C ont eu par le passé une structure d'exploitation
du système ERP similaire à celle-ci et qu'elles l'ont changée par la suite. Cela semble
encore plus pertinent lorsque l' on tient compte du fait que l'implantation du système
ERP de l'organisation A est plus récente que celle des deux autres organisations.
Une autre possibilité de recherche serait de valider quantitativement les résultats
obtenus dans la présente recherche. Grâce à ce genre d'approche, il serait possible de
rejoindre un plus grand nombre de répondants, ce qui permettrait d'obtenir une
meilleure
généralisation des résultats.
Les
données
collectées permettraient
d'identifier la structure d ' exploitation du système ERP, les mécanismes utilisés et le
rôle attribué à l'intégrateur principal pour chacune des organisations approchées.
L'analyse de ces données permettrait de découvrir des tendances et pourrait même
établir certaines corrélations entre différentes caractéristiques de l' organisation et
différentes caractéristiques liées au processus de transfert de connaissances.
ANNEXE
Page
Annexe
A
B
C
D
Guide d'entrevue - Gestionnaire de projet..................................
Guide d'entrevue- Membre de l'équipe TI.................................
Guide d'entrevue- Client interne............................................
Guide d'entrevue- Gestionnaire de portefeuille...........................
123
124
126
128
ANNEXE A : GUIDE D'ENTREVUE- GESTIONNAIRE DE PROJET
1. INTRODUCTION
a. Présentation sommaire de la thématique de l'entrevue
b. Présentation sommaire de la séquence de l'entrevue
c. Signature du formulaire de consentement et remise engagement de
confidentialité
d. Autorisation d'enregistrement
2. ÉLÉMENTS FACTUELS
a. Quel est votre rôle dans l'entreprise?
b. Quel était votre rôle dans le processus de transition des projets ERP?
3.
EXPÉRIENCES ET COMPORTEMENTS
a. Comment procédez-vous à la transition de vos projets ERP?
• Génération des idées
• Critères permettant de clôturer la phase projet d'une
initiative ERP.
• Période de transition pour les projets associés aux ERP.
• Gestion des points en suspens lors de· la transition vers les
opérations.
• Mécanismes d'intégration des connaissances (équipe de
projet vs centre de compétence)
4. OPINIONS
a. Selon vous, quels sont les avantages de votre processus de transition?
Donner des exemples?
b. Selon vous, quels sont les désavantages de votre processus de
transition? Donner des exemples?
5. CONCLUSION
a. Renseignements de profil
1.
Expérience en gestion de projet TI
11.
Scolarité
b. Rétroaction sur l'entrevue
c. Séparation
ANNEXE B :GUIDE D'ENTREVUE- MEMBRE DE L'ÉQUIPE TI
1. INTRODUCTION
• Thématique transition
• Thématique évolution
b. Présentation sommaire de la séquence de l' entrevue
confidentialité
a.
b.
c.
d.
3.
Quel est votre rôle dans l'entreprise?
Quel était votre rôle dans le processus de transition des projets ERP?
Quel était votre rôle dans le processus d'évolution ERP?
Quels sont les fonctionnalités (modules) de votre ERP?
a. Qu'elle est votre compréhension du processus de transition des projets
ERP?
•
•
•
•
•
b. Qu'elle
Implication des groupes de support dans l'initiation des
projets ERP
Critères permettant de clôturer la phase projet d'une
initiative ERP
Période de transition pour les projets associés aux ERP
Gestion des points en suspens lors de la transition vers les
opérations.
Mécanismes d'intégration des connaissances (équipe de
est votre implication dans la gestion de l'évolution de votre
solution ERP?
•
•
•
•
•
Génération des idées
Classement (support vs projet)
Catégorisation de projet (ex. Mini projet vs projet)
Priorisation des demandes de changements
Allocation des ressources du centre des compétences (ou
centre d'expertise)
125
4. OPINIONS
c. Selon vous, quels sont les avantages de vos processus de transition
entre les équipes de projet et les équipes de support? Donner des
exemples?
d. Selon vous, quels sont les désavantages de vos processus de transition
exemples?
e. Selon vous, quels sont les avantages de votre gestion de l'évolution
du ERP? Donner des exemples?
f. Selon vous, quels sont les désavantages de votre gestion de
l'évolution du ERP? Donner des exemples?
5. CONCLUSION
i. Expérience en gestion de portefeuille TI
ii. Scolarité
d. Rétroaction sur l'entrevue
e. Séparation
ANNEXE C : GUIDE D'ENTREVUE- CLIENT INTERNE
1. INTRODUCTION
confidentialité
c. Quel était votre rôle dans le processus d'évolution ERP?
3.
ERP?
•
•
•
•
•
b. Qu'elle
Implication des groupes de support dans l'initiation des
projets ERP
initiative ERP
opérations.
solution ERP?
•.
•
•
•
•
centre d'expertise)
127
4. OPINIONS
g. Selon vous, quels sont les avantages de vos processus de transition
exemples?
h. Selon vous, quels sont les désavantages de vos processus de transition
exemples?
1.
Selon vous, quels sont les avantages de votre gestion de l'évolution
J. Selon vous, quels sont les désavantages de votre gestion de
5. CONCLUSION
ii. Scolarité
f Rétroaction sur l'entrevue
g. Séparation
ANNEXE D :GUIDE D'ENTREVUE- GESTIONNAIRE DE PORTEFEUILLE
1. INTRODUCTION
confidentialité
c. Quel était votre rôle dans le processus d'évolution ERP?
3.
ERP?
•
•
•
•
•
b. Qu 'elle
Implication des groupes de support dans l' initiation des
projets ERP
initiative ERP
opérations.
solution ERP?
•
•
•
•
•
centre d'expertise)
129
4. OPINIONS
k. Selon vous, quels sont les avantages de vos processus de transition
exemples?
1. Selon vous, quels sont les désavantages de vos processus de transition
entre les équipes de projet et les équipes de support? D01mer des
exemples?
m. Selon vous, quels sont les avantages de votre gestion de l'évolution
n. Selon vous, quels sont les désavantages de votre gestion de
5. CONCLUSION
ii. Scolarité
h. Rétroaction sur l'entrevue
1.
Séparation
RÉFÉRENCES
Ajmal, Mian M., et Kaj U. Koskinen. 2008. «Knowledge transfer in project-based
organizations: An organizational culture perspective».· Project Management
Journal, vol. 39, no 1, p. 7-15.
Al-Mashari, Majed, Abdullah Al-Mudimigh et Mohamed Zairi. 2003. «Enterprise
resource planning: A taxonomy of critical factors ». European Journal of
Operational Research, vol. 146, no 2, p. 352-364.
Almeida, Paul, et Bruce Kogut. 1999. «Localization ofknowledge and the mobility of
engineers in regional networks». Management Science, vol. 45 , no 7, p. 905917. In ABIIINFORM Complete.
Appleyard, Melissa M. 1996. «How does knowledge flow? Interfirm patterns in the
semiconductor industry». Strategie Management Journal, vol. 17, no Winter
special, p. 137-154.
Argote, Linda. 1999. «Ürganizational Learning: Creating, Retaining and Transferring
knowledge». Boston, MA: Kluwer Academie Publishers p.
Argote, Linda, et Paul Ingram. 2000. «Knowledge Transfer: A Basis for Competitive
Advantage in Firms». Organizational Behavior and Human Decision
Processes, vol. 82, no 1, p. 150-169.
Argote, Linda, Paul Ingram, John M. Levine et Richard L. Moreland. 2000.
«Knowledge Transfer in Organizations: Learning from the Experience of
Others». Organizational Behavior and Human Decision Processes , vol. 82,
no 1, p. 1-8.
Atkinson, Roger. 1999. «Project management: cost, time and quality, two best
guesses and a phenomenon, its time to accept other sutcess criteria».
International Journal of Project Management, vol. 17, no 6, p. 337-342.
Baskerville, R., S. Pawlowski et E. McLean. 2006. «Enterprise Resource Planning
and Organizational Knowledge: Patterns of Convergence and Divergence».
Systèmes d'Information et Management, vol. 11, no 4, p. 7-28. In
ABIIINFORM Complete.
131
Boh, Wai Fong. 2007. «Mechanisms for sharing knowledge in project-based
organizations». Information and Organization, vol. 17, no 1, p. 27-58.
Botta-Genoulaz, V., P. A. Millet et B. Grabot. 2005 . «A survey on the recent research
literature on ERP systems». Computers in Industry, vol. 56, no 6, p. 51 0.,.522.
Botta-Genoulaz, Valérie, et Pierre-Alain Millet. 2005 . «A classification for better use
of ERP systems». Computers in Industry, vol. 56, no 6, p. 573-587.
Bower, Douglas C., et Derek H. T. Walker. 2007. «Planning Knowledge for Phased
Rollout Projects». Project Management Journal, vol. 38, no 3, p. 45 -60. In
bth . EBSCOhost.
Bradfield, D. J., et J. X . Gao. 2007. «A methodology to facilitate knowledge sharing
in the new product development process». International Journal of
Production Research, vol. 45, no 7, p. 1489-1504.
BS . 2000. p roject management - part 1: guide to proj ect management. London:
British Standards Institute p.
Chai, Kah-Hin, Mike Gregory et Yongjiang Shi. 2003 . «Bridging islands of
knowledge: a framework of knowledge sharing mechanisms». International
Journal ofTechnology Management, vol. 25 , no 8, p. 703-727.
Chen, Chung-Jen, et Jing-Wen Huang. 2007. «How organizational climate and
structure affect knowledge management-The social interaction perspective».
International Journal of Information Management, vol. 27, no 2, p. 104-118.
Chen, Yuh-Jen, Yuh-Min Chen et Hui-Chuan Chu. 2009. «Development of a
mechanism for ontology-based product lifecycle knowledge integration».
Expert Systems with Applications, vol. 36, no 2, Part 2, p. 2759-2779.
Chou, Huey-Wen, Yu-Hsun Lin, Hung-Sheng Lu, Hsiu-Hua Chang et Shyan-Bin
Chou. 2014. «Knowledge sharing and ERP system usage in postimplementation stage». Computers in Human Behavior, vo l. 33, no 0, p. 1622.
Consulting, Panorama. 201 3. 201 3 ERP report, A Panorama Consulting Solutions
Research Report: 21 p
Cross, Rob, Andrew Parker, Laurence Prusak et Stephen P. Borgatti. 2001.
«Knowing What We Know: Supporting Knowledge Creation and Sharing in
Social Networks». Organizational Dynamics, vol. 30, no 2, p. 100-120. In
pbh. EBSCOhost.
132
Davenport, T.H., et L. Prusak. 1998. Working knowledge: How organizations
manage what they know. Boston: Harvard Business School Press p.
Davenport, ThomasH. 2000. «The Future of Enterprise System-Enabled
Organizations».Information Systems Frontiers, vol. 2, no 2, p. 163-180.
Dong-Gil, Ko, Laurie J. Kirsch et William R. King. 2005. «Antecedents of
knowledge transfer from consultants to clients in enterprise system
implementations». MIS Quarter/y, vol. 29, no 1, p. 59-85 . In bth.
EBSCOhost.
Eisenhardt, Kathleen M. 1989. «Building Theories from Case Study Research». The
Academy of Management Review, vol. 14, no 4, p. 532-550.
Gable, Guy G., Taizan Chan et Wui-Gee Tan. 2001. «Large packaged application
software maintenance: a research framework». Journal of Software
Maintenance and Evolution: Research and Practice, vol. 13, no 6, p. 351371.
Gagnon, Y.C. 2012. L'étude de cas comme méthode de recherche, 2e édition: Presses
de l'Université du Québec, 123 p.
Galbraith, Craig S. 1990. «Transferring Core Manufacturing Technologies in HighTechnology Firms». California Management Review, vol. 32, no 4, p. 56. In
Periodicals Archive Online.
Galbraith, J. 1973. Designing complex organizations.
development»: Addison-Wesley Pub. Co. , 150 p.
Coll.
«organization
--------. 1994. Competing with flexible lateral organizations, second edition. Coll.
«ÜD series». USA: Addison-Wesley Publishing Company, 152 p.
Gallagher, K. P., James L. Worell et Robert M. Mason. 2012. «The negotiation and
selection of horizontal mechanisms to support post-implementation ERP
organizations». Information Technology & People, vol. 25, no 1, p. 27.
Gallagher, Kevin P ., et Gallagher Vickie Coleman. 2012. «Ürganizing for postimplementation ERP». Journal of Enterprise Information Management, vol.
25 , no 2, p. 170-185. In ABIIINFORM Complete.
133
Gattiker, Thomas F., et Dale L. Goodhue. 2005. «What Happens after ERP
Implementation: Understanding the Impact of Interdependence and
Differentiation on Plant-Level Outcomes». MIS Quarter/y , vol. 29, no 3, p.
559-585.
Goffin, Keith, et Ursula Koners. 2011. «Tacit Knowledge, Lessons Learnt, and New
Product Development». Journal of Product Innovation Management, vol. 28,
no 2, p. 300-318.
Gruenfeld, Deborah H. , Paul V. Martorana et Elliott T. Fan. 2000. «What Do Groups
Learn from Their Worldliest Members? Direct and Indirect Influence in
Dynamic Teams». Organizational Behavior and Human Decision Processes,
vol. 82, no 1, p. 45 -59.
Gupta, Anil K. , et Vijay Govindarajan. 2000. «Knowledge flow s within multinational
corporations». Strategie Management Journal, vol. 21 , no 4, p. 473-473 . In
ABIIINFORM Complete.
Ha, Young Mok, et Hyung Jun Ahn. 2013. «Factors affecting the performance of
Enterprise Resource Planning (ERP) systems in the post-implementation
stage». Behaviour & Information Technology, p. l-17.
Hansen, M.T. , N. Nohria et T Tiemey. 1999. «What's your strategy for managing
knowledge?». Harvard Business Review, no March-April, p. 106-116.
Hedlund, Gunnar. 1994. «A model of knowledge management and the N-form
corporation>>. Strategie Management Journal, vol. 15, p. 73-90. In bth.
EBSCOhost.
Hirt, Sabine Gabriele, etE. Burton Swanson. 2001. «Emergent maintenance of ERP:
new roles and relationships». Jo urnal of Software Maintenance and
Evolution: Research and Practice, vol. 13, no 6, p. 373-387.
Holzmann, Vered. 2013. «A meta-analysis of brokering knowledge in project
management». International Journal of Project Management, vol. 31 , no 1,
p.2-13.
Ifinedo, Princely, Birger Rapp, Airi Ifinedo et Klas Sund berg. 201 O. «Relationships
among ERP post-implementation success constructs: An analysis at the
organizationallevel». Computers in Human Behavior, vol. 26, no 5, p. 11361148.
134
Jasimuddin, Sajjad M. 2007. «Exploring knowledge transfer mechanisms: The case
of a UK-based group within a high-tech global corporatiom>. International
Journal of Information Management, vol. 27, no 4, p. 294-300.
Jones, Mary C., et R. Leon Priee. 2004. «Ürganizational Knowledge Sharing in ERP
Implementation: Lessons from Industry». Journal of Organizational and End
User Computing, vol. 16, no 1, p. 21-40. InABI/INFORMComplete.
Jubert, A. 1999. Developing an infrastructure for communities of practice:
International Online Meeting (Hinksey Hill, U.K.). 165-168 p.
19th
Jugdev, Kam, et Ralf Müller. 2005. «A retrospective at our evolving understanding of
project success». Project Managem ent Journal, vol. 36, no 4, p. 19-31. In
bth. EBSCOhost.
Julian, Jerry. 2008. «How project management office leaders facilitate cross-project
learning and continuous improvement». Project Management Journal, vol.
39, no 3, p. 43-58. In bth. EBSCOhost.
Langley, Ann. 1999. «Strategies for Theorizing from Process Data». The Academy of
Management Review, vol. 24, no 4, p. 691-71 O.
Larsson, Rikard, Lars Bengtsson, Kristina Henriksson et Judith Sparks. 1998. «The
Interorganizational Learning Dilemma: Collective Knowledge Development
in Strategie Alliances». Organization Science, vol. 9, no 3, p. 285-305. In
bth . EBSCOhost.
Law, Chuck C. H. , Charlie C. Chen et Bruce J. P. Wu. 2010. «Managing the full ERP
life-cycle: Considerations of maintenance and support requirements and IT
govemance practice as integral elements of the formula for successful ERP
adoption». Computers in Industry, vol. 61, no 3, p. 297-308.
Lee, Zoonky, et Jinyoul Lee. 2000. «An ERP implementation case study from a
knowledge transfer perspective». Journal of Information Technology
(Routledge, Ltd.), vol. 15, no 4, p. 281-288. In bth. EBSCOhost.
Li, Li. 2005. «The effects of trust and shared vision on inward knowledge transfer in
subsidiaries' intra- and inter-organizational relationships». International
Business Review, vol. 14, no 1, p. 77-95 .
Liang, Huigang, Nilesh Saraf, Qing Hu et Yajiong Xue. 2007. «Assimilation of
Enterprise Systems: The Effect of Institutional Pressures and the Mediating
Role ofTop Management». MIS Quarter/y, vol. 31 , no 1, p. 59-87.
135
Light, Ben. 2001. «The maintenance implications of the customization of ERP
software». Journal of Software Maintenance and Evolution: Research and
Practice, vol. 13, no 6, p. 415-429.
Lindner, Frank, et Andreas Wald. 2011. «Success factors of knowledge management
in temporary organizations». International Journal of Project Management,
vol. 29, no 7, p. 877-888.
Lundin, Rolf A., et Anders Soderholm. 1995. «A theory of the temporary
organization». Scandinavian Journal of Management, vol. 11 , no 4, p. 437455.
Madapusi, Arun, et Derrick D'Souza. 2012. «The influence of ERP system
implementation on the operational performance of an organization».
International Journal of Information Management, vol. 32, no 1, p. 24-34.
Maylor, Harvey, Tim Brady, Terry Cooke-Davies et Damian Hodgson. 2006. «From
projectification to programmification». International Journal of Project
Management, vol. 24, no 8, p. 663-674.
McGinnis, Thomas C. 2011. «Factors influencing post-adoptive enterprise resource
plannning (ERP) utilizatiom>. Trad. de: English. 3507015, United States -Texas, University ofNorth Texas, 131 p. In ProQuest Dissertations & Th eses
(PQDT); ProQuest Dissertations & Theses A&!.
McGinnis, Thomas C. , et Zhenyu Huang. 2007. «Rethinking ERP success: A new
perspective from knowledge management and continuous improvement».
Information & Management, vol. 44, no 7, p. 626-634.
Merminod, Valéry, et Frantz Rowe. 2012. «How does PLM technology support
knowledge transfer and translation in new product development?
Transparency and boundary spanners in an international context». Information
and Organization, vol. 22, no 4, p. 295-322.
Meyer,
Morgan. 2010. «The Rise of the
Communication, vol. 32, no 1, p. 118-127.
Knowledge
Broken>.
Science
Miles, M.B., et A.M. Huberman. 1991. Analyse des données qualitatives: Recueil de
nouvelles méthodes. Bruxelles: De Boeck Université, 480 p.
136
Moreland, Richard L., et Larissa Myaskovsky. 2000. «Exploring the Performance
Benefits of Group Training: Transactive Memory or Improved
Communication?». Organizational Behavior and Human Decision Processes,
vol. 82, no 1, p. 117-133.
Muscatello, Joseph R. , et Diane H. Parente. 2008. «A Post-Implementation Case
Study and Review of Enterprise Resource Planning (ERP) Implementations».
In Innovative Technologies for Information Resources Management, p. 1-20:
IGI
Global.
En
ligne.
<http ://services.igiglobal. com/resolv~doilresolve . aspx?doi= 10.40 18/978-1-59904-570-2.ch00 1>.
Nah, Fiona Fui-Hoon, Silvana Faja et Teuta Cata. 2001. «Characteristics of ERP
software maintenance: a multiple case study». Journal of Software
Maintenance and Evolution: Research and Practice, vol. 13 , no 6, p. 399414.
Newell, Sue. 2004. «Enhancing Cross-Project Leaming». E ngineering Management
Journal, vol. 16, no 1, p. 12-20. In bth. EBSCOhost.
Newell, Sue, Mike Bresnen, Linda Edelman, Harry Scarbrough et Jacky Swan. 2006.
«Sharing Knowledge Across Projects : Limits to ICT-led Project Review
Practices». Management Learning, vol. 37, no 2, p. 167-185.
Nicolaou, Andreas I. , et Somnath Bhattacharya. 2006. «Ürganizational performance
effects of ERP systems usage: The impact of post-implementation changes».
International Journal of Accounting Information Systems, vol. 7, no 1, p. 1835 .
Nonaka, lkujiro, Ryoko Toyama et Noboru Konno . 2000. «SECI, Ba and Leadership:
a Unified Madel of Dynamic Knowledge Creation». Long Range Planning,
vol. 33 , no 1, p. 5-34.
Pemsel, Sofia, et Anna Wiewiora. 201 3. «Project management office a knowledge
broker in project-based organisations». International Journal of Proj ect
Persson, Magnus. 2006. «The impact of operational structure, lateral integrative
mechanisms and control mechanisms on intra-MNE knowledge transfer».
International Business Review, vo l. 15, no 5, p. 547-569.
Peterson, William J., Lisa Gelman et Dudley P. Cooke (2001). ERP Trends. The
Conference Board
137
Pinto, Jeffrey K. , et John E. Prescott. 1990. «Planning and tactical factors in the
project implementation process». Journal of Management Studies, vol. 27, no
3, p. 305-327.
PMI. 2008. A guide to the project management body of knowledge, 4. Pennsylvania:
Project Management Institute p.
Reich, Blaize Homer, Andrew Gemino et Chris Sauer. 2008 . «Modeling the
knowledge perspective ofiT projects». Project Management Journal, vol. 39,
p. S4-S14. In bth. EBSCOhost.
Romelear, Pierre. 2005 . «L'entretien en recherche». In Management des ressources
humaines: Méthodes de recherche en science humaines et sociales, p. 448 .
Belgique: De Boeck Supérieur.
Rothenberger, Marcus A., Mark Srite et Karen Jones-Graham. 2010. «The impact of
project team attributes on ERP system implementations». Information
Technology & People, vol. 23 , no 1, p. 80-109. In ABI/INFORMComplete.
Saatçioglu, Omür Y. 2009. «What determines user satisfaction in ERP projects:
benefits, barriers or risks?». Journal of Enterprise Information Management,
vol. 22, no 6, p. 690 - 708.
Salmeron, Jose L., et Cristina Lopez. 2010. «A multicriteria approach for risks
assessment in ERP maintenance». Journal of Systems and Sof tware, vol. 83,
no 10, p. 1941-1953 .
Schlichter, Bjarne Rerup, et Pernille Kraemmergaard. 2010. «A comprehensive
literature review of the ERP research field over a decade». Journal of
Enterprise Information ·Management, vol. 23 , no 4, p. 486-520. In
ABI/INFORM Complete.
Scott, Judy E ., et Iris Vessey. 2002. «Managing r isks in enterprise systems
implementations». Communications of the ACM, vo l. 45 , no 4, p. 74- 81. In
bth. EBSCOhost.
Sedera, Darshana, et Guy G. Gable. 2010. «Knowledge Management Competence for
Enterprise System Success». The Journal of Strategie Information Systems,
vol. 19, no 4, p. 296-306.
138
See Pui Ng, Celeste 2001. «A decision framework for enterprise resource planning
maintenance and upgrade: A client perspective». Journal of Software
Maintenance and Evolution: Research and Practice, vol. 13, no 6, p. 431468 .
See Pui Ng, Celeste, Guy G. Gable et Taizan Chan. 2002. «An ERP-client benefitoriented maintenance taxonomy». Journal of Systems and Software, vol. 64,
no 2, p. 87-109.
Singley, M.K. , et Anderson J.R. 1989. The transf er of cognitive skill. Boston:
Harvard University Press p.
Smyth, Hedley J. , et Peter W. G. Morris. 2007. «An epistemological evaluation of
research into projects and their management: Methodological issues».
International Journal of Project Management, vol. 25, no 4, p. 423-436 .
Srivastva, Suresh, et Frank J. Barrett. 1988. «The Transforming Nature ofMetaphors
in Group Development: A Study in Group Theory». Hum an Relations, vol.
41 , no 1, p. 31-63.
Swap, Walter, Dorothy Leonard, Mimi Shields et Lisa Abrams. 2001. «Using
Mentoring and Storytelling to Transfer Knowledge in the Workplace».
Journal of Management Information Systems, vol. 18, no 1, p. 95-114. In
bth. EBSCOhost.
Szulanski, Gabriel. 1996. «Exploring Internai Stickiness: Impediments to the Transfer
ofBest Practice Within the Firm». Strategie Management Journal, vol. 17, p.
27-43.
-------- . 2000. «The Process of Knowledge Transfer: A Diachronie Analysis of
Stickiness». Organizational Behavior and Human Decision Processes, vol.
82, no 1, p . 9-27.
Tomas, Jean-Louis. 2007. ERP et PGI sélection, méthodologie de déploiement et
gestion du changement: Les clés du succès, les facteurs de risques, 5, 312 p.
Turner, J. R. 1999. The handbook of proj ect-based management: Improving the
processes for achieving strategie objectives, 2. London: McGraw-Hill
Publishing Co. p.
--------. 201 0. «Evolution of project management research as evidenced by papers
published in the International Journal of Project Management». International
Journal of Project Management, vol. 28, no 1, p. 1-6.
139
Van Nguyen, T. 2002. Knowledge Management: Literature Review and Findings
about Perceptions of Knowledge Transfer in Collaborative and Processoriented Teams: Pepperdine University p.
Vandaie, Ramin. 2008. «The role of organizational knowledge management in
successful ERP implementation projects». Knowledge-Based Systems, vol.
21, no 8, p. 920-926.
Volkoff, Olga, Michael B. Elmes et Diane M. Strong. 2004. «Enterprise systems,
knowledge transfer and power users». The Journal of Strategie Information
Systems, vol. 13, no 4, p. 279-304.
Wenrich, Kristi, et Norita Ahmad. 2009. «Lessons Leamed During a Decade of ERP
Experience: A Case Study». p. 55-73.
Winter, Sidney G., et Gabriel Szulanski. 2001. «Replication as strategy».
Organization Science, vol. 12, no 6, p. 730-743. In ABIIINFORM Complete.
Xu, Qing, et Qingguo Ma. 2008. «Determinants of ERP implementation knowledge
transfer». Information & Management, vol. 45 , no 8, p. 528-539.
Yin, Robert K. 1981. «The Case Study Crisis: Sorne Answers». Administrative
Science Quarter/y, vol. 26, no 1, p. 58-65.
--------. 1994. Case Study Research: Design and methods, 2. Califomia, 171 p.
Yu, Chian-Son 2005. «Causes influencing the effectiveness of the postimplementation ERP system». Industrial Management & Data Systems, vol.
105, no 1, p. 115-132.
Zhen, Lu, Lin Wang et Jian-Guo Li. 2013. «A design ofknowledge management tool
for supporting product development». Information Processing &

Mécanismes de transfert de connaissances en - Archipel

Transcription

Similar documents

Estimation du coÃ»t des systÃ¨mes d`extinction automatique Ã eau

Les Ã©tudiants rÃ©cemment immigrÃ©s : mieux comprendre le

implantation d`un erp (enterprise resource planning) : antecedents et

Recueil de témoignages à l`attention des DSI

Livre Blanc ERP Open Source

Télécharger le catalogue des études CXP

Prévision-planification : que demande le client

le livre d`or 2015 des editeurs - les livres d`or 2015 des esn et editeurs

Code ASME Edition 2013

SAP et l`Intégration Inter-Organisationnelle

Modèle HBH650 Mélangeur de bar Model HBH650 Bar blender

model/modèle modelo model/modèle modelo

Nima Shaykhian

Code de la consommation - Legilux