Cuánto dura de verdad un piloto de automatización

Un piloto de automatización bien acotado sobre un único proceso dura aproximadamente un trimestre desde el arranque hasta tener un sistema haciendo trabajo real en producción. No una demo, no un entorno de pruebas: un proceso funcionando con datos reales y una persona todavía vigilándolo. Ese calendario asume que tienes un proceso claramente delimitado, un responsable de negocio con nombre que puede tomar decisiones sin necesidad de un comité, y acceso de IT concedido en las dos primeras semanas. Si falla cualquiera de esos tres puntos, el trimestre se alarga.

La mayor parte de ese tiempo no se dedica a escribir código. La construcción en sí suele ser la fase más corta. Lo que realmente alarga el proyecto es entender qué hace el proceso de verdad (en contraposición a lo que dice el procedimiento escrito), conseguir acceso con credenciales a los sistemas implicados, y ejecutar el nuevo sistema en paralelo con el antiguo el tiempo suficiente para que la gente confíe en el resultado. Si un proveedor te dice que puede entregar una automatización en producción en dos semanas, o está automatizando algo trivial, o se salta la ejecución en paralelo, o te está entregando un prototipo y llamándolo piloto.

Las cinco fases, y en qué se va el tiempo de verdad

Mapeo del proceso. Aquí es donde observamos cómo se hace el trabajo de verdad. No un taller donde alguien describe el proceso de memoria, sino observación real, grabaciones de pantalla, muestreo de transacciones reales y un recuento de las excepciones. Todo proceso tiene un camino ideal documentado y una realidad no documentada hecha de soluciones improvisadas, hilos de correo y una persona que sabe qué hacer cuando falta el código de proveedor. La fase de mapeo existe para encontrar esa realidad. Suele llevar de dos a tres semanas para un solo proceso, y se alarga cuando el trabajo está repartido entre varios equipos que lo hacen cada uno un poco distinto.

El resultado no es un diagrama por el diagrama. Es una decisión: qué parte de este proceso merece la pena automatizar, qué excepciones vamos a gestionar en el software y cuáles vamos a enviar deliberadamente a una persona. Equivocarse en ese límite es, con diferencia, el error más caro de un piloto, porque sale a la luz durante la ejecución en paralelo, que es cuando repetir el trabajo resulta más disruptivo.

Diseño. Fase corta, de gran impacto. Aquí decidimos el enfoque de integración (API, base de datos, entrega de ficheros o automatización de interfaz como último recurso), el modelo de datos, la ruta de gestión de excepciones, el rastro de auditoría, y qué significa "correcto" en términos que se puedan probar. El diseño también cubre el modelo operativo: a quién se avisa cuando la automatización se detiene, quién aprueba una excepción, qué pasa durante el cierre de fin de mes. Esta fase suele durar una o dos semanas y depende en gran medida de la rapidez con que tus equipos de arquitectura y seguridad puedan revisar el enfoque. Explicamos con más detalle nuestra secuencia de revisión y aprobación en cómo trabajamos.

Construcción. De tres a cinco semanas para un único proceso bien acotado. Es la fase que todo el mundo imagina cuando piensa en automatización, y la más predecible. Se alarga cuando los sistemas de origen están mal documentados, cuando los límites de tasa o las ventanas de proceso por lotes obligan a una planificación incómoda, o cuando hay extracción de documentos de por medio y la calidad de la entrada varía más de lo que sugería la muestra. Construir contra un sistema con una API limpia y documentada es un trabajo distinto a construir contra una pantalla heredada sin entorno de pruebas.

Ejecución en paralelo. Aquí es donde los pilotos se ganan su credibilidad, y es la fase que más se recorta. La automatización procesa trabajo real junto al proceso manual existente, y comparas los resultados uno a uno. Las discrepancias se clasifican en tres grupos: la automatización se equivoca, el proceso manual se equivocaba, o ambos son defendibles porque la regla nunca llegó a definirse. Ese tercer grupo es habitual y útil: así es como descubres las cuestiones de política que nadie tuvo que responder mientras una persona tomaba la decisión en silencio.

La ejecución en paralelo necesita volumen suficiente y tiempo de calendario suficiente para cubrir el ciclo natural del proceso. Un proceso diario necesita semanas. Un proceso de fin de mes necesita al menos un cierre completo, y sinceramente dos. Acortar esta fase para cumplir una fecha es la manera de acabar con un sistema que falla en la semana nueve de producción ante un caso que ocurre cada trimestre.

Puesta en marcha definitiva. Corta en tiempo transcurrido, pero necesita preparación. Significa que la automatización pasa a ser el sistema de referencia para ese proceso, que la vía manual se retira o se reduce a la gestión de excepciones, y que la monitorización y la escalada ya están activas. Planificamos un plan de contingencia para los primeros ciclos —una forma documentada de volver a lo manual— y lo mantenemos hasta que la automatización ha completado limpiamente un ciclo entero sin intervención.

Qué es lo que realmente lo ralentiza

Acceso. La causa de retraso más habitual, y casi nunca es técnica. Cuentas de servicio, credenciales de lectura a un almacén de datos, un entorno que no sea producción, listas blancas de red, permiso de un proveedor para usar su API: cada una de estas cosas es un ticket en la cola de otra persona. La solución es empezar a pedir los accesos durante la fase de mapeo, antes de necesitarlos estrictamente, y nombrar una única persona de tu lado que pueda escalar cuando una solicitud se atasque. Si es probable que el acceso tarde más que la propia construcción, dilo abiertamente en el arranque y organiza el calendario en torno a ello. Nuestra página de prácticas de seguridad y acceso explica qué pedimos y por qué, lo que ayuda a acortar la revisión.

Calidad de los datos. La automatización no tolera la ambigüedad como lo hace una persona. Nombres de proveedor inconsistentes, campos de texto libre que en realidad llevan información estructurada, fechas en tres formatos distintos, registros que incumplen las restricciones que el esquema dice imponer: todo eso sale a la luz durante la construcción y la ejecución en paralelo. A veces la respuesta correcta es limpiar los datos primero, lo cual es un proyecto en sí mismo. Más a menudo, la respuesta correcta es gestionar ese desorden de forma explícita y enviar a una persona los casos genuinamente ambiguos. Los procesos con mucho documento son una disciplina aparte; es el trabajo que describimos en inteligencia documental y de datos.

Aprobaciones y número de interesados. Cada aprobador adicional añade tiempo de calendario, no esfuerzo. Un piloto que necesita el visto bueno de operaciones, finanzas, seguridad de IT, legal y una oficina de gestión de proveedores pasará más días esperando que construyendo. Organiza las aprobaciones cuanto antes, en paralelo siempre que sea posible, y arranca la revisión de seguridad antes de la construcción, no después.

Desviación de alcance. En cuanto la gente ve la automatización funcionando, llegan peticiones adyacentes. "¿Puede gestionar también las filiales internacionales?" "¿Puede escribir de vuelta en el CRM?" Cada una es razonable; cada una reinicia la ejecución en paralelo. Nosotros las registramos y las reservamos para una segunda fase. Un piloto que absorbe cada buena idea nunca llega a salir.

Disponibilidad de las personas que conocen el proceso. La persona experta en la materia suele ser la que más trabajo tiene. Su tiempo es el recurso más escaso del proyecto, y se necesita en ráfagas concentradas durante el mapeo y la ejecución en paralelo. Proteger formalmente unas horas a la semana en la agenda de esa persona vale más para el calendario que añadir más ingenieros.

Cuando la respuesta es "todavía no hay que automatizar esto"

Rechazamos trabajo o recomendamos esperar más a menudo de lo que cabría pensar. Las señales honestas son:

• El proceso está a punto de cambiar. Si en un par de trimestres llega una migración de ERP, una reescritura de políticas o una reorganización, automatizar el estado actual es construir sobre arena. Espera, o automatiza una parte que sobreviva al cambio.
• Nadie puede decir qué significa "correcto". Si dos personas con experiencia gestionan el mismo caso de forma distinta y ninguna se equivoca, el proceso necesita una decisión antes que un software. La automatización va a forzar esa decisión de todos modos: mejor tomarla de forma deliberada.
• El volumen no lo justifica. Un proceso que se ejecuta unas pocas veces al mes, tarda minutos y nunca provoca errores posteriores no es un buen primer candidato, por muy pesado que resulte. La frecuencia, el coste del error y la presión sobre los plazos importan más que lo tedioso que sea el trabajo.
• Los datos subyacentes están fundamentalmente rotos. Si los registros de origen están mal con la frecuencia suficiente como para que una persona esté prácticamente reconstruyendo la verdad cada vez, arregla el origen. Automatizar sobre datos malos industrializa los errores.
• Sin responsable. Si nadie del lado de negocio va a responsabilizarse del resultado —aprobar las reglas de excepción, dar el visto bueno a la puesta en marcha, responder al teléfono cuando algo se rompe— el piloto se estancará, por muy buena que sea la ingeniería.

Decir "todavía no" sobre un proceso suele señalar hacia uno mejor. El ejercicio de ordenar candidatos por volumen, coste del error y madurez de los datos es rápido, y merece la pena hacerlo antes de comprometer un trimestre. Nuestra calculadora de valor es una forma estructurada de trabajar esos datos con tus propias cifras.

Qué debería entregar el primer trimestre

Al final del trimestre de piloto, deberías tener todo lo siguiente. Si solo tienes una demo que funciona y nada más, el piloto no ha cumplido.

• Un proceso funcionando en producción con datos reales, con un límite de alcance definido y una lista documentada de lo que deliberadamente no gestiona.
• Una línea base medida y el rendimiento actual —tiempo de ciclo, volumen procesado, tasa de excepciones, tasa de error— registrados antes y después, con tus cifras, no con las nuestras.
• Un registro de comparación de la ejecución en paralelo que muestre dónde coincidieron la automatización y el resultado manual y cómo se resolvió cada discrepancia.
• Un manual operativo: monitorización, alertas, ruta de escalada, expectativas de guardia y el procedimiento de contingencia manual.
• Gestión de excepciones documentada: qué casos se envían a una persona, cómo se ponen en cola y cuánto tiempo esperan.
• Documentación de seguridad y auditoría: modelo de acceso, registro de eventos, retención de datos y lo que tus auditores vayan a pedir el año que viene.
• Una hoja de ruta honesta de lo que viene después, incluyendo qué procesos adyacentes ahora son más baratos de automatizar gracias al trabajo de integración ya hecho, y cuáles todavía no están listos.

Ese último punto es donde está el verdadero retorno de un piloto. El primer proceso carga con el coste de establecer accesos, entornos, despliegue, monitorización y confianza. El segundo y el tercer proceso dentro del mismo paisaje de sistemas son notablemente más rápidos porque ese trabajo de base ya está hecho. Si estás juzgando un piloto solo por el ahorro del primer proceso, estás midiendo lo que no es: estás midiendo la unidad más cara que construirás nunca.

Cómo comprimir el calendario con honestidad

Puedes acortar un piloto sin recortar la ejecución en paralelo. Elige un proceso con un sistema de referencia limpio, en lugar de uno que se extienda por seis herramientas. Empieza a pedir los accesos en el arranque. Nombra a una única persona que decida y dale autoridad. Aporta datos de muestra reales, incluidos los casos feos, en la primera semana: los datos de producción anonimizados siempre superan a los datos sintéticos, y conseguir que se aprueben pronto elimina un bloqueo clásico a mitad de proyecto. Elige un proceso donde el responsable de negocio ya tenga una idea clara de cómo es un buen resultado.

Lo que no se puede comprimir: el ciclo natural del proceso. Un cierre mensual es mensual. Una conciliación trimestral es trimestral. Planifica la ejecución en paralelo en torno al calendario, no en torno al plan de proyecto, y desconfía de quien proponga lo contrario.

Si quieres hacerte una idea de cómo es esto en distintos tipos de trabajo —procesamiento de transacciones de back office, recepción con muchos documentos o colas de atención al cliente—, consulta nuestras prácticas de automatización inteligente de procesos y operaciones de atención al cliente con IA, o el resumen general de servicios.

Si tienes un proceso en mente y quieres una respuesta directa sobre si es un buen primer candidato y cómo sería un calendario realista, habla con nosotros. Una conversación de alcance dura menos de una hora, y te diremos si la respuesta es esperar.

Preguntas que nos hacen sobre esto