Cómo plantear un piloto de automatización en 4 semanas

Qué es (y qué no es) un piloto de automatización

Un piloto es una implantación real, limitada y medible de una automatización sobre un único proceso. No es una demo ni una prueba de concepto teórica: al terminar, el proceso funciona con datos reales de la empresa y alguien del equipo lo usa en su día a día.

La limitación es deliberada. En cuatro semanas no se reorganiza una empresa: se resuelve una pieza concreta, se mide qué ha cambiado y se decide con datos si conviene ampliarlo al resto de áreas.

• —Sí: un proceso, un equipo, un criterio de éxito, datos reales.
• —Sí: documentación de lo construido y de cómo mantenerlo.
• —No: sustituir un ERP, migrar todo el sistema o automatizar cinco departamentos a la vez.
• —No: prometer un porcentaje de ahorro antes de medir la situación de partida.

Cómo elegir el proceso adecuado

El principal motivo de fracaso de un piloto es elegir mal el proceso. Un buen candidato es repetitivo, frecuente, lo bastante estable como para describirse con reglas claras y lo bastante molesto como para que alguien note su desaparición.

• —Se repite al menos semanalmente y consume horas identificables.
• —Tiene entrada y salida claras (un correo, un fichero, un formulario, un registro).
• —Las excepciones son conocidas y no son la mayoría de los casos.
• —Los datos necesarios son accesibles sin proyectos previos de infraestructura.
• —Hay una persona responsable disponible durante las cuatro semanas.

Definir el alcance y los criterios de éxito

Antes de escribir una línea de código hay que fijar por escrito qué entra en el piloto, qué queda fuera y cómo se sabrá si ha funcionado. Los criterios deben ser medibles con información que la empresa ya tenga o que pueda recogerse durante el diagnóstico inicial.

Medir la situación de partida es tan importante como medir el resultado. Sin línea base no hay comparación posible y cualquier cifra final es una opinión.

• —Tiempo dedicado al proceso antes y después, en horas/semana.
• —Volumen tratado sin intervención manual respecto del total.
• —Número de errores o correcciones posteriores detectadas.
• —Tiempo de respuesta al cliente o al departamento que recibe la salida.

Calendario semana a semana

El calendario siguiente es el que aplicamos por defecto. Puede ajustarse, pero la lógica se mantiene: primero entender, después construir, después probar con realidad y decidir.

Roles y dedicación esperada

Un piloto no funciona si la empresa participa solo en la reunión inicial. La dedicación total del cliente suele ser de entre 9 y 14 horas repartidas en cuatro semanas, concentradas en la primera y la última.

• —Responsable del proceso: conoce las excepciones reales y valida el resultado.
• —Responsable de decisión: aprueba alcance y presupuesto sin esperas largas.
• —Contacto técnico o proveedor externo: facilita accesos a sistemas, correo o base de datos.
• —AurIA42: análisis, desarrollo, integración, documentación y formación.

Riesgos que hacen fracasar un piloto

Casi siempre el problema no es técnico. Estos son los riesgos que conviene vigilar desde el primer día, con su medida preventiva.

Coste orientativo y qué incluye

El rango orientativo de un piloto funcional de cuatro semanas es de 4.000 a 12.000 €. La horquilla depende del número de sistemas a integrar, de si hace falta interfaz propia, del volumen de excepciones y de los requisitos de seguridad o trazabilidad.

El diagnóstico inicial de dos horas es gratuito y sirve precisamente para situar el proyecto dentro de ese rango antes de comprometer nada. Las automatizaciones puntuales más sencillas pueden plantearse desde 600 €, y el mantenimiento posterior desde 79 €/mes.

• —Incluye: análisis, desarrollo, integraciones, pruebas con datos reales, documentación y formación.
• —No incluye: licencias de terceros, consumo de APIs o modelos de IA, ni hardware.
• —No incluye: reorganización de procesos ajenos al alcance acordado.

Qué pasa después del piloto

Al final de la cuarta semana hay tres desenlaces legítimos: ampliar, mantener tal cual o detener. Detener no es un fracaso si el piloto ha demostrado con datos que ese proceso no compensa automatizarlo; es justo el valor de hacerlo pequeño y corto.

Si se amplía, el siguiente paso suele ser extender la automatización a procesos vecinos o a más volumen, con un mantenimiento que cubra cambios de sistemas, incidencias y evolución.