No-code y automatización

Qué cubre esta categoría

Crear cosas y automatizar el trabajo sin escribir código: creadores visuales de aplicaciones, automatización de flujos entre productos, creadores de herramientas internas y las bibliotecas de conectores que hacen posible todo ello.

Aquí se venden dos promesas distintas. Una es sustituir una hoja de cálculo por algo con permisos y un formulario en condiciones. La otra es eliminar el paso manual en el que alguien copia datos entre dos sistemas cada mañana.

La integración y las pruebas orientadas a desarrolladores están en API e integraciones. Los asistentes basados en modelos pertenecen a herramientas de IA.

La automatización y cómo funciona el recuento

La automatización con conectores es la compra más común y la más fácil de valorar mal.

Los productos cuentan el uso como tareas, ejecuciones, pasos u operaciones, y las diferencias no son cosméticas. Un flujo de ocho pasos que se activa cada quince minutos da una cifra muy distinta con recuento por pasos que con recuento por ejecuciones, y el contador que parece generoso en la página de precios puede ser el caro.

Antes de comparar planes, conviene anotar cuántos flujos se esperan, con qué frecuencia se activa cada uno, cuántos pasos contiene y cómo es un mes de mucha actividad. Después, comprobar si se cobran los intentos fallidos, las ejecuciones filtradas, las comprobaciones periódicas y las ejecuciones de prueba. En varios productos, sí.

Los intervalos de consulta importan junto con el precio. Un producto que comprueba si hay registros nuevos cada quince minutos no puede sostener nada que deba sentirse inmediato, y los activadores instantáneos suelen reservarse a niveles superiores.

La fiabilidad es la parte que se omite

Un flujo que se ejecuta en silencio durante seis meses es invisible hasta la mañana en que se detiene.

• Reintentos, con una espera razonable y no un segundo fallo inmediato.
• Visibilidad de errores, que llegue a una persona y no a un registro que nadie abre.
• Repetición, para poder repetir una ejecución cuando se ha corregido la causa.
• Idempotencia, para que una ejecución repetida no cree dos registros.
• Historial, lo bastante largo como para investigar algo que se nota una semana después.

Hay que preguntar cómo es en la práctica una ejecución fallida. Los productos difieren mucho aquí, y la diferencia solo se hace visible bajo presión.

Crear aplicaciones sin código

Los creadores de herramientas internas sustituyen a las hojas de cálculo, los documentos compartidos, los formularios en papel y la petición que llega por mensaje de chat.

Se juzgan primero por los datos. Dónde viven, si pueden conectarse a una base de datos que ya se gestiona y qué pasa cuando una tabla llega a cien mil filas. Muchos productos son excelentes con mil y inutilizables con cien mil.

Después, los permisos, porque suele ser la razón por la que había que dejar la hoja de cálculo. El acceso por fila, los roles, los pasos de aprobación y un registro de auditoría deciden si el resultado es una mejora o una versión más bonita del mismo problema.

Gobernanza, o la dispersión que sigue al éxito

Estas plataformas triunfan dejando que cualquiera cree, y así es también como fracasan.

En un año, una organización puede tener doscientos flujos, de los cuales cuarenta importan, doce están rotos y varios fueron creados por personas que ya se han ido. Nadie sabe cuál es cuál.

Conviene fijar convenciones pronto: un patrón de nombres, un responsable anotado para cada flujo y una revisión periódica que elimine lo que nada usa. Hay que preguntar si el producto admite entornos, versiones y mover una creación de una cuenta personal a una compartida. Esa última transición es donde empiezan la mayoría de los misterios heredados.

La seguridad merece la misma atención. Una plataforma de automatización guarda credenciales de todos los sistemas que toca, lo que la hace más valiosa para un atacante que la mayoría de las herramientas que conecta. Conviene buscar conexiones con alcance limitado, almacenamiento compartido de credenciales y un registro de auditoría que muestre quién cambió qué, junto con los hábitos de precios descritos en lo que ocultan las páginas de precios.

Decidir qué no debe automatizarse

El valor de esta categoría es evidente, y la disciplina que exige consiste en decidir dónde parar.

Se automatiza el trabajo repetitivo, bien entendido y estable. Un proceso que cambia cada pocas semanas dedicará más tiempo a reconstruirse del que llegó a ahorrar.

Se deja en paz todo aquello en que un error es caro y silencioso. Los movimientos de dinero, las comunicaciones masivas con clientes y los cambios en registros de los que dependen otros sistemas merecen un paso humano o una aprobación estricta, ya que un error de automatización se repite a velocidad de máquina.

Hay que tener cuidado con los procesos que nadie ha puesto por escrito. Automatizarlos congela la versión que resulte estar vigente, incluidas las partes que existen por un apaño de hace dos años.

Donde la lógica es realmente compleja, un script corto mantenido por alguien que sepa leerlo suele superar a un flujo visual de cuarenta pasos que solo entiende su autor.