8 métricas y KPI clave de la mesa de ayuda
8 indicadores clave de rendimiento (KPI) que toda mesa de ayuda de TI debe conocer
La gente suele decir que "lo que se mide se puede mejorar", pero rara vez dicen qué es exactamente lo que se debe medir. Con los recientes avances en las capacidades de elaboración de informes del software de mesa de ayuda de TI, se pueden medir y monitorear cientos de KPI y métricas de la mesa de ayuda.
Pero eso no significa que deba medirlos todos. Sólo es necesario medir los KPI y las métricas que son fundamentales para su mesa de ayuda de TI con el fin de mejorar la prestación del servicio.
Este documento describe los 8 indicadores clave de rendimiento (KPI) que son fundamentales para toda mesa de ayuda de TI. Estos KPI ayudan a cumplir los objetivos básicos de la mesa de ayuda de TI, como la continuidad del negocio, la productividad de la organización y la prestación de servicios a tiempo y dentro del presupuesto. Los KPI son los siguientes:
Garantizar la continuidad del negocio
Hacer que la organización sea productiva
Garantizar la continuidad del negocio
1. Horas de trabajo perdidas
El número de horas que la empresa está inactiva porque los servicios de TI no están disponibles.
Objetivo
Mantener las horas de trabajo perdidas al mínimo.
La mayoría de los equipos de TI controlan la disponibilidad de los servicios para conocer el rendimiento global de sus mesas de servicio de TI. Pero la pérdida de negocio no siempre se ve reflejada en los niveles de disponibilidad del servicio, incluso cuando éstos son altos. Por ejemplo, si la disponibilidad del servicio es del 99,9%, la empresa sigue perdiendo más de ocho horas al año. Controlar las horas de trabajo perdidas pone claramente de manifiesto la pérdida y su impacto en el negocio.
Estudio de caso: Tiempo sin volar en Virgin Blue
En septiembre de 2010, Virgin Blue se enfrentó a lo que podría considerarse la peor pesadilla de toda aerolínea. Unos 50.000 clientes y 100 vuelos se quedaron en tierra. Cuatrocientos vuelos más fueron retrasados o reprogramados en los días siguientes porque falló la infraestructura del servidor de discos de estado sólido que alojaba las aplicaciones de Virgin Blue. Esto afectó al sistema de facturación y reservas en línea de Virgin Blue.
A pesar de los acuerdos de nivel de servicio para restablecer los servicios inmediatamente, se tardó 11 horas en restablecer el servicio y 10 horas más en restablecer las operaciones completamente. Esto se debió a un intento de reparación de un dispositivo defectuoso, que retrasó el cambio a una plataforma de hardware de contingencia. Para entonces, el daño ya estaba hecho. Aunque estas 11 horas no supusieron un gran costo en términos de disponibilidad del servicio de TI de Virgin Blue durante el año, le costaron aproximadamente $10 millones en términos de pérdida de negocio.
Estándar de la industria - Horas de trabajo perdidas
 |  |  | |
| Métricas (n-208) | El mejor | Promedio | Rezagado |
| Número de eventos de inactividad en los últimos 12 meses | 0,56 | 2,26 | 3,92 |
| Tiempo de inactividad promedio por evento en los últimos 12 meses | 0.,16 horas | 1,49 horas | 17,82 horas |
| Evento de inactividad más largo | 0,21 horas | 4,78 horas | 43,71 horas |
| Disponibilidad de aplicaciones críticas | 99,90% | 99,62% | 99,58% |
| Tiempo de recuperación desde el último evento de inactividad | 1,13 horas | 5,18 horas | 27,11 horas |
Consejos para minimizar las horas de trabajo perdidas
- Planificar y ejecutar adecuadamente las actualizaciones de aplicaciones, la migración de servidores y cualquier proceso de implementación de cambios de TI.
- Disponer de una CMDB bien definida y organizada para identificar los puntos críticos de fallo y comprender las interacciones de los CI en la red para identificar el impacto en cascada de los cambios fallidos.
- Educar a los equipos de TI sobre los riesgos de las violaciones de los SLA en términos de pérdida de horas de trabajo e ingresos.
- Obtener información sobre cómo anticipar y gestionar las interrupciones evaluando el rendimiento anterior de la mesa de ayuda de TI
Dicho esto, hay muchos factores que pueden contribuir negativamente a la pérdida de horas de trabajo. En 2010, Gartner predijo que "en el 2015 el 80% de las interrupciones que afectaban a los servicios de misión crítica serán debido a problemas de personal y procesos, y que más del 50% de esas interrupciones serán debido a problemas de integración y transferencia de cambios/configuraciones/liberaciones".
2. Tasa de éxito de los cambios
La relación entre el número de cambios exitosos y el número total de cambios que se ejecutaron en un período de tiempo determinado.
Objetivo
Lograr un mayor porcentaje de implementaciones de cambios exitosas.
Las opiniones siguen divididas sobre lo que implica un cambio fallido. Básicamente se refiere a cualquier cambio que no cumplió sus objetivos o no salió como estaba previsto.
Estudio de caso: La interrupción de ASX
El 27 de octubre de 2011, la bolsa de valores australiana (ASX) tuvo que interrumpir sus operaciones durante cuatro horas debido a una implementación de cambios fallida. Una actualización de la red interna de la ASX (para mejorar la latencia de la plataforma de comercio) provocó problemas de conectividad sin precedentes entre los componentes de apoyo y las pasarelas de difusión del sistema de comercio. ASX tuvo que iniciar los servicios de comercio desde uno de sus centros de recuperación ante desastres. Finalmente, para restablecer la normalidad se tuvo que revertir el cambio esa misma noche.
Una tendencia a la baja o una tasa de éxito de cambios estancada suele deberse al fracaso de las implementaciones de cambios debido a:
- Falta de información relevante como el impacto del cambio, las dependencias de los activos implicados, la ventana de implementación del cambio y las prioridades empresariales.
- Incapacidad de colaborar entre equipos para una implementación de cambios exitosa.
- Comunicación inadecuada a los usuarios finales y a las partes interesadas sobre la aplicación del cambio.
Consejos para lograr una alta tasa de éxito de los cambios
- Realizar un análisis de impacto adecuado y un plan de rollout detallado con una lista de comprobación de las tareas que se deben completar.
- Recopilar toda la información pertinente de los usuarios finales y los técnicos antes de la implementación.
- Constituir CAB y garantizar un proceso de aprobación estricto.
Cambios no planificados
Otra métrica de la mesa de ayuda que se debe controlar para tener un proceso de gestión de cambios eficaz es el número de cambios no planificados. Un cambio no planificado puede ser un cambio de emergencia o un cambio urgente.
- Un cambio de emergencia: Un cambio en el restablecimiento del servicio debido a un incidente, o un cambio que se debe aplicar rápidamente para evitar un incidente.
- Un cambio urgente o acelerado: Cambios que se requieren rápidamente debido a una necesidad apremiante, como un requisito legal o una necesidad empresarial, pero que no están relacionados con el restablecimiento del servicio.
Aunque no existe un estándar industrial o un número específico de cambios no planificados permisibles en una infraestructura de TI, esta métrica es importante, especialmente durante una tendencia creciente o un pico en el número de cambios no planificados.
Una tendencia creciente de cambios no planificados
Una tendencia creciente en el número de cambios no planificados sugiere que la planificación de los cambios es inadecuada y cuestiona la eficiencia del proceso de gestión de cambios. Por lo tanto, se debe mejorar el proceso de gestión de cambios para garantizar una planificación y ejecución adecuadas de los cambios.
Tendencia creciente de cambios no planificados
Un pico aislado de cambios no planificados
Un pico repentino en el número de cambios no planificados puede deberse a incidentes graves imprevistos, que justifiquen la implementación de cambios de emergencia para restablecer el servicio. Esta situación se debe probablemente a una infraestructura inestable, que podría afectar a la disponibilidad del servicio y, en última instancia, al negocio.
Picos aislados de cambios no planificados
3. Estabilidad de la infraestructura
Una infraestructura altamente estable se caracteriza por la máxima disponibilidad, una alta continuidad y pocas interrupciones del servicio.
Objetivo
Mantener una infraestructura altamente estable.
Para medir y monitorear eficazmente la estabilidad de la infraestructura, las mesas de ayuda de TI deben monitorear lo siguiente:
- Reducción porcentual del número de activos problemáticos
- Reducción porcentual del número de incidentes graves
Infrastructure stability
Reducción porcentual del número de activos problemáticos
Ofrecer la máxima disponibilidad y una mejor calidad de servicio será imposible en una infraestructura en la que los routers tengan que reiniciarse varias veces al día, los servidores fallen a menudo o las estaciones de trabajo tengan que reconectarse de vez en cuando. Por lo tanto, estos activos problemáticos se deben identificar y sustituir para garantizar la continuidad del negocio.
Un activo problemático podría ser la causa frecuente de las interrupciones o cortes del servicio y, a efectos de la elaboración de informes, podría tratarse de activos que tienen asociados más de un par de incidentes. La reducción porcentual del número de activos problemáticos se puede calcular usando la siguiente fórmula:
Número de activos problemáticos sustituidos al final del plazo.
Número de activos problemáticos identificados al inicio del plazo
Reducción porcentual del número de incidentes graves
Otro indicio importante de la estabilidad es la recurrencia de incidentes graves en la infraestructura de TI, que pueden provocar interrupciones del servicio o el deterioro del nivel de servicio. Un incidente grave, por definición, es un incidente de gran impacto y urgencia que afecta a un gran número de usuarios, privando a la empresa de uno o dos servicios clave.
El objetivo es reducir el número de incidentes graves, lo que se puede lograr con un análisis de causa raíz (RCA) eficaz y una reducción de los problemas acumulados. Identificar las causas raíz y solucionar los problemas puede reducir la recurrencia de incidentes graves y, por consiguiente, el volumen de tickets para la mesa de ayuda de TI.
Consejos para reducir la acumulación de problemas (y por tanto los incidentes graves)
- Inicio más rápido del RCA: En este caso, cuanto antes mejor. Cuanto antes se inicie el RCA, mayores serán las posibilidades de identificar la causa raíz.
- Finalización rápida de las investigaciones: Si la causa raíz se identifica más rápidamente, el equipo de TI puede corregir y resolver el problema con mayor rapidez, asegurándose de que los incidentes no vuelvan a producirse
Los equipos también pueden medir estos elementos de acción con detalles sobre el tiempo necesario para iniciar el análisis de causa raíz tras la identificación del problema y el tiempo necesario para completar el análisis de causa raíz.
Estudio de caso: Reducir los incidentes graves contribuye a mejorar la estabilidad de TI
Una de las principales instituciones financieras del mundo pudo mejorar su estabilidad reduciendo sus principales incidentes. Esta reducción del número de incidentes se logró mejorando su proceso de análisis de la causa raíz.
Reducir los incidentes graves contribuye a mejorar la estabilidad de TI
Las principales razones de una gran acumulación de problemas podrían ser:
- RCA retrasados y pendientes desde hace tiempo.
- Calidad inconsistente de los RCA y falta de documentación adecuada.
- No comunicar eficazmente el proceso de investigación a las partes interesadas.
Al no identificar y rectificar la causa raíz, las posibilidades de que se repitan incidentes graves son bastante altas. Sin embargo, afortunadamente se puede reducir la acumulación de problemas de las siguientes maneras:
- Disponer de un equipo dedicado a la gestión de problemas con administradores y gestores de problemas.
- Identificar y capacitar a expertos en la materia.
- Capacitar al equipo de gestión de problemas en las técnicas básicas y avanzadas de análisis de causa raíz.
Trabajar en estas dos sencillas métricas de la mesa de servicios de TI —reducción porcentual del número de incidentes graves y reducción porcentual del número de activos problemáticos— puede ayudarle a mantener una infraestructura de TI altamente estable.
4. Tendencias del volumen de tickets
El número total de tickets manejados por la mesa de ayuda de TI y sus patrones dentro de un período de tiempo determinado.
Objetivo
Optimizar el número de solicitudes de servicio e incidentes, y preparar al equipo de TI para gestionar la carga de tickets.
¿Qué puede hacer con las tendencias del volumen de tickets?
- Identifique los picos y los valles para optimizar la gestión de recursos y la carga de trabajo de los técnicos.
- Cree un mejor modelo de dotación de personal.
- Diseñe sesiones de capacitación para su equipo de la mesa de servicio de TI.
- Analice los patrones de solicitud de servicios y planifique con antelación las compras de activos y licencias.
- Valide cualquier necesidad de recursos adicionales.
Las mesas de ayuda de TI deben estar atentas a unas cuantas tendencias en lo que se refiere a los volúmenes de tickets, como:
Picos aislados
Picos aislados en el volumen de tickets
Un repentino aumento del volumen de tickets puede deberse a las siguientes razones:
- a. Período de máxima actividad comercial
- b. Implementaciones de TI que conducen a:
- i. Interrupciones e indisponibilidad del servicio
- ii. Preguntas frecuentes
- c. Disrupciones de TI
- d. Tickets de restablecimiento de contraseña después de vacaciones
Estudio de caso: Las admisiones en otoño provocan un aumento de los tickets en una universidad
La siguiente figura (7) representa el número de tickets gestionados por la mesa de ayuda de TI de una universidad de Estados Unidos. El gráfico indica claramente un pico de tickets en el mes de septiembre de 2012 y 2013. Esto se debe al aumento del número de estudiantes que ingresaron a la universidad durante el otoño. Así pues, el equipo de TI se asegura de que esta carga adicional se distribuya uniformemente entre todo el equipo, y cada miembro trabaja horas extras para gestionar estos picos de tickets
Volumen de tickets en una universidad estadounidense
Tendencia gradual y continua al alza
Continua tendencia al alza del volumen de tickets
Una tendencia al alza podría deberse a alguna de las siguientes causas:
Aumento del tamaño de la organización
A medida que la empresa crece, es obvio que la mesa de servicio de TI tiene que dar soporte a más usuarios finales, lo que normalmente conlleva un aumento del volumen de tickets. Este aumento gradual del volumen de tickets se puede gestionar mediante un plan de dotación de personal eficaz acorde con el crecimiento del negocio. Además, los usuarios finales se pueden segregar en departamentos y grupos de usuarios para gestionar los tickets con eficacia.
Iniciativas para dar soporte a más funciones empresariales
A medida que el equipo de TI empieza a dar soporte a más funciones empresariales, aumenta el volumen de tickets (tanto de incidentes como de solicitudes de servicio). Esto se puede gestionar comprendiendo los requisitos y las expectativas de los usuarios finales, y equipando a la mesa de ayuda de TI para que pueda gestionar el aumento de tickets.
Disminución de la estabilidad de la infraestructura
Con el creciente número de activos problemáticos y obsoletos en la red de TI, el número de tickets también aumentará. Esto puede abordarse asociando los incidentes y los problemas con sus activos, ayudando al equipo de TI a decidir sobre la retirada del activo, su actualización, etc.
5. Tasa de resolución a la primera llamada (FCRR)
El porcentaje de incidentes resueltos por el primer nivel de soporte (primera llamada o contacto con la mesa de ayuda de TI).
Objetivo
Tener un mayor nivel de FCRR.
Una alta tasa de resolución a la primera llamada suele ir asociada a una mayor satisfacción del cliente, tal y como confirma un estudio que realizó Customer Relationship Metrics. Además, un estudio realizado por Service Quality Measurement Group también reveló que por cada mejora de uno por ciento en la FCRR, se obtiene una mejora de uno por ciento en la satisfacción del cliente o usuario final.
La resolución a la primera llamada también está relacionada con el costo por ticket. El siguiente gráfico representa el costo por ticket para cada nivel.
Costo por ticket en varios niveles de soporte
A veces, los técnicos de la mesa de ayuda de TI se apresuran a cerrar los tickets durante la primera llamada, incluso sin resoluciones precisas. Estos casos pueden hacer que los índices de resolución a la primera llamada aumenten, mientras que los índices de satisfacción del usuario final caen drásticamente, como se muestra en el siguiente gráfico.
Tasa de resolución a la primera llamada vs. Satisfacción del usuario final
Consejo de excelencia en la FCRR
Aquí hay una sencilla técnica de tres fases para conseguir que su equipo de la mesa de ayuda de TI resuelva los incidentes a la primera llamada.
Fase 1: Conocer el entorno
- Reunir conocimientos específicos sobre el entorno.
- Poblar la base de conocimientos con la información recopilada, creando artefactos relevantes.
- Generar informes de estado periódicos sobre el rendimiento de la mesa de ayuda de TI con secciones sobre las lecciones aprendidas, los logros y los obstáculos superados.
- Invitar a expertos a evaluar el rendimiento.
- Crear un manual de operaciones que describa claramente los procesos de soporte, centralice la información clave sobre el entorno y defina explícitamente los procedimientos complejos para la resolución de tickets.
Fase 2: Ajustar
Genere informes para comprobar que los esfuerzos de la fase I han dado resultado e identifique áreas de mejora. A continuación encontrará algunos ejemplos de informes que le ayudarán a empezar.
- Porcentaje de llamadas atendidas por cada técnico.
- Número de llamadas atendidas por agente, por hora.
- Tiempo medio de conversación, por agente.
- De los tickets que no cerramos, ¿a dónde fueron transferidos?
- De esos destinos de traslado, ¿quién recibió más tickets?
Fase 3: Optimizar
- Establezca un proceso bien definido para mejorar continuamente la tasa de resolución a la primera llamada.
- Esta técnica no sólo le ayuda a mejorar los niveles de FCRR, sino que también contribuye a garantizar que los tickets se resuelven adecuadamente, no sólo se cierran.
- Otra posible tendencia es una FCRR en constante degradación, como se muestra en el siguiente gráfico.
FCRR en constante degradación
Esto puede ocurrir por varias razones, pero las principales son las siguientes:
- Falta de información del solicitante y del sistema.
- Baja competencia de los técnicos.
- Escasa transferencia e intercambio de conocimientos.
Según los niveles de evaluación comparativa de MetricNet, la FCRR neta promedio de las mesas de servicio en todo el mundo es del 74 por ciento, con un rango que va del 41 al 74 por ciento. Los factores más comunes entre todos los servicios del extremo superior del espectro fueron la presencia de agentes altamente capacitados, la disponibilidad de herramientas de gestión del conocimiento y la presencia de herramientas como la gestión de desktop remoto.
La FCRR se puede mejorar con los siguientes consejos:
- Comunicar la importancia de la FCRR a los técnicos.
- Diseñar programas de capacitación para los técnicos de primer nivel sobre temas específicos para ayudar a resolver los tickets con mayor rapidez.
- Mantener una base de conocimientos de soluciones técnicas avanzadas y artículos exclusivos y limitados a los técnicos.
- Crear formularios personalizados para recopilar toda la información relevante al momento de crear el ticket y evitar así retrasos en la respuesta.
- Asignar automáticamente los tickets al técnico o grupo adecuado en función de los parámetros del ticket.
6. Tasa de cumplimiento del SLA
El porcentaje de incidentes resueltos dentro del tiempo acordado para el SLA.
Objetivo
Mantener la máxima tasa de cumplimiento del SLA.
Supervisar los niveles de cumplimiento del SLA ayuda a las mesas de ayuda de TI a:
- Asegurarse de que los niveles de servicio son realistas y alcanzables.
- Comprobar el rendimiento de la mesa de ayuda de TI con respecto a los niveles de servicio acordados con el usuario final
- Identificar las áreas de mejora, fortalezas y debilidades de la mesa de ayuda de TI.
A veces, los técnicos de la mesa de ayuda de TI cierran los tickets sin resolverlos adecuadamente, sólo para evitar violaciones del SLA. Sin embargo, cuando esto ocurre, los índices de cumplimiento de los SLA siguen siendo elevados y los niveles de satisfacción de los usuarios finales tienden a disminuir, como se muestra en el siguiente gráfico.
Tasa de cumplimiento del SLA vs. Satisfacción del usuario final
Sin embargo, los niveles de cumplimiento del SLA pueden disminuir por otras razones, por lo que es importante tener en cuenta las siguientes posibilidades:
- Es posible que su equipo no entienda los requisitos de la empresa, lo que puede dar lugar a acuerdos de nivel de servicio que no satisfagan las necesidades de la empresa, o a una categorización y priorización inadecuadas de los tickets que den lugar a violaciones de los SLA
- A menudo falta una comunicación adecuada sobre los riesgos de las interrupciones que afectan a los servicios de misión crítica y sus repercusiones en el negocio.
En tales situaciones, los equipos de la mesa de servicio de TI deben comprender los requisitos de la empresa y redefinir sus acuerdos de nivel de servicio según convenga.
Estudio de caso: Cuando cumplir los SLA no sirve de nada
Los SLA y su cumplimiento son fundamentales para garantizar la continuidad del negocio. Sin embargo, este caso de una empresa de fabricación de cemento resalta la importancia de establecer con cuidado los acuerdos de nivel de servicio. La mesa de ayuda de TI no estuvo disponible para responder inmediatamente a un problema en el despacho de un camión, pero lo resolvió dentro del SLA. Desgraciadamente, el cemento fabricado se debía enviar a la sede del cliente en el plazo de una hora para evitar que se endureciera.
La mesa de ayuda de TI no era consciente de ello y los SLA se establecían sin tener en cuenta estos factores. Como resultado, aunque el ticket se resolvió dentro del SLA, el cemento ya se había endurecido, lo que afectó al negocio.
Tendencia a la baja en la tasa de cumplimiento del SLA
Otra tendencia alarmante que se debe vigilar es una tasa de cumplimiento del SLA en constante declive.
Esta tendencia a la baja podría deberse a alguna de las siguientes causas:
- Acuerdos de nivel de servicio poco realistas.
- Falta de conocimiento de los SLA y de los riesgos de su incumplimiento.
- Ausencia de un monitoreo adecuado y de un escalamiento proactivo.
- Falta de experiencia técnica.
- Tickets sin asignar y asignaciones de tickets retrasadas y fallidas.
La tasa de cumplimiento de los SLA se puede mantener en niveles más altos haciendo lo siguiente:
- Establecer SLA realistas basados en los requisitos de la empresa y las capacidades de TI.
- Comunicar los SLA y los riesgos de violación de los SLA a la empresa y a los técnicos.
- Establecer las normas de escalamiento necesarias.
- Automatizar el proceso de enrutamiento y asignación de tickets.
- Diseñar programas de capacitación para sus técnicos
7. Costo por ticket
El gasto operativo mensual total del soporte de TI, dividido por el volumen mensual de tickets.
Objetivo
Mantener unos niveles mínimos de costo por ticket.
Según MetricNet, los siguientes fueron los valores de referencia del costo por ticket en 2014.
Estándar de la industria - Costo por ticket en un entorno de alta densidad
Estándar de la industria - Costo por ticket en un entorno de mediana densidad
Como se observa en ambos casos, el costo de las solicitudes de servicio suele ser superior al de los incidentes. Esto se debe a que los incidentes suelen tardar menos en resolverse que las solicitudes de servicio. Así, el costo por ticket está muy influido por la mezcla de incidentes y solicitudes de servicio.
El soporte de TI se considera un centro de costos en la mayoría de las organizaciones y suele ser el primero en sufrir recortes presupuestarios durante una recesión financiera. Por lo tanto, el soporte de TI debe seguir siendo eficaz, incluso cuando se reduzca el gasto en TI. El costo por ticket es una métrica clave del rendimiento de la mesa de servicio que ayuda al equipo de soporte de TI a analizar su eficiencia a la hora de gestionar tickets con un presupuesto determinado. El objetivo es mantener siempre un nivel óptimo del costo por ticket.
Sin embargo, es importante tener en cuenta que si el costo por ticket es superior al promedio, no tiene por qué ser malo. Asimismo, si el costo por ticket es inferior al promedio, no siempre es bueno, como se muestra en los siguientes gráficos.
El escenario representado en este gráfico puede significar que el equipo de la mesa de servicio de TI está comprometiendo la calidad del servicio para reducir el costo por ticket, lo que a menudo se traduce en menores niveles de satisfacción del cliente.
Costo por ticket vs. Satisfacción del usuario final
El escenario representado en el gráfico anterior muestra cómo el aumento del costo por ticket va acompañado de un incremento de los niveles de satisfacción del cliente. Esto puede significar que el aumento del costo por ticket ha llevado a una mejor prestación del servicio, lo que justifica el costo adicional.
Un factor clave para optimizar el costo por ticket es permitir una rápida resolución de los tickets y reducir cualquier escalamiento innecesario. El costo por ticket se puede mantener bajo control siguiendo estas indicaciones:
- Analice los patrones de las solicitudes de servicio para planificar con antelación la compra de activos y licencias, reduciendo así el tiempo necesario para cerrar las solicitudes de servicio.
- Identifique los picos y los valles para optimizar la gestión de recursos y la carga de trabajo de los técnicos.
- Categorice y priorice correctamente los tickets para reducir las asignaciones incorrectas de tickets, ayudando a proporcionar resoluciones rápidas.
- Cree una sólida base de conocimientos.
8. Tasa de utilización de activos de software
El porcentaje de licencias y productos de software usados realmente por la empresa.
Objetivo
Maximizar el ROI (retorno de la inversión) de las inversiones en software.
Dado que las compras de licencias de software representan una gran parte del gasto en TI, es importante realizar un seguimiento de la utilización del software. Desgraciadamente, ésta es una de las métricas de la mesa de servicio de las que menos se habla. Para facilitar su gestión, se puede clasificar el software de la siguiente manera:
- Categoría 1 - Software que necesita la mayor atención (con las mayores implicaciones empresariales, costo de licencia o riesgos de cumplimiento).
- Categoría 2 - Software que necesita la menor atención (software gratuito como Adobe Reader).
- Categoría 3 - Software prohibido y malware.
se pueden usar las siguientes métricas de la mesa de servicio para controlar la utilización del software:
Relación entre el total de software utilizado y el total de software adquirido
Esta métrica ayuda a identificar cualquier gasto de compra de software que no aporte ningún valor a la organización. Idealmente, esta proporción debería ser de casi uno, lo que significa que hay una utilización máxima de todo el software adquirido, asegurando así un máximo retorno de la inversión en la compra de licencias de software. Si en la lista de software no utilizado hay un gran número de softwares de categoría uno, esto significa que una parte importante del gasto en activos de software se destina a software no utilizado.
Relación entre las licencias no asignadas y el recuento total de licencias
Esta métrica ayuda a analizar la utilización de licencias de un determinado software, ayudando a los equipos de TI a planificar con antelación la compra de licencias. La proporción debe ser lo menor posible para obtener el máximo rendimiento de la inversión. Una proporción más alta podría significar que algunas de las aplicaciones de software tienen un exceso de licencias, lo que podría suponer una inversión inútil sin retorno de la inversión.
Estudio de caso: Aumentar la utilización de los activos de software ahorra un millón de dólares
Una empresa farmacéutica líder mundial ahorró cerca de un millón de dólares en gastos. La empresa farmacéutica, con sus servicios repartidos en más de 50 países, utilizaba una amplia gama de productos Microsoft. En una oficina concreta, había miles de aplicaciones de software con licencia bajo un acuerdo de licencias por volumen de Microsoft, pero inicialmente no había visibilidad ni control de estos activos de software. La compra se había realizado sin comprender las necesidades de la empresa.
De hecho, la empresa disponía de información limitada sobre los activos de software y el número y tipo de activos que la organización necesitaba realmente. De nuevo, esto ponía a la organización en riesgo de tener licencias excesivas o insuficientes y de recibir sanciones por incumplimiento.
La mesa de ayuda de TI comenzó con un sencillo análisis comparando el software de Microsoft instalado con las licencias de Microsoft que poseían. Los datos adquiridos y los esfuerzos del departamento de TI por comprender los requisitos de la empresa condujeron a replantear la compra de licencias de Microsoft que implicaba pasar de la edición Microsoft Office Professional a la edición Standard, más barata, que satisfacía el requisito de la empresa.
Además, se sustituyeron otras licencias por volumen, lo que significó un ahorro de cerca de un millón de dólares en las compras de licencias de software para la empresa.
Tasa de cumplimiento de licencias
Otra métrica importante de la gestión de activos de software que podría suponer un costo para la organización es la tasa de cumplimiento de licencias. Mantener el máximo cumplimiento puede salvar a su organización de sanciones y multas. A continuación le ofrecemos algunos consejos para lograr el máximo cumplimiento:/p>
- Controlar todas las instalaciones de software y compras de licencias.
- Asignar licencias a instalaciones de software individuales para encontrar el software que sobra y el que falta.
- Adquirir los tipos de licencia adecuados para el software. Por ejemplo, es mejor adquirir una licencia perpetua para un software básico para evitar problemas de cumplimiento debido a la caducidad de la licencia.
- Realizar evaluaciones internas formales respecto al cumplimiento y la preparación para auditorías.
Logre el máximo cumplimiento con una auditoría previa de tres pasos
El sueño de lograr un pleno cumplimiento de las licencias se puede hacer realidad con esta sencilla auditoría previa de tres pasos.
Paso 1: Análisis de carencias
- Solicite una lista de todas las aplicaciones de software con licencia de su organización al proveedor específico.
- Identifique y localice el software que utiliza la empresa, pero que no figura en la lista proporcionada por el proveedor.
Paso 2: Análisis de cumplimiento
Compruebe el número total de instalaciones de software frente al número total de licencias adquiridas para cada aplicación de software con el fin de identificar las licencias excesivas y faltantes.
Paso 3: Optimización de las licencias de software
Con toda la información obtenida en los pasos I y II, rediseñe sus compras de software para optimizar el cumplimiento y alcanzar una tasa de cumplimiento de licencias del 100 por ciento.
Conclusión
Estos 8 KPI, con sus respectivas métricas, le ayudarán a establecer un motor de medición para medir constantemente y mejorar continuamente el rendimiento de su mesa de servicio. El primer paso para establecer este motor de medición es comprender el negocio que atiende la mesa de ayuda de TI y alinear los objetivos de la mesa de ayuda de TI con los objetivos del negocio. El siguiente paso es identificar los KPI y las métricas que son fundamentales para estos objetivos de la mesa de ayuda y medirlos constantemente.
Los 8 KPI clave de la mesa de servicio mencionados son fundamentales para los tres objetivos básicos de la mesa de ayuda de TI: garantizar la continuidad del negocio, hacer que la organización sea productiva y prestar los servicios dentro de los presupuestos y a tiempo, lo que enfatiza el hecho de que estos 8 KPI son los que más deben preocuparle a su mesa de ayuda de TI.