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.
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)
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.
La structure du Centre de Services
Il n'exsite 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
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)
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
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
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.
Source :
|
