CHRONIQUE 
PAR JEAN-FRANÇOIS PIRUS
La saine "dictature" du processus (première partie)
Si le constat de l'échec relatif de la plupart des projets ERP est réel, les conclusions que l'on doit en tirer laissent une place aux processus.  (22/06/2004)
 
PDG de la société de conseil Internet Business Services, et responsable du site BPMS.info, deux entités spécialisées dans le management des processus.
 
  Le site
BPMS.info
Lui écrire
Christophe Deshayes, dans un article récent, s’érigeait contre la “dictature du tout processus” en se référant au constat de l’échec relatif de la plupart des projets ERP, eu égard à leurs objectifs initiaux.

Si je partage ce constat, que j’ai eu l’occasion d’étayer au travers de 10 années d’expérience professionnelle dans ce domaine, j’en tire des conclusions radicalement différentes quant aux causes et aux conclusions qu’il convient de formuler sur la place à réserver aux processus.

Le bilan mitigé des ERP : une réalité
“Le bilan d’une décennie d’ERP n’a toujours pas été tiré et ne le sera sans doute jamais” écrit Deshayes. C’est probable. J’ai même entendu des managers d’éditeurs d’ERP expliquer très sérieusement que vouloir mesurer le ROI d’un progiciel intégré était une gageure ! Une façon un peu rapide et fort peu convaincante d’évacuer la question.

Si le bilan est difficile à tirer de manière précise, cela ne tient pas tant au fait qu’un projet de mise en oeuvre d’un progiciel intégré est complexe et que la mesure de son ROI fait appel à de nombreux indicateurs mais bien que la mesure initiale de la performance opérationnelle manque à l’appel. Or en l’absence de ce point de référence, il est difficile ensuite de mesurer l’impact du nouvel outil. Quand l’entreprise dispose d’un tel système de mesure continu et homogène, elle constate généralement que le premier effet perceptible de la mise en oeuvre d’un ERP est de dégrader sensiblement la performance.

D’aucuns rétorqueront qu’ils n’ont pas eu besoin de système de mesure sophistiqué pour s’en rendre compte; mais la mesure permet tout de même de quantifier l’impact en intensité et en durée. J’ai en mémoire une PME de 200 personnes dans le domaine médical qui avait fait le choix de la mise en oeuvre d’un tel outil sur un périmètre étendu (finances, gestion commerciale et production) en une seule opération. L’entreprise a mis plus de 2 ans à retrouver le niveau de performance d’avant l’ERP.

A qui la faute ?
Cet exemple est probablement représentatif : une entreprise met souvent deux ans à digérer un projet ERP. Si cet aspect est souvent méconnu et mal anticipé par les entreprises, la vraie question est : à qui la faute ?

Dans tout projet informatique qui ne donne pas satisfaction, l'outil est le coupable idéal.
Alors que les acteurs d'un tel projet sont nombreux, la responsabilité des difficultés rencontrées se concentre immanquablement sur le logiciel.

Je vois trois raisons principales aux difficultés rencontrées par ces projets :
- un choix d’outil découlant d’une définition insuffisamment précise des besoins ;
- l’absence d’une réflexion détaillée et préalable sur l’organisation cible ;
- une gestion du changement insuffisante avec des actions de formation souvent centrées sur l’outil en négligeant les implications opérationnelles et les bénéfices retirés du projet au niveau du poste de travail.

Revenons sur les deux premiers points qui sont liés. Trop souvent la phase de choix du progiciel est polluée par des considérations externes qu’on qualifie pudiquement de "politiques" pour traduire leur caractère irrationnel. Il n’est pas rare que, dans les grands groupes, le choix soit fait d’un progiciel unique au niveau mondial, indépendamment des spécifités nationales (liées aux législations ou à la variété des métiers exercés).

Quand les besoins d’intégration se limitent à la production d’un reporting commun, il n’est pas certain que les gains de coût relatifs à la maintenance et au déploiement compensent les développements spécifiques ou les pertes de productivité relatifs à un processus inadéquat. En tout état de cause, ce choix est rarement évalué en ces termes.

Dans d’autres cas, il arrive que le top management impose plus ou moins directement le choix de l’outil à mettre en œuvre, les considérations d’image prévalant sur l’adéquation du besoin. A cet égard, l’anecdote du choix du progiciel par le PDG sur un parcours de golf ne fut pas totalement caricaturale, en particulier dans la période un peu folle précédant l’an 2000 et le passage à l’euro.

L’adéquation fonctionnelle est une chose, l’optimisation organisationnelle en est une autre. Une phrase a fait beaucoup de dégâts dans l’esprit du top management : "l’ERP est structurant". Sous entendu : à quoi réfléchir à mon organisation cible, c’est l’ERP qui va me la dicter. Un réflexe encouragé par le discours des éditeurs vantant leurs "processus best practice".

Suite de l'article dans notre édition du 23 juin


Jean-François Pirus
  Chroniques BPMS
Comment assurer la rentabilité des projets technologiques
Alain Fernandez
 
La compétence, résultat de la connaissance inscrite dans les processus
Guy Rivoire
 
L'analyse des risques opérationnels : un enjeu qui dépasse le secteur bancaire
Jean-François Pirus
 
Tableaux de bord : pourquoi mesurer la performance ?
Alain Fernandez
 
La place de la simulation dans l'optimisation de la performance
Jean-François Pirus
 

Accueil | Haut de page

 

  Nouvelles offres d'emploi   sur Emploi Center
Auralog - Tellmemore | Publicis Modem | L'Internaute / Journal du Net / Copainsdavant | Isobar | MEDIASTAY

Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Toutes nos newsletters