de ITIL au processus

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 :

1. un périmètre de responsabilité transversal,
2. un pilotage par des indicateurs et des tableaux de bord,
3. 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 » :

1. 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,
   
   
2. 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, …
   
   
3. 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 :

1. Manque d’implication du management,
2. Passer trop de temps sur des processus complexes,
3. Ne pas mettre en place d’instructions écrites et formalisées,
4. Ne pas identifier les propriétaires de processus au sein de la Production,
5. Se focaliser sur la seule performance,
6. Avoir trop d’ambition,
7. Interrompre les efforts,
8. Créer des séparations entre les différences entités de l’entreprise,
9. Ignorer les autres solutions qu’ITIL,
10. 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 :

1. un périmètre de responsabilité transversal,
2. un pilotage par des indicateurs et des tableaux de bord,
3. 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