Las mejores métricas

He vuelto a encontrarme con la pregunta del millón: ¿cuáles son las mejores métricas para gestión de X (donde X es cualquier proceso)? No he podido resistirme y he querido escribir un pequeño apunte sobre ello en este blog, y así intentar contestar a la pregunta.

Es cierto que ITIL® menciona y propone una cantidad de métricas muy grande. Quizá haya tantas métricas propuestas que el profesional se vea confundido, lo cual es perfectamente comprensible, y ocurre muchas veces. El origen de la pregunta está en qué métricas elegir, y eso no es trivial, pues la métrica es en lo que se va a basar el gestor para optimizar la generación de valor del servicio.

Para elegir las métricas tenemos que saber cuáles son los objetivos del negocio y analizarlos para traducirlos al lenguaje técnico, un análisis TOP-DOWN hacia nuestro lenguaje. El primer análisis nos dará muchísima información, llegando a las primeras métricas básicas necesarias (3, 5, 10... no importa el número). Aquí comienza nuestro primer ciclo de Deming o PDCA (concepto básico para cualquier norma o estándar).

En cuanto midamos y analicemos resultados (A), veremos si hacen falta más métricas (o menos, pues puede haber métricas que no nos den información relevante), y así volveremos a diseñarlas y planificarlas (P). Con conocimiento del negocio y ayuda sobre cómo obtenerlas, en cada ciclo tendremos las métricas que aporten información relevante a la hora de tomar importantes decisiones.

Significado de conseguir la certificación

En una de las redes sociales en la que estoy registrado, soy seguidor de una academia de idiomas que organiza no sólo cursos, sino grupos de conversación y tándem de idiomas. Me ha llamado la atención que esta semana hayan publicado en su blog el logro de la certificación ISO9000, incluso han colgado el certificado en formato pdf en su web, con su el alcance bien definido.

Siempre estoy pendiente de casos de éxito a quien entrevistar, y revisando el correo por si alguien, de forma proactiva, quiere compartir su caso en este blog. Por ello, quiero hacer un llamamiento destacando que un caso de éxito que se publica es en realidad un éxito dentro de una organización.

Conseguir la certificación de la normativa o estándar ISO (u otro sistema de estándares) es el resultado de meses de trabajo, meses de implantación, en la que están implicadas la gran mayoría de las personas dentro de una organización, aunque ellas no lo sepan.

Con esta idea, queda gratamente justificada la publicación en la red social, intranet o página web corporativa de estos logros, acompañada de un agradecimiento a todos los participantes, insisto, aunque ellos no lo sepan. No obstante, la certificación nunca es el objetivo, sino el medio para conseguir la mayor rentabilidad, sea del tipo que sea (ver posibles respuestas en Primera pregunta para cualquier ISO).

Auditoria en Gestión del conocimiento

El proceso de gestión del conocimiento es uno de los que más ha incrementado su nivel de importancia en la nueva edición 2011 de ITIL®, y su implantación ha estado creciendo en los últimos años en muchas empresas. Esto es debido a que el objetivo de este cumple con los nuevos requerimientos de las empresas, especialmente en materia de recursos humanos, especialmente en la parte de TI.

A medida que pasa el tiempo, el proceso se va haciendo cada vez más maduro, pero para saberlo hay que medir su efectividad y eficiencia, y nada mejor para ello que incluirlo en el plan de auditoría interna.

Pero como no hay una norma certificable en sí (), podemos basarnos en la Guía europea de buenas prácticas para la gestión del conocimiento (CWA 14924), en la guía española UNE 412001, en la guía australiana AS 5037 Knowledge management: A guide o en la misma ITIL®, especializada en TI (y en la que está especializado este blog), entre los muchos ejemplos que puedo dar.

Escojamos la que escojamos (si escojemos), vamos a tener que medir el proceso, como siempre, en base a:

1. Alcance

2. Requerimientos

3. Frecuencia de actualización del proceso

4. Casos de éxito (definir "caso de éxito" en función del alcance del proceso)

5. Interfaz con otros procesos

Para más información sobre la gestión del conocimiento, recomiendo seguir, tanto este mismo blog como el blog Gestión del Conocimiento TI.

¿Qué es el SAC?

SAC son las iniciales de "Service Acceptance Criteria" en inglés, en español es "Criterios de Aceptación del Servicio". Tenemos una definición oficial en ITIL®, en español, a continuación:

España: Conjunto de criterios utilizados para asegurar que un servicio de TI cumple con su funcionalidad y requisitos de calidad y que el proveedor de servicio de TI está preparado para operar el nuevo servicio de TI una vez ha sido implementado.

LATAM: Es un conjunto de criterios utilizados para garantizar que un servicio de TI cumple con sus requerimientos de funcionalidad y de calidad y que el proveedor de servicios de TI esté listo para operar el nuevo servicio de TI cuando este haya sido implementado.

En el SAC, como proveedores de servicio, escribimos cómo cubrimos los requisitos y cómo entregamos el servicio. El SAC lo tenemos en un documento, que está vivo durante todo el ciclo de vida del servicio, y está íntimamente ligado, al menos, con el SLR ("Service Level Requirements" o "Requerimientos de Nivel de Servicio"). Cuando cambia un requerimiento, el SAC debe ser actualizado para asegurar que estamos entregando el servicio como debe.

Es un documento muy importante que permite al cliente saber que podemos ofrecer el servicio, y no estamos "vendiendo humo". Le dice al cliente que cubrimos no sólo los requerimientos, también los tests que hagamos, nuestros proveedores, el soporte, el software, la documentación técnica disponible, personal y planes, tanto de implantación como de roll back; y que hacen que nosotros, como proveedor de servicios, somos una pieza sólida para el Negocio del cliente.

Puedes volverte loco/a escribiendo el SAC. Hay que estudiar bien los requerimientos y tener los procesos lo suficientemente maduros como para cubrirlos, y con esto lo diferenciamos de la oferta. El SAC es más formal, más técnico, menos comercial; es aquéllo que diferencia un proveedor de otro.