Las costuras son el producto

Casi todo proyecto de automatización de procesos acaba necesitando tres cosas a la vez: algo que ejecute los pasos automáticos, unas pantallas donde las personas hagan su parte, y un proceso que ordene quién interviene y cuándo.

El mercado te da las tres por separado. Un automatizador como n8n o Make para lo primero. Un constructor de interfaces —Retool, v0, lo que sea— para lo segundo. Un motor BPMN como Camunda para lo tercero. Cada uno es bueno en lo suyo.

El problema es lo que queda entre ellos.

Dónde se rompe

Cuando las tres capas viven en herramientas distintas, las uniones son tuyas. Y son la parte que se rompe.

• El flujo escribe en una base de datos que la interfaz lee, pero nadie garantiza que el esquema sea el mismo. Cambias un campo en el flujo y la pantalla deja de funcionar sin avisar.
• El proceso asigna una tarea a un rol, pero ese rol no existe en la aplicación publicada. Alguien lo crea a mano en los dos sitios y confía en no equivocarse.
• Un paso del proceso llama a un flujo por webhook. Cuando el flujo cambia de nombre, el proceso sigue apuntando al anterior y falla en producción.

Nada de esto es difícil por separado. Lo caro es que hay que mantenerlo sincronizado a mano, para siempre, y que cada persona nueva del equipo tiene que aprender tres herramientas antes de tocar nada.

La premisa de NoduxFlow

La mayoría de herramientas te da una de las tres capas y te deja las costuras. La premisa de NoduxFlow es que las costuras son el producto.

Las tres capas —flujo, aplicación y proceso— viven en el mismo lienzo y están acopladas por proyecto. Una serviceTask del proceso llama a un flujo que existe de verdad. Un flujo escribe lo que una página lee. Una userTask cae en la bandeja de un rol que existe en la aplicación publicada.

No es que sea más cómodo. Es que las tres cosas que antes sincronizabas a mano ya no pueden desincronizarse: son referencias, no cadenas de texto que coincidan por suerte.

Qué hay debajo

Conviene decir qué es real y qué no, porque en esta categoría se promete mucho:

• El motor de flujos ejecuta un grafo de nodos con conectores reales, reintentos y esperas duraderas. No es una demo de arrastrar cajas.
• El motor de procesos funciona por tokens, con tareas de usuario que tienen bandeja de verdad, temporizadores, compensación, correlación e incidencias. Es un motor BPMN, no un diagrama bonito.
• Las aplicaciones se publican a una dirección propia, con permisos por página y por flujo.
• Un meta-agente puede generar las tres capas desde una descripción en lenguaje claro, y —esto es lo que más nos importa— **se detiene a preguntar cuando la decisión es del negocio** en lugar de inventarse una respuesta.

Ese último punto es el que nos hizo apostar por la plataforma. Un generador que rellena huecos con suposiciones plausibles produce sistemas que parecen correctos hasta que alguien los usa. Uno que para y pregunta produce menos, más despacio, y utilizable.

Cuándo lo usamos y cuándo no

No construimos todo sobre NoduxFlow. Cuando un encargo es un sistema de operación con su propio modelo de datos —un ERP, un motor de pronóstico— lo construimos a medida, porque la forma del dato *es* el producto y no debe vivir dentro de la abstracción de nadie.

Lo usamos cuando el encargo es exactamente lo de arriba: procesos con pasos automáticos, personas que intervienen y pantallas que ambos comparten. Ahí reinventar el motor sería trabajo tirado, y las costuras que nos ahorramos son precisamente donde se va el presupuesto de mantenimiento de los dos años siguientes.

Es la misma razón por la que existen las dos empresas, y por la que la alianza tiene sentido: cada una hace lo que hace bien.