Accueil

ITIL®

Lean IT

Pratique

Plus

Crédit image : Pixabay

Processus versus procédure : un combat inutile ?

Publié le 25 janvier 2017 par Pascal Delbrayelle

Un processus est souvent présenté comme un "ensemble d’activités structurées conçues pour atteindre un objectif spécifique". Une procédure comme un "document contenant les étapes qui indiquent comment réaliser une activité". Il semblerait donc qu'une procédure fait toujours partie d'un processus et décrit le détail d'une activité de ce processus.

Comme je l'ai vu il n'y a pas longtemps sur le réseau LinkedIn : "J'irai habiter en théorie car en théorie tout se passe bien".

Dans la vraie vie, il y a les partisans des processus et qui mettent en place des outils ITSM par exemple pour l'informatique avec des flux de travail (workflows) et les partisans des procédures avec une documentation opérationnelle pour traiter un bout-en-bout dans une situation particulière.

Qui a tort ? Qui a raison ? L'expérience m'a toujours montré que la réalité était toujours plus nuancée que ce que l'on pense. Le combat processus versus procédure est stérile et doit être remplacée par une approche mixte conciliant les deux.

En général, à quoi sert un processus ?

Pour faire simple, un processus permet initialement à des responsables stratégiques de piloter l'organisation en regroupant les centaines ou milliers d'activités en thèmes qu'il est important de maîtriser et de réussir pour réussir au final la stratégie fixée.

Pour cela, chaque processus se verra attribuer un propriétaire de processus qui aura délégation des directeurs stratégiques pour réussir le fonctionnement du processus. Il lui sera fixé des objectifs et, en retour, devra remonter des informations démontrant la performance du processus. Les directeurs stratégiques les aggrègeront ensuite dans des tableaux de bord du style Balanced Scorecard pour avoir une vue d'ensemble.

Le propriétaire de processus devra ensuite concevoir et mettre en place les différentes activités du processus (parmi beaucoup d'autres éléments). Ces activités seront décrites de manière générique dans la documentation du processus.

Généralement, un objectif de processus peut être rempli par un ou plusieurs enchaînements d'activités.

Un enchaînement d'activités peut appeler un autre processus pour ensuite exploiter le résultat produit (la gestion des problèmes fait une demande de changement pour appliquer le plan d'actions de suppression des erreurs) ou peut déclencher en exception un autre processus (la gestion des événements peut déclencher la gestion des incidents).

En général, à quoi sert une procédure ?

Contrairement à sa définition dans le glossaire ITIL®, une procédure dans la vraie vie ne sert pas uniquement à décrire de manière détaillée l'enchaînement des tâches à l'intérieur d'une activité.

J'ai rencontré chez mes clients beaucoup d'utilisations pratiques d'une procédure pleines de bon sens. En généralisant, voici une définition possible : une procédure est la description opérationnelle d'un enchaînement d'activités permettant de traiter un bout-en-bout opérationnel et spécifique.

Cela ressemble beaucoup à un processus.

Néammoins, ces activités peuvent appartenir à un ou plusieurs processus, s'inscrire dans l'atteinte d'un objectif de processus et peuvent même proposer des variantes pour traiter des cas particuliers de processus. Nous retrouvons nos fameux modèles de processus.

Un cas d'école : la procédure d'incident majeur

J'ai eu à travailler chez plusieurs clients sur des procédures d'incidents majeurs. Ce qui revient systématiquement est que la procédure doit décrire le bout-en-bout des actions à partir du moment où un incident majeur est déclaré.

En essayant de relier cette procédure aux processus ITIL®, j'ai trouvé qu'elle couvrait pas moins de trois processus (en réalité, deux et demi) : la gestion des incidents évidemment, la gestion des problèmes (on en trouve la trace dans le processus) et l'amélioration continue des services !

Les activités décrites dans les processus sont en vert tandis que les activités opérationnelles décrites dans la procédure sont en bleu.

Comme le précise ITIL®, la procédure d'incident majeur est activée dès lors que le calcul de la priorité de l'incident donne la priorité la plus forte.

La caractéristique principale est que le traitement de bout-en-bout est piloté par une cellule de crise (j'ai aussi entendu "task force" et même "war room", même si je pense que c'est un peu excessif pour le dernier terme).

La procédure se déroule en 3 étapes :

  1. Rétablir le système d'information : tout le monde est sur le pont pour tout remettre en état, cela conclut la fin du processus de gestion des incidents

  2. Comprendre ce qu'il s'est passé, identifier les causes et réaliser un plan d'actions à court terme pour que l'incident majeur ne se reproduise pas : nous sommes dans le traitement d'un problème majeur

  3. Proposer un plan d'amélioration à long terme : certaines solutions ne peuvent pas être mises en place en quelques jours et devront passer par un circuit long qui est l'amélioration continue des services, c'est l'objet de la dernière réunion de la cellule de crise (quelques jours après le rétablissement complet du système d'information) où le directeur informatique veut comprendre ce qu'il s'est passé, quelles sont les erreurs dans l'infrastructure qui restent encore à corriger et valider un plan d'actions à long terme.

La dernière étape de la procédure est réalisée par la revue de problème majeur du processus de gestion des problèmes.

Processus et procédure : se respecter mutuellement

Une procédure doit, lorsqu'elle passe d'un processus à un autre, respecter la production des résultats attendus par le processus qu'elle quitte et respecter le déclenchement de l'autre processus (formulaire, etc.).

De plus, si un logiciel ITSM basé sur un moteur de workflow a intégré la procédure, il doit pouvoir calculer les indicateurs de performance d'un processus en se basant sur les activités de la procédure qui sont rattachées au processus, une procédure pouvant donc alimenter les rapports de performance de plusieurs processus.

Plus d'informations dans les ateliers que j'anime pour mes clients.

ITIL® est une marque déposée d'Axelos.