Pourquoi différencier les request des incidents

De nombreuses entreprises traitent le processus de request avec les mêmes outils que le processus d'incident. C'est bien de traiter des requests mais c'est dommage de ne pas optimiser les request.

En effet, les incidents concernent un perte de service, sa restauration est donc difficilement prévisible, tandis que les request concernent le traitement de de besoin récurrent. On sait (ou devrait savoir) qui doit les valider, qui doit les traiter. On sait également quelles sont les informations dont on a besoin de la part du demandeur.

Traiter ces request dans un workflow, avec un formulaire spécifique permet donc d'industrialiser leur traitement. Cela veut dire moins de temps perdu, moins de répétition et plus d'efficience, aussi bien pour les utilisateurs que l'informatique.

Faut il une cmdb pour un processus de change ?

Et bien aussi surprenant que cela puisse paraitre, j'ai decouvert chez un client un processus de change très mature qui tourne régulirement sur des CI générique. En effet, ce processus a un fort pouvoir de standardisation dans la planification et la réalisation de l'infrastructure.
Mais j'ai fait remarqué qu'une part importante de la plus value de ce processus était perdue : l'historique. En effet, faire un changement sur un serveur ou une application permet de garder un historique des modifications. Ne pas lier le change sur un CI précis ne permet donc d'avoir ce suivi dans le temp.