Partie du catalogue de services interne au fournisseur de services (qui comprend les équipes internes et les sous-traitants), les services d’opérations (ou services techniques dans la terminologie ITIL®) sont décrits très sommairement dans la documentation ITIL®.

La description d’un service d’opérations proposée ici est personnelle et correspond à une proposition pratique ayant un intérêt dans les activités du fournisseur de services.

L’application du référentiel ITIL® peut néammoins aboutir à d’autres définitions du service d’opérations.

La définition proposée d’un service d’opérations part des ressources techniques associées au service d’opérations.

Un service d’opérations est un ensemble de prestations fournies par différentes équipes informatiques (internes ou sous-traitées) sur un ensemble de ressources techniques similaires (serveurs Linux par ex. ou bases de données Oracle) opérées avec le même niveau de service.

La principale difficulté d’un service d’opérations est d’ « exister » entre les services d’affaires d’un côté et les ressources techniques de l’autre côté.

Cette définition permet de bien préciser l’intérêt des services d’opérations. Un service d’affaires (par ex. la gestion commerciale d’un magasin) se basera sur des services d’opérations (serveur Linux critiques, réseau, bases de données critiques, etc.).

Cela n’est pas suffisant pour aboutir à un modèle clair de catalogue de services d’opérations. Il est nécessaire d’y ajouter des contraintes supplémentaires pour définir le périmètre d’un service d’opérations et clarifier leur utilisation.

Sur un ensemble de ressources similaires à opérer, il existe différentes actions à réaliser et différentes responsabilités à assurer par les équipes internes et les sous-traitants.

Nous allons catégoriser les responsabilités et ajouter la contrainte suivante : une seule équipe (interne ou externe) ayant une responsabilité particulière sur les ressources du service d’opérations.

Par exemple, une seule équipe qui réalise l’exploitation au quotidien des ressources du service. Si des serveurs Linux sont gérés pour partie en interne par un service d’exploitation et pour une autre partie par un infogérant, il est alors nécessaire de scinder les serveurs Linux en deux services d’opérations, chacun étant exploité par une équipe spécifique.

Nous allons voir ensuite la typologie des responsabilités habituelles sur un service d’opérations.

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

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)

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.

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.

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.

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.

4.1. Principes

Cette cartographie de processus d’affaires va permettre de rapprocher les services d’affaires de ces processus.

L’apport de valeur d’un service est constitué en premier de l’utilité du service (le service doit être utile au client). L’utilité du service sera présent dès lors les fonctionnalités proposées supportent les activités métiers ou lèvent des contraintes d’utilisation de l’informatique pour faciliter le processus métier.

En effet, à quoi sert une application de prise de commande qui ne soit pas utilisable sur des terminaux mobiles (comme les tablettes et les téléphones intelligents) ? Cette application est utilisée par les commerciaux mais ils sont à l’extérieur (chez les clients de l’entreprise) lorsqu’ils en ont besoin. Noter sur un cahier les commandes pour ensuite les saisir informatiquement une fois rentré au sein de l’entreprise est une perte de temps.

Remplacer cette application par une autre possédant les mêmes fonctionnalités mais pouvant fonctionner sur des terminaux mobiles apportera plus de valeur que la première.

Il faut aussi éviter le jargon informatique aux utilisateurs et clients (sauf s’il s’agit d’informaticiens eux-mêmes). Le nom des applications (acronymes souvent farfelus ou noms commerciaux des logiciels achetés) représentent déjà un jargon technique.

Il ne faut jamais citer le terme « SAP » par exemple dans le nom d’un service d’affaires.

Il est possible de nommer le services d’affaires du nom du processus d’affaires qu’il facilite, par ex., le service d’affaires « Faire la gestion commerciale du magasin ». Il s’agit alors d’un abus de langage car le service d’affaires facilite le processus d’affaires, il N’est PAS le processus d’affaires.

Notez encore que le nom du service d’affaires ne sera très souvent connu et visible que par le client. L’utilisateur qui utilise ce service d’affaires sera lui beaucoup plus concerné par les demandes qu’il pourra faire à l’informatique sur ce services d’affaires (ces demandes seront décrites dans les services d’utilsiation associés au service d’affaires).

4.2. Exemple de la gestion commerciale d'un magasin

Reprenons l’exemple de la gestion commerciale d’un magasin.

Le détail de l’apport de valeur du service d’affaires doit être présenté sous la forme d’arguments de vente (même si souvent, le service n’est pas acheté avec un bon de commande et payé après réception d’une facture).

Il faut donc connaître le contexte d’un magasin (et l’historique du contexte). En l’occurrence ici, ce nouveau service d’affaires va remplacer une quarantaine d’applications développées en interne (je parle d’applications car quand elles ont été développées, les principes ITIL® n’étaient pas en place et ce sont les applications en question qui ont été « vendues » à tous les directeurs de magasin).

Ces applications tournent localement sur un serveur informatique installé dans le magasin, ne sont plus adaptées aux niveaux défis de la grande distribution et n’intègrent pas les dernières évolutions technologiques (ergonomie, web, mobilité, etc.). Elles nécessitent aussi quelques resaisies d’une application à l’autre car les flux ne sont pas tous automatisés d’une application à une autre.

De plus, ce grand projet de migration a aussi pour objectif de mettre un peu d’ordre dans les pratiques commerciales des magasins du groupe. Ces pratiques ne sont pas forcément optimisées et peuvent être différentes d’un magasin à l’autre. Afin d’uniformiser les pratiques, un cabinet de consultants spécialisé dans les processus métiers a été mandaté pour proposer des bonnes pratiques de gestion commerciale adaptées au contexte du groupe. Le résultat est une cartographie des processus métiers que tous les magasins devront adopter par la suite. Cette cartographie a aussi servi de cahier des charges dans la sélection de l’éditeur et les fonctionnalités de l’ERP.

En connaissant ce contexte, voici les arguments de vente du service d’affaires (ce qu’il apporte comme valeur au directeur de magasin) :

• facilite la mise en place des bonnes pratiques de gestion commerciale d’un magasin

• simplifie l’utilisation du système d’information d’un magasin (évite les resaisies et fournit une vision globale de l’activité de commerce)

• offre l’utilisation de technologies informatiques modernes plus conviviales (application web, utilisation des tablettes et des téléphones intelligents)

• permet d’avoir une approche nationale des données au lieu d’une approche locale par magasin (certaines limitations sont levées, par exemple, la possibilité d’interroger le stock d’un magasin de l’enseigne proche de son magasin)

• diminuant sensiblement le coût global l’informatique d’un magasin (le coût de ce nouveau service est plus élevé que le coût facturé précédemment pour les applications remplacées mais le nouveau service permet de faire des économies par ailleurs, notamment le serveur informatique installé dans le magasin et qui n’est plus nécessaire)

Une fois l’apport de valeur défini, le service d’affaires doit ensuite être décrit fonctionnellement.

Pour cela, la cartographie des processus métiers sera utile.

Dans l’exemple, la liste des processus de rang 2 de la gestion commerciale d’un magasin est utilisée pour définir le périmètre fonctionnel des activités métiers couvertes et, éventuellement, pour préciser ce qui est hors périmètre.

3.1. Partir de la cartographie des processus métiers

Prenons le cas simple d’une organisation informatique fournissant des services à une clientèle (ensemble de clients ayant les mêmes processus métiers).

En premier lieu, il faut référencer toutes les clientèles.

Ensuite, pour chaque clientèle, il faut cartographier l’arborescence de processus en partant par ceux du rang 1 (processus de haut niveau) puis par les processus des rangs suivants.

Il n’est pas nécessaire pour l’élaboration du catalogue de services d’affaires de détailler le contenu du processus, les éléments suivants peuvent être relevés :

• objectifs du processus

• objet, but du processus

• voire même la mission de l’entité d’organisation spécialisée qui est l’acteur principal du processus

Le dernier élément permet de se baser sur l’organigramme de l’organisation pour cartographier les processus d’affaires.

3.2. Exemple de l'informatique d'un Conseil Général en France

Par exemple, pour l’informatique d’un conseil général en France, voici les différents niveaux hiérarchiques :

• clientèle : les Pôles, par exemple :

  1. Pôle Médiation, Concertation et Risques Majeurs

  2. Pôle Ressources des Services

  3. Pôle Finances Economie Aménagement du Territoire et Environnement

  4. Pôle Education, Culture, Sport et Vie Locale

  5. Pôle Routes, Transports et Bâtiments

  6. Pôle Autonomie et Santé

  7. Pôle Actions Sociales Territoriales Insertion Enfance et Famille

• pour chaque Pôle, et en fonction de l’organigramme, les rangs suivants : Direction, Sous-Direction et Service ; par exemple, pour le Pôle Autonomie et Santé :

  • 6.0.0.1-Observatoire social et sanitaire

  • 6.0.0.2-Relais ressources humaines

  • 6.1-Secrétariat Général

  • 6.2-Maison de l'Autonomie: Direction Usagers, Prestations pour l'Autonomie

  • 6.2.0.1-Service accueil information orientation des usagers

  • 6.2.0.2-Service évaluation des besoins de compensation PAPH

  • 6.2.0.3-Service instruction et attribution des prestations PAPH

  • 6.2.0.4-Service accompagnement et suivi des personnes en perte d'autonomie et prévention de la perte d’autonomie

  • 6.2.0.5-Mission vulnérabilité adultes

  • 6.3-Maison de l'Autonomie: Direction Ingénierie, Partenariat pour l'Autonomie

  • 6.3.0.1-Service juridique et contentieux PAPH

  • 6.3.0.2-Service projets ingénierie pour l'autonomie

  • 6.3.0.3-Service autorisation tari¬cation des établissements PAPH - Relations services d'aide à domicile

  • 6.4-Direction Budget, Logistique et Contrôle

  • 6.4.0.1-Service budget

  • 6.4.0.2-Service logistique et travaux

  • 6.4.0.3-Service contrôle

  • 6.5-Direction Santé

  • 6.5.0.1-Service politiques départementales de la santé

  • 6.5.0.2-Laboratoire Départemental d'Analyses : Service administratif et comptable

  • 6.5.0.3-Laboratoire Départemental d'Analyses : Service analyses eaux e ffluents rejets

  • 6.5.0.4-Laboratoire Départemental d'Analyses : Service analyses et conseil pour l'hygiène alimentaire

  • 6.5.0.5-Laboratoire Départemental d'Analyses : Service biologie vétérinaire

  Chaque entité organisationnelle possédant ses processus métiers spécifiques et ses propres intervenants sera référencée dans cette cartographie avec leur mission.

  L’étape suivante consistant à structurer l’offre de services d’affaires permettra de relier les services d’affaires aux entités organisationnelles qui vont utiliser ces services.

  Pour simplifier cette étape suivante, chaque service d’affaires va couvrir un processus métier (qui sera soit un processus spécialisé exécuté par une unique entité organisationnelle ou par un processus de base comme « gérer le budget de l’entité organisationnelle » qui sera utilisé par la totalité ou la quasi-totalité des entités organisationnelles).

  3.3. Exemple de l'informatique d'un groupe dans la grande distribution

  
  

  

  
  

  Un autre exemple est celui de l’organisation informatique de la centrale d’une chaîne de magasins de la grande distribution.

  Ici, nous avons 3 clientèles distinctes :

  • les clients de la centrale avec une organisation classique : direction générale, direction financière, direction des ressources humaines, direction des achats, etc.)

  • les clients de type entrepôts

  • les clients de type magasins

  Pour la clientèle de type magasin, il est possible de préciser les processus de rang 1 :

  • créer un magasin ou intégrer l’ensemble du groupe (en bleu) : dans ce processus, il y a des actions informatiques à réaliser (installer un réseau local dans le magasin ou valider le réseau local existant, créer le magasin dans les référentiels centraux, etc.)

  • gérer le fonctionnement du magasin avec plusieurs processus de rang 1 (en mauve) :

    • gérer les ressources humaines

    • gérer les ressources technologiques (processus structurel car n’étant pas le cœur de métier d’un magasin, ce processus est inhérent à la structure même d’un magasin)

    • gérer les ressources matérielles (processus structurel)

    • gérer les ressources financières (processus structurel)

    • gérer le commerce du magasin (processus d’affaires car il représente l’activité du magasin qui genère directement du chiffre d’affaires)

  • fermer le magasin ou quitter l’enseigne du groupe (en vert) : certaines activités informatiques sont à réaliser comme par exemple fournir une sauvegarde de la comptabilité du magasin.

  Tous ces processus de rang 1 devront ensuite être éclatés en processus de rang 2.

  Dans le cas particulier d’un ERP (Entreprise Resource Planner) de gestion commerciale d’un magasin, il sera envisageable de définir un service d’affaires basé sur cette gestion commerciale. Ce service d’affaires couvrira tous les processus et activités du processus de rang 1 « Gérer le commerce du magasin ».

  
  

  

  
  

  Pour les processus structurels de rang 1, il existe sur internet quelques exemples de cartographies de processus plus détaillés pouvant quelquefois présenter un aspect de bonnes pratiques en la matière.

  Cependant, ils sont difficiles à trouver car il s’agit d’une chasse gardée des cabinets de consultants spécialisés dans les processus d’affaires (Business Process Management).

  Comme ces processus structurels sont en réalité des activités de support aux activités générant directement du chiffre d’affaires pour le client, il est possible de se baser sur certains processus décrits dans ITIL® comme, par exemple, la gestion financière des services ou la gestion du portefeuille de services.

  Les exemples présentés ici sont une compilation d’expériences personnelles et d’informations trouvées sur internet.

2.1. Trouver un compromis entre deux extrêmes

La difficulté va être de définir le niveau de détail de la cartographie clients. Il va falloir trouver un équilibre entre deux extrêmes.

Par exemple, pour un client interne qui est une organisation métier, il faut trouver un juste milieu entre :

• un processus unique « gérer l’informatique de l’organisation métier » : cela est un peu trop grossier comme découpage dans la grande majorité des cas

• une multitude de petits processus, difficile à maintenir en raison de la volumétrie ; et le client risque aussi de ne plus s’y retrouver

Il va donc falloir définir des processus de taille intermédiaire suffisamment détaillés pour avoir une vision intéressante des activités de l’organisation métier.

Pour cela, il faut définir des critères de découpage permettant de décider du bon niveau de détail. La solution n’est d’ailleurs pas unique et il est difficile pour ITIL® de dégager une bonne pratique pour la démarche.

La situation se complique avec des clients externes.

Le principe économique dans le fait d’avoir des clients externes est de mettre en place des services qui sont utilisés par un maximum de clients (afin de rentabiliser leur mise en œuvre et de profiter d’économies d’échelle dans leur exploitation).

Dans ce cas, il faut plutôt catégoriser les clients. Des clients de même type (les mêmes préoccupations, les mêmes activités, etc.) seront regroupés en clientèles. Il s’agit de décrire les processus d’affaires d’un client-type et d’associer les services d’affaires à ces processus d’affaires-types.

Cela est, par exemple, la clientèle cabinet comptable pour un infogérant. L’infogérant peut proposer des services spécialisés qui seront vendus à un maximum de clients de type cabinet comptable.

2.2. Quelques critères à retenir

Voici quelques critères et sources d’inspiration :

• la cartographie des processus d’affaires : il arrive qu’en interne les processus métiers aient été cartographiés ; afin de ne pas refaire le travail et de proposer un catalogue de services informatiques reliés aux activités de l’entreprise, il est fortement conseillé de s’en inspirer

• un critère de séparation des processus d’affaires est le niveau de criticité métier de chaque processus : un processus global « gérer le commerce d’un magasin » peut être décomposé en « gérer les factures fournisseur » et « gérer l’encaissement » (entre autres) car ces deux processus ont des criticités bien différentes

• un autre critère de séparation est l’ensemble des profils utilisateurs : comptables, gestionnaire de ressources humaines, etc.

• cette approche permet aussi de réfléchir à la structure des futurs SLA : il est important de proposer une structure du catalogue de services qui ne soit pas incompatible avec les futurs SLA ; l’approche décrite dans le processus ITIL® de gestion des niveaux de service peut aussi intervenir dans la démarche de structuration du catalogue

• dans la pratique, un service d’affaires peut être couvert par différents niveaux de service : par exemple, un service d’affaires « gestion commerciale d’un magasin » aura des parties gérées avec des niveaux de service différents (par ex. « gérer les factures founisseurs » et « gérer les encaissements ») ; certains critères pouvant être contradictoires, il est alors nécessaire de faire des choix

• le critère service utilisé par tous les clients ou spécifique à un groupe de clients ou spécifique à un client est un critère simple qui peut être utilisé (il rejoint la notion de cadre de SLA).

2.3. Préoccupations à retenir

D’autres critères et considérations plus généraux permettent aussi de préciser le niveau de granularité :

• le catalogue des services d’affaires est à la fois un document marketing et un document pratique (préoccupations différentes d’un client et d’un utilisateur)

• dans l’approche marketing, certains messages peuvent être passés au travers du catalogue de services : par exemple, si une organisation informatique veut insister sur le centre de services, il est possible de créer un service d’affaires lié à l’utilisation du centre de services comme point d’échange unique entre les utilisateurs et l’informatique

• les différentes vues pressenties du catalogue de services d’affaires permettent aussi de séparer les services d’affaires afin de rendre la construction des vues facile à réaliser

Pour le double aspect marketing/pratique, il faut prendre en considération les points suivants :

• un client est la seule personne habilitée à commander un service,

• un client peut déléguer à un niveau hiérarchique plus bas certaines autorisations de commande, il délègue alors son pouvoir de clients sur certains services

• cela peut aller jusqu’à déléguer ce pouvoir à un utilisateur final (cas très souvent des services d’utilisation qui vont générer des demandes de service)

Cette hiérarchisation des clients est aussi à prendre en compte lors de la réflexion sur la structure du catalogue de services d’affaires.