Introduction #
Réf. ITSM-M0106-V010-001
Les familles de services d’affaires #
Réf. ITSM-M0106-V010-002
Chaque service fourni permet de relier les technologies, les processus et les personnes de l’informatique à des résultats clients, qu’ils soient internes à l’organisation ou externes à celle-ci.
L’exemple d’un client externe est le cas d’un client qui utilise des services en mode SaaS (Software as a Service) par un infogérant. Le client externe définit les fonctionnalités demandées et les niveaux de service nécessaires. Ses utilisateurs accèderont par la suite à l’application développée et exploitée par l’infogérant.
La séparation entre clients internes et clients externes n’est pas aussi nette que cela.
Une application extranet permettant aux clients de l’entreprise de commander des produits et des services est généralement définie par une direction d’affaires en interne (la communication ou les ventes par exemple) bien que les utilisateurs finaux soient des personnes extérieures à l’entreprise.
Les services proposés sont appelés services business (services d’affaires) ou customer-facing services (services frontaux destinés aux clients de l’informatique).
Dans la suite de ce document, le terme service d’affaires sera utilisé de préférence au terme officiel ITIL® de service business.
Les cinq familles proposées sur le schéma (services d’affaires de mission, de support, de ressources, d’organisation et de transformation) sont des exemples de lignes de services (lines of services) citées dans ITIL®.
Plus simplement, ils représentent le premier niveau de rangement des services dans l’offre du fournisseur.
Ils seront à adapter en fonction des activités de l’entreprise et de ce que l’organisation informatique fournit.
Malheureusement, les liens entre services d’affaires d’une part et les technologies, les processus et les personnes d’autre part, sont trop complexes à modéliser en connectant directement les uns aux autres.
Il va nous falloir une tactique pour structurer et faire apparaître une couche intermédiaire de boîtes noires entre les deux pour pouvoir s’en sortir sans trop de travail de gestion par la suite.
Chaîne client-fournisseur : les flux de service #
Réf. ITSM-M0106-V010-003
Au-delà des clients directs, nous allons utiliser les différents processus au sein de chaque client pour structurer le catalogue de services d’affaires.
Sur le lien entre client et processus, nous allons avoir deux cas souvent séparés par la frontière interne-externe de l’entreprise ou de la collectivité.
Clients internes #
Les clients internes sont souvent les directions de l’organisation, chaque direction possédant ses propres processus : la Direction des Ressources Humaines, la Direction Financière, La Direction Commerciale, Les Directions Opérationnelles (celles qui fabriquent, fournissent et maintiennent les produits et les services de l’organisation).
Lors de l’établissement de la cartographie des processus de l’organisation, une distinction est souvent faite entre :
les processus de mission
les processus de support
Ces cartographies présentent les processus de l’organisation selon une arborescence de processus avec des processus de haut niveau (les processus « racine ») et les autres processus s’y rattachant.
Très souvent, chaque processus de haut niveau est piloté et géré par une direction dans l’entreprise.
Clients externes #
Les clients externes qu’il est possible de regrouper en clientèles, les clients d’une clientèle en particulier ont les mêmes missions et utilisent des processus communs ou identiques : les cabinets comptables, les bénéficiaires des allocations chômage, etc.
L’organisation informatique peut être amenée à fournir des services pour ces clients extérieurs.
3 exemples de cartographie de réseau de valeur #
Réf. ITSM-M0106-V010-004
Réf. ITSM-M0106-V010-005
Réf. ITSM-M0106-V010-006
Chaîne client-fournisseur : les échanges au sein du fournisseur #
Réf. ITSM-M0106-V010-007
Le niveau intermédiaire part d’un principe simple : puisque les liaisons directes entre services d’affaires d’une part et technologies, processus et personnes d’autre part pour un fournisseur de services dans sa globalité, nous allons créer de manière artificielle des mini-fournisseurs de services au sein du gros fournisseur de services.
Le fournisseur de services est constitué :
de différentes équipes internes (le support, l’exploitation, les experts techniques, les chefs de projet applicatifs, etc.)
de sous-traitants (appelé « fournisseur » tout court dans ITIL®)
Le principe est donc de créer des entités indépendantes qui vont fournir des services internes plus techniques car nous allons pouvoir parler le même langage informatique entre le mini-fournisseur de services et le client qui va être artificiellement le fournisseur de services, représenté par son responsable (le DSI par exemple).
ITIL® préconise de créer cette couche intermédiaire de services techniques pour pouvoir gérer correctement les liens :
entre les services d’affaires et les services techniques d’un côté et
entre les services techniques et les technologies, les processus et les personnes d’autre part.
En revanche, aucun conseil ni piste n’est proposé dans ITIL® pour concrétiser cette démarche.
Réf. ITSM-M0106-V010-008
Chaque équipe interne fournit des services aux autres équipes internes et les fournisseurs externes délivrent des services à l’organisation informatique.
Pour simplifier la gestion des services des fournisseurs externes, le plus simple est de considérer qu’un service fourni est délivré conformément aux exigences formulées par une équipe de l’organisation informatique. En d’autres termes, un service fourni par un sous-traitant l’est sous la responsabilité d’une équipe interne, qui en est le client.
Services d’affaires et services d’opérations #
Réf. ITSM-M0106-V010-009
Les services techniques sont des boîtes noires intermédiaires pour lesquelles il va falloir surveiller et gérer la performance.
Comme pour les services d’affaires où fournisseur et client doivent se mettre d’accord sur les niveaux de service, les services techniques doivent faire l’objet de négociation et d’accord entre le mini-fournisseur d’un service technique et le fournisseur de services dans son ensemble (ici figurant le rôle de client du service technique).
Ces accords seront formalisés dans des documents appelés accord de niveau d’opérations (OLA pour Operational Level Agreement) si le mini-fournisseur est une entité interne ou contrat de sous-traitance (UC pour Underpinning Contract, contrat sous-jacent).
Pour cette raison, dans la suite de ce document, j’utiliserai le terme de service d’opérations à la place de service technique, pour avoir une homogénéité de vocabulaire avec l’OLA ou accord de niveau d’opérations.
Chaque service d’opérations est aussi un mélange équilibré entre technologies, processus et personnes.
Certains services d’opérations seront à forte composante processus. D’autres seront à forte composante technologique.
Les services d’opérations basés sur un processus #
Il s’agit de gérer sous la forme de boîte noire le système de gestion du processus en incluant la description du processus.
Les rôles de processus et le modèle RACI pourront donc être utilisés pour décrire ce type de service d’opérations.
Un exemple de ce type est la conduite de projet applicatifs, proposé par une équipe de chef de projets.
Les services d’opérations basés sur une technologie #
Les explications qui suivent ne sont pas dans ITIL® mais sont issues de mon expérience personnelle.
Nous allons décrire les services d’opérations à base d’une technologie spécifique, par exemple le stockage disque.
Pour ce type de service d’opérations, il est possible d’accélérer la formalisation de ces services avant même que les processus ITIL® ne soient en place en définissant directement le lien entre service d’opérations et qui fait quoi pour gérer et fournir le service.
En reprenant une terminologie processus (le rôle et le modèle RACI), il est possible de définir des rôles d’opérations associés à chaque service d’opérations.
Un rôle d’opérations est un ensemble classique de responsabilités autour de la gestion d’un service :
Autorité : le propriétaire de service (celui qui décide du contenu et qui négocie avec les clients), dans l’exemple utilisé, cela peut être le responsable de l’exploitation
eXpert : celui ou ceux qui ont un niveau d’expertise sur la technologie, par exemple, l’équipe stockage au sein de l’organisation informatique
Exploitant : l’équipe qui exploite le service d’opérations au quotidien, par exemple, l’infogérant si l’environnement de production est externalisé
Réceptionnaire : quel est le point de contact à qui escalader un ticket d’incident ou une demande portant sur le service d’opérations, par exemple, le centre de services de l’infogérant (la description du service contient les informations pratiques pour le contacter : numéro de téléphone, adresse électronique, etc.)
Le modèle AXER, comme le modèle RACI, impose une règle simple : une seule équipe (ou une seule personne) n’est associé à un rôle d’opérations.
Par exemple, si le service de stockage disque est en partie exploité en interne et une autre partie est externalisée chez un sous-traitant (par exemple, dans le cadre d’un site de secours possédant lui aussi un SAN), il conviendra de créer deux services d’opérations séparés. Le principe de base étant de simplifier la présentation d’un service d’opérations et de connaître immédiatement avec le nom du service d’opérations, qui fait quoi et, en l’occurrence, qui exploite le SAN en question (l’interne ou l’infogérant).
Il s’agira de mettre en place le système de gestion permettant de suivre la performance du service d’opérations.
Enfin, les services d’opérations peuvent aussi dépendre d’autres services d’opérations. Mais attention à ne pas créer trop de dépendances, le modèle final pouvant être plus complexe que le modèle sans les services d’opérations en intermédiaire entre services d’affaires et actifs de service !
La construction la plus simple de cette cartographie dépend fortement du contexte du client et cela se travaille sous la forme d’ateliers pour avancer progressivement dans la démarche la plus efficace.
Réf. ITSM-M0106-V010-010
Il s’agira de mettre en place le système de gestion permettant de suivre la performance du service d’opérations.
Enfin, les services d’opérations peuvent aussi dépendre d’autres services d’opérations. Mais attention à ne pas créer trop de dépendances, le modèle final pouvant être plus complexe que le modèle sans les services d’opérations en intermédiaire entre services d’affaires et actifs de service !
La construction la plus simple de cette cartographie dépend fortement du contexte du client et cela se travaille sous la forme d’ateliers pour avancer progressivement dans la démarche la plus efficace.
Réf. ITSM-M0106-V010-011
Cet exemple simple présente les dépendances entre un service d’affaires dont le titre est un processus d’affaires de haut niveau (la maintenance) pour une entreprise dont le métier est de louer des véhicules. L’une des activités est la maintenance et l’entretien des véhicules loués.
Dans une première version du catalogue de services, il a été regroupé tout ce qui été fourni par l’équipe informatique et utilisé spécifiquement dans le cadre des processus de maintenance des véhicules.
Le schéma présente les principales dépendances de ce service d’affaires avec les services d’opérations :
11 applications dédiées pur couvrir l’ensemble des processus de maintenance des véhicules
un socle technique matériel allant de la salle informatique (et tout son contenu) aux serveurs physiques sur lesquels tournent les machines virtuelles supportant les applications dédiées
un socle technique système constitué des machines virtuelles hébergeant les applications dédiées
une application installée sur les tablettes utilisateurs (les tablettes sont intégrées dans un autre service d’opérations) : l’application constituant les outils de diagnostics des mécaniciens chargés de l’entretien des véhicules en atelier
Avantages et inconvénients de la structure à 2 niveaux #
Réf. ITSM-M0106-V010-012
Pourquoi s’embêter à faire deux couches de services ? #
L’une des raisons principales est la réutilisation maximale des services d’opérations dans les services d’affaires. Les services d’opérations seront donc rentabilisés au maximum.
Un autre intérêt apparaît lorsqu’il s’agit de mettre en place un nouveau service d’affaires.
En effet, l’architecte dispose d’un certain nombre de services d’opérations standardisés (spécifié avec utilité et garantie) pour élaborer l’architecture du futur service d’affaires. Cela va grandement faciliter son travail car il va pouvoir sélectionner très rapidement les briques techniques qui l’intéressent (et surtout en terme de niveaux de service, pour correspondre aux besoins du client sur la partie garantie) plutôt que de tout recréer en partant de zéro.
L’élaboration des services d’opérations est réalisée en partant des équipes d’experts. Chaque équipe d’experts proposera un catalogue de services d’opérations basés sur la technologie en question. Ils sont les mieux placés pour le faire car ce sont eux qui réalisent la conception des infrastructures associées et la mise en œuvre des solutions techniques.
Cela permet :
d’économiser du temps d’architecte
de remplacer du temps d’architecte par du temps d’assemblage de briques standardisées dans un catalogue (moins coûteux car nécessite des compétences moins pointues)
de gagner en fiabilité sur l’architecture du service d’affaires (les briques standardisées sont rôdées, notamment sur la partie niveaux de service) et donc, de gagner du temps dans les tests à venir
Ensuite, lorsque le service d’affaires sera en exploitation, cela simplifiera la gestion de la performance des équipes car elles sont jaugées sur la performance des services d’opérations, boîtes noires plus techniques que les services d’affaires, plutôt destinés à suivre la performance des services vue des clients.
L’effet spaghetti #
Une attention particulière doit être portée sur la simplification extrême à apporter à l’élaboration du catalogue des services d’opérations. Sans cette préoccupation permanente, les catalogues résultants présentent un effet spaghetti qui donne le tournis mais qui, à part satisfaire l’ego de la personne qui a conçu un catalogue indigeste à souhait, n’apporte aucune valeur à l’organisation informatique.
Il faut sans doute se rappeler que faire un plat de spaghetti est à la portée de tout le monde. En revanche, présenter simplement des notions complexes afin que tous les acteurs les comprennent et se les approprient demande des aptitudes autres.