Las métricas se ponen de moda... una vez que las organizaciones comienzan con las implantanciones de sistemas de gestión de procesos, procesos de gestión de sistemas, servicios gestionados o procesos de gestión de servicios o como quiera que le hayan llamado a la última reorganización del departamento de IT con el objetivo de dar un mejor servicio al usuario, siempre llega el momento de medir. Al fin y al cabo, va implicito en la propia palabra, ¿no? Queremos dar un mejor servicio al usuario, y mejor quiere decir...
¿Qué quiere decir mejor?
Si no tengo medidas, mejor es una palabra vacía, o cuando menos subjetiva. De ahí la gran importancia de la medida.
medir.
1. tr. Comparar una cantidad con su respectiva unidad, con el fin de averiguar cuántas veces la segunda está contenida en la primera.
Así de simple. Comparar algo con su respectiva unidad, así que necesito la unidad, y la cantidad (o cosa a medir). Las unidades son fáciles, lo malo es conseguir las medidas. Hay que decidir cuáles son y hay que ponerse de acuerdo, además, en cómo obtenerlas.
En estos últimos meses las métricas se están poniendo de moda. Supongo que precisamente se debe estar notando la gran capilaridad que han tenido las implantaciones de procesos tipo ITIL durante el año pasado y principios de este, en que el mercado ha estado muy revuelto, un gran número de organizaciones han superado las tres primeras etapas de decidir, pensar e implantar los primeros procesos y ahora viene lo siguiente, que es medir.
Y cuando la gente quiere medir, lo siguiente que quiere es representar las mediciones en un Cuadro de Mando y entonces es cuando viene el problema, porque no te piden medir, sino un CdM, un BSC o un QdC (que al fin y al cabo es todo lo mismo pero en distinto idioma).
¿Se puede tener un Cuadro de Mando sin medir?
Rotundamente no. Es necesario establecer las métricas que se deben recolectar, la forma de agruparlas y la forma de representarlas... pero lo primero es definir y recolectar métricas.
¿Y quién me ayuda a esta definición?
Pues debes pensar en un par de cosas primero y después acudir a la bibliografía existente, a saber:
- Metrics for IT Service Management, con ISBN número 9077212698.
- Planning to Implement Service Management, con ISBN número 0113308779
- COBIT 4 Management Guidelines
¿Alguna Recomendación?
Si, tengo un par de recomendaciones que hacer:
1.- No por mucho medir amanece más temprano: Es mejor tener un conjunto reducido de métricas pero muy fiables, bien calculadas y bien obtenidas que un catálogo de métricas enorme de grande pero poco fiable. El proceso de obtención de la métrica, la fuente de información, el proceso de almacenamiento y representación, todo debe ser estable, controlado y fiable. Sobre todo la fuente de información... así que se deben establecer los controles apropiados para garantizar la fiabilidad en el propio origen. Piensa en COBIT para ello.
2.- Piensa qué quieres medir: ¿Quién es el destinatario de la métrica? ¿Qué quieres hacer con estas medidas? Preguntas importantes a hacerse antes de liarse a medir... si quiero medir el proceso para mejorarlo debo aplicar medidas al proceso, normalmente serán medidas internas (no serán mostradas al cliente) y sirven para corregir y ejecutar el plan de mejora contínua sobre los procesos. Si, por otra parte, quiero dar datos al cliente, entonces lo que necesito son medidas sobre el servicio, medidas extremo a extremo y que normalmente formarán parte del proceso de Gestión de Niveles de Servicio. Si, finalmente, lo que necesito son medidas para la explotación de los sistemas, entonces necesitaré métricas muy tecnológicas que estarán fuertemente ligadas a los componentes físicos sobre los que se proporciona el servicio.
3.- Categoriza las métricas: yo normalmente aplico grandes categorías para la clasificación y presentación de las métricas, a saber:
- Métricas de Calidad: indican la calidad del proceso o servicio y tienen que ver con aspectos en la provisión (por ejemplo, tiempo de respuesta).
- Métricas de Volumetría: indican cantidad, volumen de uso o de producción y se suelen usar para poner las cosas en contexto (siempre los ANS deben ir ligados a un contexto de volumetría de uso del servicio, por ejemplo).
- Métricas de Disponibilidad (para los servicios)
- Métricas de Cumplimiento: para la gestión de los procesos, no sólo necesitamos rendimiento o volumen del proceso sino algo que nos indique el grado de acercamiento a los objetivos de calidad del proceso en sí, lo que COBIT llama KGIs.
¿Y luego?
Luego viene la parte más difícil, que es medir. Obtener todas y cada una de las métricas para posteriormente reflejarlas en un informe, una web o un Cuadro de Mando es una tarea titánica que puede resultar ser virtualmente imposible si la tecnología no nos ayuda. A veces hasta la métrica más simple se puede volver un infierno si las máquinas no están de nuestro lado. Yo siempre propongo estudiar qué métricas podemos obtener "ya mismo" y cuáles podemos obtener a medio/largo plazo. Para cada una de ellas habrá que hacer una estimación de costes para saber cuánto nos va a costar obtenerla, luego hay que tomar las decisiones y por último llevar a cabo el proyecto que nos permita obtener el mecanismo de medición. (fíjate que he utilizado la palabra proyecto!)
Otra de las grandes problemáticas que aparecen es dónde y cómo guardar estas métricas. Aquí es donde se unen los mundos ITIL y BI y comienza la fiesta de verdad: un mundo apasionante.
En Definitiva
¿Tu empresa tiene un cuadro de mando financiero o un datawarehouse de ventas? ¿Cuánto tiempo/esfuerzo/dinero ha costado hacerlo? Pues piensa que si pides un BSC para las TIC estás entrando en un terreno que utiliza exactamente los mismos criterios, pero aplicados a fuentes de datos tan heterogeneas como tus servicios y procesos TIC.
Es útil. Es importantísimo. Es vital tenerlo, pero al mismo tiempo es costoso y laborioso. Pero ¿Acaso toda empresa más o menos grande no necesita un ERP o un sistema de gestión? 
8 comentarios:
Buen artículo. Felicidades. Me pilla muy de cerca y me ha parecido muy interesante y realista.
Saludos
".. si quiero medir el proceso para mejorarlo debo aplicar medidas al proceso, normalmente serán medidas internas..." Estoy de acuerdo con K, buen articulo, aunque yo me pregunto, y que hay del PROCESO de Medir en si mismo? acaso todo proceso ITIL, no debe tener o contener dentro o fuera del mismo una serie de actividades cuyo fin sea el medir? la question esta ahi dentro o fuera del propio proceso ITIL ? ... This is the question !
El problema no viene en obtener las métricas, sino en saber qué significan.
Como bien dice Antonio, existen inmnumerables métricas ya especificadas en Cobit, en Metric for IT services, etc... y listas para usar, exactamente pasa lo mismo cuando creamos un cuadro de mando financiero o de producción, existen muchas métricas que son las mismas "métricas académicas" que todos quieren tener pero que solo unos pocos entienden en profundidad su significado.
Si no entiendes que parte del proceso de tu negocio estas midiendo con essa métrica, de poco o nada te va a servir. Si no la entiendes en de solo vistazo en el cuadro de mandos, mejor que prescindas de ella. Por eso yo creo mas en las métricas que uno hace "entendiendo su negocio", quizás no tengan la refinación de otras más academicas, pero lo importante es que te sirvan para tomar decisiones.
Seguramente la que antes obtengas será la que mas comunmente te sirva en tu toma de deciones, a veces no hace falta llegar a saber el número de transacciones por segundo que reliza tu aplicación de gestión, quizás te sea mas facil ver las puntas de trabajo en la CPU y eso ya te dará idea de ese servidor va cargado. Es una metrica mucha mas chunga, pero mas facil de obtener y que te sirve igual a mas a la hora de tomar decisiones
tsk tsk... estoy y no estoy de acuerdo contigo, Jorge. Si que acepto que la metrica "personalizada" y "adaptada" a tu negocio particular es importante, pero creo tambien que sin una estandarización de un paquete básico de métricas el benchmarking es imposible.
Si, ya se que me dirás que el benchmarking es una falacia, pero como todo, lo es en un principio y con el tiempo lo podremos convertir en un hecho.
Ahora bien, el Cuadro de Mando debe ser comprensible de una ojeada? desde luego!
PD: Esta semana he hablado con dos clientes diferentes, ambos pertenecientes a multinacionales de sectores muy diferentes y coinciden en la necesidad de un modelo de métricas estandarizado dentro de la propia compañia para poder realizar benchmarking entre las diferentes empresas / sedes de la organización.
Saludos!
Antonio
Ah Pep! ..
Como se intuia (aunque no se dijo expplicitamente) en el articulo del "cliente que sabia demasiado", en
resulta que a cada proceso le debe corresponder su proceso de control, que lo evalua, lo compara con las especificaciones de calidad, lo mejora continuamente y lo redirige... y ese es el encargado de medir, reportar y corregir.
¿De donde?
Principalmente de COBIT (Objetivos de CONTROL
Antonio
Vale, aceptamos barco como animal acuatico, desde el punto de vista de poder comparar sedes, si tiene sentido, pero con lo peces que estamos todavía en medirnos nosotros mismos (IT) un conjunto de metricas estandard y gigantesco puede ser contraproducente.
(si, si polémica)
Yo abogaría por primero unas méticas mas "artesanas" para que la empresa se vaya familiarizando y luego atacar las estándar cuando el modelo este mas maduro.
Pues voy a entrar en la polémica!
Estoy de acuerdo con ambas posturas... y con ninguna. Mi experiencia me ha llevado a tratar de definir 2 niveles de métricas:
1. Metricas de bajo nivel. A las que se refiere Antonio, por cada proceso y ligadas a las actividades de control. Aunque creo que deben ser a medida, en línea con las principales necesidades de la empresa en relación a cada proceso.
2. Metricas de alto nivel. Más generales y estandarizadas. Elaboradas a partir de las anteriores y de su correlación con el resto de parámetros organizativos de la empresa, y evaluadas en estamentos superiores. Que permitan el benchmarking, pero sin obligarnos a mostrar "más de la cuenta" si no lo deseamos. Y en última instancia, que se correspondan con las que defina el estándar adoptado (y que puestos a pedir, debería ser estándar de facto. Aunque falte todavía tiempo para que uno destaque sobre el resto, en este tema de las métricas... ).
De esta forma, creo que se puede conseguir una mayor utilidad de las métricas a bajo nivel (las más útiles desde un principio) e ir depurando las de alto nivel según vayamos madurando y asimilando los conceptos que introducen los estándares.
Saludos
Bien Bien!
Polémica, que de ella se aprende mucho!
Bueno, vistas las dos aproximaciones que están apareciendo en los comentarios, yo creo que hay que ponerse ahora en la piel del cliente. No del cliente de IT, sino el cliente de nosotros, consultores de empresas que se/nos ganan/mos la vida recomendando y ayudando a nuestros clientes:
Lo que para un departamento de TI es un proyecto, único y discreto (no por pequeño, sino por indivisible), normalmente para nosotros, proveedores, es "un proyecto más" y ese es precisamente nuestro valor añadido.
Entonces, si nos ponemos en la piel del equipo de TI que comienza (o madura) una implantación, si quieren medir la primera pregunta que se hacen es "Qué medir", luego viene "Como medir", a continuación viene "Cómo representar" y por último (y para ligarlo con la temática del blog de Jorge) dicen "Y ahora, ¿Qué hago yo con esto?"
En la pregunta de "Qué Medir" pueden intentar hacerlo ellos y por eso mis recomendaciones de bibliografía: no intentes reinventar la rueda, aprovecha las recomendaciones genéricas que te hacen los standares y, como va siendo la cantinela habitual de este blog piensa un poco y adapta esas recomendaciones genéricas a tu entorno.
Si nos contratan a nosotros, pues ¿qué haremos? Más o menos lo mismo, pero además de la bibliografía existente usaremos nuestra propia experiencia y la de nuestra compañía.
Eso si, siempre pensar, pensar y pensar.
Como me decía mi padre: "USE LA CABEZA MIJITO.. USE LA CABEZA!"
Saludos, Doctor, si me lee!! :-)
Publicar un comentario