Combien de niveau d'intervention pour traiter un incident ?

En règle générale, on a trois niveaux :

1. Service Desk dont l'objectif est de qualifier l'appel. C'est à dire de définir quelle est sa priorité, le service impacté... Il doit aussi trouver des solutions pour restorer le service, même de façon très provisoire. C'est la que la base de connaissance prend tout son sens
2. niveau intervention dont l'objectif reste assez généraliste mais peut se déplacer sur site si nécessaite
3. niveau expert dont l'objectif est de restaurer le service quoi qu'il en soit. Si un transfert de compétence est bien réalisé de ce dernier niveau sur les précédents, le nombre d'incidents traité à ce niveau doit être très faible.

Il arrive de trouver plus de niveau suivant la complexité de l'organisation.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Existe-t-il différents types de services dans un catalogue de service ?

Pour ma part, je préfère catégoriser les services en deux domaines bien distincts :

• Business Services
• Technical services

Leurs structures et leurs attributs sont les mêmes. Seul change les consommateurs des services. Pour le premier, on aura des clients Business et pour les seconds, on aura uniquement des clients techniques (du service informatique).

Différentes remarques :

1. Les collaborateurs du service informatique peuvent consommer des services des deux types, suivant si les raisons proviennent du fait de leur travail spécifique dans l'IT ou du fait d'être collaborateur. Par exemple, un responsable Citrix sera client Business pour User Environment et technical service pour Hosting Server.
2. Les Business Services auront des SLAs associés entre les clients et l'IT tandis qu'on parlera de OLA pour les technical services puisqu'il régit la relation entre deux services IT.

Voici un schéma représentant la différence entre les deux et leur connexion.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est ce que "Messagerie" est un service distinct du service "Environnement client" ?

Pour cette question, pas de réponse franche. En effet, cela va dépendre de l'approche choisie de l'entreprise. Pour ma part, je serai plutôt rétissant de le proposer dans un Business service indépendant.

J'aurai tendance à l'intégrer comme un service technique qui supporte le Business Service "Environnement client". En effet, la messagerie est une clé de voute de l'infrastructure. Mais cel n'est pas une application métier en temps que tel sinon une application bureautique.

Voici les raisons qui justifie ce choix :

1. L'ensemble des utilisateurs de l'IT ont un accès à la messagerie (il est rare de fournir un acces au système d'information sans fournir une adresse e-mail)
2. Ce service doit être géré au même titre que l'image fournie sur le poste (contenant le système d'exploitation), ou le réseau, également indispensable pour l'utilisateur.
   Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce que les Business Services sont dans la CMDB ?

Les Business sont dans deux référentiels :

• Le catalogue de service : en effet, ils peuvent être commandé par un ou plusieurs utilisateurs. Ce sont donc intégralement des éléments du catalogue
• La CMDB : comme tout élément décrivant l'infrastructure informatique, on doit les retrouver dans la base des configurations afin de pouvoir leur rattacher les utilisateurs qui les consomment, les éléments logiciels et matériels sur lequel repose le service.
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce qu'un Workaround génère toujours une erreur connue ?

Dernièrement, la question s'est posée lors de la configuration du processus de problème. En effet, il était nécessaire de savoir si le renseignement d'un workaround (solution de contournement) devait obligatoirement définir le problème comme une Known error (erreur connue).

En fait, tout réside dans l'adverbe. En effet, dans de très nombreux cas, un workaround sera trouvé lorsque l'origine du problème aura été défini et donc l'un devient la conséquence de l'autre. Mais cela n'est pas obligatoire.

Dans de nombreux cas, un workaround sera trouvé sans qu'on puisse déterminer l'origine. En voici quelques exemples :

• ordinateur plante régulièrement, je reboot. On n'a bien un workaround mais on ne sais pas pour autant la raison du plantage.
• un batch plante une fois sur 10. Relancer le batch si tous les tests ne sont pas valides. Même chose, on a bien un workaround mais on ne sait toujours pas pourquoi il lui arrive de planter.
   

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Comment mettre en place le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Revivew. A chaque début de CAB, il doit être pris 10 minutes afin d'étudier les changes réalisés 3 ou 4 semaines plutôt. Il suffit alors de répondre à quelques questions dessus tel que :

• Réalisé dans les délais annoncés ?
• Utilisateurs impactés ?
• Incident généré depuis le change ?
• Dysfonctionnement résolu ?
• Autres remarques ?

Des statistiques issues de ces résultats servent alors au pilotage de ce processus et de s'assurer qu'il répond au besoin premier : permettre de modifier l'infrastructure en maîtrisant les impacts aussi bien techniques que des utilisateurs.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Pourquoi plusieurs processus suivant le type de changement ?

Dans la mise en place du processus de changement, il arrive qu'on ne mette en place qu'un processus de changement quelque soit son type. Pour rappel, un changement peut être majeur, significatif, normal ou urgent.
Dans de nombreux cas, le change urgent reste relativement indépendant des autres car il est souvent traité hors outil, pour son caractère urgent,

Pour les autres types, il est conseillé de mettre en place des processus différents, notamment pour la validation du CAB (change Advisory Board). En effet, mettre en place un processus qui répond au processus majeur sera lourd et cher pour les changes normaux. De l'autre, un procesuss simple risque de décider des changes significatifs sans avoir pris en considération tous les paramètres.

C'est pourquoi, un unique processus peut faciliter la mise en place de ce processus, mais il est nécessaire rapidement de déployer tous les cas adaptés à chaque type.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...