Archives du blog

7. Chantier 1.1 : Définir le périmètre des clients, des services d’affaires, des SLAs et des parties prenantes

7. Chantier 1.1 : Définir le périmètre des clients, des services d’affaires, des SLAs et des parties prenantes

En partant des objectifs du projet, il s’agit de lister les clients (filiales, métiers, etc.) du périmètre 2015.

Pour chacun de ces clients, il s’agit de déterminer la partie des services d’affaires qu’il utilise pour déterminer un périmètre significatif de services d’affaires.

L’ensemble des services d’affaires sélectionnés doit aussi répondre à un ensemble de critères (non exhaustif) :

  • trouver un équilibre entre services ayant un taux de satisfaction client correct et services qui sont motifs d’insatisfaction (pour enclencher le plus tôt possible l’amélioration continue sur ces services)

  • répondre aux critères imposés par la direction et la stratégie informatique (s’ils existent)

Les parties prenantes sur le périmètre 2015 sont :

  • les différentes équipes internes à la DSI ; d’une manière plus globale, les « groupes de compétences » avec un niveau de détail plus fin éventuel comme, par exemple, une personne experte sur une technologie avec un backup dans la même équipe (si besoin) ; la formation spécifique sur le catalogue de services aborde dans le détail ces notions

  • les différents sous-traitants impliqués dans la maintenance et le support des technologies (plus généralement des services d’opérations) impliqués dans la fourniture des services d’affaires du périmètre 2015 ; cela nécessite d’identifier clairement chaque fournisseur et les contrats de sous-traitance convenus déjà en place

Activités

  • pour les clients et services d’affaires : atelier de deux heures puis rédaction des livrables

  • pour les équipes internes : atelier de deux à quatre heures pour les équipes internes (selon le niveau de complexité actuel et le niveau de détail nécessaire) et rédaction des livrables correspondants

  • pour les sous-traitants : atelier de deux heures pour réaliser l’inventaire des contrats de maintenance et de support (nécessite peut-être une collecte préalable des différents contrats si sources diverses) et rédaction des livrables

Livrables

  • liste des clients retenus

  • liste des services d’affaires retenus (un titre et, en cas de confusion possible, une description plus ou moins détaillée du contenu, avec un propriétaire de service identifié côté informatique et un représentant du métier avec qui convenir des niveaux de service plus tard)

  • liste des équipes internes et des compétences au niveau de détail pertinent

  • liste des sous-traitants du périmètre et les contrats de sous-traitance associés

Forme des livrables

  • ensemble de documents Word et Excel

  • paramétrage de l’outil ITSM cible

6. Chantier 1.1 : Transférer les connaissances complémentaires à ITIL vers le chef de projet

6. Chantier 1.1 : Transférer les connaissances complémentaires à ITIL vers le chef de projet

Une formation de 2 jours sur le catalogue de services et les niveaux de service avec au moins 25 % de travaux pratiques pour le chef de projet permettra de présenter :

  • les compléments pratiques de la création du catalogue de services et des documents sur les niveaux de service adaptés au projet

  • les compléments pratiques de conception et de mise en œuvre des processus ITIL de gestion du catalogue de services et de gestion des niveaux de service

  • les compléments pratiques pour définir les points fonctionnels à vérifier et à mettre en place dans les outils logiciels accompagnant les deux processus et les processus liés

  • les compléments pratiques pour passer d’un mode projet à un mode processus (avec amélioration continue) pour les activités des deux processus et les processus liés

  • les liens concrets existant entre ces processus et les processus de gestion des événements, des incidents (typologie d’incidents) et des demandes de service (typologie des demandes)

5. Chantier 1 – Objectif 1 : publier le catalogue de services (périmètre 2015)

5. Chantier 1 - Objectif 1 : publier le catalogue de services (périmètre 2015)

Le livrable à fournir :

  • servira de base de travail à l’élaboration des SLAs, OLAs et UCs du périmètre

  • permet aussi de décrire l’utilité des services d’affaires du périmètre ainsi que l’apport de valeur côté métier

Les activités à conduire sont décrites dans les pages suivantes.

4. Chantier : 1-Catalogue de services

4. Chantier : 1-Catalogue de services



Besoin

Afin de travailler sur les livrables de niveaux de service, il est nécessaire de déterminer quels sont les services d’affaires couverts par les accords de niveau de service, les services d’opérations présents en arrière-plan des services d’affaires du périmètre et les liens entre ces deux couches de services.

Il est aussi nécessaire de préciser qui dans l’organisation du fournisseur de services (intervenants internes et externes) fait quoi dans la gestion de chacun des services d’opérations.

Cela permettra d’aborder la mise en cohérence des SLAs avec les accords OLAs en interne et les contrats de sous-traitance et de relever des points d’amélioration.

2. Vocabulaire spécifique du document

2.Vocabulaire spécifique du document

2.1. Terminologie complémentaire à ITIL Service d’affaires

Equivalent au terme ITIL « Service business »

Service d’opérations

Equivalent au terme ITIL « Service technique »

Modèle AXER

Equivalent pour un service d’opérations du modèle RACI pour une activité de processus. Ce modèle permet de définir des responsabilités et des rôles standard sur la gestion d’un service d’opérations :

  • Autorité : équivalent au terme ITIL « Propriétaire de service »

  • eXpert : personne, groupe de personnes, équipe ou sous-traitant ayant une responsabilité d’expertise sur le service d’opérations ; habituellement, deux rôles d’expert : expert niveau 1 et expert niveau 2

  • Exploitant : personne, groupe de personnes, équipe ou sous-traitant ayant la responsabilité d’exploiter le service d’opérations

  • Réceptionnaire : point d’entrée pour escalader un incident ou faire une demande portant sur le service d’opérations

Comme le modèle RACI, le modèle AXER impose des contraintes sur les rôles d’opérations (une seule autorité par ex.).

Gestion des demandes de service

Equivalent au terme ITIL « Exécution des requêtes », processus destiné à traiter les demandes de service en provenance des utilisateurs.

2.2. Acronymes

  • SLA : Service Level Agreement, ou accord de niveau de service

  • SLR : Service Level Requirements ou exigences de niveaux de service (ensemble de cibles de niveaux de service à atteindre convenu entre le métier et la DSI)

  • OLA : Operational Level Agreement, un accord de niveau d’opérations est lié à un ou plusieurs services d’opérations

  • UC : Underpinning Contrat, un contrat de sous-traitance est lié à un ou plusieurs services d’opérations

1. Contexte client

1. Contexte client

1.1. L’entreprise

L’entreprise est un groupe travaillant dans le domaine agro-alimentaire avec plus de 10 000 collaborateurs.

Ses marchés couvrent tous les aspects allant de la production (céréales, viande, viticulture, etc.) à la vente (magasins) en passant par la transformation de la matière première et la vente de produits finis aux groupes de la grande distribution.

L’entreprise a une stratégie de croissance forte axé principalement sur de la croissance externe.

1.2. La DSI

La DSI de 150 personnes a été créée il y a quelques années par la fusion de plusieurs équipes informatiques dans le groupe.

De par la diversité des activités du groupe, la DSI doit gérer 25 métiers très différents nécessitant la gestion d’applications très compartimentée ainsi que la gestion d’applications lourdes en central telle qu’un ERP qui a été mis en place récemment.

La DSI produit sa propre stratégie, alignée avec la stratégie du groupe, et a lancé une démarche de transformation de la relation avec les directions et les filiales métiers pour passer d’un mode client-fournisseur à un mode partenariat.

Elle a mis en place il y a quelques années un logiciel ITSM reconnu intégrant la gestion de la majorité des processus ITIL.

1.3. Le projet

Dans ce contexte, la DSI a décidé de mettre en place sur un premier périmètre restreint des accords de niveau de service.

Etant donné le délai court de mise en place (4 mois), la DSI a décidé de faire appel à un consultant externe pour l’aider à formaliser le plan projet.

Le chef de projet interne est le responsable qualité au sein de la DSI et est sensibilité à la gestion qualité et aux risques de ne pas mettre en place l’amélioration continue des services.

C’est pour cela que le projet devra faire passer en douceur et sans rupture du mode projet au mode amélioration continue sur tout ce qui sera mis en place par le projet.

La suite du document propose un plan projet prenant en compte ces contraintes. Les charges et temps proposés sont spécifique au contexte de ce projet.

Approches agiles

Flux complet d'alignement

Les modèles agiles pour faire évoluer de manière itérative un domaine sont basés sur le manifeste agile et les 12 principes agile.

3. Activités d’exploitation

3. Activités d'exploitation

3.1. Une nouvelle équipe



Parmi les éléments à dimensionner en phase de conception, il faut évaluer la charge de travail supplémentaire pour les équipes projets et exploitation.

Il est préconisé de mettre en place une équipe (ou une personne) qui gère les activités courantes du processus de gestion du catalogue de services et, ultérieurement, les activités du processus de gestion des niveaux de service.

C’est dans cette équipe que nous retrouverons les propriétaires de services au sens ITIL®.

Cette équipe commence à apparaître et est souvent nommée Relations Clients ou Organisation (« O » de DOSI).

Elle peut aussi se voir attribuer comme responsabilité la gestion du Package de conception des services (SDP).

3.2. Les processus liés



Des charges de travail supplémentaires apparaissent en gestion de projet car les chefs de projet doivent maintenant considérer que ce qu’ils doivent livrer n’est plus une application ou une infrastructure technique mais un service complet.

Cela impose, si on veut être cohérent de bout en bout, de demander à ses sous-traitants de gérer leurs propres catalogues de services. Les services d’affaires qu’ils proposent et qui sont utilisés en interne seront référencés dans notre propre catalogue de services comme des services d’opérations.

Enfin, il est important, pour être cohérent avec la gestion des services ITIL® et pour rationaliser les activités, de confier la gestion des accès au catalogue de services au processus de gestion des accès ITIL® (s’il est en place dans l’organisation).

3.3. Les activités spécifiques



Les activités opérationnelles quotidiennes sont les suivantes :

  • s’assurer de la complétude, de la cohérence et de la version à jour informations du catalogue en auditant régulièrement ce livrable

  • assister les chefs de projet dans leur nouvelle démarche, au début et à chaque fois qu’un nouveau chef de projet est nommé

  • mettre en production les mises à jour du catalogue et les procédures liées aux services d’utilisation (workflows) au travers d’un outil ergonomique et complet

2. Validation, conception et pilote

2. Validation, conception et pilote

2.1. Conception du système de gestion du processus



L’approche proposée est la mise en place d’un processus de gestion du catalogue de services selon les bonnes pratiques ITIL®.

Un processus ITIL®, quel qu’il soit, et son écosystème peuvent être représentés sur le modèle ci-dessus.

Dans un référentiel qualité ISO/IEC 9000, l’écosystème du processus (tout ce qui lui permet de fonctionner correctement et d’atteindre ses objectifs) est nommé système de gestion (Management System).

Outre les personnes et les équipes qui travaillent selon le processus, le système de gestion comprend principalement 3 parties :

  • une grande partie des activités du processus va produire et maintenir à jour un ensemble de documents et d’enregistrements rassemblés dans le livrable du processus (ensemble théorique des documents et des données ; dans la réalité, il s’agit d’une collection de documents, fiches, enregistrements dans une base, etc.)

  • une petite partie des activités du processus va permettre de gérer les droits d’accès au livrable des personnes à l’extérieur du processus et dont les activités vont être facilitées par l’utilisation de ces éléments à jour

  • un outil de gestion (souvent, un logiciel ou une application) permettant de gérer et de tracer les activités du processus, de stocker et de publier de manière sécurisée le contenu du livrable du processus

2.2. Préoccupation permanente : le VOI positif et rapide du processus



Dans sa phase d’exploitation, un processus impose des contraintes (utiliser un logiciel pour assurer la traçabilité des activités) et ne présente pas toujours un apport de valeur direct à l’organisation sur la partie « Produire et maintenir à jour le contenu du livrable »).

C’est particulièrement le cas pour le processus de gestion du catalogue de services où ces activités sont aujourd’hui très peu réalisées.

De plus, l’outillage souvent logiciel) mis en place pour supporter le processus et la charge de travail supplémentaire que le processus impose aux différentes équipes augmentent encore la dépense.

La rentabilité du processus (valeur sur investissement) et assurée par la mise à disposition du contenu du livrable du processus à un maximum de personnes (côté informatique et côté clients). Ces personnes vont utiliser et exploiter le contenu du livrable du processus afin de faciliter et de fiabiliser leurs activités quotidiennes (bénéfices : gain de temps, utilisation de données à jour, fiables et complètes).

Ceci peut être représenté par le bilan ci-dessus.

Dans le cas du processus de gestion du catalogue de services, les personnes bénéficiaires seront à la fois les équipes internes de la DSI et les utilisateurs de cette même DSI.

Clairement, pour le catalogue de services (et plus tard les niveaux de service), il sera nécessaire de renforcer les équipes informatiques. Les bénéfices en retour (VOI ou Value On Investment) seront, pour les équipes informatiques et les utilisateurs, une clarification de qui propose quoi, des gains de temps et de fiabilité dans les projets et des gains de temps dans le traitement des demandes utilisateurs.

2.3. Maximiser l'apport de valeur et le VOI et mettre en place les 3 composantes d'un service



Afin de maximiser l’apport de valeur et le VOI du processus, il est préconisé de voir le projet comme ayant pour objectif la mise en place d’une prestation (ou d’un service, au sens ITIL® du terme) qui est de proposer un catalogue de services informatiques complet et à jour et de faciliter les demandes pouvant être faites avec ce catalogue.

Pour ITIL®, la mise en place d’un service nécessite 3 composantes :

  • des processus pour structurer, fiabiliser et tracer les activités liées à la prestation fournie

  • des outils (dont des outils logiciels) pour sécuriser et accélérer les activités ainsi qu’assurer le stockage des informations nécessaires pour assurer une prestation de qualité

  • des personnes pour faire fonctionner les activités des processus

Un mélange équilibré de ces 3 composants permettra aux personnes qui vont profiter de ce service de voir trois effets indispensables :

  • des fonctionnalités complètes

  • avec une qualité et des performances assurées,

  • le tout dans un coût réduit

2.4. Définition du processus et processus liés



Pendant cette phase de conception, il va être nécessaire d’évaluer les coût récurrents du processus.

Habituellement, ils sont de deux types :

  • la charge de travail des personnes dans le processus

  • les coûts de maintenance de la solution logicielle

Pour évaluer la charge de travail des personnes dans le processus, il faut prendre en compte la taille et les spécificités des activités de l’organisation et s’appuyer sur les quatre objectifs du processus ITIL® :

  • gérer les informations contenues dans le catalogue de services (mettre à jour le catalogue de services lors du traitement des changements et des projets)

  • s’assurer que le catalogue de services est à jour et reflète les détails, les statuts, les interfaces et dépendances de tous les services opérationnels ou en cours de développement, le tout en conformité avec les politiques en vigueur (vérifier l’exhaustivité, la fiabilité et la conformité des informations du catalogue de services)

  • s’assurer que le catalogue de services est accessible aux personnes habilitées de telle manière qu’elles pourront utiliser de manière efficace et efficiente les informations du catalogue de services (gérer les accès au catalogue de services)

  • s’assurer que le catalogue de services supporte les besoins en perpétuelle évolution de l’ensemble des processus de gestion des services dans leur utilisation des informations du catalogue de services, y compris toutes les informations sur les interfaces et dépendances (amélioration continue du processus)

Beaucoup de processus sont liés à la gestion du catalogue de services. Un minimum de maturité dans ces processus facilitera un VOI positif et rapide du processus.

1. Projet de mise en œuvre

1. Projet de mise en oeuvre



La démarche proposée se déroule en 2 étapes suivies de l’« étape » permanente d’exploitation et d’amélioration continue. Elle intègre les macro-activités suivantes :

  • valider les principes, concevoir le processus, les outils logiciels et la structure du catalogue et réaliser un pilote sur quelques services

  • faire évoluer la méthodologie projet pour y intégrer les activités de transition des processus de gestion :

    • du catalogue de services

    • des niveaux de service

  • élaborer la première version du catalogue de services (rétro-documentation de l’existant)

  • mise en place du processus de gestion du catalogue de services en alignement avec la nouvelle méthodologie projet, exploitation courante et amélioration continue du processus