¿Cuándo se le quedan cortos Zapier, Make o n8n?

Tres momentos, y ninguno es el que la gente espera. Cuando un flujo tiene que aplicar un criterio que solo tiene su negocio. Cuando un flujo puede fallar sin que nadie se entere. Cuando los flujos empiezan a depender unos de otros. Hasta que se cumpla alguno de los tres, estas herramientas son la respuesta correcta, y se lo diremos y nos iremos a casa.

Eso último vale la pena decirlo primero, porque el consejo que se suele recibir sobre esta cuestión lo vende alguien que tiene algo más grande que vender. La mayoría de los negocios que usan un puñado de flujos deberían seguir usándolos.

¿Para qué sirven de verdad estas herramientas?

Para mover información entre aplicaciones que nunca se diseñaron para comunicarse entre sí. Es un problema real, y lo resuelven bien. Un disparador, unos pasos, un destino: un pedido nuevo crea una fila, un adjunto se archiva solo, un formulario completa una hoja, alguien recibe un aviso. Cualquiera en su oficina que se maneje bien con una hoja de cálculo puede crear uno, sin un desarrollador, sin un proyecto y sin pedir permiso.

Además, hacen algo que nadie les reconoce. Cada flujo de su cuenta lo creó una persona que sentía un costo concreto todos los días y describió exactamente qué debería pasar en su lugar. Esa descripción de lo que necesita su negocio es mejor que la que cualquier consultor obtendría preguntando, y volveremos a ella al final.

¿Cuándo necesita un flujo saber algo que solo sabe usted?

Este es el primer límite, y llega sin hacer ruido.

“Pasar este pedido al sistema de facturación” es un problema de transporte. Estas herramientas se hicieron para eso. “Pasar este pedido al sistema de facturación salvo que el cliente tenga el crédito bloqueado y, si falta el artículo, tomarlo del almacén que pueda enviarlo antes” es un problema de criterio. Necesita sus reglas de crédito, sus niveles de inventario y su geografía de despacho, y nada de eso está en el pedido.

Se puede forzar, y la gente lo hace. Una tabla de búsqueda en una hoja. Tres ramas de filtros. Un segundo flujo que se ejecuta antes y escribe una marca que el primero lee. Funciona, durante un tiempo. Lo que ha pasado es que una parte de la lógica de su negocio vive ahora en un lienzo donde nadie puede leerla como una frase, nadie puede probarla antes de cambiarla y nadie puede explicar por qué decidió lo que decidió el martes pasado.

Una comprobación que puede hacer hoy: tome su flujo más importante y pídale a alguien que no lo creó que explique en voz alta qué hace y por qué. Si no puede, la regla no está escrita en ninguna parte de su negocio. Solo existe como cajas y flechas, en una cuenta, en la cabeza de una persona.

¿Cómo sabría usted que un flujo se detuvo?

El segundo límite, y el caro.

Estas herramientas fallan en silencio, y eso no es un defecto suyo. Una ejecución da error, el error queda registrado y quizá llega un correo al buzón de quien lo creó. El negocio sigue sin saberlo. El pedido que nunca llegó a facturación no se descubre como un error: se descubre como una factura que falta, o como un cliente que pregunta dónde está su mercancía.

Así que hágase dos preguntas sobre el flujo del que más depende. ¿Quién se daría cuenta si se detuviera esta noche? ¿Y cómo se daría cuenta? Si la respuesta honesta a la segunda es “llamaría el cliente”, usted no tiene una automatización. Tiene una dependencia no declarada.

Lo que arregla esto no es una herramienta más lista. Es un hábito, y es ingeniería corriente: un fallo llega el mismo día a una persona concreta, con lo que falló, lo que llevaba y lo que hay que hacer, y lo que falló queda en una cola que alguien puede reintentar una vez corregida la causa. Nada vistoso, y toda la diferencia entre una automatización sobre la que se puede llevar un negocio y una de la que uno se entera por un cliente.

¿Cuándo se convierte en el problema el flujo número veinte?

El tercer límite es la dependencia, y es el que decide la mayoría de los casos.

Un flujo es una herramienta. Veinte flujos son un sistema que nadie diseñó. El diecinueve escribe una fila que lee el veinte. Alguien cambia el nombre de una columna en una hoja y algo se detiene tres flujos más allá, por motivos que se tarda un día en encontrar. No hay una lista de qué funciona dónde, ni una forma de probar primero un cambio en un lugar seguro, ni un registro de por qué se construyó todo así. A menudo, la persona que creó los más importantes ya cambió de trabajo.

Fíjese en lo que no está pasando. Nada está roto. Cada flujo sigue haciendo exactamente aquello para lo que se creó. Lo que se perdió es la capacidad de cualquiera para cambiar algo con confianza, y eso es lo que de verdad significa que una herramienta se le quede corta. No que la herramienta se haya vuelto demasiado pequeña, sino que su dependencia de ella avanzó más rápido que su comprensión de ella.

¿Y lo que cuesta?

Conviene decirlo con claridad, porque suele ser lo que por fin hace que un dueño se haga la pregunta, aunque rara vez es la mejor razón para actuar.

Estas herramientas cobran según cuánto hacen. Cada ejecución, cada paso, contados y facturados. Eso significa que la factura crece exactamente en proporción a lo bien que funciona la automatización, y el mes en que por fin consigue que todo el escritorio de pedidos pase por ella es el mes en que la suscripción empieza a doler. Es un incentivo extraño para tenerlo debajo de algo de lo que depende su negocio, sea cual sea la cifra.

Entonces, ¿se tira todo?

No, y es la misma respuesta que para reemplazar o conectar el software que usa: la pregunta nunca es la herramienta, sino qué flujos fallan en qué prueba.

Tome la lista de lo que ha creado. Para cada flujo, tres preguntas. ¿Aplica un criterio que solo tiene su negocio? ¿Alguien se enteraría si se detuviera? ¿Depende de él alguna otra cosa? Los flujos que no fallan en ninguna de las tres se quedan exactamente donde están, y serán la mayoría. Los que fallan en una o más son su especificación: esos son los que deberían pasar a ser suyos, vigilados, probados y documentados en algo que una persona pueda leer.

A la mayoría de los negocios a los que estas herramientas se les quedaron cortas de verdad, se les quedaron cortas en tres o cuatro puntos, no en todas partes. Quien le diga lo contrario tiene una plataforma que venderle.

¿Qué debería conservar de lo que creó?

Más de lo que cree, y es la parte que más a menudo se tira.

Cada flujo de esa cuenta es una demanda documentada. Una persona real, que carga con un costo real, describe con precisión lo que debería pasar en su lugar, y le importa lo suficiente como para construirlo. Eso vale más que la misma respuesta dada en una reunión, porque se construyó en lugar de pedirse. Nadie crea un flujo para un problema que no tiene.

Así que, cuando el trabajo se traslada, los flujos van con él como evidencia y no como basura: qué se automatizó, quién lo hizo, en qué orden de dolor. Es el documento de requisitos más honesto que tiene su negocio, y no le costó nada producirlo.

El fabricante de muebles muestra cómo se ve el otro lado. Cada etapa de un pedido confirmada en un teléfono por quien la hace, cada pedido en el tablero del dueño, nada tecleado de nuevo entre la cotización y el despacho. Una herramienta sin código podría intentar cualquiera de esas cosas. Ninguna se le podría confiar.

En resumen: no cuando alguien le dice que la herramienta es poco profesional, ni cuando llega a cierto tamaño. Cuando un flujo aplica un criterio que nadie puede leer, cuando un fallo le llega a través de un cliente y cuando nadie se atreve a tocar el flujo número diecinueve. Son tres preguntas sobre sistemas que ya tiene, y las respuestas señalan los pocos que vale la pena trasladar. Todo lo demás se queda donde está, que es como definimos desde el principio el alcance de un trabajo de IA y automatización.