Suite de l’analyse que Philippe Lastrayoli, consultant chez Mielabelo, fait des écueils habituels à éviter pour conduire à bonne fin les projets d’évolution IT – qu’ils touchent aux structures ou aux infrastructures, qu’ils correspondent à des scénarios de renouvellement ou de changement. Relire ici la première partie de cet article. 

3. “Allez, un autre projet glissé dans la pile !” – ou l’importance de l’engagement du management dans le projet d’évolution

Initier un projet de changement d’organisation génère habituellement une réaction paradoxale. Cela peut devenir assez facilement dans l’esprit des acteurs concernés “un truc si j’ai un peu de temps après mon vrai travail, parce que mon responsable me l’a demandé”. Ce phénomène peut d’ailleurs aussi se retrouver dans l’esprit des décisionnaires, voire dans celui du responsable du projet.
Il existe plusieurs causes à cela.

•  Les projets techniques semblent généralement plus concrets pour les utilisateurs. Ils sont également plus simples à mettre en œuvre ou à intégrer dans le plan de charge des projets à venir. Les équipes savent généralement ce qu’elles doivent faire dans ce genre de cas.
•   Dans un projet de changement, les acteurs deviennent le “sujet”, ce qui change radicalement leur perception du projet! Cette remise en question est souvent génératrice de perturbation, car elle touche aux capacités et aux compétences des personnes.
•  Les projets de changement n’ont parfois pas assez, voire pas du tout, de charges ou de budget spécifiques prévisionnels.
Les projets de changement nécessitent donc une attention et un engagement spécifique de la part du management. C’est lui qui doit aider l’ensemble des personnes impliquées à intégrer et à s’approprier la nouvelle culture et les nouvelles pratiques. Pour ce faire, une allocation de temps et de budget correspondante est indispensable.
Par ailleurs, faire évoluer une organisation a fatalement des impacts temporaires sur l’activité courante: baisse momentanée de productivité liée au rodage des pratiques, besoins d’embaucher, d’être formé, etc. Cet état de fait doit être compris et accepté de tous, y compris des clients de l’organisation, par le biais:

• d’une analyse préalable des impacts sur les autres projets à mener,
• d’une priorisation et arbitrage de la part de l’ensemble des parties prenantes.

 4. “Dessiner une maison ne permet pas d’habiter dedans” – ou l’importance d’aller au-delà d’une simple planification du projet d’évolution

Une autre façon de s’égarer, très souvent liée à la précédente, consiste à établir les plans de la nouvelle organisation… et à s’arrêter là. Malheureusement, rédiger l’intégralité des nouveaux processus et s’en contenter ne produira aucune implémentation surnaturelle des activités.

Là encore, trouver ce qui ne va pas et dessiner ce qui changerait la donne est une activité nécessaire et potentiellement complexe. Mais il ne s’agit bel et bien que d’une étape, et à proprement parler, rien de concret n’a été édifié: “les plans de la maison sont là, reste à la construire”.

Beaucoup d’initiatives de changement d’organisation s’arrêtent à ce moment-là, ou perdent en partie de leur “engagement” et l’attention spécifique qui va avec.
Pourtant c’est le moment de mettre “les mains dans le cambouis”! Dans ce contexte de changement humain, les “maçons” ne peuvent être uniquement externes, même si un consultant tient le rôle de chef de chantier et d’architecte. Il est indispensable d’expérimenter les nouvelles pratiques, de se les approprier à l’aide d’une conduite de changement appropriée et d’une méthodologie d’accompagnement.

5. “Prier un messie providentiel ne comblera pas vos vœux” – ou l’importance de trouver une méthode cohérente et efficace pour le projet d’évolution

Une dernière approche problématique consiste à chercher une méthode d’implémentation du changement “sur l’étagère”.

Ce serait, par exemple, une méthode rédigée en latin dans un vieux grimoire secret, et qui solutionnerait l’ensemble des problèmes au moment-même où elle a été acquise. Ou, à la rigueur, une méthode qui consisterait à prendre quelques consultants, à les faire travailler à la place des équipes internes, à changer le nom d’un ou deux processus et “hop, c’est plié!”.

Ce type d’erreur d’appréciation a beaucoup à voir avec la précédente évoquée au point 4. Il est d’ailleurs fréquent de les voir en action simultanément. En effet, les deux répondent à un même souhait illusoire: ne pas générer de perturbations dans la “vie courante” de l’activité informatique.

Et elles fonctionnent sur la même dynamique: il suffirait de penser une théorie pour bénéficier de ses effets! Dans l’espoir de la “méthode miracle”, il ne faudrait plus faire un effort d’implémentation ni penser son organisation par rapport à ses propres besoins.
Soyons clair, les méthodes, référentiels et autres bonnes pratiques sont évidemment très utiles, voire nécessaires, pour construire son organisation dans les règles de l’art. Aussi nécessaires que les principes de construction peuvent l’être pour construire une maison qui ne s’effondrera pas au premier coup de vent! Mais aucune méthode ne dira pas s’il faut une ou trois chambres. Seul le client connaît ses besoins, et la méthode ne construira certainement pas la maison. De plus, dans l’entreprise, les composants de la maison sont ici essentiellement des gens formés qui suivent des règles communes pour fonctionner tous ensemble. Il serait donc difficile de la faire construire uniquement par des ouvriers extérieurs.

Les méthodes, référentiels et autres bonnes pratiques sont évidemment très utiles, voire nécessaires, pour construire son organisation dans les règles de l’art. Mais seule l’entreprise connaît ses besoins et ne saurait confier sa “construction” uniquement à des “ouvriers” venus de l’extérieur.

Une fois de plus, les acteurs devront donc s’approprier les bonnes pratiques, même si celles-ci ont, en très grande partie été inspirées, par une méthode externe complète. Par exemple… la méthode COBIT 5 sur laquelle Mielabelo a constitué son approche complète d’accompagnement stratégique, en tant que fil conducteur garantissant la cohésion de toute démarche d’évolution.

Conclusion

On concevrait difficilement de développer une application ou une évolution de celle-ci sans se préoccuper de savoir:

•     ce que les utilisateurs en attendent précisément en termes de bénéfices,

•     quelles sont les fonctionnalités déjà couvertes,

•     si les utilisateurs ont besoin ou adhérent à l’intérêt d’une nouvelle application.

De même, on ne concevrait pas d’oublier d’y affecter des ressources et un budget, ou encore d’acheter “tout fait” une application sans envisager de l’adapter à ses propres besoins.

Pourtant, les initiatives d’amélioration sont souvent traitées de manière moins rigoureuse qu’un projet de mise en œuvre ou d’amélioration d’une application. Cela tient en grande partie au fait que le sujet-même des travaux, d’une part, et l’organisation et les personnes qui doivent les mener à bien, d’autre part, se confondent. Cette proximité fait que les enjeux et leurs relations sont souvent mal compris et que l’approche pour les résoudre n’est alors pas structurée.

Les projets d’amélioration IT sont souvent traités de manière moins rigoureuse qu’un projet de mise en œuvre ou d’amélioration d’une application.

Pour pallier ces difficultés, Mielabelo préconise une approche intégrée associant:

•     un référentiel de gestion de l’alignement, depuis les attentes des différentes parties prenantes jusqu’au suivi des bénéfices via les indicateurs d’activité,

•     une méthode d’analyse des causes et de recherche des axes d’amélioration,

•     une méthode de mise en œuvre (Lean) des évolutions d’activité retenue.

Le tout permettant:

•     de communiquer sur les enjeux et le pourquoi de l’évolution, en insistant sur les souffrances à fonctionner de la manière existante, les causes de cette souffrance et les axes d’amélioration potentiels,

•     d’établir immédiatement un référentiel sur l’état des lieux et la capacité à évoluer afin de prendre des décisions à la fois cohérentes théoriquement et tenables en pratique,

•     de piloter et d’avancer les travaux en ne perdant pas de vue les objectifs et exigences initiales sur la base d’un budget et d’une charge de travail prévus,

•     de ne pas s’arrêter en chemin en ayant dessiné l’organisation idéale sans savoir comment la mettre en œuvre concrètement,

•     d’adapter concrètement les initiatives d’amélioration aux enjeux spécifiques de l’entreprise prise dans ses contraintes et son environnement propres (attentes et objectifs, d’une part, capacité réelle à les déployer, d’autre part).

Philippe Lastrayoli, Consultant Senior chez Mielabelo