El verdadero proyecto empieza después de la puesta en marcha

El día que la herramienta entra en producción todo el mundo respira aliviado, como si el proyecto hubiera terminado. Es justo al revés: ahí es donde empieza el proyecto de verdad. La implantación inicial importa menos de lo que parece; lo que decide el retorno es tener la capacidad de medir cómo funciona el proceso y mejorarlo cada mes. Un sistema lanzado y abandonado se degrada en silencio; uno medido y ajustado es el único que acaba justificando la inversión.

La puesta en marcha es un hito, no la meta

La mayoría de proyectos de automatización o IA se presupuestan, se venden y se celebran como si la entrega fuese el éxito. La puesta en marcha (el «go-live») es un hito necesario, pero es el kilómetro cero de la parte que de verdad genera valor. Hasta que el proceso no funciona con datos reales, casos reales y personas reales, no sabes lo que tienes.

Es precisamente en operación cuando aparece lo que ninguna demo enseña:

• Las excepciones que nadie había contado. El flujo cubre el 80% de los casos; el 20% restante es donde se atasca y consume el tiempo que ibas a ahorrar.
• La adopción real. El equipo usa el sistema a su manera, lo esquiva o vuelve al correo y al Excel de siempre si le resulta más cómodo.
• La deriva del dato. Un cambio en un formulario, en un proveedor o en otro sistema rompe una integración sin avisar.
• La distancia entre lo esperado y lo medido. El ahorro que se prometió en la propuesta no es el que aparece en el primer mes.

El error de mercado: tratar la implantación como un proyecto cerrado

El patrón habitual: se lanza, se disuelve el equipo, nadie queda como dueño del proceso y no hay ninguna métrica que vigile si sigue funcionando. Se da por hecho que «ya está implantado» equivale a «ya está dando resultado». No es lo mismo. «Lanzado» no es «medido y mejorado». Entre esas dos palabras está la diferencia entre un gasto y una inversión.

El coste de este error es invisible al principio y caro después: automatizaciones que llevan meses fallando en silencio, agentes que responden cada vez peor porque cambió el dato que los alimenta, y una sensación general de que «la tecnología no terminó de funcionar» cuando lo que faltó fue el ciclo de mejora detrás.

Si no puedes medir el antes y el después, no has implantado una mejora; has comprado una expectativa. El proyecto no termina en «lanzado»; termina en «medido y mejorado».

El marco Aito: la mejora continua es el producto

En la hoja de ruta de Aito, la última fase —mantenimiento, evolución y escalado— no es un servicio postventa opcional: es donde se captura el valor. La implantación deja el sistema en pie; la mejora continua es la que convierte ese sistema en retorno. Para que ese ciclo exista hacen falta cuatro cosas, y ninguna es tecnología nueva:

• Una línea base (baseline): cuánto costaba el proceso antes —tiempo, errores, coste por operación—. Sin baseline no hay ROI; hay intuición.
• Pocos KPIs que de verdad importen: plazo de resolución, tasa de error, coste por operación, tiempo liberado. Los justos para saber si mejora, no un cuadro de mando que nadie mira.
• Un dueño del proceso: una persona responsable de que el sistema siga sirviendo y de decidir los ajustes. Un proceso sin dueño no se transforma; se abandona.
• Una cadencia de revisión: una cita mensual para comparar con la línea base, mirar las excepciones y decidir el siguiente ajuste.

Cómo montar el ciclo de mejora después del arranque

1. Mide la línea base antes de lanzar. Si arrancas sin saber el punto de partida, nunca podrás demostrar la mejora. Captura el tiempo, los errores y el coste del proceso actual.
2. Elige tres o cuatro KPIs y deja que se midan solos. Que el dato salga del propio flujo, no de que alguien rellene una hoja a fin de mes; si medir cuesta esfuerzo, se deja de medir.
3. Nombra un dueño del proceso desde el día uno. Antes de la puesta en marcha, no después. Es quien recibe las incidencias y aprueba los cambios.
4. Instaura la revisión mensual. Una reunión corta: qué dice el KPI frente a la línea base, qué excepciones aparecieron, qué se ajusta este mes.
5. Trata las excepciones como trabajo previsto, no como sorpresa. Cada caso que el flujo no cubre es candidato a una regla nueva, a documentación o a dejarlo fuera a propósito.
6. Documenta cada cambio. Lo que no está documentado no escala y se pierde en cuanto cambia la persona que lo sabía.

Cuándo basta con lanzar y cuándo no

No todo necesita el mismo aparato de medición. Una automatización pequeña, estable y de bajo riesgo —un aviso interno, una copia de datos puntual— puede vivir bien con una revisión ocasional; montarle un cuadro de mando sería gastar más en vigilarla que lo que ahorra.

El ciclo de mejora continua es obligatorio cuando el proceso mueve dinero, toca a clientes, alimenta decisiones o cambia a menudo. Ahí, lanzar y mirar para otro lado es la forma más cara de automatizar. Y es coherente con lo que repetimos siempre: la IA no arregla procesos rotos, pero un proceso que nadie mide tampoco se mantiene sano solo. La regla es sencilla: cuanto más crítico es el flujo, menos se parece la puesta en marcha al final.