Del piloto a producción: por qué las automatizaciones se quedan a mitad

Un piloto demuestra que algo es posible; producción exige que sea confiable, mantenible y de alguien. La distancia entre ambos no es técnica sino operativa, y por eso un piloto impecable puede quedarse meses sin avanzar mientras nadie identifica qué falta exactamente.

A continuación: qué demuestra realmente un piloto, las cinco cosas que faltan al pasar, cómo se diseña el paso desde el inicio, qué criterios deciden si vale la pena, y qué hacer con los pilotos que no deberían avanzar.

Hay un patrón que se repite en programas de automatización de toda la región. La prueba de concepto sale bien, se presenta en comité, genera entusiasmo, y después el asunto se enfría. Seis meses más tarde nadie sabe muy bien en qué quedó.

La lectura habitual es que faltó decisión o presupuesto. En la mayoría de los casos que hemos visto, lo que faltó fue algo más concreto: nadie definió qué significaba estar listo para producción, así que no hubo forma de declarar que se había llegado.

Qué demuestra un piloto, y qué no

Un piloto demuestra viabilidad técnica: que la herramienta puede leer ese sistema, aplicar esa regla y producir ese resultado. Es información valiosa y suele ser la que menos duda generaba.

No demuestra que funcione con el volumen real, porque se probó con veinte casos elegidos. No demuestra que resista las excepciones, porque los casos raros se excluyeron para que la demostración fuera limpia. Y no demuestra que alguien vaya a mantenerla, porque durante el piloto la mantiene quien la construyó, que está mirándola todos los días.

Esa asimetría explica el estancamiento. El piloto responde la pregunta fácil con mucha claridad y deja las difíciles intactas, pero produce una sensación de avance que retrasa el momento de plantearlas.

Las cinco cosas que faltan al pasar

Manejo de excepciones. En el piloto, cuando algo no encaja, la persona que construyó lo resuelve a mano en el momento. En producción hace falta una cola, una regla de enrutamiento y alguien que la atienda dentro de un plazo.

Vigilancia. Nadie mira una automatización en producción. Si no avisa cuando falla, el fallo se descubre en el cierre. Hacen falta comprobaciones sobre la salida —conteo, sumas, tasa de excepción— y una alerta que llegue a una persona nombrada.

Credenciales propias. El piloto corrió con el usuario de quien lo construyó. Producción exige una identidad técnica con permisos acotados y una contraseña que pueda rotar sin romper el proceso.

Un responsable. Con nombre, no un área. Y con tiempo asignado, porque un dueño sin horas disponibles es una formalidad.

Un camino de vuelta. Qué se hace si hay que detenerla, cómo se procesa el trabajo mientras tanto y cómo se reprocesa después sin duplicar. Es lo que menos se prepara y lo primero que se necesita cuando algo sale mal.

Cómo se diseña el paso desde el primer día

La forma más efectiva de acortar la distancia es reducirla antes de empezar: definir los criterios de producción al aprobar el piloto, no al terminarlo. Cinco líneas bastan, y son las cinco de arriba.

Eso cambia lo que el piloto prueba. En lugar de veinte casos escogidos, se prueba con una muestra que incluya las excepciones conocidas. En lugar de correr en el equipo de alguien, corre donde correrá. Y en lugar de resolver los problemas a mano, se registra cada uno como requisito pendiente.

Un piloto así es menos lucido y mucho más informativo. Termina con una lista corta de lo que falta en lugar de una sensación difusa de que ya casi está.

El criterio que decide si vale la pena avanzar

No todos los pilotos deberían pasar, y esa es una conclusión legítima. La pregunta que ordena la decisión es qué cambió respecto al caso de negocio original: si el piloto reveló que el proceso tiene más excepciones de lo previsto, o que el sistema de origen cambia cada trimestre, el retorno estimado ya no es el que se aprobó.

Conviene recalcularlo con lo aprendido y volver a comparar. Un caso que era rentable con un ochenta por ciento de automatización puede no serlo con un cincuenta, y esa cifra solo se conoce después de probar.

Cuando el número deja de cerrar, detenerse es la decisión correcta. El costo hundido del piloto ya se pagó; añadir el de producción para no reconocerlo es una decisión peor.

Qué hacer con los pilotos que no avanzan

Retirarlos explícitamente. Un piloto que queda corriendo «por si acaso» en el equipo de alguien es una automatización en producción sin ninguna de las cinco condiciones — sin vigilancia, sin dueño, con credenciales personales — y es justamente el perfil que genera incidentes difíciles de diagnosticar.

La conversación de cierre debería producir tres cosas: la decisión escrita, el aprendizaje que deja para el siguiente caso, y la baja efectiva de lo que quedó corriendo.

Ese registro tiene valor propio. Un programa que documenta por qué descartó cuatro casos toma mejores decisiones en el quinto que uno que solo recuerda los éxitos.

Quién debe decidir el paso, y con qué información

La decisión de llevar algo a producción suele tomarla quien patrocinó el piloto, que es también quien tiene más interés en que avance. No es mala fe: es que la persona que defendió el caso ante el comité difícilmente será la que proponga detenerlo.

Un arreglo que funciona mejor separa las dos cosas. El área que ejecuta el proceso decide si el resultado le sirve; quien va a operar la pieza declara si cumple las condiciones de producción. Ambas respuestas tienen que ser afirmativas, y son preguntas distintas que conviene no mezclar en una sola reunión.

La información que necesitan también difiere. La primera se contesta con el porcentaje de casos resueltos y el tiempo ahorrado medido, no estimado. La segunda con una lista de verificación concreta: existe la cola de excepciones, existe la alerta, existe la identidad técnica, existe el responsable con horas asignadas, existe el procedimiento de reproceso. Cinco casillas que se marcan o no se marcan.

El patrón que evita todo esto

Los programas que avanzan con regularidad comparten una característica: no hacen pilotos sueltos. Hacen entregas pequeñas y completas — un tramo acotado del proceso, pero con manejo de excepciones, vigilancia y dueño desde el primer día.

Es menos vistoso que una demostración amplia y llega a producción, que es la única condición que importa. Y tiene una ventaja adicional: el equipo aprende el estándar construyendo, en lugar de recibirlo como un documento después.

Esa disciplina es una de las decisiones que concentra un centro de excelencia, y la evaluación de qué casos merecen ese esfuerzo la produce un assessment de automatización de procesos, que califica volumen, estabilidad del proceso y viabilidad técnica antes de que nadie construya nada. Cuando la capacidad de sostener lo entregado no existe internamente, un modelo de servicios administrados la cubre desde Bogotá y Ciudad de México, en el huso horario de quien depende del proceso.

Preguntas frecuentes

¿Por qué un piloto exitoso no llega a producción?

Porque demuestra viabilidad técnica y deja intactas las preguntas operativas: manejo de excepciones, vigilancia, credenciales propias, un responsable con tiempo y un camino de vuelta. Ninguna es técnica y todas hacen falta.

¿Qué debería probar un piloto para ser útil?

Una muestra que incluya las excepciones conocidas, corriendo donde correrá en producción, registrando cada problema resuelto a mano como requisito pendiente. Es menos lucido y termina con una lista concreta de lo que falta.

¿Cuándo conviene no avanzar a producción?

Cuando el piloto reveló más excepciones o más inestabilidad de lo previsto y el retorno recalculado ya no cierra. El costo del piloto está hundido; añadir el de producción para no reconocerlo es la decisión peor.

¿Qué se hace con un piloto que se descarta?

Se retira de forma efectiva. Un piloto que queda corriendo en el equipo de alguien es una automatización en producción sin vigilancia, sin dueño y con credenciales personales, que es el perfil que más incidentes genera.

¿Cuándo se definen los criterios de producción?

Al aprobar el piloto, no al terminarlo. Cinco líneas bastan, y definirlas antes cambia lo que el piloto prueba y acorta la distancia en lugar de descubrirla.

¿Hay una alternativa al piloto?

Entregas pequeñas y completas: un tramo acotado del proceso pero con excepciones, vigilancia y dueño desde el primer día. Es menos vistoso, llega a producción, y el equipo aprende el estándar construyendo.