Implanter un Centre de Services

2. Implanter un Centre de Services

2.1. Les règles de base

La conception est critique pour le succès et doit être conduite comme un vrai projet (sponsor, objectifs, responsabilités, livrables et gestion du projet).

C'est aussi une opportunité d’évaluer l’existant.

Il ne faut pas penser uniquement en termes d’automatisation de processus manuels et d’activités. Il faut aussi considérer les points suivants :

  • augmenter la productivité,

  • création de valeur ajoutée,

  • réduire les coûts,

  • améliorer la perception qu'ont les clients de la Production Informatique

L’équipe projet

Ce que l'on constate, c'est que, d'une manière générale, les ressources internes sont occupées en grand partie sur la gestion au jour le jour , ce qui sont des activités assez imprévisibles en charge.

Il est souvent nécessaire de prendre des ressources externes.

Le chef de projet doit avoir de solides connaissances en Service Management et doit avoir déjà mis en place un Centre de Services dans l'idéal.

Il sera nécessaire de communiquer avec les clients et les utilisateurs sur l’évolution de la mise en place.

Il faut aussi intégrer dans l’équipe projet des internes avec des formations éventuelles à prévoir pour ces personnes.

2.2. Définir les métriques cibles pour le succès du Centre de Services

Attention : après la mise en place, les métriques mesurées seront comparées aux métriques cibles donc ben les choisir.

Quelques règles simples :

  • ne pas définir d’objectifs ne pouvant pas être mesurés

  • objectifs nécessaires et viables (en rapport avec la réalité)

  • établir une base de références (baseline) sur les Incidents et demandes avant les discussions sur les Contrats de Niveaux de Services (SLAs)

  • utiliser des modèles standards de SLAs pour identifier des métriques

La base de références doit être collectée sur au moins deux mois (types, volumes, niveaux de services, ressources)

2.3. Les principes clés

Il faut définir clairement les besoins de l’entreprise et adopter une approche par phases :

  • ne pas essayer de tout mettre en place en une seule fois

  • identifier, détailler et communiquer sur des objectifs à atteindre rapidement

Il faut aussi impliquer les Clients et les Utilisateurs (attention au jargon technique) et communiquer et vendre le projet

Le projet se gagne autant sur la partie communication que sur la partie technique et organisation.

2.4. La structure du Centre de Services

Il n'existe pas de réponse toute faite.

Trois types identifiés dans la documentation ITIL® :

  1. organisations locales

  2. organisation centrale

  3. organisation « virtuelle »

L'organisation « virtuelle » est une combinaisons entre 1. et 2.. Elle est rendue possible avec les progrès technologiques (téléphonie, réseaux) et permet d’optimiser les ressources et les coûts.

Les seuls critères importants qui restent sont : la structure de l’entreprise, les utilisateurs et les services à fournir

2.4.1. La structure de l’entreprise

Les critères principaux à prendre en considération sont :

  • un site, mono-sites

  • externalisation de services à des sociétés tierces

  • circuits d’escalade exhaustifs (centres délocalisés et en central, supports locaux et centraux, niveaux de support)

2.4.2. Les utilisateurs

Les critères principaux à prendre en considération sont :

  • nombre, répartition géographique

  • jours et heures de support (décalages horaires)

  • langues, cultures

  • niveau des utilisateurs

2.4.3. Les services

Les critères principaux à prendre en considération sont :

  • objectifs et livrables pour les activités de l’entreprise

  • nombre d’appels traités

  • applications (progiciels, outils spécialisés, développements internes) et domaines supportés

2.5. Classification des Incidents

L'un des éléments les plus importants pour le traitement correct des Incidents est la classification de l'Incident.

Les classifications vont permettre de traiter efficacement les points suivants :

  • identifier le service ou l'équipement impacté

  • associer à un Contrat de Niveaux de Services

  • sélectionner le spécialiste qui traitera l’incident

  • définir la priorité et l’impact

  • mot-clé pour la recherche dans les solutions, Erreurs Connues et Solutions de Contournement

Il faut définir une première version pour la remontée d’informations. Elle sera complétée et affinée par la suite.

Lors de la fermeture d'un Incident, la classification finale peut être différente de la classification initiale.

Lorsqu'un Incident est clos, il peut être intérressant de définir un code de fermeture (résolu, formation utilisateur requise, modification documentation, demande de changement à lancer, etc.).

La classification des Incidents est à revoir régulièrement. Cela permet de suivre l’évolution des Services et d'ajuster (détailler, grouper) la classification existante au fil du temps.

A la mise en place du Centre de Services, il ne faut pas définir trop de détails car des difficultés apparaîtront ensuite au démarrage pour classer un Incident.

Il ne faut pas hésiter à créer un code « Inconnu » ou « Impossible à classifier » pour les problèmes complexes. Il faut démarrer simple puis affiner et ajuster ensuite régulièrement.

Précédent : Vue d'ensemble

Suivant : Les technologies