| |
La mise en œuvre dans
une entreprise d'un progiciel d'ERP (Enterprise Resources
Planning) ou Progiciel de Gestion Intégré
(PGI), entraîne des changements de méthode
considérables pour les utilisateurs finaux. Cette
conduite du changement doit être particulièrement
préparée et suivie, au risque de générer
un refus des utilisateurs et un échec du projet.
Selon une étude récente
et à titre d'exemples, 31 % des projets ERP seraient
abandonnés, dans 189 % des cas les budgets prévus
seraient dépassés et dans 222 % les délais
ne seraient pas tenus (Matinée A.P.P. sur
les ERP). Bien entendu, ces chiffres ne précisent
pas qui du client ou des prestataires sont responsables.
De ces constats, plusieurs
recommandations générales peuvent être
données.
- les projets ERP ne
doivent pas être des projets " informatiques
" et être gérés uniquement
pas la Direction des Systèmes d'Information.
Ils doivent notamment être lancés, suivis
et soutenus par la Direction Générale
et toutes les directions ;
- le client doit tout particulièrement
définir la nature et le périmètre
du projet notamment aux niveaux technique et géographique,
définir ses objectifs en termes financiers et
de délais (forfait, régie, régie
plafonnée, délais impératifs ou
non) ;
- les utilisateurs doivent être
impliqués dans le processus d'implémentation.
Plusieurs projets d'ERP ont ainsi échoué
car les utilisateurs n'ont découvert le produit
quasiment qu'au moment de la réception finale.
C'est la raison pour laquelle des projets ERP doivent
s'accompagner d'une communication interne (voire externe)
permanente ;
- la phase préparatoire
ou pré-contractuelle (étude d'opportunité,
élaboration d'un cahier des charges, appel d'offres,
choix du ou des prestataires, négociation du
ou des contrats) est essentielle dans les projets ERP.
Tel n'est pas toujours le cas. Pourtant, ces projets
font intervenir de nombreuses équipes, sur différents
sites et/ou pays, avec des cultures d'entreprises et
des méthodes de travail souvent divergentes.
L'organisation (Comités
de pilotage et de suivi, Plan d'Assurance Qualité,
etc.) et les procédures d'avancement du projet
(réceptions et validation de chaque étape
ou des lots) doivent également être précisément
définies puis appliquées.
Pour chacune de ces raisons,
les projets ERP sont particulièrement sensibles.
Mais
quelle structure contractuelle retenir ?
Deux logiques contractuelles s'opposent généralement
; les clients souhaitant une relation bipartite entre
un maître d'ouvrage et un maître d'œuvre
et un contrat " clé en mains " ; les
prestataires (éditeurs, cabinets de conseil,
constructeurs) préférant une architecture
plus complexe associant des contrats de licence, de
maintenance, de vente, de prestations et de conseils.
En fonction du projet et du client, ces différents
prestataires peuvent également se positionner
l'un vis-à-vis des autres comme cotraitants,
solidaires ou conjoints, ou sous-traitants.
A ce titre, les notions de maîtrise d'ouvrage
et de maître d'œuvre sont généralement
utilisées. Mais que recouvrent-elles ?
1
Le Maître d'ouvrage
Le maître d'ouvrage est globalement celui
pour qui le projet informatique est réalisé.
Il doit clairement définir ses besoins, leur
nature et leur étendue dans un " cahier
des charges ".
En principe, le maître d'ouvrage est responsable
de la définition du "système".
Cependant, il peut confier cet aspect à un tiers
par contrat (l'assistant à maîtrise d'ouvrage).
La jurisprudence considère que le maître
de l'ouvrage :
- doit apporter toutes les précisions voulues
dans la définition de ses besoins et dans l'expression
des contraintes d'exploitation (CA Paris, 18 juin 1985,
Gaz. Pal. 1986, I, p. 72) ;
- doit définir, eu égard à son
organisation et ses problèmes spécifiques,
tous ses besoins réels et les objectifs et performances
à atteindre (…), définir de façon
précise, tous les éléments susceptibles
d'affecter la solution proposée (CA Paris, 15
juin 1990, Juris-Data n° 22939 et CA, Toulouse 5
mai 1997, Juris-Data n° 041319) ;
afin de permettre aux prestataires de s'engager en toute
connaissance de cause et de limiter les "dérapages".
Le maître d'ouvrage doit également :
- choisir et lancer les moyens nécessaires pour
le projet ;
- préciser un délai de mise en service
opérationnel qui soit compatible avec les moyens
mis en œuvre ;
- communiquer au maître d'œuvre tous les
éléments sur le contexte général
de l'opération, les données préexistantes,
les contraintes et difficultés particulières
;
- anticiper les conséquences de la mise en place
du système sur son organisation ;
- procéder aux différentes réceptions
découlant de l'opération ;
- assurer l'exploitation restant à sa charge.
2 Le Maître d'œuvre
Le maître d'œuvre est "la personne
physique ou morale qui, pour sa compétence technique,
est chargée par le maître d'ouvrage de
diriger et de contrôler les travaux et de proposer
la réception et leur règlement" (AFNOR,
Norme P03001) ou "se charge de la mise en place
des systèmes sur le plan technique" (Parisot).
La qualification de maître d'œuvre ne peut
être retenue que s'il dispose d'une autonomie
dans ses choix techniques et qu'il pilote de manière
effective le projet.
Le maître d'œuvre doit proposer à
son client la solution la mieux adaptée à
ses besoins, en lui communiquant toutes les informations
nécessaires avant et durant le projet et, si
nécessaire, en le mettant en garde. Il doit également
piloter, animer, coordonner, planifier et suivre le
déroulement du projet, assister aux opérations
de réception et corriger les " écarts
" constatés.
Enfin, en fonction des projets, il peut être utile
de faire une distinction entre la maîtrise d'œuvre
de conception, la maîtrise d'œuvre de réalisation
et d'intégration.
Trop souvent, le choix de la structure contractuelle
n'est abordé par les clients utilisateurs qu'après
la sélection du ou des prestataires. Pourtant,
elle impacte directement les obligations de chacune
des parties.
|
Marc d'Haultfoeuille