La même prudence et la même approche doivent être de mise dans la mise en place d’un processus particulier.

Il est nécessaire de prendre les bonnes décisions dès la réflexion sur les objectifs et les activités du processus et les choix plus globalement sur le système de gestion qui va concrétiser le processus.

Voyons la rentabilité de chacune des composantes du processus prises isolément :

1. Processus de gestion et de traçabilité

Chaque processus unitaire de gestion et de traçabilité (associé à un objectif du processus) aura un bilan positif ou négatif selon le contexte. Ce qui est sûr c’est qu’il va imposer des contraintes (remplir des documents, tracer ce que l’on fait, etc.), ce qui est un point négatif. Cependant, le formalisme et la traçabilité peuvent parfois faciliter la gestion de ces mêmes activités, d’où quelquefois une composante positive de l’apport de valeur.

2. Outillage

L’outillage a un bilan négatif car il faut soit payer les licences, les formations, la prestation de paramétrage, tous les coûts de matériels ou logiciels associés avec tous les contrats de maintenance associés, soit acheter une prestation complète en mode SaaS.

3. Personnes

Les activités nouvelles et le formalisme des activités existantes imposés par le processus créent des nécessite l’utilisation de personnes supplémentaires pour lesquelles il faut payer les salaires, les charges et tous les éléments associés (bureau, poste de travail, etc.). Cela représente un bilan négatif.

4. Processus de gestion des accès au livrable

Il s’agit là d’activités nouvelles créant une charge supplémentaire.

Cependant, c’est bien là qu’est le gisement de rentabilité d’un processus.

Le bilan des 3 premières composantes est très souvent négatif.

Or, un processus fait partie d’un éco-système (l’organisation avec sa mission) dans lequels les processus interagissent entre eux.

Beaucoup d’interactions sont des consultations d’informations : un processus a, dans le cadre d’une activité, besoin d’une information gérée par un autre processus. S’il est possible de faire gagner du temps dans cette recherche d’information (passer de la demande aux personnes du processus pour fournir l’information à une consultation autonome et rapide par le demandeur), cela fait gagner du temps aux DEUX processus et assure un gain de rentabilité.

Lors de l’élaboration de la gestion des accès au livrable du processus, il est nécessaire d’identifier le maximum de personnes et de processus ayant besoin d’une information dans ce livrable afin d’avoir le plus possible de gains dans la rentabilité du processus.

Lorsque cela est fait correctement, le bilan d’un processus est très souvent positif. Cela dépend en premier lieu de la taille du fournisseur de services : le détail des activités processus de gestion de la stratégie des services informatiques n’a aucun intérêt à être mis en place dans une équipe informatique de 3 personnes !

Lorsqu’une étude préliminaire de maturité de l’organisation a été réalisée, elle a permis d’identifier les processus qui seront rentables à mettre en place. Ensuite, pour chacun de ces processus, il faut concevoir avec soin cette composante d’accès en consultation au livrable du processus avec soin car c’est elle qui permettra d’atteindre le seuil de rentabilité.

Dans tous les cas d’organisation, le processus de gestion du catalogue de services est rentable et sa rentabilité sera assurée par la mise à disposition rapide du contenu du catalogue de services à un maximum de personnes.

La mise en œuvre de la gestion des services informatiques prend du temps (plusieurs mois à plusieurs années) et produit des effets sur le moyen et long terme.

Le schéma peut être interprété selon plusieurs contextes. Prenons le cas de la mise en œuvre des processus ITIL® dans leur ensemble.

Chaque processus sera mis en place mais il ne faut pas voir un processus comme quelque chose de figé et d’immuable. Ils suivent les mêmes règles (et les mêmes aléas) que les logiciels et applications : il faut gérer des versions de processus, des corrections mineures, etc.

Le principal moteur de cette mécanique est l’ACS (amélioration continue des services).

Très souvent, il est nécessaire de respecter le cycle de vie des services dans la mise en œuvre des processus ITIL® : commencer d’abord par une première version des processus de SS (stratégie des services), puis par une première version des processs de CS (conception des services) et ainsi de suite avec les autres étapes de TS (transition des services) et ES (exploitation des services).

Une fois la première version des processus en place, il faut recommencer en sortant une version 2 des processus et ainsi de suite.

Après un certain nombre d’itérations pouvant durer plusieurs années, l’ensemble arrive à un état méta-stable piloté par l’amélioration continue des services.

Malheureusement, bien des grains de sable (des fois de gros rochers) peuvent se mettre en travers de cette route.

Il faut bien comprendre deux évolutions :

• la contribution au business et le ressenti des clients sur la qualité de l’informatique commence à augmenter assez rapidement dès lors que des processus de transition et d’exploitation sont en place ; elle augmente jusqu’à arriver à une limite

• la profitabilité du projet ne sera pas positive avant plusieurs itérations du cycle de vie ; elle commence même par être négative ; l’amélioration continue des services est essentielle dans la forme de la courbe

Seule l’amélioration continue des services permet d’espérer un jour de faire repasser par zéro la rentabilité négative de début de projet. Certaines organisations se sont lancées dans de tels projets sans se connecter à une direction qualité pour gérer l’amélioration continue des processus mis en place. Le résultat est inévitable :

• dans les meilleurs cas, la courbe finit par repasser en positif au bout de très longtemps (plusieurs années)

• dans les pires cas, elle ne repasse jamais en positif

Bien souvent, le responsable de l’organisation informatique constate qu’au bout de deux ou trois ans, la mise en place des processus ITIL® n’apporte pas grand-chose, à part beaucoup de factures à régler et prend la décision d’arrêter le projet.

Un processus, quel qu’il soit, est d’abord défini par un but global s’inscrivant dans la mission de l’organisation (pour une direction informatique par ex., il s’agit de fournir des services informatiques).

Le but du processus doit être clair et permet de voir clairement ce qu’on y fait comme activités à l’intérieur du processus.

Ensuite, dans la définition du processus, il est nécessaire de lui assigner un certain nombre d’objectifs précis qui permettront dans leur globalité de respecter le but du processus. Chaque objectif, pour simplifier, sert à préciser l’objectif de chaque traitement réalisé dans le processus.

A la base, le processus est un « ensemble structuré d’activités ». Il ne s’agit pas de voir un processus (notamment un processus ITIL®) comme un « enchaînement d’activités » pouvant être concrétisé par un traitement de flux (workflow) dans un outil spécialisé.

En revanche (et pour simplifier), un objectif du processus peut être vu comme étant l’objectif d’un workflow. La définition des objectifs d’un processus est une étape intermédiaire pour développer l’ensemble des workflows nécessaires pour atteindre le but du processus.

Sur le schéma, un workflow est présenté sous la forme d’un processus unitaire.

Pour comprendre la définition de chaque processus ITIL®, il est nécessaire de voir le processus ITIL® comme étant défini de manière opérationnelle par un système de gestion (Management System).

Ce système de gestion comprend la mise en place des processus unitaires dans un outil de gestion (logiciel généralement).

Il est aussi nécessaire de tracer toutes les activités réalisées dans le processus (enregistrements) et de gérer de manière stucturée tous les documents et livrables produits par les activités du processus.

Traditionnellement dans ITIL®, chaque processus a son livrable global appelé xxDB (CMDB dans le cas de la gestion des configurations et des actifs de service par ex.). Il contient l’ensemble des documents et enregistrements produits par le processus.

Cette première étape de centraliser tous ces documents et enregistrements est nécessaire (combien de fois cherchons-nous un document précis sur le réseau et, une fois trouvé, nous posons-nous la question : est-ce bien la dernière version ?). Mais elle n’est pas suffisante.

Chaque processus ITIL® contient un objectif précis un peu particulier qui est de faire partager à un maximum de personnes le contenu de ce livrable global (enfin, à celles qui sont autorisées à consulter les informations contenues dans ce livrable, attention à la confidentialité des données).

Les informations stockées dans ce livrable servent au quotidien aux acteurs du processus mais peuvent aussi servir à d’autres personnes dans le cadre de leurs activités dans d’autres processus. Ces personnes peuvent faire partie de l’organisation informatique mais peuvent aussi être des clients et des utilisateurs.

Il est donc nécessaire d’ouvrir le livrable global à la consultation par des personnes extérieures au processus et de gérer les accès aux différents documents et enregistrements du livrable global. Il s’agit d’assurer les mêmes fonctions que celles couvertes par un outil de gestion documentaire.

Nous verrons par la suite que, loin d’être anecdotique, cette partie du processus sera celle qui permettra bien souvent de rentabiliser les investissements nécessités par la mise en place opérationnelle du processus.

La gestion du catalogue de services est particulièrement concerné par cette manière d’aborder sa rentabilité.

Depuis l’apparition de l’informatique de gestion, les technologies permettent de développer et de gérer des applications qui correspondent aux besoins fonctionnels des utilisateurs.

Or, aujourd’hui, fournir une application parfaitement adaptée aux besoins des utilisateurs n’est plus suffisant. Le contexte des clients a changé et doit s’adapter à une concurrence de plus en plus grande, la mondialisation, la baisse des prix et une demande de plus en plus exigente de la part des clients finaux.

L’informatique doit faire le constat que fournir des applications en respectant un cahier des charges fonctionnel n’est plus suffisant. Elle doit maintenir fournir une prestation globale autour de ces applications et garantir que l’application sera utilisable dans des conditions acceptables lorsqu’un utilisateur a besoin d’utiliser l’application dans le cadre de ses propres activités.

Il est alors nécessaire de définir le terme « service informatique » comme un service fourni par l’informatique. Service est à prendre au sens prestation et l’informatique doit fournir des prestations informatiques.

Du point de vue de celui qui reçoit (le client et l’utilisateur, nous verrons plus tard la différence entre ces deux termes), le service doit lui apporter quelque chose de positif (ce quelque chose est appelé valeur). Au final, un service doit fournir de la valeur directement aux clients de l’entreprise (ou de l’organisation dans son ensemble) ou indirectement par l’utilisation du service informatique par les organisations métiers dans l’organisation qui, par leux activités quotidiennes, vont apporter de la valeur aux clients de l’organisation.

Le service perçu par un client doit d’abord être défini par son apport de valeur, avant même les fonctionnalités ou les niveaux de service.

Du point de vue de celui qui fournit (le fournisseur informatique), le service sera complet (et optimum en apport de valeur pour les clients) par un équilibre (compliqué à atteindre d’ailleurs) entre technologies utilisées, processus pour gérer la prestation (incidents, changements, etc.) et personnes (les équipes informatiques qui gèrent les technologies et qui interviennent dans les processus). Le tout à un coût raisonnable (le niveau de qualité de service le plus haut sera défini par le prix que le client est prêt à payer pour utiliser le service en toute sérénité.