5. Couche 2 : les services d’affaires – vue cliente et vue utilisateur #

5.1. Vue cliente #

Voyons maintenant la structure détaillée d’un service d’affaires.

Pour cela, revenons à la terminologie ITIL® et présentons là de manière simplifiée (les détails du référentiel ITIL® sur ce point n’apporte pas grand chose à la présentation).

Pour un client, le service d’affaires sera vue comme étant composé :

• d’un service principal (Core Service) répondant aux besoins de base du processus d’affaires pour tous les clients qui l’utilisent

• éventuellement d’un ou de plusieurs services complémentaires ou options (Enhancement Services) pour apporter de la valeur supplémentaire dans certains cas d’utilisation ou contextes d’utilisation du processus d’affaires (mais qui n’est pas nécessaire à tous les clients)

Evidemment, des options sont proposées lorsque certaines parties du service ne sont pas utilisées par un client et que ces options coûtent un supplément. Cela permet aussi de différencier le prix du service en fonction des contextes des différents clients.

5.2. Vue utilisateur #

Pour l’utilisateur, la perception en est toute autre. Il ne s’occupe pas du prix de ce qu’il utilise. En revanche, le service le satisfait lorsqu’il peut réaliser de manière autonome ses activités métiers en utilisant des ressources informatiques.

L’utilisateur peut utiliser de manière autonome une application par ex. sans qu’il ait besoin de faire appel à une personne de l’organisation informatique. Et ce, à chaque fois qu’il a besoin de l’utiliser.

De plus, dans certains cas pour réaliser des actions métiers spécifiques, l’utilisateur peut contacter l’informatique pour demander une invervention du fournisseur de services informatiques afin de compléter son « expérience » du service d’affaires.

Certaines de ces demandes peuvent être formalisées sous la forme de services (en fait, il s’agit de sous-services attachés au service d’affaires) ; que j’appelle services d’utilisation car ils sont nécessaires pour l’utilisation correcte et optimale du service d’affaires.

Ces services d’utilisation seront aussi décrits dans le catalogue de services.

Voici quelques exemples de services d’utilisation :

• demande d’accès au service d’affaires : obtenir, modifier ou résilier

• traitements convenus et standard (dans le sens : formalisés et décrits dans le catalogue de services avec une procédure de traitement elle-même formalisée et écrite) : déménagement d’un poste de travail par ex.

Ces traitements ne peuvent pas être réalisés de manière autonome par les utilisateurs du service d’affaires, soit nécessairement (par ex. fonctionnalités non prévues dans le logiciel acheté à l’extérieur et nécessitant une intervention technique) ou volontairement (fonctionnalités verrouillées et non accessibles dans l’application par les utilisateurs afin d’avoir un contrôle de l’organisation informatique ou d’un responsable hiérarchique client dans le traitement de ces demandes).

Ces demandes seront traditionnellement traitées et gérées dans le cadre d’outils logiciels embarquant des fonctions de traitement de flux (workflow).

On s’aperçoit ici que l’outil logiciel gérant le catalogue de services devra soit intégrer des fonctions de traitement de flux, soit interfacé avec un outil de traitement de flux.

6. Couche 2 : les services d’affaires – critère discriminant entre un service d’affaires et un service d’utilisation #

Lorsqu’on aborde de manière conceptuelle services d’affaires et services d’utilisation, il peut être difficile lorsqu’on a identifié un service de le catégoriser affaires ou utilisation.

Une question très concrète permet de distinguer ces deux types : quels sont les niveaux de service essentiels à proposer au client qui va l’acheter :

• service d’affaires : ce sont les quatre thèmes classiques ITIL® de disponibilité, de capacité (et de performance), de sécurité de l’information et de continuité de service qui sont à proposer

• service d’utilisation : seul ce qui va intéresser le client (comme l’utilisateur du reste), c’est le délai de livraison ou de réalisation.

Dans ITIL®, les demandes faites sur ces services d’utilisation seront traitées dans le processus d’exécution des requêtes sous la forme de modèles de requête (ou modèle de demande de service) qui sont, rappelons-le, des manières pré-définies (des procédures) de traiter certains types de requête.

A noter que certains services d’utilisation seront traités sous la forme de changements standard.

7. Couche 2 : les services d’affaires – structure d’un service d’affaires #

Ceci posé, il est nécessaire de définir la structure de la description d’un service d’affaires avec tous les éléments que nous venons de voir.

Cela permettra d’aborder la définition d’un modèle de fiche concret pour décrire les services d’affaires.

Le service d’affaires est composé :

• du service principal : décrit en premier lieu par son apport de valeur aux clients

• des services complémentaires (ou d’amélioration selon la terminologie ITIL®) : décrits aussi par leur apport de valeur aux clients

• des services d’utilisation associés : pouvant être catégorisés s’il y a beaucoup de services à présenter

Les principales catégories de services d’utilisation peuvent être :

• préparer à l’utilisation du service : par ex., un client a commandé un service d’affaires et ses utilisateurs peuvent maintenant demander à utiliser le service d’affaires

• utiliser le service : ce sont les demandes standard pouvant être faites par les utilisateurs dans le cadre d’une utilisation normale du service d’affaires (par ex. déménager le poste de travail) ; cette catégorie peut aussi être éclatée en plusieurs catégories s’il y a un nombre important de services d’utilsiation associés

• arrêter l’utilisation du service : par ex. un magasin veut quitter l’enseigne pour en intégrer une autre, il faut proposer un service d’utilisation pour extraire les données comptables du magasin et lui remettre un ensemble de fichiers qui pourra ensuite être repris par les services centraux de la nouvelle enseigne.

Dans ITIL®, on parle aussi de services facilitateurs ou pratiques (Enabling Services). Pour ces services, il est possible de définir la même structure de description.

8. Couche 2 : les services d’affaires – données essentielles #

Cette liste est une liste classique de données détaillant un service d’affaires en complément de l’apport de valeur et des fonctionnalités déjà présentés.

Point important : il est nécessaire de distinguer le titre et la description pour un client du titre et de la description pour un utilisateur.

9. Couche 2 : les services d’affaires – quelques points importants #

Voici quelques erreurs classiques (que j’ai donc aussi faites par le passé) dans l’élaboration du catalogue de services d’affaires :

• nommer la prestation informatique et non pas uniquement l’application ou le matériel proposé : par ex. le poste bureautique qui est souvant facturé 2 à 3 fois plus cher que le même matériel acheté « nu » dans une grande surface

• si une partie d’un service d’affaires est commune avec une autre partie de services d’affaires : éviter les copier/coller (difficultés de maintenance par la suite) et créer un nouveau service d’affaires avec la partie commune (il s’agit de factoriser cette partie dans un nouveau service d’affaires) ; cela arrive avec les services facilitateurs (ou pratiques)

Autres points importants dans la réflexion :

• les clients et utilisateurs ne voient que la partie services d’affaires du catalogue (et un utilisateur n’a pas la même vue qu’un client) : ce point est développé juste après

• chaque client ou organisation d’affaires ne voit pas le même ensemble de services d’affaires, de services d’utilisation et de niveaux de services : il est utile de ne présenter que les services qu’une personne a le droit d’utiliser mais attention au nombre de vues ; plus le nombre de vues est important, plus la charge de travail pour les gérer est importante

• la présentation et l’utilisation doivent être conviviales et compréhensibles des personnes qui consultent le catalogue : interdire le jargon informatique (sauf si les clients sont eux-mêmes des informaticiens)

• tous ces éléments nécessite impérativement d’intégrer dans la réflexion l’outil logiciel qui va gérer le catalogue de services : il ne sont pas nombreux à répondre à tous ces critères (si on ne tient pas compte des discours commerciaux et marketing) ; il est, par ex., nécessaire d’étudier quelles sont les fonctionnalités de recherche d’une information dans le catalogue et les fonctionnalités de filtres (ceux obligatoires et ceux définissables par l’utilisateur)

10. Couche 2 : les services d’affaires – exemples #

10.1. Distinction entre vues cliente et utilisateur : organiser des sessions de formation #

Point important : il est nécessaire de distinguer le titre et la description pour un client du titre et de la description pour un utilisateur.

Par ex., dans le cas de mon propre catalogue de services, je propose une prestation d’organisation de sessions de formation ITIL® Fondamentaux.

Je m’adresse à la fois aux organismes de formation (où je propose une prestation plus ou moins complète mais sans à avoir à planifier les sessions de formation ni à gérer les inscriptions) et aux directions informatiques désirant organiser des sessions de formation en interne.

La vue cliente contient la description de la prestation portant sur les sessions de formation et la vue utilisateur ne contiendra que le descriptif de la formation.

Evidemment, un client doit avoir aussi accès à la vue utilisateur.

Dans l’exemple proposé, si une DSI me commande une prestation pour organiser des sessions de formation et gérer les incriptions du personnel informatique, je dois proposer deux services d’utilisation aux utilisateurs (qui sont ici les participants aux sessions de formation) : l’inscription et la désinscription.

10.2. Structure d’un service d’affaires : gérer le commerce #

Autre exemple (simplifié) : la gestion commerciale d’un magasin

• service principal : gestion commerciale du magasin

• service en option : assistance sur site à l’inauguration du magasin (l’informatique envoie du personnel sur place pendant les journées d’inauguration du magasin qui ne doivent pas être perturbées par un incident informatique malgré les risques : expérience limitée des équipes du magasin sur le nouveau logiciel, stress des équipes du magasin pendant cette période, etc.)

• service d’utilisation (ou service d’accession pour Enabling Services) pour la préparation à l’utilisation :

  • initialiser les données du magasin dans le système (cas de la création d’un magasin),

  • migrer les données du magasin de l’ancien système (cas d’un magasin existant migrant vers le nouveau système)

• services d’utilisation dans l’utilisation quotidienne du service :

  • donner, modifier ou supprimer l’habilitation d’accès d’un utilisateur : réservé au directeur du magasin par ex. ; nécessite une opération technique de la part de l’informatique

  • ajouter ou modifier une caisse : fonction de l’ERP qui a été verrouillée pour les magasins afin de les contraindre à passer par l’organisation informatique pour réaliser ces actions ; la raison première est que la stratégie de tarification est basée sur le nombre de caisses d’un magasin (item facturable décrit dans le processus ITIL® de gestion financière des services) car cela est un bon critère pour évaluer la taille d’un magasin (qui est proportionnel au coût de fourniture du servces d’affaires) ; dans ce contexte, si cette option peut être utilisée directement par un directeur de magasin et qu’il le sait (parce qu’il a suivi la formation), je vous laisse deviner le scénario non prévu qui se mettra en place…

• services d’utilisation dans l’arrêt de l’utilisation du service :

  • obtenir une sauvegarde des données du magasin : cela indique une volonté de quitter l’enseigne ou d’arrêter le magasin (la sauvegarde servira, dans le premier cas, à réinjecter les données dans un autre système d’information et, dans le second, à conserver les données pour un éventuel contrôle fiscal par ex.)