Medir procesos no es tan simple

Como ya comentaba en un post anterior, en el mundo de las métricas hay dos grandes conjuntos: las métricas de proceso y las métricas de servicio.

Básicamente, las métricas de proceso están orientadas a medir rendimiento y cumplimiento de objetivos en la ejecución del proceso, mientras que las métricas de servicio están orientadas a medir calidad, capacidad y disponibilidad de los servicios TIC .

Ahora bien, cuando llega el momento de medir nos encontramos con una curiosa situación: a priori, parece más sencillo y viable obtener métricas sobre los procesos que sobre los servicios; pero la experiencia nos acaba demostrando que no es así. ¿Por qué?

Pues yo tengo una teoría que trata de explicar esto: aplicando (de aquella manera) el principio de indeterminación, lo que queremos medir debe ser estable al menos durante el instante que necesitamos para realizar la medicion y para que estas medidas sean comparables entre sí deben ser relativas a algo básicamente similar.. vamos, lo que nos explicaban de pequeños: "no podemos comparar peras con manzanas"

Los chicos de la Carnegie Mellon lo tienen claro, y en CMMI han apostado por un modelo de madurez en 5 etapas que también ha sido adoptado por COBIT:

0. El proceso es inexistente
1. El proceso está en un estado inicial
2. El proceso es repetible pero intuitivo
3. El proceso está definido
4. El proceso está Gestionado y Medido
5. El proceso está Optimizado

Así, para poder tener unas métricas decentes de un proceso necesitamos que el proceso esté ubicado en nivel 4 de madurez y eso no es tan fácil como conseguir que la tecnología esté en un estado "Gestionado y Medido". Lo primero es un problema de cultura de empresa y lo segundo es simplemente un problema de dinero.

Vamos a verlo con un ejemplo que creo que será bastante claro: es bastante común que tengamos un proceso de Gestión de Incidencias, donde registramos incidencias, las clasificamos, las tratamos, comunicamos al cliente y las cerramos.

A la que tenemos una herramienta donde poder registrar las incidencias y les hemos explicado a los chicos de soporte cómo se debe trabajar, es posible que tengamos un proceso en un nivel más o menos similar al Nivel de Madurez 3 - Definido

Tenemos un proceso DS8 en un nivel de madurez Definido cuando se ha reconocido y aceptado la necesidad de una función de ServiceDesk y de un proceso de Gestión de Incidencias. Los procedimientos se han documentado y se ha impartido formación (aunque sea informal) al respecto. Se desarrollan FAQs y guías de usuario, pero los individuos deben buscarlas y posiblemente no las sigan, Las peticiones e incidencias se siguen de forma manual y son monitorizadas de forma individual, pero no existe un sistema formal de reporting. La respuesta "a tiempo" a las incidencias y peticiones no se monitoriza y algunas de estas llamadas de servicio pueden quedar sin resolver. Los usuarios han recibido información clara al respecto de dónde y cómo reportar estas llamadas de servicio.

Ahora veamos qué pasa con nuestro ServiceDesk: los usuarios contactan con la extensión 3030 y un equipo de operadoras registra sus llamadas, hay un equipo de técnicos que resuelven las llamadas, escriben FAQs y guías de usuario, resuelven las incidencias y lo documentan todo en la herramienta XXX... el departamento de IT se ha gastado una pasta y el Director quiere mostrar los fantásticos resultados en unos preciosos informes que deben subir a Dirección General (que se pregunta en qué se ha gastado la pasta el CIO), así que pide tener un informe muy chulo que muestre, entre otros valores, los siguientes:

• Número de Incidencias registradas
• Número de Incidencias resueltas
• Tiempo medio de primer contacto (T0)

Parece fácil, no? A primera vista parece realmente fácil, pero vamos a ver qué pasa cuando intentamos analizar los números:

Para empezar, tenemos que poder diferenciar las incidencias de cualquier otro tipo de llamada de servicio... ¿Lo hemos tenido en cuenta en la implantación de la herramienta? ¿Podemos diferenciar una incidencia de, digamos, una petición o una consulta?

Luego viene la segunda parte: cuando Rosa registra una llamada, la clasifica como incidencia y la pasa al pool de primer nivel. Manolo, de primer nivel, ve que lo que el usuario está pidiendo no es una incidencia, sino una consulta (bajo su criterio, lógicamente). Pero como no le parece importante para la resolución, no modifica el registro, sino que hace lo posible por cerrar la incidencia y termina.

Con el ejemplo anterior, y si no hemos dejado muy, pero que muy claro en qué se diferencia una incidencia de una consulta, los operadores y/o técnicos nos clasificarán las llamadas de servicio como buenamente les parezca y así... ¿qué validez tendrá nuestra métrica?

En definitiva, lo que ocurre con las métricas es que dependen directamente de la calidad del hecho analizado, y normalmente lo que nos encontramos es que los datos analizados suelen tener bien poca calidad.

¿Y porqué tan poca calidad?

Pues simplemente porque las personas que manipulan esos datos no son conscientes de su importancia, de la importancia de obtener un dato bien "modelado" y (como decíamos en un post anterior) de las consecuencias que se sufren si los datos no son de buena calidad.

Así que como conclusión deberíamos ver una serie de condiciones que se deben cumplir para que nuestro sistema de medición y reporting de KPI's , KGI's y demás números informativos sea realmente útil:

1. El equipo que trata los datos "unitarios" debe ser consciente de la importancia de los datos introducidos.
2. Los datos introducidos deben ser periodicamente auditados para validar su coherencia
3. Los criterios de clasificación deben ser claros y no dar pie a ambigüedades
4. Las métricas definidas deben contar con un manual de interpretación: quien tome decisiones utilizando las métricas como fuente de información debe conocer el significado exacto de la métrica.

Y conseguir todo esto es precisamente lo que hace que medir procesos no sea tan fácil: aparece el factor humano y eso lo complica todo.

¡Felices y Mesuradas Fiestas!