El proceso de tickets de TI como modelo de cálculo listo

Entrada: 24 000 tickets al año, es decir, alrededor de 96 en un día laboral, con una dispersión diaria del 28 % y un factor de pico de 1,35 en el 8 % de los días. Puestas en marcha, despliegues, incidencias.

La columna «Porcentaje» es la razón por la que esta plantilla se lee de forma distinta que las demás: El segundo nivel ve solo un tercio de los tickets. Si se calcula su carga respecto del total, se obtienen 155 % y se considera sobrecargado un paso que en realidad muestra 57 %.

El hallazgo decisivo. La probabilidad de cuello de botella por paso a partir de 20 000 ejecuciones:

La columna suma 100 %: en cada ejecución se cuenta exactamente un paso que ata, el que tiene la mayor carga ese día.

El segundo nivel, que en la empresa se considera la causa de los largos tiempos de tramitación, lo es en el 14 % de las ejecuciones. El Servicedesk, el lugar donde un ticket solo se registra durante cinco a diez minutos, lo es en el 75 %. El proceso pierde el tiempo antes del trabajo, no en él.

Y aquí es donde falla una tabla: Cinco minutos por ticket pasan desapercibidos. 96 veces cinco a diez minutos, no.

1. Tickets por día laborable. Tickets del último año ÷ días laborables. Aparece en el informe del helpdesk, y concretamente donde también se cuentan tickets duplicados y colectivos. Use la misma definición que empleará más tarde al volver a medir.
2. Factor de pico. ¿Cuántos tickets llegan en el día más fuerte frente a uno normal? Lunes, el día después de un despliegue, el día de una incidencia. Es habitual un factor de 1,3 a 2. Sin este valor calculará un Servicedesk que nunca está bajo carga, y la carga es el estado normal en los tickets.
3. Personas en el Servicedesk y sus horas para triaje. No el número de cabezas del equipo. Quien atiende llamadas además no tiene ocho horas para registro.
4. Rango de procesamiento del triaje. Extremo inferior y superior. Cinco minutos para una contraseña, veinte para una incidencia que primero hay que reconstruir. Precisamente este rango impulsa el tiempo de espera.
5. Porcentaje resuelto de inmediato. En la plantilla 65 frente a 35. Este número aparece en todo informe de helpdesk como «First Contact Resolution» y es el único que realmente puede medir. Desplaza carga entre las ramas, no antes de ellas.
6. Tarifas de coste completo por rol. Salario bruto × 1,5 a 1,8, dividido por alrededor de 1 500 horas productivas al año. Con 24 000 procesos anuales, cada euro de diferencia en la tarifa tiene mucho peso; una tarifa ingenua calculada como salario ÷ 2 080 horas hace que la afirmación en euros sea atacable más tarde.

Comprobación antes de calcular: Cuente los tickets abiertos en el sistema y divídalos por los tickets que cierra en un día (Little's Law). Si sale su tiempo de tramitación conocido, el modelo es utilizable. Si difiere mucho, falta una cola; en los tickets casi siempre falta el estado «espera respuesta del usuario».

Lo que la plantilla no contiene. El tiempo de paso es procesamiento más cola en días laborables. No se modela la priorización: el modelo trabaja en orden de llegada. Quien tiene una priorización real la representa como una segunda rama con su propia capacidad; de lo contrario el modelo calcula los tickets urgentes demasiado despacio y el resto demasiado rápido. Tampoco incluye tiempos de inactividad en los que un ticket espera al usuario.

Palanca 1. Un formulario en la entrada. Campos obligatorios para dispositivo, aplicación, síntoma del error y prioridad. La Triage pasa de 5–10 a 3–6 minutos porque se evita reconstruir la información. Efecto: P90 del tiempo de ciclo de 4,9 a 0,22 días laborables, carga en el día pico de 129 % a 77 %. La palanca más barata en el campo, y la única que no requiere personal.

Palanca 2. Una tercera persona en el servicio de asistencia. También tiene un efecto notable (0,38 días), pero cuesta un puesto. La relación con la palanca 1 es la verdadera tesis de esta tabla.

Palanca 3. Base de conocimiento que intercepta el 20 % de los tickets. Menos tickets siempre es mejor, pero no resuelve el cuello de botella: la Triage sigue siendo el paso limitante en el 75 % de los recorridos, su carga cae solo de 129 % a 103 % en el día pico. Una quinta parte menos de volumen apenas empuja un paso por encima de la línea, no más.

Palanca 4. Más tickets resueltos en el primer nivel. El hallazgo nulo más interesante. Elevar la tasa de resolución en primer contacto de 65 a 75 % es la recomendación estándar en soporte y funciona: el coste laboral por ticket baja de 28,82 € a 25,34 €, porque los minutos caros de segundo nivel son sustituidos por minutos más baratos de primer nivel. El tiempo de ciclo no mejora, incluso aumenta mínimamente a 5,0 días. La palanca ahorra dinero, no tiempo. Quien la venda como medida para reducir los plazos estará vendiendo lo incorrecto sobre la misma medida correcta.

Calcule las cuatro por separado y ordénelas por efecto por esfuerzo. La palanca 1 es un formulario, la palanca 2 un puesto, y en el modelo están separadas por 0,16 días.

Cómo, a partir de 20 000 ejecuciones, se obtiene un porcentaje por paso se explica en el artículo Simulación de Monte Carlo para procesos; por qué ya un 85 % de carga es demasiado, en Cálculo del cuello de botella.

Tras asegurar el estado actual, aplicar una palanca modificada y realizar una segunda ejecución, la comparación muestra:

• Tiempo de ciclo antes/después como P50 y P90. Un compromiso de servicio se compara con el P90, no con la mediana. Ahí es donde una afirmación de SLA difiere de una afirmación de promedio: la mediana dice 0,08 días y, aun así, la promesa se incumple uno de cada diez días.
• Carga por paso en el día pico y el nuevo cuello de botella tras la medida. En este modelo se desplaza al primer nivel en dos de las cuatro palancas.
• Rendimiento como tickets por semana frente a los entrantes: 455 de 480 en el estado actual. La diferencia es el acumulado que el servicio de asistencia genera cada semana.
• Coste de tiempo laboral por ticket y por año, calculado a partir de volúmenes, tiempos y costes completos. Con 24 000 procesos, influye cada céntimo; la plantilla considera 28,82 € por ticket.
• La lista de suposiciones con cada entrada estimada. La frase «Priorización y pausas no están modeladas» atenúa la objeción más dura antes de que se formule.

Se entrega como dos PDF: propuesta para el decisor, documentación para la trazabilidad, con su membrete si ha cargado uno.

La misma plantilla, dos preguntas. Esta página responde la cuestión de cálculo: de dónde salen el 75 % y por qué una quinta parte menos de tickets no resuelve el cuello de botella. La otra pregunta (qué se recomendaría y cuánto cuesta un ticket que queda pendiente) pertenece al método y no a la herramienta. Está en el archivo de análisis de Flowrefy, junto con el procedimiento del que surgieron estas plantillas. Un conjunto de datos, dos preguntas, dos públicos.

• El procesamiento de pedidos va desde el pedido hasta la confirmación del pedido. El caso con un rol compartido: dos pasos que por separado parecen cómodos son la tarde de la misma persona.
• El proceso de ofertas es el caso en el que el tiempo de ciclo afecta a los ingresos en lugar de a los costes.
• La aprobación de facturas es el caso de volatilidad: de media por debajo de la capacidad, al final de mes por encima.
• En la reclamación el cuello de botella está fuera de la empresa, y la recomendación honesta por eso no es «automatizar».
• El onboarding de empleados tiene poco volumen y muchos participantes, y un paso ocupa el 86 % de las ejecuciones.
• El ticket de TI es esta página.

Cada plantilla se abre en la ventana de bienvenida a través de Ver plantillas. La primera vez merece la pena abrir una antes de empezar su propio modelo. Si no, se construye demasiado fino.