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.

Le catalogue de services est composé de deux couches :

• les services d’affaires et les services pratiques, partie visible des clients et des utilisateurs et ne contenant aucune information ou terme technique informatique

• les services d’opérations, partie interne du fournisseur des services (interne et sous-traitants) reprenant l’ensemble des services plus techniques des équipes internes et des sous-traitants, services qui vont constituer la charpente interne des services d’affaires fournis aux clients

A cela, il faut ajouter des services d’utilisation pour les services d’affaires. Ces services d’utilisation décrivent formellement les demandes de service standard qu’un utilisateur pourra faire dans le cadre de l’utilisation du service d’affaires.

Cependant, pour élaborer efficacement la structure du catalogue de services, il est nécessaire de s’intéresser aux deux extrémités de la chaîne :

• le côté client : les organisations-types, les processus d’affaires et les rôles des utilisateurs dans ces processus et les objectifs et résultats attendus de ces processus

• le côté technique et le côté organisationnel du fournisseur de services : le côté technique est l’inventaire des composants techniques liés aux services d’opérations ; le côté organisationnel (description des équipes internes du fournisseur et de ses sous-traitants) permet de préciser qui fait quoi sur chacun des services d’opérations.

Les informations collectées de ces 2 extrémités de la chaîne vont donner des critères pour découper ou regrouper les services d’affaires d’un côté et les services d’opérations de l’autre.

Enfin, les niveaux de service (SLA sur les services d’affaires et OLA/UC sur les services d’opérations), s’ils existent, seront aussi des critères pour structurer les deux parties du catalogue de services.

Enfin, pour compliquer l’ensemble, d’autres types de service apparaissent dans la réalité.

Un utilisateur accédant à un service d’affaires :

• est autonome dans son utilisation mais

• peut être obligé de faire appel au fournisseur de services car il ne peut pas réaliser une opération en lien avec le service d’affaires (fonctionnalité non prévue ou demande d’assistance par ex.)

Dans ce dernier cas, il va demander un service complémentaire au fournisseur en lui faisant une demande de service.

Certaines demandes peuvent être standardisées et, pour faciliter le travail de tout le monde, être publiées dans le catalogue de services.

Enfin, le même échange apparaît dans l’organisation informatique entre équipes internes et sous-traitants, soit à l’intérieur d’un service d’opérations, soit entre un client « intermédiaire » et un fournisseur de services d’opérations (fournisseur secondaire).

Habituellement, ces demandes sont dénommées demandes de travaux (bien que ce ne soit pas un terme ITIL® bien défini).

ITIL® préconise deux premiers niveaux de classification des services.

En complément et pour simplifier la démarche, j’ai ajouté quelques contraintes supplémentaires pour aboutir à ce modèle.

Un service est soit destiné directement à un client (service d’affaires ou business) soit utilisé dans la fourniture de tels services (services d’opérations ou techniques).

De plus, il existe deux types de services d’affaires :

• les services d’affaires proprement dits qui apportent directement de la valeur aux clients avec les services de base (Core Service) et leurs options (Enhancement Services) qui apportent de la valeur additionnelle dans certains cas d’utilisation

• les services pratiques ou facilitateurs (Enabling Services) qui vont faciliter la vie des utilisateurs dans l’utilisation des services d’affaires (centre de services ou portail de téléchargement de logiciels autorisés sur le poste de travail par ex.).

Les services d’affaires se décomposent uniquement en services d’opérations. Cette contrainte personnelle permet d’éviter le mélange d’éléments de base (technologies, processus, personnes) avec des services « intermédiaires ».

Les services d’opérations se décomposent en technologies, processus, personnes et d’autres services « intermédiaires ».

Ensuite, après avoir intéressé un client potentiel avec l’apport de valeur d’un service, il va falloir décrire de manière plus détaillée le service.

Le service sera décrit en reprenant les trois éléments vus du client :

• l’utilité : le contenu fonctionnel du service

• la garantie : l’engagement convenu de niveau de service avec quatre critères préconisés par ITIL® (mais cette liste n’est pas limitative) :

  • disponibilité (et surtout l’indisponibilité)

  • capacité et performance

  • sécurité des données métiers

  • continuité de service

• le prix et la manière dont il est recouvré : par des mécanismes budgétaires (uniquement interne dans une organisation) et/ou de facturation (et avec le détail dans ce cas)

Seules ces informations intéressent le client mais, pour des raisons internes de gestion, le service sera aussi décrit par sa combinaison de technologies, de processus et de personnes.

Cependant, pour simplifier la décomposition interne d’un service, des services « intermédiaires » regroupant technologies, processus et personnes seront utilisés. Cela permettra de diminuer drastiquement le nombre d’éléments intervenant dans la décomposition du service. Ces services « intermédiaires » sont en fait des regroupements d’éléments de base et présentés sous une forme extérieure de service : utilité, garantie et coût.

Evidemment, cette mise en œuvre de services « intermédiaires » doit être gérée strictement pour éviter que la complexité apportée par cette approche ne soit supérieure à la simplification de l’élaboration des services.

Nous verrons que certains critères simples permettent d’identifier le strict nécessaire de services « intermédiaires ».

2.1. Le résultat du service

Pour décrire un service en fonction de ce qui a été dit précédemment, il est nécessaire de commencer par le résultat que va produire le service côté client.

Nous ne sommes pas là dans la technique mais plutôt dans une approche marketing : le client doit acheter le service non pas pour le service lui-même mais pour ce qu’il va faciliter, améliorer et rendre plus rentable dans ses propres activités.

Pour savoir si un service doit être proposé, il faut se poser la question essentielle : est-ce que cela va intéresser un client ? Un client ne l’achètera que s’il y trouve un intérêt : la valeur apportée par le service doit être supérieure au prix demandé (quel que soit la manière dont il sera réglé : budgets, facturation, etc.).

Il faut donc s’intéresser aux différentes populations de clients potentiels.

Un fournisseur de services est une entité logique fournissant un ensemble de services à des clients. Il est constitué d’équipes internes (organisation informatique) et de sous-traitants extérieurs qui sont d’autres entités juridiques.

La notion de fournisseur de services est une notion relative. En effet, pour l’un des sous-traitants, l’organisation informatique est pour elle un client car elle va fournir des services spécifiques à cette organisation informatique.

Cette dernière devra intégrer les services fournis par les sous-traitants dans sa propre fourniture de services.

Les services sont donc imbriqués les uns dans les autres. En réalité, ils sont inter-connectés et inter-dépendants : un service de sous-traitant entrera dans la fourniture de plusieurs services de l’organisation informatique.

Enfin, pour rendre cohérente la vision d’ensemble, les propres équipes de l’organisation informatique vont aussi être sollicitées pour fournir des services (au même titre que les sous-traitants) entrant dans la composition des services fournis aux clients.

Nous allons voir comment certains critères simples permettent d’éviter l’inflation du nombre de services en limitant au strict nécessaire ce nombre et d’éviter les « délires » conceptuels inapplicables dans le monde réel.

Une première séparation est à faire entre les services « finaux » destinés aux clients du fournisseur de services (les services d’affaires ou business) et les autres services sous-tendant la fourniture et le support de ces services à l’intérieur du fournisseur de services avec les équipes internes et les sous-traitants (services d’opérations ou techniques).

Nous reviendrons par la suite sur un découpage plus fin de ces deux catégories de service.

2.2. Issu de la gestion du portefeuille de services

Au niveau stratégique, la démarche d’élaboration du portefeuille de services passe par une étape permettant d’identifier les gains de performance et d’apport de valeur aux futurs clients dans leurs activités. Dès qu’il y a une possibilité économiquement viable, le fournisseur de services peut imaginer un service qui sera en premier lieu défini par son apport de valeur.

Par exemple, dans un processus d’affaires permettant de gérer des prêts vendus à des clients de la banque, l’un des traitements de flux (workflow) consiste à traiter la demande de prêt d’un client, à déterminer si le prêt peut être accordé (gestion de risque) et, si c’est le cas, à quel taux le proposer.

Ce processus d’affaires peut clairement être facilité par l’utilisation d’un service informatique pour lequel l’objectif détaillé est :

Accroître le nombre de demandes de prêt traités dans les temps

Lorsque le fournisseur de services a identifié diverses opportunités de ce type, il pourra ensuite les regrouper (le regroupement doit se faire sur des critères cohérents) et empaqueter (package) l’ensemble sous la forme d’un service d’affaires.

L’ensemble des apports de valeur élémentaires permettra de définir les métriques du futur service d’affaires sur son aptitude à créer de la valeur.

Un service est une notion permettant de séparer ses constituants de ce qu’il apporte comme intérêt à ceux qui l’utilisent.

C’est en quelque sorte une interface entre ceux qui fournissent et ceux qui en profitent.

En échange d’un prix payé, le client va tirer une valeur lors de l’utilisation du service. Par contre, le service est bien défini dans sa globalité et le client ne veut absolument pas connaître la manière dont est fabriqué, fourni et géré (en particulier les coûts unitaires et les risques à fournir un fonctionnement normal du service).

Seul le résultat (facilitation et performance des activités métiers) compte pour le client. Ceci est pourquoi le client achète un service et sera matérialisé par l’apport de valeur du service.

Le service doit répondre à deux critères prédéfinis, à savoir les fonctionnalités apportées (l’utilité du service) et les niveaux de service (garantie). Pour la garantie, il doit répondre à ces questions :

• est-il accessible au moment où les utilisateurs en ont besoin ?

• est-il suffisamment dimensionné pour supporter la charge des utilisateurs ?

• est-il sécurisé dans la gestion et le stockage de mes données métiers ?

• est-il suffisamment sécurisé en cas de catastrophe à l’informatique pour me fournir un service minimum si le service est vital pour moi ?

1.2. Composantes d'un service

Afin de fournir un ensemble complet et cohérent (le service), le fournisseur doit combiner l’utilisation efficace et efficiente d’éléments (actifs de service).

Ces éléments se répartissent en trois familles distinctes :

• la technologie

• les processus

• les personnes qui vont gérer la technologie et intervenir dans les processus

Lorsque le fournisseur devra gérer le détail des coûts et des risques, il le fera en gérant en termes de coûts et de risques les technologies mises en place, les processus mis en œuvre et les personnes qui vont intervenir.