Las métricas de ITSCM no son solo el número de invocaciones

La identificación de métricas de ITSCM para el seguimiento y control no siempre resulta igual de sencillo para según qué proceso. Cuando se habla de gestión de incidencias, peticiones, problemas, cambios,... todo resulta más o menos fácil (al menos a priori), pero cuando hablamos de otros procesos como la gestión de continuidad, la cosa se complica, y se acaba midiendo por medir. Veamos algunas ideas...

Cuando se definen las métricas o indicadores para controlar un proceso, lo primero que hay que tener claros son los objetivos: qué se quiere conseguir, qué se quiere controlar, cuál es la meta a la que se quiere llegar, y con todo eso perfectamente claro, habría que definir las métricas apropiadas.

 En la realidad, (tristemente) muchas veces se comienza un proceso de medida estándar, out-of-the-box, y en función de los “dolores” que se identifiquen en esas primeras mediciones, se van tomando las decisiones oportunas, y se van ajustando las métricas de seguimiento. No digo que sea ni mucho menos la mejor manera de hacerlo, pero hay que reconocer que es una realidad 🙁

Las métricas de ITSCM 

Dando por bueno (o al menos por válido) el planteamiento anterior, el problema es: ¿qué se puede medir para ITSCM? Lo evidente es medir el número de invocaciones a los planes de recuperación, pero precisamente esa media no ayudará mucho a madurar el proceso. Aquí van algunas ideas alternativas que sí creo ayudarán a establecer una hoja de ruta para la mejora:

• ¿Para cuántos servicios del catálogo no se ha realizado un BIA? Si no lo tienen, quizá una mejora sea realizarlo y determinar el impacto real en el negocio de una hipotética indisponibilidad.
• ¿Cuántos BIAs tienen una antigüedad superior a un determinado umbral temporal? Para los que hayan excedido ese umbral, quizá sea hora de revisarlos.
• ¿Para cuántos servicios críticos no se ha realizado un análisis de riesgos? Sería un buen momento para hacerlo 😉
• ¿Hace cuánto que no se revisa el impacto de los riesgos que afectan a los servicios más críticos? Esta revisión debería hacer con cierta frecuencia, no vaya a ser que cambie.
• ¿Cuántos servicios críticos no tienen un DRP vinculado? Esto no debería ocurrir…
• ¿Cuántos DRPs no han sido probados y revisados en los últimos X meses? Los DRPs siempre deberían estar al día…
• Tras un cambio “grande” a un servicio o elemento de infraestructura crítica, ¿se han revisado los DRPs relacionados con ese servicio / CI? Siempre debería hacerse, y si no es así, habría que ir planificando esa revisión.
• ...

Son solo algunos ejemplos, en absoluto un listado exhaustivo, y  está sesgado desde un punto de vista de ser “abogado del diablo”, buscando identificar situaciones no deseables con una solución no muy compleja, como puede ser realizar las revisiones, realizar o actualizar los BIAs,... Una de las principales dificultades del proceso ITSCM, no es implantar y generar y los entregables oportunos, sino manetnerlos a lo largo del tiempo, y la mayoría de las métricas anteriores ayudarán precisamente a mejorar ese aspecto.

Alejandro Castro