Miracle… ou mirage d’un “grand projet” ERP, traitement traumatique post-ERP ?
Interrogations sur la rentabilité des « grands projets » de systèmes d’information
Un journal anglo-saxon spécialisé en management des entreprises faisait apparaître un titre provocateur en 2002, après l’explosion de la « bulle Internet – nouvelle économie » :
- 1996 : ERP
- 1998 : SCM
- 2000 : CRM
- 2002 : SOS !
(N. B. : il faut en effet un acronyme à 3 lettres pour qu’une nouvelle méthode de management ait quelque chance d’être transformée en succès commercial par le consulting.)
Au-delà de la polémique et du slogan, il est trop fréquent de constater une certaine désillusion des entreprises quant à leur amélioration de performance opérationnelle faisant suite aux implantations de grands progiciels intégrés de type ERP (dont SAP est le symbole emblématique).
Cette désillusion est surtout notable lorsqu’elle est confrontée aux espérances que leur avaient vendues (« survendues ? ») les différents acteurs qui sont intervenus autour de ces projets (sociétés de conseil, intégrateurs SSII, éditeurs…, ce que ces acteurs aux intérêts convergents appellent eux-mêmes leur « écosystème »).
Citons quelques chiffres sans prétendre à l’exhaustivité ou à la représentativité.
De la microéconomie (quel retour sur investissement (ROI) pour ce projet d’implantation d’ERP ?) à la macroéconomie (le paradoxe de Solow)
Cette interrogation, au niveau de chaque entreprise et décideur, sur la rentabilité intrinsèque des projets d’implantation d’ERP, des progiciels associés de type SCM (chaîne logistique intégrée), CRM (gestion de la relation client) ou plus généralement des grands projets de systèmes d’information, se retrouve sur le plan macroéconomique dans le paradoxe de Solow (« on trouve des ordinateurs partout, sauf dans les statistiques de productivité ! »).
L’absence de corrélation (indice d’une possible causalité !) entre la croissance des investissements en technologies de l’information et la croissance de la productivité du travail de ces utilisateurs a été identifiée dès la fin des années 1980. La croissance retrouvée en 1995–2000 (surtout aux USA) a un temps fait croire à la fin de cette énigme, mais ce paradoxe retrouve de l’actualité après l’explosion de la bulle dite de la « nouvelle économie » et la remise en question des grands investissements en technologies de l’information.
Récemment (2002), une étude du Mac Kinsey Global Institute met en évidence la forte disparité sectorielle de ce lien entre investissement informatique et productivité.
La corrélation est faible entre l’accroissement des investissements en technologies de l’information et l’accroissement de productivité du travail (périodes de références 1987–1995 et 1995–2000 aux USA). Il n’y a donc clairement pas d’automaticité liant l’investissement en nouvelles technologies et l’amélioration de la productivité globale. L’analyse plus détaillée de différents secteurs industriels et des services montre que les investissements en nouvelles technologies efficaces relativement à l’amélioration de la productivité du travail partagent certaines caractéristiques communes.
Quelles sont ces caractéristiques communes ?
Retour à la microéconomie : comment bénéficier au mieux des opportunités des technologies de l’information, en optimisant les investissements associés ?
Comme il a été indiqué précédemment, un investissement en technologies de l’information n’est pas rentable en lui-même, mais seulement s’il est associé à une transformation et une amélioration des processus de l’entreprise.
Nous proposons d’illustrer le déploiement d’un programme stratégique de transformation : la trajectoire vers la performance opérationnelle sur le diagramme ci-contre, suivant les deux axes : l’axe « infrastructure technologique » et l’axe des « métiers et processus de l’entreprise ».
Projet type 1 : « mirage technologique »
Le ROI est faible, ou plus probablement négatif.
Exemple type : rénovation de l’architecture informatique et mise en place d’un ERP « compatible an 2000 » sans analyse et transformation (préalable ou conjointe).
Contre-exemple « type » (industrie cosmétique) : mise en place de module de prévision commerciale et de gestion de la demande (avec modèles statistiques sophistiqués de prévisions) sans établir de processus de pilotage de la demande et des échanges d’information qui soient transparents sur les niveaux de stock de produits finis et les politiques commerciales avec les principaux distributeurs.
Projet type 2 : « tactiques, opportunistes »
Exemple type : réorganisation et amélioration des processus de production, maîtrise statistique des processus, amélioration de la qualité/fiabilité machine, projet TPM « Total productive maintenance ».
Ces projets « métiers », conduits à infrastructure technologique et informatique identique, sont généralement à temps de retour rapide. Ils sont cependant limités par les contraintes des systèmes existants.
Projet type 3 : « stratégique, transformation métier » radicale supportée par des architectures informatiques, progiciels et fonctionnalités ciblés sur la transformation du métier
Exemple type (industrie alimentaire et grande distribution) : projet de transformation de la chaîne logistique, amélioration radicale du service client par segmentation et différenciation du taux de service suivant les canaux de distribution, mise en place de gestion partagée des approvisionnements entre fournisseurs et distributeurs privilégiés, appuyées par des échanges d’information et de décision en temps réel entre les partenaires (Extranet et programme CPFR « Co-operative Planning, Forecasting, Replenishment » entre fournisseur et distributeur).
Un programme stratégique de transformation : quelles sont les conditions de succès
a) Un management de la transformation avec une maîtrise d’ouvrage « métier », une forte implication (soutien et engagement) de la direction générale du plus haut niveau pour fixer une orientation stratégique d’entreprise et ciblée vers le métier au programme de transformation. C’est cette orientation stratégique » métier » qui détermine alors les moyens technologiques permettant et supportant cette transformation vers l’excellence opérationnelle (et non l’inverse !)
b) Un programme global, cohérent, constitué par un ensemble de projets à enjeux, ROI identifiés, modulaires et phasés.
Il est souhaitable de segmenter et séquencer ce programme en projets tactiques, à retour rapide, « donnant confiance » et en projets stratégiques à plus long terme, mais à déploiement phasé, modulaire.
Cette démultiplication « programmes/ projets » permet ainsi de limiter la taille et la complexité des projets (l’expérience montre que le taux de réussite des projets est inversement proportionnel à leur taille et leur complexité !).
Le déploiement des technologies « support » et des modules « fonctionnalités » des progiciels intégrés est progressif, en « juste à temps » et en « tant que de besoin » ; ceci permet simultanément de décaler les investissements dans le temps (meilleure rentabilité globale du programme) de conserver des options ouvertes pour tenir compte de l’évolution des besoins (adaptabilité globale du programme).
Ce déploiement progressif (« au plus tard ») des technologies support permet aussi de tenir compte de l’obsolescence technologique rapide (ne pas faire d’impasse ni d’anticipation) : le critère de cohérence prime ici sur celui de la complétude des fonctionnalités.
c) Un pilotage par la valeur ajoutée et le retour sur investissement : éviter « l’effet tunnel ».
Le calcul du retour sur investissement n’est pas ici limité aux deux moments classiques de la gestion d’un projet : le ROI « a priori » au moment de la décision d’investir, et le ROI « a posteriori » à la clôture du projet, mais nous proposons d’en faire un indicateur de pilotage permanent tout au long du programme, pour permettre un pilotage du programme par la valeur ajoutée.
- Lors du diagnostic initial du programme de transformation (étude d’opportunité, benchmarking) : cette phase permet d’établir le niveau initial de cet indicateur de performance, auquel vont s’additionner toutes les « valeurs ajoutées » des projets.
- En cours de programme et à chaque date jalon : grâce à cet indicateur on établira et analysera la « valeur ajoutée du programme de transformation », permettant d’ajuster et de décider des projets complémentaires avec leur ROI marginal (choix progressif des options, adaptation du programme).
- En fin de programme : on chiffrera la valeur ajoutée globale, et par comparaison avec les investissements cumulés on établira le ROI global.
d) Une capitalisation, appropriation des connaissances par les acteurs : management, opérationnel (dynamique d’amélioration continue « Plan Do Check Act » PDCA) allant bien au-delà de l’activité « conduite du changement » qui accompagne (souvent comme « alibi ») les projets purement informatiques et technologiques.
Éviter l’effet « débandade » de l’équipe projet : les consultants extérieurs et les experts en métiers internes qui accompagnent souvent ce type de projet, lorsque la fin de celui-ci est déclarée (souvent en « surcoûts » et en « surdélais ») regagnent alors leurs unités d’origine ou sont déjà engagés sur d’autres projets.
Les opérationnels sont alors quelque peu abandonnés à eux-mêmes avec un outil » système d’information » qu’ils connaissent mal et qui répond imparfaitement à leurs besoins. Le résultat est alors très fréquemment une appropriation maladroite, des processus et pratiques fonctionnant en mode « forcé » bien loin des meilleures pratiques choisies lors des phases d’analyse fonctionnelle et de paramétrage, avec tous les risques opérationnels et financiers correspondants.
Que faire dans l’autre cas ? (retour au titre initial : traitement traumatique post-ERP)
La démarche « Programme de transformation : trajectoire vers l’excellence en performance opérationnelle » que nous préconisons ci-dessus est la voie « royale », logique et rationnelle.
Que faire dans l’autre cas de figure (purement imaginaire ou hypothétique ?) d’un projet de type « mirage technologique » ?
Le management de l’entreprise, convaincu par les arguments brillants, les présentations « PowerPoint » fascinantes des commerciaux « avant-vente » des éditeurs renommés, a lancé un grand projet technologique. Il s’agit (avec les arguments imparables présentés par les consultants « partners » des ex-« big five », gourous du e‑Business : avantage au premier entrant, au plus rapide !) de préempter les dividendes si prometteurs de la « Nouvelle économie ». Le progiciel intégré ERP est alors déployé simultanément dans toutes les Business Units, suivant le « core model » et les « best practices » préconisées par les consultants experts, l’intégrateur et l’éditeur choisi (les partenaires de « l’écosystème » dont on a parlé précédemment).
Les difficultés surviennent, progressivement et s’accumulant, lorsque ces processus types et « best practices » sont confrontés avec la réalité du terrain opérationnel et du métier propre à l’entreprise, et aux spécificités de ses processus.
L’activité de « conduite du changement » prévue dans le projet est dans les faits limitée à l’apprentissage mécanique par les acteurs opérationnels des différentes interfaces et de la navigation à l’aveugle entre celles-ci.
La conséquence, douloureuse, apparaît généralement à la mise en exploitation (« 75 % des entreprises ont constaté une baisse modérée à importante de leur productivité »).
Par rapport à cette situation pathologique, quel traitement traumatique post-ERP appliquer ? Nous proposons un traitement en deux phases :
- traitement symptomatique d’urgence, pour obtenir une situation opérationnelle satisfaisante et stabilisée,
- traitement curatif de fond, une transformation radicale pour obtenir la meilleure valorisation des investissements technologiques réalisés.
Le traitement symptomatique d’urgence
L’analyse de la situation au niveau « terrain » (avec les acteurs utilisant le système) permet de séparer les dysfonctionnements et écarts fonctionnels selon trois classes « d’écart », avec leurs remèdes appropriés :
- écart de formation, d’appropriation (les fonctionnalités requises sont présentes et adéquates, mais mal utilisées),
- écart d’organisation/d’ajustement des processus (pratiques actuelles non conformes aux meilleures pratiques),
- écarts de fonctionnalités (« trous fonctionnels ») mineurs, avec adaptations ne remettant pas en cause le « core model ».
Ce traitement curatif permet de maîtriser la situation, de retrouver un fonctionnement opérationnel satisfaisant (même s’il reste sous-optimal).
Le traitement de fond, la transformation radicale
La démarche proposée rejoint alors le programme stratégique de transformation présenté précédemment. Il est probable qu’une partie des investissements technologiques et informatiques engagés seront alors en partie « récupérés » et valorisés, et qu’une autre partie devra être abandonnée (cette partie du traitement peut apparaître difficile du point de vue « managérial », car remettant en cause des choix et solutions technologiques qui viennent d’être implantés sans être rentabilisés).
En synthèse
Le message clef est la nécessité de retour aux « basiques » de l’excellence opérationnelle (maîtriser ses processus clefs, réduire les coûts, produire de la valeur, améliorer le service client) qui sont les éléments déterminants de la performance économique et financière (le retour sur investissement), la technologie étant un moyen stratégique au service de cette excellence opérationnelle et devant donc s’adapter aux métiers de l’entreprise (et non l’inverse !).