0
Le paradoxe (apparent)
Les projets informatiques au sens large (mise en place d'ERP, projets EAI, projets Inter-/intra/extranets...) sont traditionnellement consommateurs de conseil, que ce soit en amont (étude d'opportunité), durant le projet lui-même (assistance à maîtrise d'ouvrage, à maîtrise d'œuvre), ou en aval de celui-ci (formation des utilisateurs et, plus généralement, "mise en tension" organisationnelle). Or, le paradoxe -apparent- réside en ceci que ce sont précisément ces projets fortement encadrés qui connaissent le taux d'insatisfaction, voire d'échec, le plus élevé... de là à y voir une relation de cause à effet... Nous nous bornerons ici à en étudier le volet assistance à maîtrise d'ouvrage, les dérapages relevant de la maîtrise d'œuvre étant généralement mieux identifiables. Pour ce faire, nous choisirons d'observer un projet informatique au travers du prisme des acteurs internes à l'entreprise.
A chaque acteur interne son travers...
L'influence du consultant va potentiellement s'exercer sur trois acteurs. Examinons en premier lieu quels vont être les travers naturels de chacun.
Au plus haut niveau, nous trouvons la Direction Générale, qui assure la maîtrise d'ouvrage stratégique. Elle ne peut accorder qu'une fenêtre d'attention réduite au projet, essentiellement pendant les réunions du Comité de pilotage. Ceci tend à placer une pression exacerbée sur les autres participants, qui savent qu'il leur faudra sortir de réunion en ayant impérativement obtenu soit un feu vert, soit un veto (c'est selon...). Ce phénomène biaise fréquemment les restitutions en Comité de pilotage, que l'ordre du jour soit de nature fonctionnelle (par exemple : "au regard de nos besoins, devons-nous implanter tel module de tel ERP ?") ou de nature technique (par exemple : "notre architecture informatique actuelle doit-elle évoluer sous la pression du projet ?").
Vient ensuite la Direction Métier, que l'on définira comme la Direction (des Ressources Humaines, Commerciale...) au service de laquelle le projet se place prioritairement, et qui assure la maîtrise d'ouvrage opérationnelle. Elle va quant à elle s'intéresser au volet fonctionnel du projet, les aspects techniques ne retenant son attention qu'en terme de poste budgétaire à minimiser autant que possible. Elle oubliera donc dans la plupart des cas d'aborder les questions d'intégration, de reprise de l'existant, ou bien les rejettera à plus tard, "quand on en arrivera à la boîte noire".
Enfin, la Direction Projet constitue le troisième acteur et assure pour sa part la maîtrise d'ouvrage opérationnelle déléguée (par la Direction Métier). Traditionnellement, elle est physiquement incarnée par un cadre de confiance choisi au sein de la Direction Métier, et chargée d'assurer l'interface entre les instances hiérarchiques supérieures de maîtrise d'ouvrage déjà citées et la Direction Projet côté maîtrise d'œuvre. L'expérience montre que la Direction Projet maîtrise d'ouvrage est de facto l'acteur le plus "réaliste", qui apprend à manager un projet informatique sous contraintes (puisque la Direction Métier, à qui il reporte, le presse ou l'ignore, tandis que son homologue côté maîtrise d'œuvre, dont il ne sait si ses contraintes alléguées sont réelles ou non, conditionne pourtant "l'opérationnalité" de son projet...).
Quel rôle pour le consultant ?
Partant de ce constat, quel devrait être le rôle du consultant côté maîtrise d'ouvrage... et qu'en est-il en réalité ?
Idéalement (mais, en pratique, seulement dans la moitié des cas...), le consultant devrait donc :
- Sensibiliser la Direction Générale aux contraintes et craintes de ses acteurs internes, afin qu'elle aborde d'elle-même en séance les sujets anxiogènes, en dédramatisant les "zones grises" existantes : oui au droit à l'erreur, non au droit au silence...
- Sensibiliser très tôt la Direction Métier aux opportunités et contraintes connues de l'architecture informatique existante : pour que le fonctionnel ne soit plus parallèle au technique, mais orthogonal (c'est-à-dire "lié à", sans pour autant être "dépendant de") ;
- Professionnaliser et soutenir la Direction Projet : à savoir mettre à sa disposition des outils et méthodes de pilotage, la former aux enjeux fonctionnels et techniques, créer un binôme avec elle.
Or, trop souvent (l'autre moitié du temps...), le consultant :
- Conforte la Direction Générale dans une vision "high level" des enjeux, et par conséquent...
- Met la pression sur / influence la Direction Métier pour qu'elle ouvre le champ fonctionnel des possibles et fasse rêver, et par conséquent...
- Place la Direction Projet sous le feu croisé des exigences fonctionnelles et techniques, en ayant beau jeu de lui fournir outils, méthodes et coaching pour l'aider dans "son rôle décidément ingrat", avant de...
- Structurer un cahier des charges ne répondant que partiellement aux enjeux fonctionnels (ils étaient trop beaux) et plus ou moins bien articulé à l'architecture technique existante (on s'en est préoccupé trop tard).
Pour un mea culpa constructif
Dès lors, si le marché du conseil ne veut plus avoir à justifier de taux d'échec dépassant les 50% sur l'ensemble des projets informatiques, un mea culpa constructif semble nécessaire. Le premier pas en serait de tenir un discours approprié à son client : accepter de reprendre de la hauteur sur une thématique dont il pensait avoir fait le tour ; ne négliger aucun acteur du projet... ce qui suppose de les identifier et de connaître leurs besoins et contraintes spécifiques ; travailler en mode projet : le management du projet conditionne la pertinence du contenu qui s'y produit ; demander à son conseil de lui donner les éléments pour arbitrer, plutôt que la solution elle-même : la responsabilité ne se délègue pas.
Au total, une meilleure efficience globale des projets informatiques n'est pas hors de portée, pour peu que les instances dirigeantes des entreprises acceptent toute leur part de responsabilité et se montrent ouvertes aux (voire curieuses des) contraintes techniques relevant de la maîtrise d'œuvre, et que les consultants qui les accompagnent ne cherchent pas à les conforter dans leurs travers, mais bien à remettre en question ces mauvaises habitudes, quitte à risquer de déplaire au prince... Pascal n'affirmait-il pas : "dire la vérité est utile à celui à qui on la dit, mais désavantageux à ceux qui la disent" ?
Nicolas HUMEAU
(initialement publié sur le site www.360journal.com)
Les projets informatiques au sens large (mise en place d'ERP, projets EAI, projets Inter-/intra/extranets...) sont traditionnellement consommateurs de conseil, que ce soit en amont (étude d'opportunité), durant le projet lui-même (assistance à maîtrise d'ouvrage, à maîtrise d'œuvre), ou en aval de celui-ci (formation des utilisateurs et, plus généralement, "mise en tension" organisationnelle). Or, le paradoxe -apparent- réside en ceci que ce sont précisément ces projets fortement encadrés qui connaissent le taux d'insatisfaction, voire d'échec, le plus élevé... de là à y voir une relation de cause à effet... Nous nous bornerons ici à en étudier le volet assistance à maîtrise d'ouvrage, les dérapages relevant de la maîtrise d'œuvre étant généralement mieux identifiables. Pour ce faire, nous choisirons d'observer un projet informatique au travers du prisme des acteurs internes à l'entreprise.
A chaque acteur interne son travers...
L'influence du consultant va potentiellement s'exercer sur trois acteurs. Examinons en premier lieu quels vont être les travers naturels de chacun.
Au plus haut niveau, nous trouvons la Direction Générale, qui assure la maîtrise d'ouvrage stratégique. Elle ne peut accorder qu'une fenêtre d'attention réduite au projet, essentiellement pendant les réunions du Comité de pilotage. Ceci tend à placer une pression exacerbée sur les autres participants, qui savent qu'il leur faudra sortir de réunion en ayant impérativement obtenu soit un feu vert, soit un veto (c'est selon...). Ce phénomène biaise fréquemment les restitutions en Comité de pilotage, que l'ordre du jour soit de nature fonctionnelle (par exemple : "au regard de nos besoins, devons-nous implanter tel module de tel ERP ?") ou de nature technique (par exemple : "notre architecture informatique actuelle doit-elle évoluer sous la pression du projet ?").
Vient ensuite la Direction Métier, que l'on définira comme la Direction (des Ressources Humaines, Commerciale...) au service de laquelle le projet se place prioritairement, et qui assure la maîtrise d'ouvrage opérationnelle. Elle va quant à elle s'intéresser au volet fonctionnel du projet, les aspects techniques ne retenant son attention qu'en terme de poste budgétaire à minimiser autant que possible. Elle oubliera donc dans la plupart des cas d'aborder les questions d'intégration, de reprise de l'existant, ou bien les rejettera à plus tard, "quand on en arrivera à la boîte noire".
Enfin, la Direction Projet constitue le troisième acteur et assure pour sa part la maîtrise d'ouvrage opérationnelle déléguée (par la Direction Métier). Traditionnellement, elle est physiquement incarnée par un cadre de confiance choisi au sein de la Direction Métier, et chargée d'assurer l'interface entre les instances hiérarchiques supérieures de maîtrise d'ouvrage déjà citées et la Direction Projet côté maîtrise d'œuvre. L'expérience montre que la Direction Projet maîtrise d'ouvrage est de facto l'acteur le plus "réaliste", qui apprend à manager un projet informatique sous contraintes (puisque la Direction Métier, à qui il reporte, le presse ou l'ignore, tandis que son homologue côté maîtrise d'œuvre, dont il ne sait si ses contraintes alléguées sont réelles ou non, conditionne pourtant "l'opérationnalité" de son projet...).
Quel rôle pour le consultant ?
Partant de ce constat, quel devrait être le rôle du consultant côté maîtrise d'ouvrage... et qu'en est-il en réalité ?
Idéalement (mais, en pratique, seulement dans la moitié des cas...), le consultant devrait donc :
- Sensibiliser la Direction Générale aux contraintes et craintes de ses acteurs internes, afin qu'elle aborde d'elle-même en séance les sujets anxiogènes, en dédramatisant les "zones grises" existantes : oui au droit à l'erreur, non au droit au silence...
- Sensibiliser très tôt la Direction Métier aux opportunités et contraintes connues de l'architecture informatique existante : pour que le fonctionnel ne soit plus parallèle au technique, mais orthogonal (c'est-à-dire "lié à", sans pour autant être "dépendant de") ;
- Professionnaliser et soutenir la Direction Projet : à savoir mettre à sa disposition des outils et méthodes de pilotage, la former aux enjeux fonctionnels et techniques, créer un binôme avec elle.
Or, trop souvent (l'autre moitié du temps...), le consultant :
- Conforte la Direction Générale dans une vision "high level" des enjeux, et par conséquent...
- Met la pression sur / influence la Direction Métier pour qu'elle ouvre le champ fonctionnel des possibles et fasse rêver, et par conséquent...
- Place la Direction Projet sous le feu croisé des exigences fonctionnelles et techniques, en ayant beau jeu de lui fournir outils, méthodes et coaching pour l'aider dans "son rôle décidément ingrat", avant de...
- Structurer un cahier des charges ne répondant que partiellement aux enjeux fonctionnels (ils étaient trop beaux) et plus ou moins bien articulé à l'architecture technique existante (on s'en est préoccupé trop tard).
Pour un mea culpa constructif
Dès lors, si le marché du conseil ne veut plus avoir à justifier de taux d'échec dépassant les 50% sur l'ensemble des projets informatiques, un mea culpa constructif semble nécessaire. Le premier pas en serait de tenir un discours approprié à son client : accepter de reprendre de la hauteur sur une thématique dont il pensait avoir fait le tour ; ne négliger aucun acteur du projet... ce qui suppose de les identifier et de connaître leurs besoins et contraintes spécifiques ; travailler en mode projet : le management du projet conditionne la pertinence du contenu qui s'y produit ; demander à son conseil de lui donner les éléments pour arbitrer, plutôt que la solution elle-même : la responsabilité ne se délègue pas.
Au total, une meilleure efficience globale des projets informatiques n'est pas hors de portée, pour peu que les instances dirigeantes des entreprises acceptent toute leur part de responsabilité et se montrent ouvertes aux (voire curieuses des) contraintes techniques relevant de la maîtrise d'œuvre, et que les consultants qui les accompagnent ne cherchent pas à les conforter dans leurs travers, mais bien à remettre en question ces mauvaises habitudes, quitte à risquer de déplaire au prince... Pascal n'affirmait-il pas : "dire la vérité est utile à celui à qui on la dit, mais désavantageux à ceux qui la disent" ?
Nicolas HUMEAU
(initialement publié sur le site www.360journal.com)
