Blog

Gestión de cambios madura antes de madurar su CMDB

Publicado por de junio 06, 2017

Gestión de cambios madura antes de madurar su CMDB

Demasiados proyectos CMDB se han convertido en agujeros negros, absorbiendo recursos y la vida de TI con muy poco a cambio. A pesar de los enfoques más pragmáticos en estos días, Gartner1 afirma que más de la mitad de los esfuerzos de CMDB se vuelven inmanejables. Teniendo esto en cuenta, ¿cuánta información debe ingresar en su CMDB y cuándo? Se han escrito cientos de artículos y libros completos 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. En aras de la brevedad, condensaré esto en una publicación de blog.

Proceso de adopción y una jerarquía de necesidades

Es con buena razón que la gestión de incidentes y cambios encabezar la lista de los procesos ITSM o ITIL más comúnmente adoptados. Los "tres grandes" suelen incluir la gestión de problemas, incluso si este proceso específico no suele ser muy maduro. El nivel de servicio y la gestión del conocimiento suelen completar los cinco primeros procesos adoptados. Y a medida que el autoservicio se vuelve más común, Service Catalog y Request Fulfillment se unen al escalón superior de los procesos implementados.

Si bien necesita conocer el elemento de configuración (CI) cuando maneja un incidente o administra una solicitud de cambio, el alcance de la administración de la configuración y la adopción de CMDB varía ampliamente. Como comida y refugio en jerarquía de Maslow de necesidades, todos los mostradores de servicio rastrean los IC hasta cierto punto. (Y es interesante que el modelo de Maslow y los modelos de madurez populares como CMMI or Puntuación de TI de Gartner todos tienen cinco niveles.) Ya sea que se llame un repositorio de datos maestros (MDR) o un CMBD, una mesa de servicio tendrá este tipo de información básica de CI para respaldar sus procesos centrales de administración.

Gestión de servicios y el Santo Grial CMDB

Si bien muchos procesos se benefician de la visibilidad que proporciona una CMDB, la mejora de la gestión de cambios sigue siendo un factor importante para implementar una CMDB con reconocimiento de servicios. Las interrupciones del servicio autoinfligidas debido a “colisiones” de cambios han sido una pesadilla para los equipos de TI durante años. Comprender las dependencias y relaciones entre los servicios, las aplicaciones y la infraestructura ayuda a identificar posibles colisiones durante una fase de evaluación de impacto, en lugar de después de que llega a producción.

Para abordar el enigma del riesgo de colisión de cambios, la información de CMDB, incluidas las dependencias, debe ser precisa. A medida que los entornos de TI escalan 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 la detección de "cambios no planificados" y su gemelo, la "deriva de la configuración", que son aspectos comunes de los programas de gestión de seguridad y cumplimiento.

Si fuera tan simple. Los esfuerzos de CMDB continúan teniendo dificultades por varias razones, pero con mayor frecuencia, se relaciona con el alcance excesivo, es decir, poner demasiada información en una CMDB o intentar mapear demasiadas aplicaciones o servicios a la vez, especialmente al comenzar.

Lo primero es lo primero: gestión del cambio maduro

Regreso a los modelos de madurez por un momento. Antes de que la TI pueda alcanzar la autorrealización, optimizarse o convertirse en un socio comercial, la TI debe tener procesos definidos que las personas realmente sigan. Para complicar las cosas, Change Management es uno de los procesos más altamente personalizados debido a las diferencias entre las organizaciones en cuanto a qué cambios pueden estandarizarse o automatizarse, el grado de supervisión regulatoria, lo que está sujeto a la Gestión de cambios o configuración, y más.

Antes de estratificar el análisis de impacto basado en servicios, debe tener procesos razonables y bien definidos que seguirá el departamento de TI, en lugar de procesos excesivos que se omiten o se "solucionan" 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 eficacia de la gestión de cambios y deben realizarse antes de agregar visibilidad a las dependencias de los servicios.

Con el auge de DevOps, también recomendaría evaluar su proceso de Gestión de cambios para incorporar tamaños de lotes más pequeños que se pueden clasificar como cambios estándar de ITIL®. Estos cambios pueden luego 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 buscar mejor la gestión basada en servicios y madurar su CMDB agregando mapeo de dependencia de aplicaciones.

Siguiente: vea cómo Cherwell admite procesos clave de ITIL, incluida la gestión de cambios

Aprenda Más

Referencia
1 Gartner: implemente la gestión de cambios y configuración de TI antes de desarrollar una CMDB
Publicado: 3 de enero de 2017 ID: G00318869

Ivanti adquiere Cherwell para ofrecer experiencias personalizadas a los empleados en cualquier lugar de trabajo

Obtenga los consejos, la orientación y los casos prácticos líderes en la industria de Cherwell para una mejor gestión del servicio que ayude a su empresa a cumplir, directamente en su bandeja de entrada.

* Por favor complete el campo de correo electrónico