Blog de Youssouf Chotia

Article intéressant  qui pose la question de l'interdépendance entre ces 2 process majeurs. Ou la question de l'oeuf et de la poule réinventée ?


Si vous mettez en place une gestion du changement sans gérer votre configuration, comment vous allez qualifier les impacts indirects générées par la modification d'un élément ?

Si vous gérez votre configuration sans gérer le changement, comment est ce que votre configuration sera maintenue à jour ? (les solutions de découverte automatique sont une aide précieuse mais ne fonctionnent pas avec tous les CI)


Dans la réalité je pense qu'au délà du débat réthorique, il n'est pas forcément abérrant de partir d'abord sur la gestion des changements pour plusieurs raisons :

 
- Il existe souvent un embryon de CMBD dans toute production. (que ce soit une micro base de données ou le fameux fichier excel ...) On peut donc partir de cet existant même partiel.

- La gestion des changements implique une réflexion globale ; à la fois sur les technologies (soft, hard) mais aussi sur les impacts utilisateurs et les niveaux de service.
Commencer par le changement c'est donc dès le départ se positioner dans une logique de service qui englobe la partie technique.

- La gestion des changements est moins "naturelle" mais peut apporter des quick wins beaucoup plus vite que la gestion des configurations.