A quoi correspond une demande d'information ?

J'entends par demande d'information des questions tel que "Comment imprimer dans cette application ?" ou "Qui dois-je contacter pour obtenir les informations suivantes ?"... Il ne s'agit pas d'incident car il n'y a pas de perte d'information.

Pour ma part, je recommande de pouvoir les traiter au niveau du Service Desk. En effet, en plus de pouvoir catégoriser les contacts entrants comme incident, demande, erreur... il doit exister une type information. Et la base de connaissance doit être suffisamment complète pour que l'opérateur puisse répondre directement.

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

Comment justifier le processus de problème ?

On vient de voir à quoi peut servir ce processus.

Pour justifier son implémentation, il est possible de commencer par regarder les incidents dont la date d'échéance est passée depuis plusieurs jours, voir souvent plusieurs semaines. Lorsqu'on creuse ces cas, on se rend compte qu'ils sont restés ouvert car on attend une migration, on n'est pas sûr de la résolution apportée... Il s'agit de toute évidence de problème géré dans le processus d'incident. Démarrer par ses cas le processus de problème permet de présenter l'avantage de ce processus : supprimer ces incidents dont l'impact sur les niveaux sont effroyables.

Par cette démarche, les opérateurs vont alors commencer à comprendre l'utilité du processus de problème pour sa part réactive.

Traiter les problèmes pro-actifs devra se faire dans une seconde étape. La maturité du processus aide alors et la mise en place est naturelle.

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

A quoi sert le processus de problème ?

Si les processus d'incident  et de change sont devenus naturels dans les entreprises, le lien entre les deux est souvent flou. En effet, le processus de problème est souvent difficile dans son appréhension. Et pourtant lorsqu'on creuse le sujet, il apparait qu'entre un incident déclaré par un utilisateur dont l'origine est inconnue et la mise en place du changement pour corriger, une étape est évidente : la recherche de l'origine et la définition des modifications nécessaires à apporter.

Et bien le processus de problème permet justement de traiter cette phase.

Le processus d'incident a des exigences fortes en terme de délai de traitement pour remettre à niveau le service, le temps imparti ne permet donc pas de prendre le temps pour rechercher la cause.
Le processus de changement se concentre sur l'opportunité ou non de réaliser cette modification. Le détail du changement est donc déjà connu.

Le processus de problème a donc un objectif de mettre en place une Task Force qui va rechercher les origines techniques (ou fonctionnelles suivant le cas) pour présenter les bons changements à mettre en place.

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

Que valide-t-on dans le CAB ?

Pour rappel, le CAB est le Comité de Consultation des Changes. Un client m'a présenté un double processus de change afin de valider dans un premier l'acceptation ou non du point de vue fonctionnel ; ensuite pour valider la planification.


Cela génère un double change et donc une surcharge du processus. Dans le processus de change, on valide le change durant le CAB. Celui-ci est d'ailleurs constitué d'un représentant du Business et de technicien afin de pouvoir juger l'importance fonctionnelle des risques à prendre. La planification est simplement en avant de la réalisation et permet de traiter la file d'attente et de trouver un créneau sur les plages de maintenance pour positionner le change. En aucun cas, la planification n'a la possibilité de refuser un change, elle va au pire le planification pour une date très lointaine.

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