ITIL: ¿Qué es un cambio?

Me ha pasado de ir a muchas organizaciones que tienen problemas en la implementación de un proceso de Change Management debido a la falta de definición de que es un cambio...

Recurramos a la definición que nos da ITIL sobre lo que es un cambio:

"Alta, Baja o Modificación de cualquier cosa que pudiera afectar un servicio de IT"

De la definición podemos inferir que cualquier cosa que afecta un servicio de IT tiene que ser gestionada y cualquier cosa que tiene que ser gestionada, en ITIL se define como un configuration item (CI).

Entonces podemos decir que el alcance de Change Management son todos los configuration item (CIs).

Parece que pateamos la pelota para adelante....ahora que es un CI?
"Un CI es cualquier componente o activo de un Servicio de IT."

• Servicio IT es un CI?
• SI. Podemos decir que la definición de un CI es recursiva. Como analogía: Un auto es un CI, que se compone de  ruedas, que son CI, que se componen de llantas que es un CI, etc.... Un Servicio de IT es como el auto. "Un componente compuesto de componentes".
• Componente Hardware?
• SI. Seria como una rueda en el ejemplo anterior.
• Componente Software?
• SI. Una aplicación, Sistema Operativo, herramientas, componentes de aplicaciones, etc.
• Componentes Virtuales?
• SI. Servidores Virtuales, Storage Virtual, Clouds son un activos de un servicio.
• Edificio u Oficina o Sector o Locación?
• SI. Las facilities donde ser brinda un servicio son CI. Pensemos, ¿no nos interesa saber donde se brinda un servicio?
• Personas?
• SI. Nuevamente, ¿no nos interesa saber quienes son las personas asociadas al servicio, que lo brindan o que lo consumen?
• Documentación asociada al servicio?
• SI. Diagramas de arquitectura, SLAs, Manuales de usuario, Contratos, Métricas, Documentación de proceso, etc. 
• Estrategia de Negocio?
• NO. Usualmente la estrategia de negocio, cambios organizacionales, etc, no son tomados como CIs.

Como primera recomendación uno puede decir que primero se definan cuales son los servicios de IT, después se descomponga cada servicio granularmente en cada componente y luego cada componente queda bajo control de Change Management.

Ejemplo:

• Servicio de Correo Electrónico
• Webmail
• Servidor de aplicaciones Apache
• Maquina Virtual 1
• Virtualizador A
• Servidor Rackeable I
• Microprocesador #

Así sucesivamente podemos ir descomponiendo un servicio en componentes y ver cuales son los que si sufren un ABM, afecta al servicio. (Afectar al servicio es que tengan un impacto, no que produzcan una interrupción).

Por este motivo me parece muy saludable implementar Change Management junto con Service Asset & Configuration Management.... pero la verdad es que pocas veces pasa....Es mas, la mayoria de las empresas empiezan a implementar Change Management antes de pensar en servicios...

Otro punto importante que me gustaría destacar, es que normalmente se piensa que Change Management solo aplica cuando un servicio esta operativo, pero el verdadero alcance del proceso es mas amplio, el diseño de un servicio también debería estar alcanzado por Change Management (Requerimientos funcionales, Recursos previstos, Capacidades, Herramientas, Arquitectura tecnológica, procesos, métodos de medición, métricas, etc).

Ahora bien, la primera reflexión que suelo recibir, es que el alcance de Change Management es muy amplio, que es impracticable, tengo que pedir permiso hasta para reiniciar un servidor, que necesito un batallon de gente desarrollando las actividades de Change....

Por suerte existe la clasificación de los cambios, pero eso lo veremos mas adelante!