Périmètre ITSM du projet

2. Périmètre ITSM du projet

2.1. Pourquoi investir sur les connaissances ITSM de l’organisation informatique

Parallèlement à l’approche processus informatiques (mise en œuvre des processus ITIL®), le projet nécessite une approche plus directe sur la mise en œuvre (et la gestion ultérieure) des connaissances ITSM nécessaires pour maîtriser le contenu du catalogue des services informatiques et les niveaux de service fournis.

Les connaissances ITSM font partie des aptitudes de l’organisation à gérer et à optimiser les ressources consommées pour fournir les services d’affaires aux niveaux de service convenus.

Les logiciels ITSM sont focalisés sur les activités opérationnelles des équipes informatiques et les données opérationnelles manipulées. La définition des connaissances de base comme les processus informatiques, l’organisation informatique et le catalogue des services informatiques font traditionnellement partie du paramétrage et de la configuration de ces logiciels. Ils sont vécus comme une étape préliminaire obligatoire avant de pouvoir les utiliser.

De cela découle que cette étape préliminaire doit être traitée le plus rapidement possible afin de commencer l’utilisation opérationnelle du logiciel.

Or, ceci est une erreur fondamentale car le référentiel des connaissances ITSM fait partie des aptitudes de l’organisation informatique à gérer et à optimiser les ressources du fournisseur de services. Mal faire cette étape condamne à ne pas obtenir les résultats attendus de la mise en place d’un outil ITSM.

Le périmètre complet des connaissances ITM d’un fournisseur de services peut être présenté de la manière suivante :



Compte-tenu que d’autres projets existent par ailleurs pour mettre en œuvre les bonnes pratiques ITIL®, il est essentiel que l’ensemble des projets se basent sur le même référentiel de connaissances ITSM afin d’éviter les conflits et les incompatibilités entre les différents projets et, éventuellement, les différents outils logiciels qui seront mis en place dans le cadre de ces projets.

Il est aussi à noter que cette approche permet d’éviter les doublons de conception et qu’une partie du référentiel ITSM définie dans l’un des projets sert aux autres projets en leur permettant de gagner du temps et des ressources.

2.2. Restreindre le périmètre de connaissances ITSM à l’objectif du projet

Afin d’éviter le gaspillage dans la définition de connaissances ITSM qui ne seraient pas utiles au projet, il est nécessaire de restreindre ce périmètre.

Malheureusement, les domaines visibles à mettre en place (catalogue des services informatiques et niveaux de service) imposent pour être efficaces (résultats obtenus conformes aux résultats attendus) la mise en place d’une chaîne de valeur allant profondément dans le référentiel ITSM.

La notion de chaîne de valeur permet de ne pas perdre de vue dans un ensemble de concepts à mettre en œuvre les objectifs du fournisseur de services : faciliter les activités d’affaires et ainsi apporter concrètement de la valeur aux organisations clientes.

En partant de l’objectif primaire (catalogue des services d’affaires et niveaux de service d’affaires), voici la chaîne de valeur qu’il faut analyser, formaliser et gérer :



2.2.1. Organisations d’affaires et processus d’affaires facilités

La présentation claire des services d’affaires et des niveaux de service proposés aux organisations d’affaires nécessitent une classification propre à chaque organisation d’affaires dénuée de toute notion technique.

Les catalogues de services les présentant classés par « matériels », « logiciels » et « applications » par exemple ne permettent pas l’identification claire par les utilisateurs des services informatiques qu’ils peuvent utiliser dans le cadre de leurs activités d’affaires.

La seule classification connue naturellement d’un utilisateur est l’ensemble des activités qu’il réalise. D’une manière plus formelle, chaque organisation d’affaires a des processus dits d’affaires (par distinction des processus informatiques) composés d’enchaînements d’activités d’affaires connues naturellement des utilisateurs connaissant leur métier.

Il est donc nécessaire de référencer l’ensemble des processus d’affaires de chaque organisation d’affaires afin de déterminer la présentation naturelle des services d’affaires pour chaque utilisateur.

De plus, l’identification des processus d’affaires va aussi grandement faciliter une approche structurée de la définition des exigences de niveau de service en se basant sur une échelle de criticité des processus d’affaires facilités.

2.2.2. Services d’affaires et demandes de service

Les services d’affaires doivent évidemment être détaillés dans le catalogue de services. Afin de faciliter le travail des équipes informatiques, les services d’affaires seront rangés selon une classification technique compréhensible des équipes internes. Ce classement technique (« services à base de matériels », « services à base de vidéo-surveillance », « services à base ‘applications », etc. par exemple) sera uniquement visible des équipes informatiques.

Il est aussi nécessaire de référencer les demandes que peuvent faire un utilisateur sur un service informatique : demander à utiliser le service, demander une sauvegarde exceptionnelle des données, etc.

Chaque demande de service doit aussi être présentée dans les vues utilisateurs du catalogue des services et donc être attachée aux processus d’affaires.

2.2.3. Accords de niveau de service

Les accords de niveau de service seront formalisés dans des documents d’accords de niveau de service (SLA).

La rédaction et le suivi de ces documents peuvent se révéler catastrophiques s’ils ne sont pas conçus aussi dans une optique de facilité de maintenance.

C’est pour cela que le référentiel des connaissances ITSM doit contenir la formalisation d’accords-types de niveau de service qui seront des modèles utilisés pour la définition de certains accords de niveau de service. Sur cette notion d’accord-type de niveau de service seront attachées les notions ITIL® d’accords de niveau d’entreprise, d’accords orientés client et d’accords orientés service et structurées de manière à rendre la plus simple possible la maintenance de ces accords.

Les thèmes classiques ITIL® d’un accord de niveau de service sont : la disponibilité (premier thème à travailler), la capacité et la performance, la sécurité et la continuité de service.

Il est possible d’y adjoindre d’autres thèmes émergents selon la sensibilité de l’entreprise. Ainsi, l’organisation informatique peut s’engager sur le développement durable associé à la fourniture d’un service d’affaires et introduire dans l’accord de niveau de service un engagement sur la quantité de CO² produit pour fournir ce service par exemple.

Selon la complexité d’un service d’affaires, il pourra proposer un ou plusieurs ensembles d’engagements sur ces thèmes liés à chaque processus d’affaires servi.

Les demandes de service devront aussi être associées à des niveaux de service. Le thème classique est le délai de réalisation de la demande (ou délai de livraison). Si un engagement de développement durable doit être pris, la notion de quantité de CO² produit pour réaliser la demande pourra être mis en place.

2.2.4. Périmètre sur les services d’affaires et niveaux de service d’affaires

L’ensemble des notions présentées précédemment et leurs liens peuvent être schématisés de la manière suivante :



2.2.5. Services d’opérations

Afin de déterminer des niveaux de service d’affaires réalistes, il faut aussi déterminer les engagements de niveau de service de chacune des équipes internes et des sous-traitants dans la fourniture d’un service d’affaires.

Pour cela, il est nécessaire de décomposer chaque service d’affaires en services d’opérations. Un service d’opérations peut être défini comme étant un ensemble de composants (items de configuration) :

  • exploités par une seule équipe interne ou sous-traitant,

  • supportés par une seule équipe interne ou sous-traitant et

  • gérés par une seule équipe interne ou sous-traitant

L’approche ITIL® France permet d’obtenir le meilleur compromis possible entre le niveau de détail et le volume des données ainsi définies.

Afin de ne pas être dépendant de la définition des processus informatiques basés sur ITIL® et des rôles de processus qui seront liés ensuite aux équipes informatiques, ITIL® France propose un raccourci basé sur un modèle de responsabilité similaire au modèle RACI pour les rôles de processus.

Le modèle AXER permet de recenser facilement les rôles d’opérations (interventions sur un service d’opérations) :

  • A pour Autorité : propriétaire du service d’opérations

  • X pour eXpertise : traditionnellement le niveau 3 pour tous les processus informatiques : incidents, problèmes, conception, disponibilité, capacité, etc.

  • E pour Exploitation : traditionnellement le niveau 2 pour tous les processus informatiques

  • R pour Réceptionnaire : traditionnellement le niveau 1 pour toute requête utilisateur et incident (très souvent le centre de services)

Cette approche facilite aussi la définition optimisée des accords de niveau d’opérations( OLA) et des contrats de sous-traitance (UC).

Cette partie du référentiel peut être schématisée de la manière suivante :



2.2.6. Métiers de l’organisation et organisation du fournisseur de services

Comme pour les rôles de processus, les rôles d’opérations devront être associés à des métiers dans l’organisation informatique et chez les sous-traitants.

Pour cela, il est nécessaire de formaliser les métiers en synthétisant les fiches de poste de chacun des collaborateurs et chez les ous-traitants (au moins ceux visibles de l’extérieur).

Si ces fiches métiers n’existent pas, il est possible d’utiliser le référentiel des métiers de l’informatique édité par le CIGREF (version 2011) pour en extraire des métiers existant dans l’entreprise.

Le lien entre rôles d’opérations et métiers est complexe et segmenté par des domaines de responsabilité (ou domaines de compétences). Cette structuration permet d’associer au même rôle d’exploitant par exemple le métier d’opérateur informatique (organisation informatique) pour les serveurs physiques Windows et Unix et de sous-traitant pour les serveurs virtualisés.

Les métiers sont ensuite attachés à des entités de l’organisation du fournisseur de services. Pour les rôles d’opérations, les métiers liés seront attachés soit à une fonction (organisation interne) ou à un sous-traitant.

Il sera donc nécessaire de préciser les fonctions (au sens ITIL® du terme) de l’organisation informatique et de recenser les sous-traitants intervenant de manière opérationnelle sur les services d’opérations.

Cette partie peut être schématisée de la manière suivante :


2.3. Identifier les personnes ayant les connaissances du périmètre

L’éventail des connaissances à réunir pour élaborer un catalogue des services informatiques et les niveaux de service est très large et composé des personnes suivantes :

  • responsables d’organisations clientes ou personnes de l’organisation informatiques connaissant les processus d’affaires (composante « O » d’une DOSI ou appelé parfois Relations Clients)

  • responsables d’équipes techniques internes ou leurs représentants

  • responsables de sous-traitants (ils peuvent être répartis dans plusieurs équipes informatiques)

  • la DRH ou le service administratif de l’organisation informatique

Sans le concours de toutes ces personnes, au moins un maillon faible sera introduit dans la chaîne de valeur du fournisseur de services et c’est l’ensemble du projet qui ne permettra pas d’aboutir sur les résultats attendus.

Enfin, il est nécessaire de respecter un ordre de formalisation de ces différentes parties du référentiel. Certaines parties pourront être formalisées en parallèle alros que d’autres devront être traitées en séquence.