de ITIL au processus
Il est toujours extrêmement risqué de se tromper de nature de projet : choisir ITIL est avant tout une initiative forte de management au sein d’une DSI. Présenté souvent comme la simple mise en œuvre d’un référentiel de « bonnes pratiques » - ou pire comme le déploiement d’un progiciel - un projet ITIL est surtout un projet de conduite du changement.
Entre deux verres …
Lors de notre première soirée ADELI « Autour d’un
verre », Thierry CHAMFRAULT nous rappelait l’importance à accorder à la
gestion des ressources humaines, notamment dans les métiers parfois ingrats de
la production et du support informatique.
Notre seconde soirée était consacrée à la notion de
processus. Didier DUSSARD a animé un vif débat autour de l’orientation client
des processus opérationnels et de support.
De mon point de vue, ces deux thèmes sont liés : ITIL
préconise – comme par ailleurs plusieurs démarches présentes dans l’ODOScope
telle Cobit, CMMi, … - une approche de management par processus.
Mais de quoi parle-t-on ? BPMS.info a publié les
résultats de son enquête 2005 sur le management par processus (200 projets).
Dans le résumé disponible sur le site web, on peut retenir les quatre points
suivants :
- La démarche est reconnue comme un enjeu majeur pour toute l’entreprise,
- Les notions de cartographie de processus sont à peu près maîtrisées par les projets (même si l’ADELI constate l’existence de marges de progrès conséquentes),
- Les autres concepts moins « techniques » restent bien moins bien compris,
- Les principales difficultés des projets restent malheureusement classiques : des périmètres et objectifs mal définis, un accompagnement du changement insuffisant.
L’adoption de référentiels comme ITIL par les DSI ne doit pas être un prétexte : l’amélioration durable des services rendus aux clients ne se contentera pas de la lecture d’un ouvrage ou de la participation à une formation.
Le contenu du référentiel ITIL facilite l’élaboration de la
cartographie des processus. Mais pour s’engager dans une telle démarche, il
faut aborder aussi les questions habituelles de l’organisation et du
management : les périmètres de responsabilité, les circuits de décision, les
personnes et leurs comportements.
J’identifie trois innovations majeures dans le management
par processus :
- un périmètre de responsabilité transversal,
- un pilotage par des indicateurs et des tableaux de bord,
- un Comité de processus, instance de coordination et de décision.
Savoir mettre en place ces trois dispositifs, progressivement et de manière coordonnée, est un facteur critique de succès. Le référentiel ITIL et la cartographie des processus sont des étapes d’un projet dont l’objet est d’instaurer une autre façon de voir l’activité et son management. Il ne faut pas confondre les moyens et la fin.
ITIL : un
accélérateur de valeur ajoutée
Les
enjeux d’ITIL résident dans la maîtrise des services fournis aux
utilisateurs : les applications en production représentent leur outil de
travail. Les DSI y consacrent entre 50% et 80% de leur budget, en fonction de
leurs plans de développement et du modèle d’imputation.
ITIL est un référentiel de « bonnes pratiques »
qui couvre essentiellement les métiers de la production informatique et du
support. Un langage commun s’impose de fait à toutes les entreprises
(prestataires, fournisseurs, clients) en termes de vocabulaire, de périmètre
d’activité, d’articulation de processus.
Les DSI en avaient vraiment besoin et se l’approprient très
rapidement. C’est très bien pour tout le monde, on va pouvoir se parler sur des
bases solides. Les Directions métier et la Direction Générale vont voir se
formaliser leurs exigences et les niveaux de services qu’elles demandent,
qu’elles obtiennent, qu’elles financent. Les informaticiens vont faire
progresser leurs pratiques et se professionnaliser.
Néanmoins, les auteurs – des professionnels du métier –
savent que « best practice » ne veut pas dire « one best way ». ITIL ne
préconise donc pas de modèle d’organisation.
Dans l’élaboration d’une cartographie, on peut considérer
qu’on dispose immédiatement d’une couverture fonctionnelle très complète en
termes de processus, d’activités, d’indicateurs.
Ceux qui ont déjà eu le plaisir de cartographier une
organisation savent que cet apport de contenu fonctionnel représente une valeur
ajoutée extrêmement importante. Le référentiel ITIL va donc permettre
d’accélérer la démarche de transformation.
Pour la mise en œuvre, ITIL recommande le pragmatisme, l’efficacité, la pertinence par rapport au contexte et aux priorités. Un diagnostic permet donc de déterminer les processus prioritaires dans la mise en place d’ITIL.
Ceux qui ont déjà contribué à faire évoluer une organisation
savent que cela constitue un bon début.
« modéliser
n’est pas organiser »
Une cartographie de processus reste un outil formidable pour
se poser des questions. Encore faut-il vouloir :
- se les poser réellement,
- évaluer l’enjeu des réponses possibles (scénarios),
- avoir mobilisé des décideurs pour y répondre et mettre en œuvre les préconisations.
Comme chaque organisation possède ses particularités, ses
contraintes et même son histoire, des scénarios restent à élaborer.
Prenons un exemple théorique mais simple, comme le
traitement des incidents. ITIL distingue trois activités relatives au processus
de gestion des incidents que je propose de nommer « de la réception d’un
appel … jusqu’à sa clôture » :
- le « groupe d’intervention » que je préfère nommer
« gérer la relation utilisateur » est chargé de recevoir et
qualifier l’appel, de piloter la résolution et d’informer régulièrement
d’utilisateur jusqu’à la clôture,
- la « gestion des incidents » qui instruit à chaud l’incident
en fonction de la criticié et en s’appuyant au mieux sur les erreurs déjà connues :
résolution, contournement temporaire, …
- la « gestion des problèmes » qui gère le référentiel des erreurs connues et qui détermine à froid les actions de progrès et leur priorité
Une première vague de scénarios interroge le degré de
spécialisation verticale de l’organisation : le groupe d’intervention ne
fait-il que distribuer des tickets d’incident ? Doit-on prévoir plusieurs
niveaux de compétences en résolution d’incident ? Les experts
n’interviennent-ils que sur les nouveaux problèmes à qualifier ? …
Une seconde vague de scénarios ausculte les opportunités de
spécialisation horizontale : faut-il un groupe d’intervention par pays ou
par langue ou par filiale ou par site ? Traite-t-on les VIP ou les
commerciaux avec les mêmes équipes que les gestionnaires ? Doit-on
spécialiser par domaine applicatif ou technologique ? …
Pour secouer un scénario, l’Hexamètre de Quintilien (I siècle après JC) reste une « bonne pratique » : qui, quoi, où, avec quels moyens, pourquoi, comment, quand. On peut lui préférer la version anglo-saxonne des 5W2H qui sonne plus moderne : Why, What, Where, When, Who, How, How much. Personnellement, j’apprécie surtout la variante japonaise qui introduit le « Pourquoi » comme une seconde dimension, transversale :
La réalité sera certainement à l’intersection de ces points
de vue, et les critères à surveiller comprennent la performance attendue du
processus (les niveaux de service), les volumes à traiter, les moyens
envisageables en quantité et en qualité (dont les niveaux de compétence et de
motivation).
Un peu de créativité, d’expérience et beaucoup de bon sens produisent
souvent deux ou trois scénario possibles, avec leurs avantages et leurs inconvénients.
Le Comité de pilotage (qu’on aura mobilisé lors du lancement !) aura l’autorité
et la légitimité pour décider de la cible et de la trajectoire d’évolution.
Le scénario retenu sera cartographié, détaillé, voire
outillé. Les actions de conduite du changement peuvent alors être qualifiées en
fonction de l’impact des évolutions envisagées. Outre les actions de formation
et d’accompagnement, les actions de communication apporteront aux intéressés du
sens au projet : pourquoi on le fait, comment on le fait, et avec qui.
Peut-on considérer qu’il suffit d’appliquer cette démarche successivement
sur chaque processus pour considérer qu’on a fini le mettre en œuvre
ITIL ? La réponse est non.
Le
management par processus ? des processus, du management.
Quelque soit l’intérêt du
référentiel retenu, le principal enjeu est de faire évoluer efficacement tous
les collaborateurs d’une organisation. Les témoignages sur les risques d’échecs
de tels projets convergent sur ce point.
Par exemple, l’article « ITIL : Les dix causes d’échec » de
Malcolm Fry [1]
mentionne :
- Manque d’implication du management,
- Passer trop de temps sur des processus complexes,
- Ne pas mettre en place d’instructions écrites et formalisées,
- Ne pas identifier les propriétaires de processus au sein de la Production,
- Se focaliser sur la seule performance,
- Avoir trop d’ambition,
- Interrompre les efforts,
- Créer des séparations entre les différences entités de l’entreprise,
- Ignorer les autres solutions qu’ITIL,
- Ignorer toutes les composantes ITIL.
A propos d’effort (point 7), l’auteur constate qu’une
« implémentation complète d’ITIL demande entre trois et cinq ans, ce qui
est long ». A propos d’ambition (point 6), il rappelle que « les DSI
ont trop tendance à penser qu’ITIL est un aboutissement alors que, au
contraire, ce n’est qu’un début ». Mais le début de quoi ?
Les quelques expériences vécues dans différents contextes
m’amènent à penser que le management par processus nécessite trois éléments
indispensables dont les mises en œuvre doivent être coordonnées pour être
compréhensibles et efficaces :
- un périmètre de responsabilité transversal,
- un pilotage par des indicateurs et des tableaux de bord,
- un Comité de processus, instance de coordination et de décision.
La majeure partie des organisations sont basées sur une décomposition fonctionnelle, et parfois géographique ou/et technologique. Les structures en place gèrent « verticalement » une ou plusieurs activités et les ressources associées.
Ces structures capitalisent des savoir-faire qui génèrent
des gains de productivité. Il est admis que ce type d’organisation plus ou
moins « taylorienne » ne peut pas s’auto-reconfigurer rapidement pour
répondre aux exigences croissantes et mouvantes des clients.
L’approche par processus d’ITIL découle de son orientation «
client ». Le périmètre de responsabilité à définir couvre l’exécution d’un
processus de bout en bout, représenté par sa cartographie. La « voix du
client » et la responsabilité des articulations et des interfaces sortent
du no man’s land, enfin !
Le premier principe de la systémique s’applique pleinement :
le tout est plus que la somme des parties, les articulations sont au moins aussi
importantes que les composantes. Les individus de chaque structure ne sont pas directement
remis en cause, mais leurs managers les considèrent comme un ensemble. Ils
doivent alors apprendre à s’ajuster mutuellement, à se coordonner en
permanence.
Un processus devient un objet de management, lié à un
résultat visible par le client. La performance recherchée doit être régulière
et économiquement maîtrisée. Le pilotage par la performance doit s’appuyer sur
des indicateurs reconnus par tous, dans leur compréhension et leur modalité
d’obtention.
Les premiers indicateurs à mettre en place doivent être
représentatifs des résultats, et non ceux des moyens qui sont plus facilement
disponibles par les dispositifs techniques ou organisationnels en place. D’où
l’importance accordée par ITIL à la gestion des contrats de service.
Une fois encore, la systémique et la carte du processus nous
fournissent de bons points de départ : les indicateurs de résultats
qualifient les interactions majeures entre le processus et ses clients.
N’oublions pas qu’en matière de qualité de service, les
qualiticiens prévoient deux démarches distinctes dans leur mise en œuvre bien
que complémentaires dans leurs objectifs finaux.
La démarche de certification de service vise à formaliser
les critères d’un « bon service rendu » vu du client et de s’engager
sur ce résultat. Les démarches qualité de type Iso 9000 considèrent d’abord que
la maîtrise du processus est le levier prioritaire. Les mesures d’amélioration
continue permettront à terme de livrer un bon service quand on contrôlera les
tenants et aboutissants du processus.
ITIL procède de ces deux approches : quelle
organisation pour quels niveaux de service, et inversement. C’est un problème classique
de « poule et d’œuf » qu’il est toujours délicat d’initialiser et
quasiment impossible à résoudre sur un seul cycle.
Pour incarner les principes d’amélioration continue, le
management par processus requiert un dispositif d’animation. Son instance
principale, présidée par le responsable de processus, est le Comité de
processus. Il réunit les responsables des structures intervenant transversalement
sur le processus.
L’existence d’un espace de concertation permet de rendre les
arbitrages en commun, d’agir avec souplesse dans la complexité. Nous sommes
alors loin d’une vision un peu « mécaniste » de l’organisation.
L’univers de ces managers est complexe et mouvant, leurs
contraintes et objectifs aussi. Il faut accepter la réalité du quotidien. La
cohérence des priorités et directives du moment, données à chacun d’eux, n’est
pas assurée par une instance supérieure, omnisciente.
Ils doivent « faire avec » et négocier entre eux
en fonction de leurs marges de manœuvre et des intérêts bien compris pour leur
entreprise. Même si des arbitrages à un niveau supérieur restent possibles, ils
doivent rester l’exception. C’est d’ailleurs un indicateur à surveiller.
A ce stade, on comprendra donc que la mise en œuvre d’ITIL
requièrent un peu de temps et nécessite un accompagnement du changement.
Évidemment, on peut se contenter d’élaborer une cartographie
de processus et lui ajouter une batterie d’indicateurs. C’est plus simple, mais
adresse-t-on alors les vrais enjeux ? Qu’espère-t-on comme résultat ?
Du dynamisme, de l’implication, des propositions, de la prise de
responsabilité, des performances concrètes et mesurables, …
La DSI doit-elle rester dans sa tour d’ivoire ?
Dans les années 90, les entreprises se sont massivement
lancée dans des démarches qualité. Il suffisait de « écrire ce qu’on
faisait et de faire de qu’on avait écrit ». Hors, tout groupe de travail
digne de ce nom cherche à améliorer l’organisation. Les projets qualité qui ont
réussi à se transformer en projet d’organisation ont parfois réussi, les autres
ont essentiellement produit de la documentation qualité.
Les dix causes d’échec sur ITIL se retrouvent dans toute
démarche de mise en place de nouveaux modes de management ciblant le paradoxe
d’une exigence d’agilité croissante dans un univers de plus en plus complexe.
La DSI les connaît bien puisqu’elle les voit régulièrement s’étendre
dans l’entreprise quand elle déploie les systèmes d’information auprès des « métiers »,
leurs clients. Faute de les identifier, elle ne les reconnait pas toujours.
L’industrialisation des services IT se réduit-il à
l’application tardive des concepts du taylorisme du siècle dernier ? La
DSI serait-elle encore isolée dans une tour d’ivoire, qu’il faut prendre
d’assaut ? Pourquoi les personnes qui travaillent dans la DSI doivent-elles
être isolées des évolutions récentes sur le management ?
Il me semble au contraire que la DSI doit en être à la
pointe. Par nature, son action est transversale car l’information circule
partout, ses clients – internes - deviennent de plus en plus exigeants, ses
préoccupations sont complexes et mouvantes, on lui demande d’innover et d’être
agile.
La DSI doit se servir des référentiels comme ITIL (Cobit,
CMMi, …) pour enrichir ses réflexions d’organisation, pérenniser ses acquis,
accélérer sa transformation. Elle doit se méfier des solutions toutes faites
qui ne mettent en avant que des dispositifs formels au risque d’occulter la
vraie nature du projet : la conduite du changement.
Alain GUERCIO
[1] spécialiste de la méthodologie ITIL et consultant indépendant pour BMC Software, article paru dans CIO Juin-juillet 2005
Alain GUERCIO représentera l’ADELI le 5 avril 2006 après-midi dans le cadre des prochaines rencontres du management de projet sur le thème « Risque et Enjeux de la conduite du changement »