Change Management y CMDB ¿un agujero negro?

Demasiados proyectos CMDB se han convertido en agujeros negros, absorbiendo recursos y vida fuera de TI con poco a cambio. ¿Sabes cuánta información necesitas ingresar a la CMDB y en qué momento? Cientos de artículos y libros enteros se han escrito sobre este tema, sin embargo, éste entrada al blog haremos un resumen sobre cómo mejorar Change Management y ser el principal propulsor de una CMDB de servicio.

Adoptando Change Management, una jerarquía de necesidades

Ciertamente la Gestión de Incidentes y Cambios se encuentra en la lista de los procesos ITSM o ITIL más comúnmente adoptados. Los "Tres Grandes" suelen incluir la Gestión de Problemas, aunque este proceso específico frecuentemente no es muy maduro. El Nivel de Servicio y la Gestión del Conocimiento completan típicamente los cinco primeros procesos adoptados. Y a medida que el autoservicio se vuelve más común, Catálogo de Servicios y Cumplimiento de Solicitudes se unen al escalón superior de los procesos implementados.

Descarga la infografía: 5 Do's & Don'ts de la Gestión de incidentes

Aunque es necesario conocer el elemento de configuración (CI o Configuration Item) al manejar un incidente o gestionar una solicitud de cambio, el alcance de la administración de la configuración y la adopción de CMDB varían ampliamente. Todas las mesas de servicio controlan los CI hasta cierto punto. Ya sea un repositorio de datos maestros (MDR) o de un CMBD, un centro de servicio dispondrá de este tipo de información básica CI para apoyar los procesos centrales de gestión.

Gestión de servicios y CMDB

Mientras que muchos procesos se benefician de la visibilidad que proporciona una CMDB, la mejora de la Gestión de Cambios continúa siendo el principal impulsor para implementar una CMDB de servicio. Las interrupciones de servicio autoinfligidas debido a cambios "colisiones" han sido una pesadilla de los equipos de TI durante años. La comprensión de las dependencias y relaciones entre servicios, aplicaciones e infraestructura ayudan a identificar colisiones potenciales durante una fase de evaluación de impacto, en lugar de cuando llega a la producción.

Descarga la infografía: Incident Management Vs Problem Management

Para abordar el enigma del riesgo de colisión de cambio, la información CMDB incluyendo dependencias debe ser precisa. A medida que los entornos de TI se expanden y se vuelven más dinámicos, los medios automatizados de descubrimiento y la población de CMDB se vuelven esenciales. La combinación de tener información de configuración actual y registros de cambios permite además el "cambio no planificado" y su detección gemela, "desviación de configuración", que son aspectos comunes de los programas de cumplimiento y administración de seguridad.

Si fuera tan simple. Los esfuerzos de CMDB continúan luchando por varias razones, pero con mayor frecuencia se relacionan con el exceso de alcance, es decir, poner demasiada información en un CMDB o tratar de asignar demasiadas aplicaciones o servicios a la vez, especialmente al inicio.

Primero lo primero: manejo del cambio

Volver a los modelos de madurez por un momento. Antes de que la TI pueda alcanzar la autorrealización, ser optimizada o convertirse en un socio comercial, el área de TI necesita tener procesos definidos que la gente realmente siga. Para complicar las cosas, la Gestión del Cambio es uno de los procesos más personalizados debido a las diferencias entre las organizaciones en cuanto a los cambios que pueden ser estandarizados o automatizados, el grado de supervisión reguladora, lo que está sujeto a la Gestión del Cambio o Configuración y más.

Antes de superponer el análisis de impacto basado en el servicio, es necesario tener procesos bien definidos y razonables que seguirá, en contraposición a los procesos excesivos que se pasan por alto o "trabajados" con un proceso de cambio de emergencia con fugas. Esto incluye evaluar, autorizar / rechazar, programar y revisar cambios. Todas estas son tareas importantes para mejorar la efectividad de la Gestión del Cambio y deben hacerse antes de agregar visibilidad a las dependencias del servicio.

Con el aumento de DevOps, también recomendaría evaluar el proceso de gestión de cambios para incorporar lotes más pequeños que se pueden clasificar como cambios estándar de ITIL®. Estos cambios pueden moverse a través del proceso de una manera más automatizada. Una vez que estén en su lugar, la organización de TI puede perseguir mejor la administración basada en servicios y madurar la CMDB añadiendo mapeo de dependencias de aplicaciones.

Descarga el eBook: ITIL Made Easy, u descubre cómo integrar las soluciones adecuadas de automatización, a las personas, los procesos y la tecnología para hacer que la organización avance.

ITIL Made Easy: Procesos ITSM y mejores prácticas

Solicita una demostración de Cherwell Software

Por Chuck Darst, Cherwell Staff