8 métricas y KPI de la mesa de ayuda de TI
para medir el rendimiento

8 indicadores clave de rendimiento (KPI) que todo servicio de asistencia técnica de TI debe conocer

La gente suele decir "lo que se mide mejora", pero rara vez dicen qué, exactamente, se debe medir. Con los desarrollos recientes en las capacidades de generación de informes del software de mesa de ayuda de TI , se pueden medir y monitorear cientos de KPI y métricas de mesa de ayuda.

Pero eso no significa que debas medirlos todos. Solo los KPI y las métricas que son fundamentales para su mesa de ayuda de TI deben medirse para mejorar la prestación de servicios.

Este documento describe los 8 KPI que son fundamentales para cada 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 organizativa y la prestación de servicios a tiempo y dentro del presupuesto. Los KPI son los siguientes:

Asegurar la continuidad del negocio

Hacer productiva la organización

Asegurar la continuidad del negocio

1. Horas comerciales perdidas

La cantidad de horas que la empresa está inactiva porque los servicios de TI no están disponibles.

Objetivo

Mantenga las horas de trabajo perdidas al mínimo.

La mayoría de los equipos de TI realizan un seguimiento de la disponibilidad del servicio para ver el rendimiento general de sus mesas de servicio de TI. Pero el dolor de la pérdida de negocios no siempre se refleja en los niveles de disponibilidad del servicio, incluso cuando esos niveles son altos. Por ejemplo, si la disponibilidad del servicio es del 99,9%, la empresa aún pierde más de ocho horas al año. El seguimiento de las horas laborales perdidas destaca claramente la pérdida y su impacto en el negocio.

Estudio de caso: tiempo sin vuelos en Virgin Blue

En septiembre de 2010, Virgin Blue enfrentó lo que podría considerarse la peor pesadilla de todas las aerolíneas. Cerca de 50.000 clientes y 100 vuelos fueron suspendidos. Cuatrocientos vuelos más se retrasaron o reprogramaron durante los días siguientes porque la infraestructura del servidor de disco de estado sólido que aloja las aplicaciones de Virgin Blue falló. Esto afectó al sistema de registro y reserva en línea de Virgin Blue.

A pesar de los SLA para restaurar los servicios de inmediato, se necesitaron 11 horas para restaurar el servicio y 10 horas más para restaurar las operaciones completas. 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 costaron mucho en términos de disponibilidad del servicio de TI de Virgin Blue para el año, le costaron a Virgin Blue aproximadamente $ 10 millones en términos de negocios perdidos.

Estándares de la industria - Horas comerciales perdidas

Consejos para minimizar las horas laborales perdidas

• Planificación y ejecución adecuadas de actualizaciones de aplicaciones, migración de servidores y cualquier proceso de implementación de cambios de TI .
• Tener una CMDB limpia y bien definida para identificar los puntos críticos de falla y comprender las interacciones de CI en la red para identificar el impacto en cascada de los cambios fallidos.
• Educar a los equipos de TI sobre los riesgos de infracciones de SLA en términos de horas laborales perdidas e ingresos.
• Obtenga información sobre cómo anticipar y manejar interrupciones mediante la evaluación del desempeño anterior de la mesa de ayuda de TI .

Dicho esto, muchos factores podrían contribuir negativamente a la pérdida de horas de trabajo. En 2010, Gartner proyectó que, "hasta 2015, el 80% de las interrupciones que afecten a los servicios críticos para la misión serán causadas por problemas de personas y procesos, y más del 50% de esas interrupciones serán causadas por cambios / configuración / integración de versiones y -Obtener problemas ".

2. Cambiar la tasa de éxito

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

Logre un mayor porcentaje de implementaciones de cambios exitosas.

La opinión sigue dividida sobre lo que implica un cambio fallido. Básicamente se refiere a cualquier cambio que no cumplió con sus objetivos o salió según lo planeado.

Estudio de caso: la interrupción de ASX

El 27 de octubre de 2011, la negociación tuvo que detenerse en la Bolsa de Valores de Australia (ASX) durante cuatro horas debido a una implementación fallida del cambio. Una actualización en la red interna de ASX (para mejorar la latencia de la plataforma de negociación) generó problemas de conectividad sin precedentes entre los componentes de soporte y las puertas de enlace de difusión del sistema de negociación. ASX tuvo que iniciar servicios comerciales desde uno de sus sitios de recuperación de desastres. Finalmente, para restaurar la normalidad, el cambio tuvo que ser anulado esa noche.

Una tendencia a la baja o una tasa de éxito del cambio obsoleto generalmente se debe a fallas en las implementaciones del cambio debido a:

• Falta de información relevante como el impacto del cambio, las dependencias de los activos involucrados, la ventana de implementación del cambio y las prioridades comerciales.
• Incapacidad para colaborar entre equipos para la implementación exitosa del cambio.
• Comunicación inadecuada a los usuarios finales y partes interesadas de la implementación del cambio.

Consejos para una alta tasa de éxito del cambio

• Realice un análisis de impacto adecuado y un plan de implementación detallado con una lista de verificación de las tareas que deben completarse.
• Recopile toda la información relevante de los usuarios finales y los técnicos antes de la implementación.
• Constituir CAB y asegurar un estricto proceso de aprobación.

Cambios no planificados

Otra métrica de la mesa de ayuda que debe rastrearse para tener un proceso de gestión de cambios eficaz es la cantidad de cambios no planificados. Un cambio no planificado puede ser un cambio de emergencia o un cambio urgente.

• Un cambio de emergencia: un cambio de restauración del servicio debido a un incidente o un cambio que debe implementarse rápidamente para evitar un incidente.
• Un cambio urgente o acelerado: cambios que se requieren rápidamente debido a una necesidad urgente, como un requisito legal o una necesidad comercial, pero que no están relacionados con la restauración del servicio.

Aunque no existe un estándar industrial o un número definido para el número de cambios no planificados permitidos en una infraestructura de TI, esta métrica de informes es importante, especialmente durante una tendencia creciente o un pico en el número de cambios no planificados.

Una tendencia creciente en cambios no planificados

Una tendencia creciente en el número de cambios no planificados indica la planificación inadecuada de cambios y cuestiona la eficiencia del proceso de gestión de cambios. Por lo tanto, el proceso de gestión de cambios debe mejorarse para garantizar una planificación y ejecución adecuadas de los cambios.

Tendencia creciente en cambios no planificados

Un pico discreto en cambios no planificados

Un aumento repentino en la cantidad de cambios no planificados puede deberse a incidentes importantes imprevistos, que justifican cambios de emergencia para restablecer el servicio. Tal situación probablemente se deba a una infraestructura inestable, lo que podría afectar la disponibilidad del servicio y, en última instancia, el negocio.

Picos discretos en cambios no planificados

3. Estabilidad de la infraestructura

Una infraestructura altamente estable se caracteriza por la máxima disponibilidad, muy pocas interrupciones y pocas interrupciones del servicio.

Objetivo

Mantener una infraestructura altamente estable.

Para medir y monitorear de manera efectiva 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 importantes

Estabilidad de la infraestructura

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 enrutadores deben reiniciarse varias veces al día, los servidores suelen estar inactivos o las estaciones de trabajo deben reiniciarse de vez en cuando. Por lo tanto, estos activos problemáticos deben identificarse y reemplazarse para garantizar la continuidad del negocio.

Un activo problemático puede ser repetidamente la causa de interrupciones o interrupciones del servicio y, para fines de informes, estos podrían ser activos que tengan más de un par de incidentes asociados. La reducción porcentual en el número de activos problemáticos se puede calcular utilizando la siguiente fórmula:

Reducción porcentual del número de incidentes importantes

Otro indicio importante de estabilidad es la recurrencia de incidentes importantes en la infraestructura de TI, que pueden provocar interrupciones o deterioro del nivel de servicio. Un incidente importante , por definición, es un incidente de gran impacto y alta urgencia que afecta a un gran número de usuarios y priva a la empresa de uno o dos servicios clave.

El objetivo es reducir el número de incidentes importantes, lo que se puede lograr con un análisis de causa raíz (RCA) eficiente y una reducción de la acumulación de problemas. La identificación de las causas raíz y la solución de problemas puede reducir la recurrencia de incidentes importantes y, posteriormente, el volumen de tickets al servicio de asistencia de TI.

Consejos para reducir la acumulación de problemas (y, por lo tanto, los incidentes importantes)

• Inicio más rápido de RCA: en este caso, cuanto antes, mejor. Cuanto antes se inicie la 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ápido, el equipo de TI puede arreglar y resolver el problema más rápidamente, asegurándose de que los incidentes no vuelvan a ocurrir.

Los equipos también pueden medir estos elementos de acción con detalles sobre el tiempo necesario para iniciar el análisis de la causa raíz después de la identificación del problema y el tiempo necesario para completar el análisis de la causa raíz.

Estudio de caso: Reducir los incidentes importantes ayuda 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 en el número de incidentes se logró mediante la mejora de su proceso de análisis de causa raíz.

Reducir los incidentes importantes ayuda 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 mucho tiempo.
• Calidad inconsistente de los RCA y falta de documentación adecuada.
• No comunicar de manera efectiva el proceso de investigación a las partes interesadas.

Sin identificar y rectificar la causa raíz, las posibilidades de que se repitan incidentes importantes son bastante altas. Afortunadamente, sin embargo, la acumulación de problemas se puede reducir mediante:

• Tener un equipo de gestión de problemas dedicado con administradores de problemas y gestores de problemas.
• Identificación y formación de 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 métricas simples de la mesa de servicio de ITIL ^® (reducción porcentual en la cantidad de incidentes importantes y reducción porcentual en la cantidad de activos problemáticos) puede ayudarlo a mantener una infraestructura de TI altamente estable.

4. Tendencias del volumen de entradas

Número total de tickets manejados por el servicio de asistencia de TI y sus patrones dentro de un período de tiempo determinado.

Objetivo

Optimice la cantidad de incidentes y solicitudes de servicio, y prepare al equipo de TI para manejar la carga de tickets.

¿Qué puede hacer con las tendencias del volumen de entradas?

• Identifique picos y valles para optimizar la gestión de recursos y la carga de trabajo de los técnicos.
• Cree un mejor modelo de personal.
• Diseñe sesiones de capacitación para su equipo de mesa de servicio de TI.
• Analice los patrones de solicitud de servicio y planifique con anticipación las compras de activos y licencias.
• Valide los requisitos de recursos adicionales.

Las mesas de ayuda de TI deben estar atentas a algunas tendencias cuando se trata de volúmenes de tickets, como:

Picos discretos

Picos discretos en el volumen de entradas

Un aumento repentino en el volumen de las entradas puede deberse a las siguientes razones:

1. a. Período de máxima actividad empresarial
2. segundo. Implementaciones de TI que conducen a:

• yo. Interrupciones del servicio e indisponibilidad
• ii. Preguntas frecuentes

C. Interrupciones de TI

re. Entradas para restablecer la contraseña después de las vacaciones

Estudio de caso: la ingesta de otoño conduce a un pico de boletos en la universidad

La siguiente figura (7) representa la cantidad de tickets manejados por el servicio de asistencia de TI en una universidad en los Estados Unidos. El gráfico indica claramente un aumento de las entradas en el mes de septiembre de 2012 y 2013. Esto se debe a la mayor cantidad de estudiantes que se unen a la universidad durante el otoño. Por lo tanto, el equipo de TI se asegura de que esta carga adicional se distribuya de manera uniforme en todo el equipo, y cada miembro trabaja horas extras para manejar estos picos de tickets.

Volumen de boletos en una universidad estadounidense

Tendencia progresiva continua al alza

Tendencia continua al alza en el volumen de entradas

Una tendencia alcista podría deberse a alguna de las siguientes razones:

Aumento del tamaño de la organización

A medida que el negocio crece, es obvio que la mesa de servicio de TI tiene que dar soporte a más usuarios finales, lo que normalmente conduce a un mayor volumen de tickets. Este aumento gradual en el volumen de tickets puede manejarse mediante un plan de dotación de personal eficaz de acuerdo con el crecimiento del negocio. Además, los usuarios finales se pueden segregar en departamentos y grupos de usuarios para gestionar los tickets de forma eficaz.

Iniciativas para respaldar más funciones comerciales

A medida que TI comienza a admitir más funciones comerciales, aumenta el volumen de tickets (tanto incidentes como solicitudes de servicio). Esto se puede manejar entendiendo los requisitos y expectativas de los usuarios finales y equipando al equipo de la mesa de ayuda de TI para manejar 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, la cantidad de tickets también aumentará. Esto se puede abordar asociando los incidentes y problemas con sus activos, ayudando al equipo de TI a decidir si retira el activo, mejora los activos, etc.

5. Tasa de resolución de la primera llamada (FCRR)

Porcentaje de incidencias resueltas por el primer nivel de soporte (primera llamada o contacto con la mesa de ayuda de TI).

Objetivo

Tener un mayor nivel de FCRR.

La alta tasa de resolución en la primera llamada generalmente se asocia con una mayor satisfacción del cliente, como lo confirma un estudio que realizó Customer Relationship Metrics. Además, un estudio realizado por el Grupo de medición de la calidad del servicio también reveló que por cada uno por ciento de mejora en FCR, se obtiene un uno por ciento de mejora en la satisfacción del cliente o del usuario final.

La resolución de la primera llamada también está relacionada con el costo por boleto. El siguiente gráfico representa el costo por boleto para cada nivel.

Costo por ticket en varios niveles de soporte

A veces, los técnicos del servicio de asistencia de TI se apresuran a cerrar los tickets durante la primera llamada, incluso sin resoluciones precisas. Estos casos pueden llevar a que aumenten las tasas de resolución de la primera llamada, mientras que las tasas de satisfacción del usuario final disminuyen drásticamente, como se muestra en el siguiente gráfico.

Tasa de resolución de la primera llamada vs. Satisfacción del usuario final

Consejo de excelencia FCRR

A continuación, se incluye una técnica simple de tres fases para que su equipo de soporte técnico de TI resuelva los tickets en la primera llamada.

Fase 1: Conozca el medio ambiente

1. Reúna conocimientos específicos del entorno.
2. Llene la base de conocimientos con la información recopilada, creando artefactos relevantes.
3. Genere informes de estado periódicos sobre el rendimiento de la mesa de ayuda de TI con secciones sobre lecciones aprendidas, logros y obstáculos superados.
4. Invite a expertos para evaluar el desempeño.
5. Cree un manual de operaciones que describa claramente los procesos de soporte, centralice la información ambiental clave y defina explícitamente procedimientos complejos para la resolución de tickets.

Fase 2: Ajuste fino

Genere informes para cerciorarse de que los esfuerzos de la fase I dieron resultado e identifique áreas de mejora. A continuación, se muestran algunos informes de muestra para ayudarlo a comenzar.

• Porcentaje de llamadas atendidas por cada técnico.
• Número de llamadas recibidas por agente, por hora.
• Tiempo medio de conversación por agente.
• De las entradas que no cerramos, ¿a dónde fueron transferidas?
• De esos destinos de transferencia, ¿quién recibió más boletos?

Fase 3: Optimizar

Establezca un proceso bien definido para la mejora continua de la tasa de resolución de la primera llamada.

Esta técnica no solo lo ayuda a mejorar los niveles de FCRR, sino que también ayuda a garantizar que los tickets se resuelvan correctamente, no solo se cierren.

Otra posible tendencia es un FCRR en constante degradación, como se muestra en el siguiente gráfico.

FCRR en constante degradación

Hay algunas razones por las que esto podría ocurrir, pero las razones principales son las siguientes:

• Falta de información del solicitante y del sistema.
• Pobre capacidad técnica.
• Transferencia e intercambio de conocimientos deficientes.

Según los niveles de evaluación comparativa de MetricNet, el FCRR neto promedio para las mesas de servicio a nivel mundial es del 74 por ciento, con un rango del 41 al 74 por ciento. Los factores más comunes entre todos los servicios en el 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 escritorios remotos.

FCRR se puede mejorar con los siguientes consejos:

• Comunicar la importancia de FCRR a los técnicos.
• Diseñar programas de capacitación para técnicos de primer nivel en temas específicos que ayuden a resolver los tickets más rápidamente.
• Mantener una base de conocimientos de artículos y soluciones técnicas avanzadas exclusivamente para, y limitado a, técnicos.
• Cree formularios personalizados para recopilar toda la información relevante en el momento de la creación del ticket para evitar retrasos en los plazos de entrega.
• Enrute automáticamente los tickets al técnico o grupo adecuado según los parámetros del ticket.

6. Tasa de cumplimiento del SLA

Porcentaje de incidencias resueltas dentro del tiempo de SLA acordado.

Objetivo

Mantenga la tasa máxima de cumplimiento de SLA.

El seguimiento de los niveles de cumplimiento de SLA ayuda a las mesas de ayuda de TI a:

• Asegúrese de que los niveles de servicio sean reales y obtenibles.
• Verifique el desempeño de la mesa de ayuda de TI con los niveles de servicio acordados con el usuario final
• Identifique á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 las resoluciones adecuadas, solo para evitar infracciones de SLA. Cuando esto sucede, las tasas de cumplimiento de SLA siguen siendo altas y los niveles de satisfacción del usuario final están destinados a disminuir, como se muestra en el siguiente gráfico.

Tasa de cumplimiento de SLA vs. Satisfacción del usuario final

Sin embargo, los niveles de cumplimiento de SLA pueden caer por otras razones, por lo que es importante tener en cuenta las siguientes posibilidades:

• Es posible que su equipo no comprenda los requisitos comerciales, lo que puede conducir a acuerdos de nivel de servicio que no satisfacen las necesidades comerciales, o una categorización y priorización inadecuadas de los tickets que conducen a violaciones del SLA.
• A menudo existe una falta de comunicación adecuada sobre los riesgos de interrupciones que afectan los servicios de misión crítica y sus impactos comerciales.

Durante tales escenarios, los equipos de la mesa de servicio de TI deben comprender los requisitos del negocio y redefinir sus SLA según corresponda.

Estudio de caso: cuando cumplir los SLA no ayuda

Los SLA y el cumplimiento de SLA son fundamentales para garantizar la continuidad del negocio. Sin embargo, este caso de una empresa de fabricación de cemento enfatiza que los SLA también deben establecerse con cuidado. La mesa de ayuda de TI no estaba disponible para una respuesta inmediata a un problema en el despacho de un camión, pero lo resolvió dentro del SLA. Desafortunadamente, el cemento fabricado tuvo que enviarse a la ubicación del cliente en una hora para evitar el endurecimiento.

La mesa de ayuda de TI no estaba al tanto de esto, y los SLA se establecieron sin considerar 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 decreciente en la tasa de cumplimiento de SLA

Otra tendencia alarmante a la que hay que estar atento es una tasa de cumplimiento de SLA en constante degradación.

Esta tendencia a la baja podría deberse a cualquiera de los siguientes:

• Acuerdos de nivel de servicio poco realistas.
• Falta de conocimiento de los SLA y los riesgos de violaciones de SLA.
• Ausencia de seguimiento adecuado y escalado proactivo.
• Falta de conocimientos técnicos.
• Tickets sin asignar y asignaciones de tickets retrasados ​​y defectuosos.

La tasa de cumplimiento de SLA se puede mantener en niveles más altos mediante:

• Establecer SLA realistas basados ​​en los requisitos comerciales y las capacidades de TI.
• Comunicar los SLA y los riesgos de violaciones de SLA a la empresa y los técnicos.
• Establecer las reglas de escalada necesarias.
• Automatizar el proceso de enrutamiento y asignación de tickets.
• Diseñando programas de formación para sus técnicos.

7. Costo por boleto

El gasto operativo mensual total de soporte de TI, dividido por el volumen de tickets mensuales.

Objetivo

Mantener niveles mínimos de costo por boleto.

Según MetricNet, los siguientes fueron los puntos de referencia de costo por boleto para 2014.

Estándar de la industria: costo por boleto en un entorno de alta densidad

Estándar de la industria: costo por boleto en un entorno de densidad media

Como se ve en ambos casos, el costo de la solicitud de servicio suele ser más alto que el costo de las incidencias. Esto se debe a que los incidentes suelen tardar menos en resolverse que las solicitudes de servicio. Por lo tanto, el costo por boleto está muy influenciado por la combinación de incidentes y solicitudes de servicio.

El soporte de TI se considera un centro de costos en la mayoría de las organizaciones y, por lo general, es el primero en obtener recortes presupuestarios durante una recesión financiera. Por lo tanto, el soporte de TI debe seguir siendo eficiente, incluso cuando se reduce el gasto en TI. El costo por ticket es una métrica clave del rendimiento de la mesa de servicio que ayuda al soporte de TI a analizar su eficiencia en el manejo de tickets dentro de un presupuesto determinado. El objetivo es siempre mantener un nivel óptimo de costo por boleto.

Sin embargo, es importante tener en cuenta que un costo por boleto superior al promedio puede no ser necesariamente algo malo, y un costo por boleto inferior al promedio puede no siempre ser 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 resulta en niveles más bajos de satisfacción del cliente.

Costo por ticket Vs satisfacción del usuario final

El escenario que se muestra en el gráfico anterior muestra dónde el aumento en el costo por boleto se acompaña de un aumento en los niveles de satisfacción del cliente. Esto puede significar que el costo cada vez mayor por boleto 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 la resolución rápida de tickets y reducir cualquier escalada innecesaria. El costo por boleto se puede mantener bajo control siguiendo estos consejos:

• Analice los patrones de solicitud de servicio para planificar con anticipación la compra de activos y licencias, lo que reduce el tiempo necesario para cerrar las solicitudes de servicio.
• Identifique picos y 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 la asignación incorrecta de tickets, lo que ayuda a proporcionar resoluciones rápidas.
• Cree una sólida base de conocimientos .

8. Tasa de utilización de activos de software

Porcentaje de productos de software y licencias en uso real por parte de la empresa.

Objetivo

Maximice el ROI (retorno de la inversión) de las inversiones en software.

Dado que las compras de licencias de software representan una parte importante del gasto en TI, es importante realizar un seguimiento de la utilización del software. Desafortunadamente, esta es una de las métricas de la mesa de servicio menos discutidas. Para una fácil administración, el software se puede clasificar de la siguiente manera:

• Categoría 1 : software que necesita la mayor atención (con las mayores implicaciones comerciales, 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 y malware prohibidos.

Las siguientes métricas de la mesa de servicio se pueden utilizar para realizar un seguimiento de la utilización del software:

Relación entre el total utilizado y el software de propiedad total

Esta métrica ayuda a identificar cualquier gasto de compra de software que no aporta ningún valor a la organización. Idealmente, esta proporción debería ser cercana a uno, lo que significa que hay una utilización máxima de todo el software comprado, asegurando así un ROI máximo en la compra de la licencia de software. Una gran cantidad de software de categoría uno en la lista no utilizada significa que una parte importante del gasto en activos de software se encuentra en software inactivo.

Relación de licencias no asignadas con respecto al recuento total de licencias

Esta métrica ayuda a analizar la utilización de la licencia de un software en particular, lo que ayuda a los equipos de TI a planificar con anticipación la compra de licencias. La proporción debe ser lo más pequeña posible para obtener el máximo retorno de la inversión. Una proporción más alta podría significar que algunas de las aplicaciones de software tienen licencia excesiva, lo que podría ser una inversión inactiva sin retorno de la inversión.

Estudio de caso: aumentar la utilización de activos de software ahorra un millón de dólares

Una empresa farmacéutica líder a nivel mundial ahorró alrededor de un millón de dólares en gastos de licencias de software . La compañía farmacéutica, con sus servicios repartidos en más de 50 países, estaba utilizando una amplia gama de productos de Microsoft. En una oficina en particular, había miles de aplicaciones de software con licencia bajo un contrato 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 los requisitos comerciales.

De hecho, la empresa tenía información limitada sobre los activos de software y la cantidad y tipo de activos que la organización realmente necesitaba. Esto, una vez más, puso a la organización en riesgo de licencias excesivas, licencias insuficientes y sanciones de cumplimiento.

La mesa de ayuda de TI comenzó con un análisis simple comparando el software de Microsoft instalado con las licencias de Microsoft que tenían. La información obtenida y los esfuerzos de TI para comprender los requisitos comerciales llevaron a la compra de una licencia de Microsoft rediseñada que implicó pasar de la edición Microsoft Office Professional a la edición estándar más económica, que cumplía con los requisitos comerciales.

Además, se reemplazaron varias otras licencias por volumen, lo que provocó recortes de costos que le ahorraron a la empresa alrededor de un millón de dólares en sus compras de licencias de software.

Tasa de cumplimiento de la licencia

Otra métrica importante de gestión de activos de software que podría generar costos para la organización es la tasa de cumplimiento de la licencia. Mantener el máximo cumplimiento puede salvar a su organización de sanciones y multas. A continuación, se ofrecen algunos consejos para lograr el máximo cumplimiento:

• Realice un seguimiento de todas las instalaciones de software y compras de licencias .
• Asigne licencias a instalaciones de software individuales para encontrar el software que cumple o no cumple con las normas.
• Adquiera los tipos de licencia adecuados para el software. Por ejemplo, es mejor comprar una licencia perpetua para un software central para evitar problemas de cumplimiento debido a la caducidad de la licencia.
• Lleve a cabo evaluaciones internas formales para el cumplimiento y la preparación para la auditoría.

Logre el máximo cumplimiento con una auditoría previa de tres pasos

La tasa de cumplimiento de licencias del cien por ciento ya no será un mito con esta simple auditoría previa de tres pasos.

Paso 1: análisis de brechas

• Solicite una lista de todas las aplicaciones de software con licencia para su organización del proveedor específico.
• Identifique y señale el software que utiliza la empresa, pero que no se encuentra en la lista proporcionada por el proveedor.

Paso 2: análisis de cumplimiento

Verifique el número total de instalaciones de software frente al número total de licencias adquiridas para cada aplicación de software para identificar el software con licencia excesiva o insuficiente.

Paso 3: optimización de la licencia 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 lograr una tasa de cumplimiento de licencias del 100 por ciento.

Conclusión

Estos 8 KPI, con sus respectivas métricas, lo ayudarán a establecer un motor de medición para medir y mejorar constantemente el desempeño de su mesa de servicio. El primer paso para establecer este motor de medición es comprender el negocio que respalda la mesa de ayuda de TI y alinear los objetivos de la mesa de ayuda de TI con los objetivos comerciales. 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 de la mesa de servicio que se analizan aquí son fundamentales para los tres objetivos básicos de la mesa de ayuda de TI de garantizar la continuidad del negocio, hacer que la organización sea productiva y prestar servicios dentro de los presupuestos y a tiempo, lo que subraya el hecho de que estos 8 KPI son los que necesita su TI. la mesa de ayuda debería preocuparse más.