Piloto de innovación: ¿cuántos casos debe ver?
¿Cuántos casos necesita ver un piloto? Todos los que la operación produce con frecuencia suficiente para aparecer en un año, incluido el cierre de mes, la cancelación, la corrección y la excepción que nadie documentó. La duración no mide eso. Un piloto de tres semanas puede ver mucho o casi nada, según qué casos entraron en él.
¿Por qué el piloto funcionó y el sistema no?
Porque los dos se enfrentaron a poblaciones distintas. El piloto recibió los casos que cupieron en la ventana, y la ventana la eligió el calendario del proyecto. El sistema recibe la operación entera, con el cierre de mes, el cliente que cancela a mitad de camino, el pedido que vuelve y la factura emitida mal.
Eso no es una falla de ejecución del piloto. Es consecuencia de cómo se dimensionó. La pregunta que suele abrir la reunión de planificación es cuánto va a durar la prueba. La pregunta que decide el resultado es qué casos tiene que contener.
Ya tratamos cómo montar el experimento y qué falta después de aprobarlo. Este artículo es anterior a los dos: lo que entró en la prueba.
¿Cuántos caminos tiene un proceso real?
Más de los que el diagrama de proceso suele mostrar. Se puede responder eso con datos, porque algunas empresas empezaron a donar sus registros de eventos a la investigación.
Uno de los casos públicos mejor documentados es el de una multinacional holandesa de pinturas y recubrimientos, que en 2019 abrió para investigación los pedidos de compra de 2018 de parte de sus 60 filiales. Son 76.349 documentos de compra, 251.734 ítems y 1.595.923 eventos registrados en 42 tipos de actividad, ejecutados por 607 personas y 20 procesos automáticos (descripción oficial del registro).
Dos alumnos de la RWTH Aachen, en la categoría estudiante del desafío, analizaron ese registro y contaron 11.973 secuencias distintas de actividades (Hüser y Heisenberger). Un caso tiene entre 1 y 990 eventos.
El número que más le importa a quien diseña un piloto es otro. Seis actividades concentran cerca del 86% de los eventos, y las otras 36 se reparten lo que queda. Un piloto dimensionado por lo que más aparece ve el proceso con seis palabras.
Ese formato no es exclusivo de aquel registro, y el extremo opuesto también existe. Un grupo de la TU München catalogó 98 registros públicos de procesos reales en 37 atributos, entre ellos la cobertura de las cinco variantes más frecuentes, y anotó recuentos de variantes que van de 1 a 22.632 (Costa, Eroglu, Andree y Pufahl). Dónde cae tu operación en ese rango es una pregunta empírica, no una suposición.
Lo que el piloto descubre y el diagrama no sabía
La parte útil de la prueba rara vez es la confirmación. Es la distancia entre el proceso que la empresa cree tener y el que ejecuta.
En el registro de compras, la empresa cree que un grupo específico de ítems siempre pasa por un cotejo entre la recepción de la mercadería y la recepción de la factura. Dentro de la categoría dominante del registro, los analistas encontraron unos 14.000 casos, de 747 proveedores distintos, en los que los dos asientos no aparecieron juntos. El control existía en el documento y no en la ejecución. Quien escribe el piloto a partir del documento hereda esa distancia entera.
En la misma categoría, 53.092 casos necesitaron quitar un bloqueo de pago antes de liquidar la factura, y 7.800 terminaron con el ítem de compra borrado, un desenlace que suma 72 días en promedio al caso. Ninguna de esas tres cosas es el camino que alguien dibuja en la pizarra.
Un segundo registro, de otro sector, muestra el mismo tipo de desvío con números menores. Al seguir a 1.050 pacientes con sospecha de sepsis en un hospital regional holandés durante un año y medio, Felix Mannhardt y Daan Blinde midieron, en un estudio publicado en 2017, la adherencia a dos reglas clínicas de tiempo: antibiótico dentro de la hora posterior al triaje y lactato dentro de las tres horas (informe BPMDS).
La primera regla se violó en el 58,5% de los casos. La segunda, en el 0,7%.
Los propios autores no leen ese 58,5% como un veredicto sobre la atención. Señalan dos explicaciones que compiten: la regla de una hora es reconocidamente estricta y no todos los pacientes de la muestra tenían sepsis grave; y la hora del antibiótico se carga a mano, con registros 24 horas después del triaje y otros anteriores a él. Su conclusión es que la medición, sola, no sostiene una acción.
Para quien dimensiona un piloto, ahí está la lección. La distancia entre el 58,5% y el 0,7% puede ser una regla que no cabe en la operación o un registro que no captura lo que pasó, y las dos hipótesis solo se separan midiendo.
Cómo dimensionar la cobertura en lugar del calendario
Empieza por la lista, no por el cronograma. Antes de elegir la fecha de inicio, escribe los casos que el piloto tiene que contener, con nombre y cantidad mínima:
El caso común, para ver si el diseño básico funciona. La excepción que el equipo resuelve hoy por fuera, con una hoja de cálculo, un mensaje o una llamada. El caso de corrección, cuando alguien se equivoca y hay que deshacerlo. La cancelación a mitad del flujo. El caso periódico, que solo existe en el cierre del mes o del trimestre.
Ese último es el que más se escapa. En el proceso de compras de la multinacional, un ítem de alquiler genera un pedido y doce recepciones a lo largo del año, una por mes, cada una con una factura por un doceavo del valor. Los ítems de logística llegan a cientos de recepciones en una sola línea. Un piloto de tres semanas no ve nada de eso, y no por ser corto: por no contener el caso.
Cuando un caso de la lista no se puede producir dentro del período, tienes dos salidas honestas. Inyectar el caso a propósito, reprocesando un registro real del año pasado dentro del piloto. O declarar el caso como no cubierto, por escrito, y tratarlo como riesgo abierto en la decisión de promoverlo.
Existe una tercera salida, que es suponer que va a funcionar porque los otros funcionaron. Esa es la que suele producir el sistema que se rompe en el primer cierre.
Cómo funciona esto en la práctica
El escenario siguiente es una hipótesis de trabajo, no una medición de cliente. Sirve para mostrar la diferencia entre las dos formas de dimensionar.
Una empresa de mantenimiento de equipos que factura cerca de 280.000 euros al mes prueba un sistema de órdenes de servicio. El piloto corre tres semanas con dos técnicos y cierra 60 órdenes sin incidentes. La recomendación es promoverlo.
Reescrito por cobertura, el mismo piloto pide otra cosa. Treinta órdenes comunes. Cinco atenciones con una pieza en garantía, que hoy el técnico resuelve por teléfono con el proveedor. Cinco órdenes abiertas y canceladas por el cliente después del desplazamiento. Tres casos de retrabajo, cuando el equipo vuelve por la misma falla en menos de 30 días. Y el cierre mensual del contrato, que hay que reprocesar con datos de un mes pasado porque no cabe en la ventana.
Las treinta órdenes comunes probablemente pasan con cualquiera de los dos diseños. Las otras trece son las que definen si hay un sistema o una pantalla bonita con una operación paralela detrás.
El caso que el piloto no vio necesita una dirección
Esta es la parte arquitectónica, y vale incluso para el piloto bien dimensionado, porque la cobertura completa no existe.
El caso imprevisto termina ocurriendo. La única elección real es si ocurre dentro del sistema o fuera de él. Sin un lugar definido, se va. Se convierte en un mensaje en el móvil de alguien, y después en conocimiento que solo esa persona tiene. Así fue como la operación llegó a ser lo que es hoy.
Tres decisiones resuelven esto, y todas caben antes del go-live. Dónde queda registrado el caso fuera de patrón, con el mismo identificador que el caso común. Quién tiene atribución para resolverlo y en qué plazo. En qué estado queda el registro después, para que el informe del mes siguiente sepa contarlo.
Sin esas tres, el sistema queda con una cobertura declarada que la operación no respeta, y el número que sale de él deja de coincidir con finanzas.
El estudio del hospital deja además una lección sobre método. El modelo de proceso generado automáticamente por los algoritmos resultó demasiado impreciso para conversar con médicos y enfermeros. El modelo dibujado a mano, en rondas con quien ejecuta el trabajo, cubrió el 98,3% del registro. Leer bien el dato sigue dependiendo de quien opera.
Preguntas frecuentes
¿La implementación va a exigir demasiado tiempo del equipo?
Dimensionar por cobertura suele costar menos tiempo que dimensionar por calendario, porque cambia semanas de observación pasiva por casos elegidos. Un piloto que inyecta cinco excepciones en la primera semana aprende más que uno que espera tres semanas a ver si aparece alguna. El costo real está en reprocesar registros viejos, y eso suele ser trabajo de horas y no de sprints.
No veo cómo medir el resultado del piloto.
Mide cobertura antes de medir desempeño. La lista de casos escrita al inicio se convierte en el tablero: cuántos se ejecutaron dentro del sistema, cuántos salieron a una hoja de cálculo o a un mensaje, cuántos nadie logró producir. Ese tablero es verificable y no depende de la opinión del usuario, a diferencia de la percepción de que la prueba salió bien.
Temo que el sistema no elimine los cuellos de botella de verdad.
Ese temor está fundado, y la cobertura existe justamente para resolverlo. El cuello de botella rara vez vive en el caso común, que ya es rápido porque se repite. Vive en la excepción, en el retrabajo y en la espera por una decisión. Un piloto que solo vio el caso común no tiene cómo demostrar nada sobre el cuello de botella, y aprobar por eso es decidir sin evidencia.
El siguiente paso
Si tu piloto está por promoverse y la lista de casos que vio nunca se escribió, vale una conversación de 30 minutos: el Diagnóstico de Arquitectura Operacional mapea qué caminos produce tu operación antes de que se tome la decisión.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico