Perdonad si soy ordinario, pero es que han pasado muchas cosas idiotas en mi oficina últimamente: por fin hemos inaugurado nuestra herramienta de Service desk, después de 9 meses de diseño y rediseño (el tiempo medio de implantación en otros clientes de 1 a 2 meses). Aunque inicialmente la ventaja de esta aplicación es que es ITIL compliant por lo que ayudaría a la adopción de procesos ITIL, el jefe del departamento ha decidido, ehrm, redefinir algunos conceptos de ITIL, especialmente algunos relacionados con la gestión de cambios y de SLAs.
Para empezar, ha creado un nuevo tipo de cambio: el Cambio Urgente. No tiene nada que ver con las emergencias, sino con la urgencia. ¿Qué es un cambio urgente? Un cambio que debe ejecutarse lo antes posible. Pero no a causa de una emergencia. Por ejemplo: un project manager quiere desplegar una nueva versión de su aplicación “Tal”, y lo quiere ahora. Esta nueva versión no resuelve un problema grave de la versión previa ni añade una funcionalidad o un requisito que el negocio necesita por imperativos legales o de cualquier otro tipo ni por cualquier otra razón que se te pueda ocurrir para elevar un cambio de emergencia porque, y este es el problema, no es una emergencia. Generalmente, se tratará de una fecha de entrega demasiado cercana y un project manager poco inclinado a asumir la responsabilidad del retraso de la entrega (para qué asumir la culpa cuando tienes a los de Sistemas y su gestión de cambios que “no desplegarán hasta la semana que viene porque nuestra petición ya no entra en el CAB”).
Donde yo veo una ardua resistencia a seguir el dictado que un marco de buenas prácticas da, mi jefe y sus colegas creen que han tenido una idea genial porque con los cambios urgentes pueden demostrar que están orientados al cliente. Y una mierda. Es pura cabezonería.
Y además, ¿qué narices? ¿¡¿De todos los libros de ITIL desde v1 hasta v3, dónde leches han leído ellos ese invento de los “Cambios Urgentes”?!?
Southern ITIL 