la pratique de l'itsm elaborer un catalogue de services

La pratique de l’ITSM

Elaborer un catalogue de services

Création : mars 2012 Mise à jour : mars 2012

2

A propos

A propos du document Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL et d'autres référentiels dans des directions informatiques en France au travers des missions qui me sont confiées depuis 2004. Il est mis à la disposition de la communauté francophone ITIL pour diffuser quelques conseils et notes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels. Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l'auteur Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production. Ces projets requièrent :

la connaissance des différents métiers du développement et de la production informatique

la pratique de la conduite de projets techniques de la direction informatique

la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter les méthodes de travail au sein de la direction informatique

A propos de mission et de formation Si vous pensez que l’expérience de l’auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n’hésitez pas à le contacter pour toute question ou demande :

par mail : [email protected]

par téléphone : +33 (0)6 61 95 41 40 Quelques exemples de mission :

Modélisation simple des processus de gestion des changements, des projets et des mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances

Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL

Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL

3

Table des matières 1. Termes utilisés dans le document .......................................................................................................... 5

1.1. Accord de niveau de service ........................................................................................................... 5

1.2. Accord de niveau opérationnel ....................................................................................................... 5

1.3. Contrat de sous-traitance ................................................................................................................ 5

1.4. Demande de service ....................................................................................................................... 5

1.5. Processus d’affaires ....................................................................................................................... 5

1.6. Rôle ............................................................................................................................................... 6

1.7. Service d’affaires ........................................................................................................................... 6

1.8. Service d’opérations ....................................................................................................................... 6

1.9. Unité d’affaires .............................................................................................................................. 6

2. Périmètre ITSM du projet ..................................................................................................................... 7

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

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

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

2.2.2. Services d’affaires et demandes de service .............................................................................. 8

2.2.3. Accords de niveau de service................................................................................................... 8

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

2.2.5. Services d’opérations .............................................................................................................. 9

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

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

3. Objectifs du projet .............................................................................................................................. 11

4. Synoptique du processus de mise en oeuvre ........................................................................................ 13

5. Etape 1 : préparer le déroulement du projet ......................................................................................... 15

4.1. Préparer et animer la réunion de lancement .................................................................................. 16

4.2. Analyser les documents existants ................................................................................................. 18

4.3. Former les acteurs du projet aux concepts généraux ..................................................................... 18

4.4. Installer le logiciel PiloTI en production....................................................................................... 20

6. Etape 2 : élaborer la version initiale du catalogue des services informatiques ...................................... 22

5.1. Lancer l'étape ............................................................................................................................... 23

5.2. Elaborer les vues clientes du catalogue de services d'affaires ........................................................ 23

5.3. Elaborer le catalogue de services d'affaires ................................................................................... 23

5.4. Elaborer le catalogue des services d'opérations ............................................................................. 24

5.5. Elaborer le catalogue de l'organisation et des métiers ................................................................... 25

5.6. Rattacher les différentes parties du catalogue ............................................................................... 25

5.7. Publier le catalogue de services .................................................................................................... 26

4

5.8. Clôturer l'étape du catalogue de services ...................................................................................... 26

7. Etape 3 : élaborer la version initiale des niveaux de service................................................................. 27

6.1. Préparer le déroulement du processus ........................................................................................... 27

6.2. Dérouler le premier cycle de la gestion des niveaux de service ..................................................... 28

5

1. Termes utilisés dans le document Cette partie donne la définition des termes techniques utilisés dans le document. La définition de certains termes est directement issue du glossaire ITIL V3 français, d'autres définitions sont issues du glossaire de l'outil PiloTI. Pour des raisons de mise en oeuvre concrète du référentiel ITIL, certaines notions conceptuelles doivent être adaptées au monde réel afin d’éviter des délais de mise en oeuvre trop longs ou des résultats réels obtenus trop faibles et différents des résultats attendus théoriques. En raison de cette prise de position décalée par rapport au référentiel ITIL, certains termes ITIL ont dûs être adaptés et d’autres termes inédits sont définis ici.

1.1. Accord de niveau de service Accord entre un fournisseur de services et un ou plusieurs clients sur la garantie de fonctionnement d’un ou de plusieurs services d’affaires destinés aux utilisateurs qui sont représentés par ces clients. Il porte sur des critères de disponibilité, de capacité, de sécurité et de continuité des services d’affaires pour ces clients. Il comprend la manière de mesurer l’atteinte des objectifs de niveau de service (indicateurs). Note : dans le logiciel PiloTI, l'accord de niveau de service lie un seul service d'affaires à un processus d'affaires et un client. Les niveaux de service peuvent être spécifiques ou être basés sur ceux d'un accord-type de niveau de service.

1.2. Accord de niveau opérationnel Accord entre la direction du fournisseur de services et une équipe dans son organisation sur la garantie de fonctionnement d’un ou de plusieurs services d’opérations afin de garantir le fonctionnement des services d’affaires basés sur ces services d’opérations conformément aux accords de niveau de service. Il porte sur des critères de disponibilité, de capacité, de sécurité et de continuité des services d’opérations pour ces services d’affaires. Il comprend la manière de mesurer l’atteinte des objectifs de niveau de service (indicateurs). Pour une équipe dans l’organisation, l’accord se limite aux responsabilités de cette équipe sur le service d’opérations.

1.3. Contrat de sous-traitance Accord entre la direction du fournisseur de services et un sous-traitant sur la garantie de fonctionnement d’un ou de plusieurs services d’opérations afin de garantir le fonctionnement des services d’affaires basés sur ces services d’opérations conformément aux accords de niveau de service. Il porte sur des critères de disponibilité, de capacité, de sécurité et de continuité des services d’opérations pour ces services d’affaires. Il comprend la manière de mesurer l’atteinte des objectifs de niveau de service (indicateurs). Pour un sous-traitant, l’accord se limite aux responsabilités du sous-traitant sur le service d’opérations.

1.4. Demande de service Demande d’un utilisateur pour obtenir un résultat convenu sur un service d’affaires (commande du service, traitements associés au service, etc.) ou bénéficier d’un changement standard (changement pré-approuvé présentant peu de risque et récurrent). Les demandes de service sont détaillées dans le catalogue des services d'affaires.

1.5. Processus d’affaires Processus dont la propriété et l’exécution sont du domaine de l’unité d’affaires. Un processus d’affaires contribue à la fourniture d’un produit ou d’un service à un client de l’unité d’affaires. Par exemple, un revendeur peut avoir un processus d’achat qui contribue à fournir des services à ses clients externes (sa clientèle). De nombreux processus d’affaires dépendent des services informatiques.

6

1.6. Rôle Fait référence à un ensemble de comportements et de responsabilités sur des activités d’un processus, un livrable ou un service d'opérations. Un rôle est associé à des métiers (les personnes de ces métiers jouent ce rôle) et des comités de l'organisation (ces comités jouent ce rôle).

1.7. Service d’affaires Prestation fournie pour répondre aux besoins d'affaires des clients selon un engagement préalablement négocié avec eux. Cet engagement inclut l’utilité (partie fonctionnelle) et la garantie (partie niveau de service) du service. D'une manière plus globale, le service d'affaires est un moyen de fournir une valeur à des clients en facilitant les résultats que les clients veulent obtenir sans qu'ils aient à gérer directement le détail des coûts et les risques liés aux composants techniques. Concrètement, chaque unité d'affaires ayant besoin de ce service d'affaires verra les informations qui l'intéresse (publiées dans le catalogue de services) et l'utilisera dans le cadre d'un ou plusieurs accords de niveau de service (SLA). Le fournisseur de services, de son côté maintiendra toutes les informations destinées à l'ensemble de ses clients et se conformera aux niveaux de services validés dans l'ensemble des accords.

1.8. Service d’opérations Ensemble de prestations fournies par les équipes internes du fournisseur de services et par ses sous-traitants sur un ensemble de ressources techniques en production. Un service d'opérations peut être utile dans la fourniture d'un seul service d'affaires (service d'opérations dédié), plusieurs services d'affaires (service d'opérations partagé) ou une majorité de services d'affaires (service d'opérations commun ou de base). Un service d'opérations est avant tout une notion technique : serveur informatique, réseau, application, environnement de virtualisation ou bases de données par exemple. Les équipes internes et les sous-traitants interviennent dans la gestion opérationnelle du service d'opérations dans le cadre respectivement d'accords de niveau opérationnel (OLA) et de contrats de sous-traitance (UC). Les responsabilités de base des intervenants sur un service d'opérations sont : l'exploitation, la réception des incidents et des requêtes, l'expertise et l'autorité (propriétaire du service d'opérations). Un service d'opérations est associé à une et une seule entité (équipe interne ou sous-traitant) pour chaque responsabilité de base.

1.9. Unité d’affaires Entité d’organisation interne ou externe d’utilisateurs et de clients ayant ses propres objectifs, stratégies, plans, métriques, recettes et coûts. Chaque unité d’affaires possède ses actifs propres et les utilise pour créer de la valeur pour ses clients sous la forme de biens et de services.

7

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 oeuvre 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 oeuvre 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.

8

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 oeuvre 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.

9

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

10

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.

11

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.

3. Objectifs du projet Les objectifs principaux du projet sont les suivants :

élaborer le catalogue des services d’affaires et des services d’opérations dans son intégralité, y compris les modèles de document

élaborer les niveaux de service sur un premier périmètre, y compris les modèles de document

assister les équipes opérationnelles dans l’élaboration des niveaux de service sur un second périmètre

transférer les connaissances de l’équipe projet vers les équipes opérationnelles pour qu’elles intègrent les mises à jour du catalogue de services et des niveaux de service dans les projets (méthodologie projet si elle existe) et la transition des services, notamment par l’utilisation du logiciel PiloTI

L’objectif secondaire du projet est le suivant :

12

permettre au chef de projet interne d’acquérir l’expertise nécessaire à la conduite d’un projet ITSM (s’il ne l’a pas déjà)

Les objectifs de l’accompagnement de l’équipe projet dans l’atteinte de leurs propres objectifs sont les suivants :

piloter le projet

former l’équipe projet aux notions ITSM nécessaires à la réalisation du projet

assister l’équipe projet dans les différentes étapes du projet

former les équipes opérationnelles sur le travail à réaliser dans la future gestion du catalogue des services et des niveaux de services

assister les équipes opérationnelles dans la future gestion du catalogue des services et des niveaux de service pendant les étapes du projet où cette gestion est mise en place

13

4. Synoptique du processus de mise en oeuvre Le processus de mise en oeuvre du catalogue et des niveaux de service peut être représenté sous la forme du synoptique suivant :

15

5. Etape 1 : préparer le déroulement du projet Ce processus permet de préciser les objectifs du projet et les objectifs éventuels de l'accompagnement et de réaliser toutes les actions relatives au lancement du projet et à la montée de compétence initiale de l'équipe projet. Il s'incrit dans un projet de mise en oeuvre d'un périmètre ITSM et en représente la première étape. L'enchaînement-type des activités détaillées ci-dessous pourrait être le suivant :

16

Un exemple de calendrier-type pourrait être le suivant :

4.1. Préparer et animer la réunion de lancement La réunion de lancement n'est pas seulement une occasion de réunir tout le monde et de s'auto-congratuler sur le lancement d'un projet ITSM au sein de l'organisation informatique. Elle sert à bien communiquer les objectifs du projet, les résultats attendus, le périmètre (et le hors-périmètre), le pilotage du projet, l'équipe projet et le calendrier prévisionnel. Pour bien se représenter ce dont il s'agit, il faut bien comprendre qu'un projet ITSM reste avant toute chose un projet qui doit être traité comme tel. Si une méthodologie projet est déjà en place dans l'organisation informatique, il est important pour limiter les risques du projet de bien appliquer cette méthodologie d'autant plus qu'il ne s'agit pas d'un projet mineur car il va toucher au fonctionnement de l'organisation informatique et à la culture du personnel informatique. Bien sûr, certains modèles de document de la méthodologie projet devront être adaptés à la nature particulière d'un projet ITSM.

4.1.1. Préciser le dimensionnement du projet (réunion)

Parce qu'un projet ITSM a dû être présenté auparavant à un comité de direction pour y obtenir le feu vert et surtout le budget, il a fait l'objet d'une approche macro en ce qui concerne la charge de travail à réaliser et le calendrier prévisionnel. Avoir avoir été validé par le comité décisionnaire, il est nécessaire en premier lieu de revoir les estimations de charge et de calendrier et de bien dimensionner l'équipe projet.

17

L'utilisation du modèle de référentiel ITSM du logiciel PiloTI permet de simplifier ce dimensionnement en ayant une vue concrète des informations qu'il va falloir renseigner (fiches de processus informatique, fiches de service d'affaires, etc.) en complément d'une feuille Excel permettant de calculer rapidement la charge de travail à partir d'hypothèses sur la volumétrie (nombre d'unités d'affaires, nombre de services d'affaires, nombre de demandes de service, etc.).

4.1.2. Définir et rédiger le plan projet détaillé

Le plan projet doit être rédigé à partir du modèle fourni par la méthodologie projet. Le modèle est parfois appelé sous d'autres noms comme la lettre de cadrage. Il permet de préciser le contour et les grands axes du projet et c'est principalement le contenu de ce document qui sera restitué pendant la réunion de lancement. Un sommaire classique de ce document est la suivante (basé sur un sommaire réel) :

Contexte

Objectifs

Description des besoins

Périmètre

Bénéfices attendus

Priorité et dates souhaitées

Solutions techniques envisagées

Risques

Coûts et charge

Pré-requis ou préalables

Macro-planning prévisionnel

Impacts organisationnels Ce document devra être légèrement adapté sur le paragraphe : "Solutions techniques envisagées" car il ne s'agit pas d'un projet technique ou applicatif. Les solutions envisagées porteront sur 3 thèmes :

solutions sur l'organisation ne concernent pas l'organigramme ni les responsables mais comprennent la répartition des responsabilités sur les fonctions au sens ITIL du terme et la définition des comités comme le comité des changements ou le comité des problèmes

solutions sur les processus : quels sont les processus ITIL pressentis et quel est le niveau de maturité envisagé (la gestion des problèmes peut être mise en place dans une version simplifiée ou aller jusqu'à la mise en place de la partie préventive)

solutions techniques envisagées (tout de même, il y a une partie outillage) : logiciel PiloTI mais aussi logiciel ITSM pour la partie opérationnelle (EasyVista, Service Now, Isilog, etc.) et le choix d'exploitation (installé et exploité en interne, installé et exploité chez un fournisseur externe ou mode SaaS, c'est-à-dire la location complète de l'exploitation de la solution (les éditeurs de logiciels proposant cette solution ont aussi une expertise ITIL et vous vous verrez alors proposer un SLA)

4.1.3. Configurer initialement le logiciel PiloTI

Afin de compléter la présentation de la réunion de lancement avec quelques aspects concrets, il pourra être utilisé une démonstration en direct du logiciel PiloTI et montrer des exemples de formalisation du référentiel ITSM envisagé. Pour cela, il sera nécessaire de préparer un nouveau référentiel pour le logiciel PiloTI et de définir les différentes sorties web prévues avec leurs chartes graphiques. Cela peut être réalisé avant l'installation du logiciel dans l'environnement de production par un consultant externe sur son portable ou par une personne de l'organisation informatique sur son poste de travail en utilisant un environnement virtualisé VMware dans lequel est installé un système Windows, un serveur Apache/php et le logiciel PiloTI. Les différentes sorties web fournies en exemple dans le logiciel sont basées sur un CMS (Content Management System ou système de gestion de contenu) simplifié qui peut être modifié si besoin par l'organisation informatique. Le site ITIL France est un exemple d'utilisation de ce CMS.

18

4.1.4. Rédiger le support de présentation de la réunion de lancement

Dans le respect de la charte graphique de l'organisation informatique ou de l'entreprise, le chef de projet et le consultant externe rédigeront la présentation de la réunion de lancement.

4.1.5. Effectuer la réunion de lancement

Les participants à la réunion de lancement sont toutes les personnes concernées par le projet (cela peut toucher beaucoup de personnes). Aussi la réunion, comme toutes les réunions de lancement, doit être courte (une heure à une heure et demi maximum). Elle sera animée par :

le sponsor (commanditaire) qui fera une brève introduction (pas plus de 5 minutes) pour montrer que c'est lui qui soutient le projet, il est important d'avoir le soutien visible d'une personne de la direction informatique car le projet va entraîner un changement de culture et il y aura des résistances fortes au changement

le chef de projet qui pourra laisser la parole au consultant externe qui doit aussi être présenté aux équipes internes

4.1.6. Rédiger le compte-rendu de la réunion de lancement et le diffuser

Il est important qu'un compte-rendu de la réunion de lancement soit rédigé et publié. Il n'est pas crédible que, dès la première réunion, la méthodologie projet ne soit pas respectée et qu'une réunion ne soit pas suivie de la publication d'un compte-rendu. Cela permettra aussi à ceux qui n'ont pas pu être présents d'avoir accès à la présentation du projet. Le compte-rendu contiendra les réponses aux premières questions posées pendant la réunion, instituant ainsi un début de document FAQ (foire aux questions) et un début de glossaire sur les termes ambigüs qui seront aussi publiés et complétés régulièrement tout au long du projet.

4.2. Analyser les documents existants Parallèlement ou préalablement à la réunion de lancement, il est nécessaire que les consultants externes (et le chef de projet) étudient et analysent les documents existants qui vont permettre de comprendre :

le contexte et les risques du projet et

le fonctionnement de l'organisation informatique dans le périmètre du projet.

4.2.1. Lister les documents existants (réunion)

Il s'agit pour le chef de projet interne de définir la liste des documents qui seront à analyser par les consultants et le chef de projet dans un délai et un volume raisonnables.

4.2.2. Collecter les documents identifiés et les envoyer aux consultants

Il s'agit pour le chef de projet et les équipes internes d'identifier la dernière version (à jour ou non) des différents documents identifiés précédemment et de les mettre à disposition des différents consultants et du chef de projet qui vont les analyser.

4.2.3. Lire et analyser les documents mis à disposition

Il s'agit pour le chef de projet et les consultants externes d'examiner et d'analyser les documents mis à disposition afin d'affiner les objectifs du projet, la charge, le calendrier, les objectifs et les résultats attendus ainsi qu'identifier les risques du projet à ne pas atteindre les objectifs.

4.3. Former les acteurs du projet aux concepts généraux Il s'agit de faire une première montée en compétence des différents acteurs du projet en présentant les concepts généraux ITSM et les concepts nécessaires à la première étape du projet après la réunion de lancement. Cette partie est souvent réalisée à l'aide de formations et d'ateliers. Leur nombre et leur contenu dépendent des objectifs du projet et du périmètre des connaissances ITSM à mettre en place. Pour ma part, je préconise de puiser dans les formations suivantes :

Certification aux fondamentaux ITIL 2011 (formation officielle) : formation en français de 3 jours avec certification ITIL Fondamentaux 2011 le troisième jour pour connaître les concepts fondamentaux de ce référentiel.

Introduction à la gestion des services informatiques (1 jour) : formation spécifique ITIL France sur la base de mon expérience de consultant

19

Conduite du changement dans un projet ITSM (1 jour) : formation spécifique ITIL France sur la base de mon expérience de consultant

Elaboration du catalogue de services et des niveaux de service (1 jour) : formation spécifique ITIL France sur la base de mon expérience de consultant

Processus et documentations du centre de production (1 jour) : formation spécifique ITIL France sur la base de mon expérience de consultant

Former à l'utilisation du logiciel PiloTI (1 jour) : formation spécifique ITIL France pour une utilisation simple du logiciel PiloTI de gestion du référentiel de connaissances ITSM

Toutes ces formations peuvent passer dans un budget formation. Le site ITIL France a un agrément en France pour dispenser des formations dans le cadre des budgets de formation. Il est préférable que certaines formations soient planifiées en début d'étapes ultérieures du projet ITSM afin de ne pas avoir un effet d'évaporation des connaissances dû à une durée trop importante entre ces formations et l'utilisation pratique des connaissances acquises.

4.3.1. Certification ITIL Fondamentaux 2011

Il s'agit d'une formation de 3 jours avec certification ITIL Fondamentaux V3 le troisième jour pour connaître les concepts fondamentaux de ce référentiel. ITIL France propose en intra-entreprise la formation suivante :

Introduction à la gestion des services

Le cycle de vie des services

Principes clés de la gestion des services informatiques

Concepts, objectifs et activités de base

Vue d’ensemble des fonctions

Structure organisationnelle avec le passage de la certification ITIL Fondamentaux l'après-midi du troisième jour soit en version papier soit en version électronique.

4.3.2. Présenter une introduction à la gestion des services informatiques

L'objectif de cette formation d'une journée est de donner les rudiments de la gestion des services informatiques afin d'entamer une démarche complète (refonte totale du fonctionnement de la DSI) ou partielle (amélioration de l'existant par étapes afin de monter petit à petit la qualité de service fournie et la crédibilité de la DSI). Le plan de formation est le suivant :

Constat

Qu'est-ce qu'un service ?

Ressources et aptitudes du fournisseur de services

Principes et culture de gestion de services (catalogue de services et niveaux de service)

L'organisation informatique

Les processus informatiques

Modèle de connaissances ITSM

Prise en compte du catalogue de services et des niveaux de services : impacts sur la documentation existante et les projets

4.3.3. Former à la conduite du changement dans un projet ITSM

Les objectifs de cette formation d'une journée sont les suivants :

proposer une feuille de route pratique et donner les éléments-clés pratiques au chef de projet ITSM afin de structurer son projet compte-tenu des spécificités de leur organisation informatique

accélérer et diminuer les risques d'erreur sur certaines étapes de la démarche en fournissant des documents et modèles de documents concrets et éprouvés lors de missions réelles réalisées par le consultant

Le plan de formation est le suivant :

20

Conduite du changement dans un projet

Application au cas d'un projet ITSM

Notions indispensables dans la gestion des services informatiques

Exemples de projets ITSM

4.3.4. Former à l'élaboration du catalogue de services et des niveaux de service


proposer une feuille de route pratique et donner les éléments-clés pratiques au chef de projet catalogue de services et/ou niveaux de service afin de structurer son projet compte-tenu des spécificités de leur organisation informatique

accélérer et diminuer les risques d'erreur sur certaines étapes de la démarche en fournissant des documents et modèles de documents concrets et éprouvés lors de missions réelles réalisées par le consultant.


Processus de gestion du catalogue et des niveaux de service

Catalogue des services d’affaires et accords de niveau de service (SLAs)

Catalogue des services d’opérations (IT), accords de niveau opérationnels (OLAs) et contrats de sous-traitance (UCs)

4.3.5. Former aux processus et documentations du centre de production


proposer une feuille de route pratique et donner les éléments-clés pratiques aux propriétaires des processus de gestion des opérations afin de structurer leurs projets compte-tenu des spécificités de leur organisation informatique

accélérer et diminuer les risques d'erreur sur certaines étapes de la démarche en fournissant des documents et modèles de documents concrets et éprouvés lors de missions réelles réalisées par le consultant.


Rappels de quelques concepts ITIL

Processus et activités

Livrables et documentations du centre de production

Rôles des processus et organisation

Les livrables

4.3.6. Former à l'utilisation du logiciel PiloTI

Les objectifs de cette formation d'une journée est de permettre d'aborder l'utilisation de l'outil PiloTI avec les exemples fournis avec le logiciel pour la partie publication vers des sites web. Le plan de formation est le suivant :

Rappels sur le référentiel de connaissances ITSM

Concepts de la gestion documentaire, référentiels et environnements de sortie

Documents et symboles, liaisons, listes et filtres

Configuration d’un site web

Gestion des connaissances sur l’organisation

Gestion des connaissances sur les processus informatiques

Gestion des connaissances sur le catalogue de services et les niveaux de service

Structurer une page web, structurer une arborescence

4.4. Installer le logiciel PiloTI en production Il s'agit de mettre en production le logiciel PiloTI, le référentiel du client et les différents sites web intranet de publication du référentiel.

21

4.4.1. Installer le logiciel PiloTI en production

Le logiciel PiloTI est un client lourd accédant à une base de données partagée. Ce logiciel ne concernent que très peu d'utilisateurs à l'organisation informatique. Un serveur web/php doit aussi être présent en production pour permettre l'installation des différents sites web de publication du contenu du référentiel de connaissances ITSM. Il s'agit de pages semi-statiques (utilisation de scripts php pour afficher des fichiers textes sans accéder aux données dans une base).

22

6. Etape 2 : élaborer la version initiale du catalogue des services informatiques Ce processus permet d'élaborer et de publier le catalogue des services informatiques avec toutes les informations annexes. L'enchaînement-type des activités détaillées ci-dessous pourrait être le suivant :


23

Les objectifs du processus sont les suivants :

définir une version initiale du catalogue de services qui sera ensuite gérée par le processus opérationnel de gestion du catalogue de services

jeter les bases du processus opérationnel de gestion du catalogue de services

5.1. Lancer l'étape

5.1.1. Lancer l'étape

Activité factice jalon du début de l'étape.

5.2. Elaborer les vues clientes du catalogue de services d'affaires Il s'agit de préciser les unités d'affaires et les processus d'affaires des clients du fournisseur de services afin de préparer la classification des services d'affaires, des demandes de services et des accords de niveau de service (SLA) dans la vue cliente du catalogue de services.

5.2.1. Définir les modèles de fiche unité d'affaires et processus d'affaires (atelier)

Il s'agit de définir dans le détail ces modèles de fiche. Les modèles du logiciel PiloTI peuvent servir de point de départ. Ces modèles pourront évoluer par la suite en fonction des difficultés rencontrées et des contraintes du projet.

5.2.2. Etablir la liste des unités et processus d'affaires

La liste des unités et processus d'affaires sera réalisée en ateliers. Le résultat sera directement saisi dans l'outil PiloTI et non pas rédigé dans un document Word à partir d'un modèle.

5.2.3. Formaliser les processus des unités et processus d'affaires (ateliers)

Il s'agit de remplir les fiches décrivant les unités d'affaires et les processus d'affaires. Ce travail doit être réalisé en ateliers.

5.3. Elaborer le catalogue de services d'affaires Il s'agit de définir les modèles de fiche de service d'affaires, de demandes de service, de définir la classification interne des services d'affaires et de remplir les fiches de service d'affaires.

5.3.1. Définir les modèles de fiche service d'affaires et demande de service (atelier)

Il s'agit de définir dans le détail ces modèles de fiche. Les modèles du logiciel PiloTI peuvent servir de point de départ. Ces modèles pourront évoluer par la suite en fonction des difficultés rencontrées et des contraintes du projet.

5.3.2. Définir la classification interne des services d'affaires (atelier)

Cet atelier permet de définir la classification interne des services d'affaires. Un premier niveau de classification est souvent : 1. Services de matériel 2. Services de réseau 3. Services liés au poste de travail 4. Services de données 5. Services d'application 6. Services d'appui 7. Services de formation Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.3.3. Etablir la liste des services d'affaires (ateliers)

La liste des services d'affaires sera réalisée en ateliers. Elle représente aussi le nombre de fiches qu'il faudra remplir pour décrire les services d'affaires identifiés. Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

24

5.3.4. Rédiger les fiches de service d'affaires et demande de service

C'est le travail le plus long à réaliser : la rédaction des fiches décrivant les services d'affaires et les demandes de service. Certains services d'affaires simples et bien bornés prendront environ 2 heures à remplir. D'autres, comme ceux basés sur un ERP, peuvent prendre plusieurs jours à être remplis. Les demandes de service représentent aussi un travail non négligeable : le temps pris pour rédiger une fiche est plus court que pour un service d'affaires mais les demandes de service sont souvent plus nombreuses. Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.4. Elaborer le catalogue des services d'opérations Il s'agit de définir les modèles de fiche de service d'opérations, de définir la classification interne des services d'opérations et de remplir les fiches de service d'opérations.

5.4.1. Définir le modèle de fiche service d'opérations (atelier)

Il s'agit de définir dans le détail ce modèle de fiche. Le modèle du logiciel PiloTI peut servir de point de départ. Ce modèle pourra évoluer par la suite en fonction des difficultés rencontrées et des contraintes du projet.

5.4.2. Définir la classification interne des services d'opérations (atelier)

Cet atelier permet de définir la classification interne des services d'affaires. Un premier niveau de classification pourrait être : 1. Services d'opérations TERMINAUX 2. Services d'opérations SERVEURS MATERIELS 3. Services d'opérations HYPER-SYSTEMES 4. Services d'opérations SYSTEMES D'EXPLOITATION 5. Services d'opérations LOGICIELS : hors outils d'exploitation 6. Services d'opérations LOGICIELS : outils d'exploitation 7. Services d'opérations ENVIRONNEMENT PHYSIQUE 8. Services d'opérations APPLICATIONS 9. Services d'opérations DONNEES 10. Services d'opérations de SUPPORT Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.4.3. Etablir la liste des services d'opérations (1 atelier)

La liste des services d'opérations sera réalisée en ateliers. Elle représente aussi le nombre de fiches qu'il faudra remplir pour décrire les services d'opérations identifiés. Certains critères présentés en début de chaque atelier et en foramtion sur l'élaboration du catalogue de services permettent d'optimiser cette liste. Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.4.4. Définir le modèle de responsabilité AXER (réunion équipe projet)

Cette activité courte abordée lors d'une réunion de l'équipe projet permet de valider ou de modifier le modèle de responsabilité AXER permettant de définir des types de responsabilité lorsqu'on lie un service d'opérations à différents rôles. Le modèle AXER pour les rôles d'opérations, basé sur le principe du modèle RACI pour les rôles de processus, définit 4 types de responsabilité :

A-Autorité : approuve le travail effectué par les autres rôles et est garant du résultat.

E-Exploitation : est lié à des activités opérationnelles (exploitation au quotidien du service technique) et, par extension, aux responsabilités de niveau 2 sur les processus informatiques ayant des activités opérationnelles (support incidents de niveau 2, support problèmes de niveau 2, gestion opérationnelle de niveau 2 de la disponibilité des services et des composants, gestion opérationnelle de niveau 2 de la capacité des services et des composants, gestion opérationnelle de niveau 2 de la sécurité des services et des composants, gestion opérationnelle de niveau 2 de la continuité des services) ; il est aussi lié à des activités opérationnelles de mise en production des services et des composants et intervient sur l'environnement de production sous le contrôle de la gestion des changements

R-Réception : support incidents N1, exécution des requêtes, disponibilité N1, capacité N1, sécurité N1, continuité N1

25

X-eXpertise : expertise sur un domaine de responsabilité amenant à intervenir dans les différents processus ITIL notamment ceux de la conception des services (support incidents de niveau 3, support problèmes de niveau 3, gestion opérationnelle de niveau 3 de la disponibilité des services et des composants, gestion opérationnelle de niveau 3 de la capacité des services et des composants, gestion opérationnelle de niveau 3 de la sécurité des services et des composants, gestion opérationnelle de niveau 3 de la continuité des services)

Le résultat sera directement saisi dans l'outil Piloti.

5.4.5. Rédiger les fiches de service d'opérations

C'est le travail le plus long à réaliser : la rédaction des fiches décrivant les services d'opérations. Certains services d'opérations simples et bien bornés prendront environ 1 heure à remplir. D'autres, comme un ERP, peuvent prendre plusieurs jours à être remplis. Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.4.6. Lister les domaines de responsabilité (réunion équipe projet)

Les domaines de responsabilité permettent de segmenter l'association entre un rôle d'opérations et un métier (lui-même rattaché à l'organisation du fournisseur de services), c'est-à-dire de pouvoir associer un rôle d'opérations à plusieurs métiers différents en fonction du domaine de responsabilité. Cette activité courte et traitée en réunion de l'équipe projet peut adopter une répartition simple du style :

Interne : rôle traité en interne

Sous-traitant A : rôle global joué par le fournisseur externe A à qui l'organisation informatique sous-traite l'exploitation du réseau WAN

Sous-traitant B : rôle global joué par le fournisseur externe B à qui l'organisation informatique sous-traite la gestion des postes bureautiques dans les sites utilisateurs où il n'y a pas d'équipe informatique locale

etc. Le résultat sera directement saisi dans l'outil Piloti.

5.5. Elaborer le catalogue de l'organisation et des métiers Il s'agit de définir l'organisation du fournisseur de services et des métiers associés.

5.5.1. Lister les métiers du fournisseur de services (atelier)

Les métiers du fournisseurs de servies (les postes internes mais aussi les métiers des fournisseurs externes) sont à identifier en atelier. Pour les métiers internes, la manière la plus simple et la plus rapide est de prendre la description des fiches de poste de chacune des personnes de l'organisation informatique. Le résultat sera directement saisi dans l'outil Piloti.

5.5.2. Rédiger les fiches métiers

Cette activité peut être rapide si les fiches de poste existent et que les informations non confidentielles (telles que le salaire) peuvent être publiées. Une organisation qui ne publie pas ces fiches de poste ne permet pas aux personnes y travaillant d'avoir une idée claire sur les responsabilités de chacun, ce qui nuit au travail des uns et des autres. Le résultat sera directement saisi dans l'outil Piloti.

5.6. Rattacher les différentes parties du catalogue 5.6.1. Lancer le rattachement des différentes parties du catalogue

Activité factice de début de groupe d'activités.

5.6.2. Rattacher les services et dem. de service aux processus d'affaires

Ce travail de mise en relation les services d'affaires aux processus d'affaires permet :

26

de préparer la publication des vues clientes du catalogue de services d'affaires : seuls les services d'affaires rattachés à un processus de l'unité d'afffaires ne seront visibles de celle-ci et classés par processus d'affaires

de préparer l'élaboration des accords de niveau de service (SLA) qui relie toujours les services d'affaires aux unités d'affaires en mettant en place des engagements de niveaux de service (ces derniers sont définis principalement sur la criticité des processus d'affaires servis)

Le résultat sera directement saisi dans l'outil Piloti et non pas rédigé dans un document Word à partir d'un modèle.

5.6.3. Rattacher les services d'affaires et les services d'opérations

Ce travail de mise en relation les services d'opérations aux services d'affaires permet :

de saisir une version simplifié d'un schéma d'architecture technique

de mettre à disposition de la gestion des incidents des informations permettant d'assigner de manière plus ciblée à une équipe de support de niveau 2 un incident signalé sur un service d'affaires indisponible (le centre de services a la liste des services d'opérations sur lequel est basé le service d'affaires

de mettre à disposition de la gestion des incidents et de la gestion des changements des informations permettant des analyses d'impact plus fines et plus rapides (un service d'opérations est indisponible ou doit être modifié : quels sont les services d'affaires impactés ?)


5.6.4. Rattacher les services d'opérations et les métiers (rôles d'opérations)

Ce travail de mise en relation les services d'opérations aux métiers par l'intermédiaire des rôles d'opérations permet :

de savoir quelles équipes (quels métiers) ont une responsabilité sur un service d'opérations permettant une identification rapide du bon interlocuteur à contacter lors de l'escalade d'un incident (service d'opérations indisponible ou hors limites des niveaux de service autorisées) ou de l'analyse d'impact sur un changement (quels sont les fournisseurs externes à intégrer dans l'équipe projet par exemple)


5.7. Publier le catalogue de services 5.7.1. Publier vers les sites web intranet et les logiciels à paramétrer

La publication vers les différents sites web se fait simplement en générant les fichiers textes contenant les informations saisies formattées selon la destination. PiloTI peut aussi être utilisé pour importer certaines de ces données pour paramétrer la typologie des incidents par ex. (paramétrage d'un logiciel de gestion des incidents à partir du catalogue des services d'afffaires et des services d'opérations PiloTI) ou un moteur de traitement de flux (workflow) ou de planification de projet (MS Project par ex.) à partir de la description des processus PiloTI. Le formattage des informations vers les différents sites web pourra être modifié si l'organisation informatique ou les organisations d'affaires désirent une autre présentation. Les grandes parties à publier sont les suivantes :

catalogue des services d'affaires par vues clientes : destinée aux différentes organisations d'affaires

catalogue des services d'affaires : destinée aux équipes internes de l'organisation informatique et, éventuellement, des différents sous-traitants

catalogue des services d'opérations : destinée aux équipes internes de l'organisation informatique et, éventuellement, des différents sous-traitants

catalogue de l'organisation et des métiers : destinée aux équipes internes de l'organisation informatique

5.8. Clôturer l'étape du catalogue de services 5.8.1. Faire un bilan élaboration et publication du catal. des serv. (atelier)

Cette activité de clôture permet de faire le blian de l'aboration des différentes parties du catalogue car il s'agit d'un processus réutilisable en grande partie et qui va donner naissance au processus ITIL de gestion du catalogue de services. Tout élément pouvant être amélioré doit pouvoir être identifié tant que les différentes actions sont encore dans la mémoire des acteurs.

27

7. Etape 3 : élaborer la version initiale des niveaux de service Ce processus permet d'élaborer et de publier la version initiale des documents de niveau de service sur un périmètre restreint : accords de niveau de service (SLA), accord de niveau d'opérations (OLA) et contrats de sous-traitance (UC). L'enchaînement-type des activités détaillées ci-dessous pourrait être le suivant :


Les objectifs du processus sont les suivants :

définir une version initiale des accords de niveau de service et des accords de niveau d'opérations sur un périmètre restreint qui sera ensuite gérée par le processus opérationnel de gestion des niveaux de service

définir une version initiale des contrats de sous-traitance sur un périmètre restreint qui sera ensuite gérée par le processus opérationnel de gestion des fournisseurs

jeter les bases du processus opérationnel de gestion des niveaux de service

jeter les bases du processus opérationnel de gestion des fournisseurs

6.1. Préparer le déroulement du processus Il s'agit de compléter l'étape précédente de l'élaboration initiale du catalogue des services informatiques et d'aborder cette nouvelle étape d'élaboration des niveaux de service par une montée de compétences des personnes sur la pérennisation et l'actualisation de ces nouveaux livrables.

28

D'autres actions préalables importantes doivent être réalisées avant de démarrer concrètement cette étape.

6.1.1. Former à l'intégration du catalogue et des niv. de service dans les changements/méthodologie projet

Il s'agit de faire une montée en compétence intermédiaire de l'équipe projet mais désormais aussi de l'ensemble des équipes de l'organisation informatique afin de pérenniser et de garantir l'actualisation des livrables suivants :

catalogue des services informatiques déjà en place,

accords de niveaux de service (SLA) sur les services d'affaires à venir

accords de niveaux d'opérations (OLA) et contrats de sous-traitance (UC) sur les services d'opérations existants et à venir

Il est notamment nécessaire d'intégrer de nouvelles activités dans la gestion des changements (si une approche ITIL est utilisée) ou la méthodologie projet (si une approche de ce type est favorisée par rapport à l'approche ITIL de gestion des changements). Cela est réalisé sous la forme de formations ou d'ateliers dont voici un exemple qu'il peut être utile de programmer à ce moment-là du déroulement du processus :

Conduite du changement dans un projet ITSM (1 jour) : formation spécifique ITIL France sur la base de mon expérience de consultant

Toutes ces formations peuvent passer dans un budget formation. Le site ITIL France a un agrément en France pour dispenser des formations dans le cadre des budgets de formation.

6.1.2. Définir les thèmes de niveau de service et des indicateurs

Il s'agit, lors d'un ou de deux ateliers, de préciser les éléments de base de la démarche niveau de service :

Thèmes de niveau de service : il s'agit de préciser les domaines d'engagement de l'organisation informatique (des constantes se dégagent des attendus des organisations clientes et des bonnes pratiques ITIL)

Indicateurs de mesure possibles : il s'agit de déclencher une réflexion sur ce qu'il est possible de mesurer techniquement aujourd'hui et ce qu'il sera possible rapidement de mettre en place pour mesurer l'atteinte des objectifs de niveaux de service qui seront élaborés

Les thèmes de niveau de service classiques sont les suivants :

cités dans ITIL comme indispensables : disponibilité (et indisponibilité), capacité (et performance), sécurité (préotection des données d'affaires gérées informatiquement), continuité de service

cités dans ITIL comme complémentaires : délais de traitement d'un changement

cités dans d'autres référentiels de bonnes pratiques : coût en CO² de la fourniture d'un service (développement durable)

non cités mais indispensables pour un service de qualité : délai de livraison d'une demande de service Dans la même réflexion, il faudrait intégrer éventuellement en parallèle toute la facturation des services d'affaires à partir du coût des services d'opérations mais cela fait partie du processus de gestion financière des services et n'est pas abordé dans le cadre de ce processus. L'identification des indicateurs de mesure possibles est basée sur le processus d'amélioration en 7 étapes de l'amélioration continue des services ITIL. Ce processus doit être appliqué pour produire des tableaux de bord et des rapports pertinents à partir de sources techniques mesurables et réalistes. Ces tableaux de bord et rapports permettent de prendre des décisions d'amélioration sur le périmètre considéré. Le résultat de cette activité sera saisi directement dans l'outil PiloTI.

6.2. Dérouler le premier cycle de la gestion des niveaux de service Il s'agit de dérouler de manière renforcée la partie cyclique des processus de gestion des niveaux de service et la partie niveaux de service du processus de gestion des fournisseurs. Ce premier cycle sera effectué sur un périmètre raisonnable d'unités d'affaires et de services d'affaires. Les deux points principaux à équilibrer sont :

la durée de ce premier cycle : fonction principalement du volume de services d'affaires à étudier et de leur complexité (les durées d'élaboration des niveaux de service sont très variables d'un service à un autre)

la pertinence des résultats obtenus (documents de niveaux de service) : les résultats obtenus à l'issue de ce premier cycle doivent être significatifs pour démontrer l'intérêt de la démarche (aussi bien en interne pour faire adhérer les

29

équipes à la démarche et pour les organisations clientes qui doivent constater une clarification des engagements de service de l'organisation informatique)

6.2.1. Définir le périmètre de services ou d'orga. d'affaires (atelier)

Cette activité préalable au déclenchement du cycle de gestion des niveaux de services permet de préciser un périmètre :

d'unités d'affaires : souvent, le périmètre est réduit à une organisation d'affaires et celle qui est en rapport direct avec la réalisation du chiffre d'affaires dans l'entreprise (par exemple, la gestion des magasins pour un groupe de la grande distribution)

de processus d'affaires ou de services d'affaires : un périmètre cohérent de processus ou services d'affaires est sélectionné (la sélection dépend du contexte et des problématiques de l'entreprise)

Elle est réalisée sous la forme d'un atelier.

6.2.2. Identifier éléments du périmètre (processus, services d'aff. et d'opé.)

Cette activité est en réalité une analyse d'impact pour déterminer tous les éléments concrets du périmètre :

processus d'affaires et services d'affaires

services d'opérations

équipes internes et sous-traitants ayant une responsabilité opérationnelle dans l'un des services d'opérations identifiés (prise d'appel, exploitation, installation, expertise, etc.)

les propriétaires de services d'affaires et propriétaires de services d'opérations concernés Cela est réalisé simplement en interrogeant le logiciel PiloTI sur l'ensemble des éléments saisis dans l'outil lors de l'étape d'élaboration des différentes parties du catalogue de services.

6.2.3. Détailler les exigences de niveau de service SLR (ateliers)

Cette activité consiste à rencontrer les représentant des unités d'affaires du périmètre et à collecter les réels besoins de niveau de service des clients et utilisateurs pour les services d'affaires du périmètre. Les exigences de niveau de serivce s'expriment à ce moment-là en termes purement d'affaires et non pas en termes techniques (100 connexions simutanées sur la base de données par ex.). Cette activité doit plutôt être menée par un chef de projet fonctionnel ou une personne de l'informatique connaissant bien les métiers de l'unité d'affaires. Il est nécessaire de collecter les réels besoins de garantie de service sans imposer ou faire valoir le point de vue de l'organisation informatique. Le temps des négociations viendra plus tard.

6.2.4. Traduire techniquement les exigences de niveau de service (ateliers)

Il s'agit de traduire les exigences de niveau de service exprimés précédemment en termes plus techniques. Par exemple, une organisation d'affaires précise qu'elle peut potentiellement avoir une centaine d'utilisateurs engagés dans un processus d'affaires pendant les pointes de charge. Dans cet exemple, il faut analyser plus en détail le processus d'affaires et quels sont les services d'affaires utilisés et à quel moment. Deux services d'affaires différents peuvent être utilisés et la charge de 100 utilisateurs connectés simultanément doit se reporter sur les exigences de chacun de ces deux services. Ensuite, selon la décomposition en services d'opérations des deux services d'affaires considérés, il faut aussi reporter cette exigence sur chacun des services d'opérations. Considérons que chacun des services d'affaires aient sa propre base de données (service d'opérations) et que le second service d'affaires accède aussi à la base de données du premier service d'affaires pour consulter ou extraire des données : dans ce cas, la contrainte initiale deviendra 200 connexions simultanées sur la première base de données. Ce cas extrêment simplifié par rapport à la réalité montre les difficultés de cette étape indispensable pour ne pas oublier quelques "détails" techniques d'architecture dans l'évaluation exacte des impacts réels d'une exigence initiale. Cette activité est réalisée sous la forme d'ateliers.

6.2.5. Confronter avec les ressources techniques et budgétaires (ateliers)

La traduction en termes techniques des exigences de niveau de service permet de confronter la "lettre au père Noël" exprimée par les organisations d'affaires et les possibilités budgétaires et techniques réelles du fournisseur de services. Va s'engager alors un long processus d'ajustement des deux univers (celui des organisations d'affaires et celui de l'organisation informatique) :

30

les organisations d'affaires vont limiter leurs exigences au strict nécessaire pour le fonctionnement correct des activités d'affaires et l'atteinte des objectifs d'affaires

l'organisation informatique va améliorer ses possibilités en lançant des projets d'amélioration (changements ayant pour objectifs la réduction des coûts et l'amélioration des performances)

La première action est d'identifier les cibles atteignables en fonction des possibilités réelles du fournisseur de services. Cela inclut les possibilités internes (budgets de fonctionnement et budgets prévus pour les améliorations) et les possibilités externes (budgets de sous-traitance).

6.2.6. Confronter avec les budgets de sous-traitance (1 atelier)

Cette activité du processus ITIL de gestion des fournisseurs est menée en parallèle et en interaction avec l'activité de confrontation avec les ressources techniques et budgétaires (les deux peuvent interagir si la décision est lancée d'externaliser ou de ré-internaliser l'exploitation de services d'opérations dans le périmètre d'étude).

6.2.7. Faire des propositions cohérentes de SLA, OLA et contrats de ST (ateliers)

Cette activité consiste à faire une synthèse cohérente des deux activités précédentes avant de rencontrer une nouvelle fois les organisations d'affaires pour négocier et ajuster les deux points de vue afin d'obtenir un consensus réaliste. La phase de négociation comprend trois activités distinctes qui doivent impérativement être réalisées en parallèle et en interaction pour conserver la cohérence de l'ensemble.

6.2.8. Négocier et valider les accords de niveau de service SLA (ateliers)

Cette activité consiste pour le fournisseur de services à négocier avec les organisations d'affaires les niveaux de service d'affaires sur le périmètre considéré. Elle doit être menée en parallèle et en interaction avec les deux autres activités de négociation pour conserver la cohérence de l'ensemble des propositions.

6.2.9. Négocier et valider les accords de niveau d'opérations (ateliers)

Cette activité consiste pour le fournisseur de services à négocier avec les différentes équipes internes les niveaux de service d'opérations sur le périmètre considéré. Elle doit être menée en parallèle et en interaction avec les deux autres activités de négociation pour conserver la cohérence de l'ensemble des propositions.

6.2.10. Négocier et valider les contrats de sous-traitance (ateliers)

Cette activité du processus ITIL de gestion des fournisseurs consiste pour le fournisseur de services à négocier avec les différents sous-traitants les niveaux de service sur le périmètre considéré. Elle doit être menée en parallèle et en interaction avec les deux autres activités de négociation pour conserver la cohérence de l'ensemble des propositions.

6.2.11. Mettre en place la mesure des niveaux de service

Il s'agit maintenant de mettre en place concrètement les niveaux de service sur le périmètre considéré. La mise en place concrète passe par la mise en place de la chaîne d'outils techniques qui va permettre de collecter les données de base afin de produire les valeurs et leur évolution des différents indicateurs de mesure définis dans :

les accords de niveau d'opérations (OLA)

les contrats de sous-traitance (UC)

les accords de niveau de service (SLA)

6.2.12. Faire un bilan de la mise en place des niveaux de service sur le périmètre

Il s'agit d'identifier les choses qui n'ont pas fonctionné correctement dans le déroulement de ce premier cycle car il va ensuite être répété de manière opérationnelle dans le processus de gestion des niveaux de service. Il s'agit typiquement d'une activité d'amélioration.