Profil LinkedInImplanter 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® :
organisations locales
organisation centrale
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