Cada propuesta de automatización de flujos de trabajo de código simple comienza con lo mismo: la velocidad. Construcciones más rápidas, implementaciones más rápidas, más rapidez en todo.
Es verdad que la velocidad ayuda, pero no es lo que decide si un flujo de trabajo sobrevive a su primer año. La responsabilidad, es decir, quién es responsable de la lógica que contiene y qué sucede cuando esa persona deja el equipo, asciende de puesto o simplemente se va de vacaciones durante dos semanas. Un flujo de trabajo que se ejecuta rápido hoy y solo vive en la mente de una persona no está automatizado. Es solo rápido, no duradero, lo cual es un problema.
Esa brecha entre la velocidad y la durabilidad rara vez aparece en la demostración de un producto, de manera comprensible, porque no es precisamente un punto de venta para ninguna herramienta. En realidad, el problema no se hace evidente hasta unos ocho meses después, cuando la persona que creó el flujo de trabajo está fuera de la oficina o ya no forma parte del equipo, y el informe que alimenta sigue teniendo que entregarse el lunes por la mañana. En ese momento, nadie celebra lo rápido que se creó originalmente.
Este artículo analiza cinco aspectos en los que la velocidad y la durabilidad entran en conflicto, comenzando por el propio discurso sobre la velocidad.
Por qué la velocidad no es la única razón por la que el código simple importa
La velocidad es, sin duda, un beneficio real del código simple, pero si la persigues como objetivo, lo único que obtienes es una hoja de cálculo más rápida, no una pieza duradera de automatización de flujos de trabajo.
Las organizaciones están apostando decididamente por la velocidad, y las cifras del mercado lo respaldan. Gartner proyecta que el mercado de tecnologías de desarrollo de código simple alcanzará los USD 58.2 mil millones para 2029, con un crecimiento anual del 14.1 % a medida que la IA agéntica y el desarrollo ciudadano impulsan una mayor adopción. Pero eso no dice nada sobre si lo que construyen se sostiene.
Y ahí es donde la diferencia entre adopción y durabilidad realmente importa. Un flujo de trabajo que se puede crear rápidamente y transferir con facilidad adquiere más valor cada mes, ya que alguien que no sea la persona que lo creó originalmente puede hacerse cargo de él y seguir mejorándolo. En cambio, un flujo de trabajo que simplemente se puede crear rápido se vuelve más riesgoso cada mes, porque nadie más que su creador conoce realmente lo que sucede en su interior. Confundir ambos es donde la mayor parte del marketing de código simple se equivoca.
Por ejemplo, un analista prepara algo en una tarde. Funciona y, poco a poco, se convierte en un componente esencial. Seis meses después, nadie más puede modificarlo de forma segura. Es un patrón que se repite de la misma manera en todos los equipos de analítica, y probablemente lo hayas visto suceder de primera mano.
Ninguno de esos aspectos es un problema exclusivo del código simple, pero la velocidad del código simple facilita llegar más rápido a esa situación, con menos supervisión en el camino, de lo que jamás ocurriría con un proceso desarrollado manualmente.
Imagina dos flujos de trabajo creados durante la misma semana, ambos para resolver el mismo problema. El primero se crea con rapidez y se mantiene exactamente igual de rápido que el día en que se implementó, sin documentación y sin un responsable asignado más allá de quien lo creó; es el equivalente, en el mundo de los flujos de trabajo, a una puerta sin señalización que nadie quiere abrir. El segundo tarda un poco más en finalizar porque está construido con una estructura documentada y un punto de entrega claro.
Un año después, el primer flujo de trabajo permanece intacto, porque actualizarlo se siente riesgoso. El segundo flujo de trabajo ha sido modificado cuatro o cinco veces por distintas personas, porque actualizarlo da confianza.
La velocidad de creación de los dos flujos de trabajo fue casi idéntica, pero el valor que aportó cada uno durante 12 meses no lo fue.
Sin código o con código nunca fue una opción permanente
Una corrección manual se convierte en un paso programado. Un paso programado se convierte en un componente compartido y reutilizable al que recurren otros flujos de trabajo. Esa progresión es el verdadero ciclo de vida, aunque la mayoría del contenido de los proveedores presenta la decisión entre no usar código y permitir código como una elección única que se toma al momento de la compra.
Los compradores eligen el código simple, en parte, para evitar quedar atrapados en una única forma rígida de crear soluciones, pero tomar esa decisión de manera definitiva durante la adquisición puede resultar contraproducente en ambos sentidos. Si se lleva demasiado lejos el enfoque sin código, el primer caso excepcional que la interfaz no puede manejar se resuelve con una solución alternativa añadida fuera de la plataforma. Si se lleva demasiado lejos el enfoque basado en código, el equipo pasa meses desarrollando algo que un lienzo gobernado habría resuelto de forma nativa y, después, termina asumiendo todo el mantenimiento del que el código simple se suponía que debía liberar.
La mejor pregunta: ¿puede un solo flujo de trabajo combinar un paso de arrastrar y soltar con una línea de SQL o Python, sin reconstruirlo cada vez que cambian los requisitos? Esa capacidad importa más que si se etiqueta como “sin código” o “compatible con código”, porque las necesidades de un flujo de trabajo rara vez permanecen fijas por mucho tiempo. Una unión de arrastrar y soltar que funciona correctamente al momento de la implementación puede necesitar un paso personalizado con regex seis meses después, cuando un sistema de origen comienza a enviar un campo con un formato diferente al que tenía antes.
Si la plataforma solo permite arrastrar y soltar, ese paso con regex se crea en otro lugar, mediante un script que solo conoce quien lo escribió. El flujo de trabajo todavía “funciona”, pero la lógica que realmente importa se ha deslizado silenciosamente fuera del sistema destinado a gobernarla.
¿Hay algún flujo de trabajo en tu equipo que esté estancado en este momento, específicamente porque esa decisión entre una opción u otra se tomó demasiado pronto y nadie la ha vuelto a revisar desde entonces?
Restringir el desarrollo ciudadano inevitablemente conduce a la TI en la sombra
Este es el problema al que probablemente te enfrentes cuando restrinjas el desarrollo ciudadano para mantener las cosas bajo control, por lo general, obtendrás más TI en la sombra, no menos. Esta paradoja ocurre porque la demanda de automatización no desaparece simplemente cuando se bloquea el acceso; solo se traslada a la herramienta que sea más fácil de usar sin pedir permiso, que rara vez es la que alguien habría elegido deliberadamente.
La investigación de Forrester sobre el desarrollo ciudadano reveló que al menos dos tercios de las organizaciones ya tienen una estrategia formal de desarrollador ciudadano o planean crear una en los próximos 12 meses. Forrester trazó tres formas de escalarlo de forma responsable:
- Privateer: un equipo pequeño y autónomo integrado en una unidad de negocio.
- Democracia: un modelo ampliamente abierto, disponible para cualquiera, con límites de control definidos sobre lo que pueden crear.
- Federación: un híbrido que combina los dos, con estándares centrales y construcción distribuida.
La mejor manera de administrar el desarrollo ciudadano es construir la estructura de gobernanza antes de que la demanda la supere, en lugar de luchar por ponerse al día después del hecho.
Pero antes de que puedas construir esa estructura, tienes que ponerte de acuerdo sobre quién la construirá realmente. La investigación del MIT sobre el desarrollo ciudadano distingue tres roles independientes:
- Los desarrolladores ciudadanos crean aplicaciones.
- Los automatizadores ciudadanos configuran automatizaciones entre sistemas que no se comunican de forma nativa entre sí.
- Los ciudadanos científicos de datos construyen los modelos y paneles de control.
Cada uno de estos roles necesita un tipo diferente de supervisión, y agruparlos a todos bajo el “desarrollo ciudadano” solo oculta esa distinción.
El objetivo no es que haya menos personas que creen flujos de trabajo. Se trata de que los creen dentro de un sistema que mantenga el trabajo visible y auditable. La analítica de autoservicio es un gran ejemplo de esa misma idea llevada a la práctica: cuando TI dejó de verla como una amenaza y empezó a considerarla como algo para lo cual diseñar la usabilidad, la adopción despegó a partir de ahí.
Sinceramente, la pregunta de “¿Debería permitirse que los analistas automaticen su propio trabajo?” quedó respondida hace mucho tiempo, la primera vez que alguien escribió una macro simplemente para ahorrarse una tarde de trabajo. Así que esa pregunta ya no es realmente la conversación que TI debería estar teniendo.
La verdadera conversación gira en torno a dónde establecer los límites de control: qué flujos de trabajo necesitan un responsable documentado y un paso de revisión antes de afectar una cifra financiera, y cuáles tienen un nivel de riesgo lo suficientemente bajo como para que un usuario pueda automatizarlos y ponerlos en producción sin esperar a que se atienda un ticket. Si evitas esa conversación, no terminarás con menos desarrollo ciudadano. Terminarás teniendo la misma cantidad; simplemente ya no la puedes ver.
Una lista de verificación para cualquier conversación con proveedores de código simple
Estas cuatro preguntas son útiles para cualquier conversación con un proveedor, independientemente de la plataforma que estés evaluando:
- ¿La lógica del flujo de trabajo puede avanzar a lo largo del espectro de sin código a compatible con código sin tener que reconstruirlo?
- ¿El desarrollo ciudadano dentro de la plataforma está sujeto a controles de gobernanza y es visible, o simplemente está permitido y no se supervisa?
- ¿Los flujos de trabajo se crean como componentes reutilizables y documentados, o como scripts aislados que nadie más puede abrir de forma segura?
- ¿La plataforma admite la iteración continua a medida que cambian los requisitos, o solo la implementación inicial?
El código simple se desmorona cuando nada se reutiliza
Lo que limita una implementación de código simple se reduce, en última instancia, a la reutilización: ¿el flujo de trabajo se creó para que alguien pudiera retomarlo, o para olvidarlo en cuanto funciona?
Como ejemplo, así es como suele manifestarse esa cuestión de reutilización en un equipo de adquisiciones que concilia excepciones de órdenes de compra con facturas de proveedores. Por lo general, alguien del equipo termina creando una macro personal de Excel que señala las discrepancias según el monto en dólares, y suele funcionar lo suficientemente bien como para que nadie la cuestione durante años, lo que, en el continuo espacio-tiempo de las macros de oficina, equivale prácticamente a una eternidad.
Ese tipo de macro suele detectar correctamente la mayoría de los tipos de excepciones, digamos siete de nueve, pero pasa por alto cualquier caso excepcional que nadie haya previsto al momento de crearla, como las discrepancias en el formato de los números de las órdenes de compra entre el sistema ERP y el PDF de la factura, una peculiaridad específica de la forma en que ciertos proveedores presentan su documentación. Brechas como esa son exactamente el tipo de cosas que activan un hallazgo en una auditoría de SOX.
Si alguna vez heredaste la hoja de cálculo de otra persona, este escenario te resultará familiar. El analista que normalmente supervisa la hoja de cálculo se ausenta de la oficina, y el retraso en la gestión de excepciones crece silenciosamente durante un par de semanas antes de que alguien se dé cuenta, porque nadie más del equipo sabía que existía la macro, y mucho menos cómo abrirla.
Esa falla suele ser lo que finalmente impulsa a un equipo a reconstruir la lógica de coincidencia de manera adecuada, como un componente de flujo de trabajo documentado y reutilizable con su propia programación y activador, incluido cualquier caso límite que se le haya pasado por alto a la macro original.
Nada de eso se trata de construir más rápido. Se trata de crear algo que no dependa de que una sola persona recuerde que existe, algo que es igual de importante para los stakeholders de finanzas o auditoría que para el equipo.
Aquí tienes un ejemplo de un componente reutilizable, en este caso una macro, que se creó en Alteryx:
| Antes: macro personal | Después: componente reutilizable | |
|---|---|---|
| Propietario | Un analista, no documentado | Compartido, documentado, abierto al equipo |
| Cobertura de excepciones | 7 de 9 tipos | Los 9, incluida la discrepancia en el número de la orden de compra |
| Tiempo para conciliar | Pase manual de varios días | Lista de excepciones del mismo día |
| Reutilización entre categorías | Ninguna; se reconstruye desde cero cada vez | Se reutiliza en otras dos categorías de gasto, sin necesidad de reconstruir |
Si esto se parece a la situación de tu equipo, vale la pena poner a prueba el estado actual de tu propio flujo de trabajo antes de elegir un proveedor. Pasar de hojas de cálculo a flujos de trabajo explica cómo se lleva a la práctica ese cambio de hojas de cálculo con un único responsable a flujos de trabajo reutilizables y documentados.
La automatización no termina en la implementación
Un flujo de trabajo que se automatiza una sola vez y nunca se vuelve a revisar se deteriora de la misma manera que una hoja de cálculo sin mantenimiento, solo que de forma menos visible. El problema aparece más adelante, por lo general como una observación de auditoría o como una cifra que, sin que nadie lo note, dejó de reflejar la realidad.
La idea de componentes reutilizables del ejemplo de compras da frutos de nuevo aquí mismo. Actualiza el componente de coincidencia compartido una sola vez, digamos que un proveedor cambia o un umbral se modifica, y cada flujo de trabajo creado a partir de él se actualiza de manera automática. Nadie tiene que buscar una docena de copias y corregirlas una por una, porque, para empezar, solo hay una copia.
Los asistentes de IA en lenguaje natural también están apareciendo aquí, y vale la pena tener claro qué hacen realmente. Ask Alteryx es un buen ejemplo. Ayuda al equipo a consultar o actualizar un flujo de trabajo existente y sujeto a controles de gobernanza mediante lenguaje natural, pero no sustituye la estructura con controles de gobernanza subyacente. Piensa en ello como el asistente, no como el arquitecto: son dos funciones diferentes que conviene distinguir al evaluar cualquier herramienta.
La lista de verificación, probada con Alteryx One
Así es como Alteryx se compara con la evaluación de proveedores que mencionamos anteriormente.
| Pregunta | Cómo cumple Alteryx One |
|---|---|
| ¿La lógica puede avanzar a lo largo del espectro de sin código a compatible con código sin necesidad de una reconstrucción? | Los flujos de trabajo combinan pasos de arrastrar y soltar con Python y SQL nativos en el mismo lienzo, por lo que un equipo no queda atrapado en un solo extremo del espectro al momento de la adquisición. |
| ¿El desarrollo ciudadano está sujeto a controles de gobernanza y es visible, no solo permitido? | El acceso basado en roles y el historial de versiones le dan a TI la visibilidad para permitir que los analistas construyan sin perder el rastro de lo que se ha construido. |
| ¿Los flujos de trabajo son componentes reutilizables o scripts puntuales? | Las macros y las aplicaciones analíticas se crean una vez como componentes documentados y compartibles, el mismo patrón que convirtió el proceso de conciliación del equipo de compras en infraestructura compartida. |
| ¿La plataforma admite iteración continua, no solo la implementación inicial? | Copilot ayuda a los equipos a consultar y actualizar flujos de trabajo existentes en lenguaje natural, sobre la estructura gobernada ya existente. |
Primeros pasos con la automatización de flujos de trabajo de código simple
Si todavía estás evaluando los detalles, la automatización de flujos de trabajo recurrentes de los analistas y un marco formal de evaluación profundizan en algunos aspectos de este argumento que este artículo no puede abordar por completo.
Pero no necesitas leer todo eso, ni adoptar una plataforma entera, antes de comenzar. Elige un informe recurrente o un proceso de conciliación manual, de esos que probablemente aún residen en la hoja de cálculo personal de una persona, y vuelve a crear solo esa parte como un componente gobernado y reutilizable. Ve cómo resulta antes de decidir si vale la pena trasladar el resto del catálogo.
La conclusión es que la automatización de flujos de trabajo de código simple demuestra su valor en la propiedad y la durabilidad, no solo en la rapidez con la que se realiza la primera creación. Alteryx One se creó exactamente con eso en mente, y una prueba gratuita es la forma más rápida de descubrir si se adapta a tu propio flujo de trabajo.