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.
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.
Equivalent au terme ITIL « Service business »
Service d’opérationsEquivalent au terme ITIL « Service technique »
Modèle AXEREquivalent 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.).
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
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 DSILa 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 projetDans 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.
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).
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).
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
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
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.
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 :
|
|
|
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.
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
Après la présentation détaillée du contenu du catalogue de services, il est évident que, pour une performance optimale, le catalogue de services doit être intégré réellement dans un référentiel plus large qui s’appelle la CMDB et placé sous le contrôle du processus de gestion des configurations et des actifs de service.
Ceci permet de lier :
les utilisateurs et clients aux services d’affaires
les services d’affaires aux services d’opérations
les services d’opérations aux composants techniques
certains composants techniques à des caractéristiques d’utilisateur
les rôles d’opérations aux équipes du fournisseur de services (internes et sous-traitants)
L’apport de valeur est de faciliter tout ce qui analyse d’impact : incident, changement, etc.
Les investissements réalisés pour l’élaboration du catalogue de services et les dépenses d’exploitation courante de la gestion du catalogue seront ainsi mieux rentabilisés.
Le référentiel ITIL® précise que les demandes de service fréquentes devraient être définies sous la forme de modèles de requête (ou de demande de service).
Cela nécessite la définition d’une procédure de traitement et des données en entrée que doit fournir le demandeur.
Les demandes de service sont décrites dans le catalogue des services d’affaires (services d’utilisation) et devraient être associé à une procédure de traitement.
L’outil idéal devrait intégrer un moteur de traitement de flux (workflow) pour effectuer le suivi administratif du traitement des demandes. Certains logiciels proposent une orchestration des activités du workflow en ce sens que certaines activités ne sont pas manuelles mais peuvent être réalisées par des outils logiciels à condition de pouvoir les piloter au travers du moteur de traitement de flux.
Attention à la complexité du projet de mise en œuvre du catalogue de services avec les procédures : il peut y avoir plusieurs centaines de services d’utilisation à développer (donc plusieurs centaines de procédures) et le choix de l’outil est crucial pour la faisabilité du projet : s’il faut plusieurs jours pour développer un workflow, il va falloir une équipe de 5 personnes pendant un an pour saisir toutes les procédures de traitement !
Enfin, l’utilisateur peut aussi suivre l’avancement du traitement de sa demande.
Le catalogue des services d’affaires (avec les services d’utilisation) sera plus performant :
s’il est intégré à un portail utilisateurs proposant par ailleurs d’autres fonctionnalités comme la saisie de tickets d’incidents par ex.
si l’outil logiciel permet de gérer facilement les différents profils des personnes qui consultent (client, utilisateur) afin de proposer des vues différentes
si l’outil logiciel permet de filtrer les services proposés en fonction du type de client auquel l’utilisateur appartient
Le portail utilisateurs devrait aussi offrir :
des facilités pour trouver rapidement une information dans le catalogue : au bout d’un certain temps (très court généralement), l’utilisateur décroche son téléphone et appelle le centre de services pour demander son information s’il ne la trouve pas dans le catalogue
distinguer la consultation simple (pour s’auto-former) de la consultation pour faire une demande
Afin d’être complet dans les informations proposées (utilité et garantie d’un service), le catalogue de services présentés aux utilisateurs et clients devraient contenir les niveaus de service décrits dans les SLA.
La gestion des niveaux de service n’est pas de la responsabilité du processus de gestion du catalogue de services. Néammoins, la publication du contenu des SLA peut être intégrée dans la publisation du catalogue de services.
Cela est aussi valable en interne sur les services d’opérations (avec les OLA et UC).
