Métricas de Ops: Tiempo de Ciclo, Rendimiento, Tasa de Error, SLA de Proveedor

La mayoría de los dashboards de Ops son informes de actividad disfrazados de métricas. Tickets gestionados. Reuniones asistidas. Tareas cerradas. Mensajes enviados en Slack. El COO aguanta quince minutos de gráficos de barras y sale sin saber si la función es más rápida, más barata o más fiable. Asentirá con educación y luego le pedirá a Finanzas que modele qué ocurre si le recorta dos personas.

Eso es lo que compra un informe de actividad. Un asiento caro en una reunión donde está perdiendo el argumento antes de empezar.

Un COO quiere tres respuestas. Si el rendimiento está subiendo. Si el costo por proceso está bajando. De dónde vendrá la próxima ruptura. Seis métricas, correctamente segmentadas y con tendencia a lo largo de cuatro trimestres, dan esas respuestas. Todo lo demás es decoración.

Por Qué las Métricas de Actividad Fracasan Hacia Arriba

"Cerramos 1.400 tickets este trimestre" no le dice nada a la sala. No indica si el trabajo fue correcto, rápido o barato. No dice si 1.400 fue más o menos de lo que el mismo esfuerzo produjo el trimestre anterior. No separa una solicitud de reembolso de una incorporación de proveedor de una excepción de nómina, aunque esas tres cosas requieren cantidades radicalmente distintas de tiempo y dinero.

Las métricas de actividad fracasan hacia arriba por una razón estructural. Premian el movimiento, no el resultado. Una vez que un equipo se mide por tickets cerrados, se vuelve muy bueno cerrando tickets, incluyendo el truco de dividir un problema real en cuatro tickets pequeños para inflar el número. El Ops Manager que presenta ese dashboard no está mintiendo. Simplemente está midiendo la cosa equivocada, y el COO lo descubrirá en el segundo QBR.

La solución es cambiar el verbo. Deje de contar lo que hizo el equipo. Empiece a medir lo que entregó la función.

Las Seis Métricas que Pertenecen a una Diapositiva de QBR

Estas seis sobreviven al escrutinio de un COO con formación cuantitativa. Se corresponden con rendimiento, costo y riesgo: las tres cosas que le importan a un ejecutivo con formación financiera. Cada una debe segmentarse por tipo de proceso, porque un promedio que mezcla incorporaciones, reembolsos y órdenes de compra a proveedor es un número que no describe nada.

1. Tiempo de Ciclo por Proceso

Medido desde la entrada de la solicitud hasta la entrega. Mediana, no media. Segmentado por tipo de proceso.

El tiempo de ciclo promedio es una trampa. Una orden de compra atascada que tardó 47 días arrastrará una serie de reembolsos de 2 días hacia un número que parece malo sin serlo, o peor, ocultará una cola en deterioro silencioso bajo un valor atípico. La mediana indica cómo se siente una solicitud típica. El percentil 90 indica cómo se ve el peor caso tolerable. Ambos pertenecen a la diapositiva.

Rangos aproximados para anclar la conversación:

• Reembolso al cliente: una mediana de 1-3 días hábiles es saludable. Por encima de 5 días, hay un cuello de botella en las aprobaciones.
• Orden de compra a proveedor desde la solicitud hasta la emisión: mediana de 5-10 días hábiles. Por encima de 15, el proceso de compras es el cuello de botella.
• Incorporación de nuevo empleado (desde la solicitud hasta el aprovisionamiento completo): mediana de 2-4 días hábiles. Por encima de una semana, IT y HR no están coordinados.
• Escalada de cliente desde la entrada hasta la resolución: mediana de 4-24 horas según el nivel. Por encima de 48 horas, la cola está rota o con falta de personal.

El número en la diapositiva es "Tiempo de ciclo de reembolsos, mediana: 2,1 días, trimestre anterior: 2,8 días, objetivo: 2,0." Tres cifras, un proceso. Luego se repite para el siguiente. Cinco procesos en una diapositiva es el límite antes de que la vista se pierda.

2. Rendimiento Trimestral

Unidades de trabajo completadas, por categoría de proceso, con tendencia a lo largo de los últimos cuatro trimestres.

El mes a mes es ruido. Una vista acumulada de cuatro meses suavizará una semana festiva o una pausa de proveedor. El trimestre a trimestre es el ritmo correcto para un QBR. También es el ritmo con el que Finanzas planifica, lo que significa que su línea de tendencia de rendimiento se alinea con su línea de tendencia de ingresos, y las dos gráficas se hablan entre sí.

La trampa a evitar: no agregue. "Total de tickets cerrados: 1.400" es el número del informe de actividad que está intentando dejar atrás. La versión que justifica el presupuesto es:

Esa tabla le cuenta al COO tres historias distintas. Los reembolsos escalan con el negocio, lo cual está bien. Las órdenes de compra son planas: explíquelo o corríjalo. Las incorporaciones casi se han duplicado, y esa es la línea que justifica la plantilla. Debe estar en la parte superior.

3. Tasa de Error / Porcentaje de Retrabajo

Proporción del trabajo completado que volvió para corrección. Segmentado, con tendencia y con nombre.

"Volvió" necesita una definición en la que el equipo esté de acuerdo antes de que empiece el trimestre. Un reembolso que el cliente disputó porque el importe era incorrecto: retrabajo. Una orden de compra que volvió porque el código de GL era erróneo: retrabajo. Un ticket de incorporación reabierto porque se omitió un acceso al sistema: retrabajo. Los tickets reabiertos por nuevas solicitudes del mismo cliente no son retrabajo, son trabajo nuevo, y confundirlos es cómo un equipo honesto infla accidentalmente su tasa de error.

Rangos aproximados de la industria, como referencia y no como dogma:

• 3-5%: saludable para la mayoría de los procesos de Ops.
• 5-8%: rango normal, observe las tendencias.
• 8-12%: un proceso está bajo presión (la dotación de personal, la formación o las herramientas no están a la altura).
• >12%: un proceso está roto. Deje de añadir volumen hasta que lo corrija.

La tasa de retrabajo es el número más útil de la diapositiva porque es el indicador adelantado de todo lo demás. El costo por proceso sube cuando el retrabajo sube. El tiempo de ciclo sube cuando el retrabajo sube. El NPS del cliente baja cuando el retrabajo sube. Si solo puede incluir una métrica adicional más allá de la capacidad de atención del COO, que sea esta.

4. Porcentaje de Incumplimiento de SLA de Proveedor

Porcentaje de compromisos de proveedor incumplidos en el período, por proveedor. Los tres principales infractores, identificados por nombre.

Esta es la métrica que convierte a una función de Ops pasiva en una que influye en las compras. Los datos de SLA viven en los contratos que firmó y en los tickets que abrió. La mayoría de los equipos de Ops nunca cierran el ciclo entre ambos, que es por qué las renovaciones con proveedores los pillan por sorpresa.

La diapositiva debería verse así:

Dos cosas ocurren cuando esta diapositiva llega a la sala. Primero, Finanzas y compras quieren los datos subyacentes. Dáselos y acaba de convertirse en la fuente de referencia sobre el rendimiento de los proveedores. Segundo, la siguiente conversación de renovación con el Proveedor B y el Proveedor C transcurre de manera muy diferente. Entra con datos de incumplimiento, no con intuiciones, y el precio baja o el contrato desaparece.

Identifique los tres principales infractores por nombre. El COO recordará esos nombres en la reunión de renovación. Ese es el objetivo.

5. Cobertura de Automatización

Porcentaje de los pasos del proceso en alcance que se ejecutan sin intervención humana. Registre el movimiento, no el nivel absoluto.

La cobertura de automatización absoluta es una métrica falsa. Un equipo que procesa reembolsos simples y programables parecerá 80% automatizado. Un equipo que gestiona excepciones contractuales complejas parecerá 15% automatizado y estará haciendo un trabajo más difícil con mayor competencia. Comparar esos dos números carece de sentido.

Lo que importa es el delta. "El trimestre pasado, la automatización de reembolsos era del 62%. Este trimestre, 71%. El próximo trimestre, objetivo 78%." Eso es una historia sobre una función que obtiene más apalancamiento del mismo número de personas, que es el titular que el COO necesita escuchar antes de la conversación sobre el presupuesto.

El denominador también importa. Defina "pasos en alcance" desde el principio y mantenga la definición estable. Mover los postes para que el número quede mejor es un truco de un trimestre que Finanzas descubrirá en cuanto pida la lista de pasos subyacentes.

6. Costo por Proceso

Costo totalmente cargado (mano de obra más herramientas más proveedor) dividido por unidades entregadas.

Este es el número que un COO puede comparar con los ingresos por unidad, que es la comparación que decide si su función se expande o se contrae. Si el ingreso por cliente incorporado es $4.200 y el costo por incorporación es $380, la función tiene economía unitaria obvia. Si el costo por incorporación es $1.100, tiene un problema que necesita visibilizar antes de que lo haga Finanzas.

Tres reglas para calcularlo sin engañarse:

1. Incluya la mano de obra con costo totalmente cargado, no el salario base. Un IC de Ops con $90K cuesta a la empresa aproximadamente $115K-125K una vez incluidos beneficios, impuestos y gastos generales. Use el número cargado.
2. Incluya las herramientas por asignación, no en total. Si su CRM cuesta $80K al año y Ops usa el 30% de las licencias, asigne $24K al costo de Ops, no $80K.
3. Incluya los costos de proveedor que son parte del proceso. Si el Proveedor B cobra $40 por cada llamada a la API de incorporación y realiza 800 incorporaciones, eso son $32K de costo de proveedor que pertenecen al cálculo del costo por proceso.

Compare el costo por proceso trimestre a trimestre junto con el rendimiento. El par cuenta la historia del apalancamiento. Rendimiento subiendo un 30%, costo por proceso bajando un 12%: la función está escalando. Rendimiento subiendo un 30%, costo por proceso subiendo un 8%: está comprando volumen con dinero, no con apalancamiento.

El Diagnóstico de "Alto Rendimiento, Tasa de Error en Alza"

Este es el patrón que pilla por sorpresa a los equipos, y el que un IC de Ops inteligente nombra en voz alta antes de que lo haga el COO.

El rendimiento está subiendo. Los tiempos de ciclo se mantienen. La tasa de retrabajo también está subiendo. El dashboard parece mayoritariamente verde, pero una línea amarilla va aumentando poco a poco.

Esta es la trampa de tomar prestado de la calidad. El equipo está alcanzando el volumen saltándose verificaciones, comprimiendo los pasos de revisión o poniendo a nuevas contrataciones sin suficiente formación en trabajo en producción demasiado pronto. Parece una victoria durante dos trimestres. Luego llegan las quejas del lado del cliente, el backlog de retrabajo explota y el número de tiempo de ciclo se rompe porque una de cada dos solicitudes es ahora un trabajo rehecho.

Causas típicas:

• QA o capa de revisión con insuficiente personal. El volumen creció, la capa de verificación no, así que las verificaciones se omitieron.
• Incorporación de nuevas contrataciones. Tres IC nuevos incorporándose al mismo tiempo elevarán el retrabajo antes de que eleven el rendimiento. El desfase es real y predecible.
• Cambio de herramientas. Un nuevo CRM, un nuevo sistema de tickets, un nuevo workflow de aprobación: todos generan un aumento temporal del retrabajo que debería estar rastreando a propósito, no descubriendo por accidente.
• Compresión del proceso. Alguien eliminó un paso para acelerar las cosas. Ahora el trabajo es más rápido y de peor calidad.

La solución no es frenar el rendimiento. Es identificar qué proceso está generando el retrabajo, segmentar específicamente ese proceso y corregir la causa de origen. Una tasa de retrabajo del 15% en una categoría de proceso es un problema que puede resolverse. Una tasa de retrabajo combinada del 7% en toda la función oculta el proceso roto dentro de los sanos.

Nombre el diagnóstico en voz alta en el QBR. "El rendimiento subió un 14% trimestral, lo cual es positivo. El retrabajo también subió, del 5,1% al 7,4%, concentrado en el procesamiento de órdenes de compra a proveedor. Dos tercios de eso corresponde a un IC nuevo en su curva de aprendizaje. Esperamos que el retrabajo vuelva al 5% el próximo trimestre a medida que se complete la incorporación. Esto es lo que rastreamos semanalmente para confirmarlo." Esa es la narrativa de un IC de Ops que está prestando atención. El COO confiará en la previsión del próximo trimestre gracias a cómo se enmarcó este.

Patrón de Diapositiva para el QBR: Seis Métricas, Una Diapositiva

Todo el conjunto pertenece a una sola diapositiva. Obligarse a que quepa en una es la disciplina. Si no encaja, está complicando demasiado.

El patrón que funciona:

Esa es la diapositiva. Seis filas. Cuatro columnas. Una frase cada una. Sin gráficos de barras. Sin "tickets cerrados" en ningún lado. El COO la lee en 30 segundos y sabe dónde presionar.

El comentario en una línea es la parte que la mayoría de los IC de Ops omiten y la que hace más trabajo. El número le dice al COO qué ocurrió. El comentario le dice si usted entiende por qué. Lo segundo es lo que le consigue el próximo presupuesto.

Métricas de Vanidad a Eliminar

Erradíquelas. No tienen lugar en una diapositiva que va a un COO.

• "Tickets cerrados": sin sentido sin segmentación por proceso y tasa de retrabajo. Un equipo puede cerrar más tickets haciendo un trabajo peor.
• "Tiempo de respuesta promedio" sin segmentación: los promedios ocultan la cola larga. Use la mediana más el percentil 90, por proceso.
• "Horas registradas": mide el esfuerzo, no el resultado. La métrica correcta son las horas por unidad entregada, que no es más que el costo por proceso con otro nombre.
• "Mensajes enviados en Slack" o "reuniones celebradas": indicador de actividad sin vínculo defendible con el resultado. Si alguien en su organización rastrea esto en una diapositiva, averigüe quién y elimínelo discretamente.
• "Tickets envejeciendo" sin umbrales: todos los tickets envejecen. El número que importa es cuántos están envejeciendo más allá de su umbral de SLA.
• "NPS" sin contexto de volumen: un NPS de 72 de 8 clientes es un NPS de 72 de 8 clientes. Acompáñelo del volumen de respuestas o no lo muestre.

La prueba para saber si una métrica pertenece a la diapositiva es sencilla. Si el COO preguntara "¿y qué?" tres veces seguidas, ¿tendría respuesta cada vez? "Tickets cerrados" falla en el primer "¿y qué?". "Costo por proceso" lo responde con tres capas de profundidad.

Lo Que Justifica el Próximo Presupuesto

El IC de Ops que llega al QBR con estas seis cifras, segmentadas por proceso, con tendencia a lo largo de cuatro trimestres y con una frase de comentario honesto en cada una, es el IC que obtiene la próxima ampliación de plantilla. El que se presenta con un gráfico de barras de tickets cerrados pierde el argumento antes de terminar la segunda diapositiva.

Las métricas importan. El encuadre importa más. Un COO no busca un dashboard. Busca un líder de Ops que entienda qué entrega la función, cuánto cuesta y dónde fallará a continuación. Estas seis cifras, bien utilizadas, demuestran las tres cosas.

Preséntelas el próximo trimestre. Luego el siguiente. En el tercer QBR consecutivo con este conjunto, ya no será el IC que presenta métricas. Será la persona a la que Finanzas consulta antes de construir el modelo.

Más Información

• Plantilla de descripción del puesto de Operations Manager
• Cómo Conducir un QBR de Ops que Justifique la Plantilla
• Gestión de Proveedores para Ops Managers
• Documentación de Procesos que Sobrevive a la Rotación