1

White paper 1 : Gouvernance IT

Philippe Lastrayoli

Consultant Senior chez Mielabelo depuis 2010. Contrôleur de gestion de formation, spécialiste des problématiques de Gouvernance et d’Alignement des Systèmes d’Information, il rejoint Mielabelo après avoir évolué durant de nombreuses années en France sur les thématiques du conseil informatique. En parallèle des missions chez nos clients, il synthétise des méthodes et référentiels d’alignement, d’analyse d’impact et d’arbitrage pour proposer un framework transverse de mise en contrôle des évolutions des organisations de support.

1. « Donne un poisson à un homme et il mangera un jour. Apprends-lui à pêcher et il mangera toujours » ou l’importance de percevoir l’intérêt du projet

d’évolution

Dans la plupart des cas de volontés d’évolution, le sponsor d’un projet ICT oeuvre pour accroître la valeur de l’organisation. Il peut alors décider de lancer un programme d’évolution. Dans ce programme, il devra identifi er précisément les principaux problèmes existants, et, ensuite, prioriser leur résolution.

Cette excellente initiative risque pourtant d’être insuffi sante pour garantir la réalisation des bénéfi ces espérés ! Ce sera le cas, notamment, si les collaborateurs perçoivent cette initiative comme un ordre venu «d’en haut», lancé sans réelle réfl exion.

En effet, le succès d’un changement est étroitement lié à la perception de son intérêt par l’ensemble des acteurs de l’organisation. Sans cette perception, la plupart des gens concernés par une évolution de leur activité ne mettra rien en place. Et cela, le plus souvent parce que « changer c’est compliqué et moi ça fait 10 ans que je bosse comme ça... je ne vois vraiment pas pourquoi je changerais »!

De plus, il est peu probable que les acteurs de l’entreprise soient davantage convaincus par cette initiative en cours de déroulement du projet. En effet, si un dysfonctionnement peut sembler relativement évident vu de l’extérieur, les acteurs n’en ont pas toujours conscience ou n’en perçoivent pas toujours les effets négatifs.

Pour résumer, un projet de changement doit donc initialement « rencontrer son public ». Le public doit être conscient de l’existence de douleurs et de leurs impacts négatifs dans le bon fonctionnement de l’entreprise.

2. « Marcher dans le noir est la meilleure façon de se perdre » ou l’importance

de tout connaître du projet d’évolution

Un projet a également toutes les chances d’échouer si l’on démarre le projet sans savoir d’où l’on part. Il est alors diffi cile de « tomber » par hasard sur les bonnes solutions d’amélioration. À terme,

5 raisons courantes de l’échec des projets d’évolution des organisations informatiquesLes solutions à mettre en place pour assurer la viabilité et le succès des projets d’évolution

Par le passé, et même encore relativement récemment, un projet IT pouvait la plupart du temps avoir comme justifi cation : « On peut le faire ! » ou « Ça a l’air chouette, si on essayait ? » ou encore une ou plusieurs autres raisons internes ayant comme caractéristique commune de ne pas nécessairement être très orientées client.

Cette période d’euphorie a pris fi n et les « projects simplex inutilis » n’ont pas survécu à l’arrivée des politiques de réduction des coûts. Toutefois, ce changement de paradigme n’implique pas forcément la disparition de certaines pratiques impactant la réussite de programmes ou de projets...

Introduction

2

cela empêche aussi de mesurer la réalité de l’amélioration ; il est diffi cile de prouver que les efforts ont porté leurs fruits. Et le risque est fort de piétiner les éléments qui fonctionnaient bien à la base et d’envoyer ad patres les bénéfi ces qui y étaient associés...

Une variation peut aussi consister à ne pas tenir compte de ce qui a déjà été fait lors des précédents (voire énièmes) audits ou projets d’amélioration, et en particulier de ce qui avait été identifi é comme problèmes ou axes d’amélioration.

Les effets peuvent alors être nocifs pour deux types de raisons :

• Le manque de mesure sur l’atteinte des objectifs et le pilotage des actions,

• Le fait que ce genre de fonctionnement génère énormément de frustration et de lassitude chez l’ensemble des parties prenantes, aussi bien pour les équipes IT que pour les utilisateurs fi naux. Une sensation répétée de « déjà vu » mettra à terre la plus énergique et enthousiaste des équipes!

Pour pallier ces problèmes, il est donc indispensable d’avoir une idée précise et détaillée de la situation de départ en termes de maturité, de souffrances, mais aussi de bonnes pratiques et bénéfi ces existants. Tous ces éléments serviront de base référentielle pour le suivi des résultats du programme d’évolution.

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 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 budget spécifi ques prévisionnels.

Les projets de changement nécessitent donc une attention et un engagement spécifi que 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 se 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 planifi cation 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’arrêter à cela 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 ce n’est bien qu’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 »

3

et l’attention spécifi que 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 Mielabelo 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 effi cace 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, celle 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 suffi rait de penser une théorie pour bénéfi cier 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 s’il faut 1 ou 3 chambres, seul le client connait 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 diffi cile de la faire construire uniquement par des ouvriers extérieurs.

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 fi l conducteur garantissant la cohésion de toute démarche d’évolution.

Des exemples concrets : quelques expériences rencontrées…

• Percevoir l’intérêt du projet d’évolution

Un projet d’évolution de la gestion de la maintenance pour une société de transport a connu des diffi cultés à se mettre en place parce que les opérateurs spécialisés n’étaient pas prêts au changement et n’en voyaient pas l’intérêt.

Ils étaient attachés en particulier à leur « bon vieux système » de 20 ans d’âge et ressentaient le nouvel outil et les nouveaux modes de fonctionnement comme une réelle source de souffrance et de perturbation.

En l’absence d’anticipation de ce point par une intégration préalable des acteurs dans la défi nition du nouveau système, l’intégration de ce dernier a nécessité au fi nal une longue période de négociation pour les convaincre de l’employer. Et ce, dans une version adaptée «moins effi ciente mais acceptable» de la façon de fonctionner. Le tout a généré un important retard dans la mise en œuvre du projet et dans la délivrance d’une partie uniquement des bénéfi ces attendus.

• Tout connaître d’un projet d’évolution et obtenir l’engagement du

management dans ce projet

Une compagnie d’assurance avait généré plusieurs projets afi n de régler les manques mis en lumière par plusieurs audits successifs, afi n de se conformer aux règles de l’autorité de régulation.

Les projets ne bénéfi ciaient pas des éléments suivants :

• une cartographie précise entre les causes, les initiatives et les bénéfi ces attendus,• une politique de suivi des avancées pendant le projet et surtout avant et après chaque projet.

4

Du fait de cette absence au cours des différents projets du programme d’évolution global de l’IT, la direction informatique a connu des diffi cultés à se concentrer sur les éléments les plus importants et à savoir ce qu’il restait à faire. Elle a consommé plus de ressources que nécessaires et a dû faire face à une démotivation progressive des équipes et des utilisateurs. La société a également eu des diffi cultés à démontrer la réalité de l’amélioration et de la couverture des règles à l’autorité de régulation.

• Aller au-delà de la simple planifi cation du projet d’évolution et trouver une

méthode cohérente et effi cace pour ce projet

Une société de services a décidé de modifi er certains processus et activités afi n d’améliorer la satisfaction des clients internes.

Une équipe undercover a été constituée, et a commencé à creuser « son propre sillon ». Afi n d’aider l’équipe et de gagner du temps, il a été décidé de faire appel à de l’aide extérieure. Les consultants choisis ont eu comme consigne de fournir un package complet incluant à la fois une forme d’organisation standard « aux avantages prouvés », et des jours d’intervention pour résoudre les petites différences et l’appliquer au contexte client.

Au fi nal, le projet a donc produit un ensemble complet de nouveaux processus avec les activités, les rôles et responsabilités, le tout absolument conforme à ITIL. L’ensemble n’avait aussi et surtout que peu de rapport avec les points spécifi ques de souffrances, ne correspondait pas à la capacité de l’organisation existante à évoluer et à fonctionner, et restait globalement méconnu par les principaux acteurs et parties prenantes qui allaient avoir à vivre avec.

La mise en œuvre effective de l’organisation dessinée resta « relativement partielle » (pléonasme).

5

Conclusion

On concevrait diffi cilement 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éfi ces,

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

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

Non plus, en oubliant d’y affecter des ressources et un budget, ou encore en achetant 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, sont confondus. 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.

Pour pallier ces diffi culté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éfi ces 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 afi n de prendre des décisions à la fois cohérentes théoriquement et tenables en pratique,

• De piloter et 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écifi ques 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).