Gestión del cambio antes de madurar su CMDB

Gestión del cambio antes de madurar su CMDB

Por Chuck Darst, Cherwell Staff

Demasiados proyectos CMDB se han convertido en agujeros negros, absorbiendo recursos y vida fuera de TI con poco a cambio. A pesar de enfoques más pragmáticos en estos días, Gartner1 afirma que más de la mitad de los esfuerzos de CMDB se vuelven incontrolables. Teniendo esto en cuenta, ¿cuánta información necesita ingresar a su CMDB y en qué momento? Cientos de artículos y libros enteros se han escrito sobre este tema, y llegar a una respuesta específica para una organización individual puede requerir semanas o meses de talleres y análisis de diseño, sin embargo, ésta entrada al blog consistirá en un resumen.

Adopción del proceso y 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.

Aunque es necesario conocer el elemento de configuración (IC) 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 sus procesos centrales de gestión.

Gestión de servicios y la 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.

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 cuando comienza.

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, la 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 su proceso de administración de cambios para incorporar tamaños de lote 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 su CMDB añadiendo mapeo de dependencia de aplicaciones.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *