A veces, la realidad es peor que la expectativa, como en los ejemplos anteriores; , pero también puede ocurrir lo contrario. Por ejemplo, cuandono hacemos algo porque es demasiado difícil, cuando podríamos haberlo logrado con el conocimiento y enfoque correctos.
Este artículo analiza tres suposiciones incorrectas comúnmente aceptadas y las falencias en las expectativas de ITSM. ¡Esperamos que te sirvan!
Expectativa #1: Que implementar una CMDB es demasiado difícil
De acuerdo, no vamos a mentir: la implementación de una base de datos de gestión de la configuración (CMDB) no es de las tareas más fáciles de ITSM, pero agregará valor de muchas maneras. Desde categorizar incidentes más fácilmente, a través de una mejor gobernabilidad, hasta hacer una evaluación de impacto más precisa al revisar cambios.
Implementar una CMDB es una tarea importante, pero el estrés inicial definitivamente vale la pena. La clave es no intentar hacer (ni lograr) demasiado a la vez.
Divide el trabajo requerido en partes pequeñas y alcanzables, para aliviar la presión y reducir el impacto en los equipos involucrados. Por ejemplo, utilizando los siguientes pasos y consejos:
- Mantenlo simple. Siempre es más fácil construir con el tiempo o agregar cosas a medida que avanzas. Cuantos más atributos de elementos de configuración (CI) agregues, más detalles deberás mantener en el futuro. Así que comienza con lo mínimo y aumenta con el tiempo. Es importante que recuerdes agregar donde hay una demanda para los datos.
- Hazlo alcanzable. Comienza con tu servicio más conocido y fácil de soportar , y planifícalo de punta a punta. Esto te permitirá familiarizarte con el proceso de mapeo de servicios y CI, así como con todos los atributos, relaciones y peculiaridades. Al comenzar con un servicio fácil, ganarás confianza y el próximo servicio no parecerá tan desalentador.
- Realiza un ejercicio de revisión. La forma más rápida y fácil de verificar que los datos sean correctos es que la gente los use. Solicita a los analistas de la mesa de servicio que intenten categorizar incidentes y solicitudes de servicio utilizando la CMDB. Pide a los equipos de soporte que realicen cambios con los servicios afectados marcados en la CMDB. Esta es una excelente manera de incorporar formas de trabajo y aumentar la confianza.
- Hazlo de nuevo. Utiliza ese primer servicio probado como un prototipo. Una vez que lo tengas, tendrás un enfoque que funciona. Repite el proceso para el próximo servicio y el siguiente, y así sucesivamente. ¡Sigue avanzando hasta que hayas capturado todos tus sistemas más críticos y así tendrás una CMDB completamente funcional!
Expectativa #2: la gestión del cambio es simplemente demasiado
Si tu capacidad de cambio es vista como una preocupación y un problema en lugar de un facilitador de negocios, entonces algo estás haciendo mal. La Gestión de Cambios (o el Control de Cambios, utilizando la nueva terminología de ITIL 4) tiene muchas opciones para hacer que las cosas fluyan más rápido y, al mismo tiempo, permitir que el trabajo se realice de manera efectiva, eficiente y segura.
Lo primero que hacemos cuando implementamos cualquier capacidad de administración de cambios es pasar tiempo con los equipos de soporte de infraestructura y aplicaciones. Les pedimos que nos hablen sobre todos los tipos de trabajo que realizan, y creamos un banco de plantillas para que solo tengan que seleccionar la plantilla adecuada y completar la fecha, en lugar de tener que completar la misma información cada vez.
Lo que hacemos después es ver si alguna parte de estetrabajo es rutinaria y de bajo riesgo, de manera que pueda ser preaprobada. Este tipo de cambio se denomina cambio estándar y, si se hace bien, puede marcar una gran diferencia en la eficiencia de tu proceso de cambio. Es verdaderamente importante que te sientes con tus equipos de soporte y escriban todo, porque hace la vida mucho más fácil para todos los involucrados. Tú obtienes los detalles que necesitas, y para ellos es fácil y rápido plantear un cambio. ¡Todos contentos!
Otro método para aumentar la fluidez del cambio es usar tableros Kanban para reducir o incluso reemplazar el consejo asesor de cambios (CAB). Cuando se utiliza el enfoque Kanban, los elementos de trabajo se representan visualmente en un tablero, lo que permite a los miembros del equipo ver el estado de cada trabajo en cualquier momento. Esto brinda a los equipos más flexibilidad, un enfoque más claro y transparencia a lo largo de los ciclos de vida de desarrollo e implementación. Combinado con la delegación de autoridad, por la que un cambio puede ser aprobado por un propietario de servicio predeterminado, se podría eliminar la reunión regular de CAB o, al menos, tenerla como excepción en vez de como regla.
Expectativa #3: los incidentes y los problemas son (y pueden tratarse como) lo mismo
¡No! ¡Los incidentes y los problemas son dos cosas completamente diferentes!
En resumen, la gestión de incidentes es la capacidad que hace que el equipo (y los usuarios finales) se vuelvan a alinear lo más rápido posible. En tanto,la gestión de problemas tiene que ver con la identificación de la causa raíz de los problemas y el progreso hacia una solución.
La gestión de incidentes se ocupa de coordinar el incidente, gestionar las comunicaciones con los equipos de soporte técnico y los clientes empresariales, y de garantizar que el problema se solucione lo antes posible. Además, alimenta a la gestión de problemas marcando a los conflictos reincidentes y dando soporte a los incidentes grandes, siendo amboscandidatos para el análisis de tendencias y la resolución de la causa raíz.
La gestión de problemas, por otro lado, se centra en la investigación de la causa raíz, las tendencias, la búsqueda de una solución y la seguridad de que las lecciones aprendidas estén documentadas y se apliquen. La gestión de problemas soporta la administración de incidentes al crear problemas y errores conocidos, para vincular los incidentes e identificar soluciones, de manera que el usuario final continúe trabajando mientras se avanza hacia una solución más permanente.
Evidentemente, los incidentes y los problemas deben ser vistos y tratados de manera diferente. De lo contrario, ¡probablemente solo estés haciendo gestión de incidentes!
Aquí hemos proporcionado tres ejemplos de diferencias en las expectativas de ITSM versus la realidad, pero ya escribimos un artículo bastante largo. ¿Deberíamos escribir otro? Por favor, haznos saber si eso ayudaría.
¿Qué problemasde expectativas en ITSM agregarías? Por favor, déjanos un comentario.
