Por qué se estanca un piloto
Un piloto que funciona técnicamente y aun así desaparece casi siempre se estanca por lo mismo: nadie había acordado de antemano cuándo sería suficientemente bueno o quién lo gestionaría después. La tecnología era la parte fácil. Las cinco decisiones siguientes tratan de todo lo demás.
Decisión 1 — ¿Qué problema y por qué ese problema?
Elige un proceso de alta frecuencia cuyos errores sean reversibles. No el proceso con el mayor costo anual, porque normalmente también es el que tiene más excepciones, más partes interesadas y la retroalimentación más lenta.
Registra cuánto tiempo de trabajo requiere hoy cada ejecución y cuánto tarda el proceso de principio a fin. Eso no es un caso de negocio, sino una línea de base; sin esas dos cifras no puedes demostrar nada después y la discusión se convierte en una disputa de opiniones.
Decisión 2 — ¿De dónde vienen los datos y dónde se quedan?
Esta decisión suele aplazarse hasta la revisión de seguridad, y ahí fracasan los pilotos. Define antes qué sistemas se leerán, si se escribirá algo, qué datos saldrán de tu entorno, cuánto tiempo se conservará la información y dónde se procesará. Para muchas organizaciones, procesar en la UE es un requisito obligatorio; es una decisión de diseño, no un detalle que configuras después.
También deja explícito qué datos decides no incluir. Un flujo que ve menos es más fácil de aprobar y de explicar.
Decisión 3 — ¿Qué nivel de control tendrá cada paso?
Para cada paso, elige entre solo lectura, propuestas con aprobación humana y ejecución automática con registro de cada paso. No es una configuración que buscas después: determina cómo será el flujo, quién participará y cuánto tardará el proceso.
Casi todo paso que modifica algo o envía algo al exterior empieza con aprobación. El cambio viene después, respaldado por el registro de propuestas aprobadas y rechazadas; no por intuición ni porque aprobar se sienta como una demora.
Decisión 4 — ¿Cuándo es suficientemente bueno?
Acuerda el criterio de aceptación antes de construir y exprésalo en términos del trabajo del usuario, no de métricas del modelo. Por ejemplo: de cien casos reales, al menos x propuestas se aprueban sin cambios, y los casos que se ajustan requieren menos tiempo que el proceso anterior.
Más importante aún: acuerda también qué ocurre si no se cumple el criterio. Detenerse es un resultado válido y mucho más económico que ajustar un piloto indefinidamente porque nadie se atreve a terminarlo.
Decisión 5 — ¿Quién gestionará esto dentro de seis meses?
Un flujo en producción necesita un responsable que revise las excepciones, alguien que intervenga si cambia un sistema de origen y un acuerdo sobre dónde quedarán el flujo, las credenciales y los registros si termina la colaboración. Resuélvelo al comienzo. Después es una negociación; antes es un párrafo.
Qué ganas con esto
Cuatro de las cinco decisiones juntas toman una mañana y tratan de acuerdos, no de código. Es el momento más económico para cancelar un piloto y la única razón por la que un piloto exitoso después sigue funcionando de verdad.