Introducción

En las entregas 1 y 2 confirmamos que el EUC y Kami Excel salvaron a los equipos en el corto plazo, pero dejaron legados negativos para las organizaciones. En este artículo desplazamos la mirada al presente para analizar la luz y la sombra de las plataformas modernas de desarrollo ciudadano, como el RPA y el no-code/low-code.

Son al mismo tiempo una repetición de Kami Excel y un riesgo mayor por su escala y el grado de dependencia que generan. Entender su naturaleza es imprescindible antes de sumar el impacto de la IA generativa en la siguiente entrega.

Serie completa

Luz: por qué fueron aceptadas

Rapidez inmediata

Sin escribir código, basta con operaciones en la interfaz gráfica para completar pequeñas automatizaciones o aplicaciones. Reemplazar tareas diarias de copia o procesos rutinarios en cuestión de días tiene un valor enorme para quienes están en el terreno.

Poder de convicción de la “visualización”

Como las plataformas permiten plasmar flujos y pantallas en diagramas que cualquiera puede ver, son comprensibles incluso para quienes no tienen conocimientos especializados. Para la dirección es tranquilizador ver un “resultado que se mueve”, algo que a menudo resulta decisivo para impulsar la implantación.

El primer paso ciudadano

Siempre que el uso sea limitado —formularios de entrada o flujos de trabajo sencillos— incluso personas sin formación en ingeniería pueden construirlos. En este nivel sí se siente que “cualquiera puede hacerlo” y la organización ensancha la base de participantes en el desarrollo ciudadano.

Sombra (1): la “pared profesional” que emerge en la práctica

En la superficie parece que “cualquiera puede manejarlo”, pero cuando se quiere usar en serio aparece la necesidad de pensar como si se estuviera programando y de adoptar una visión de diseño propia de los ingenieros de sistemas.

  • La inevitabilidad de las estructuras de control
    Para separar los procesos según la condición del cliente hacen falta bifurcaciones (If/Else). Para tratar cientos de registros es imprescindible iterar (ForEach). Para anticipar retardos o errores en sistemas externos hay que preparar manejos de excepciones (Try/Catch). La interfaz permite arrastrar bloques, pero en esencia sigue siendo programación.

  • Comprender las estructuras de datos
    Desplegar JSON o arreglos, mapear jerarquías y unificar formatos de fechas y números es indispensable para integrar procesos. No basta con sustituir una tabla; sin entender la estructura de datos todo colapsa.

  • La complejidad de la integración entre sistemas
    Gestionar la caducidad de credenciales API, mantener la consistencia entre múltiples sistemas o esquivar límites de peticiones son problemas idénticos a los de la ingeniería de software tradicional. La GUI solo los oculta; la dificultad real es incluso mayor.

  • Requisitos de operación y calidad
    Sin un diseño que contemple monitorización, recopilación de logs, entornos diferenciados para pruebas y producción o planes de reversión de despliegues, el caos llega enseguida. Como no se gobierna con código, la observabilidad suele degradarse.

Ante esta pared es difícil que una persona desarrolladora ciudadana construya y mantenga por sí sola un sistema apto para operaciones reales. Inevitablemente termina dependiendo de especialistas, sin que el problema de capacidad del equipo experto quede resuelto.

Sombra (2): vendor lock-in y la dificultad de migrar

Kami Excel aún tenía un resquicio de salvación: vivía en un archivo. Los datos tabulares podían exportarse como CSV, y aunque las funciones y macros estuvieran ligadas a Excel existían hojas de cálculo compatibles y siempre era posible leer el código.

En cambio, los artefactos del RPA y del no-code/low-code quedan encerrados casi por completo en interfaces y archivos de configuración específicos de la plataforma.

  • Migrar a un producto de otro proveedor equivale, en la práctica, a “volver a construir desde cero”.
  • El cierre de un SaaS o un cambio de especificaciones escapa al control de la organización y puede dejar sin valor los activos acumulados de la noche a la mañana.
  • Si se construye sobre un PaaS, se queda atado al ecosistema de esa nube y llevarlo a otro entorno se vuelve extremadamente difícil.
  • Definir la lógica mediante UI en lugar de código dificulta buscar o localizar el punto donde reside un problema.
  • Según el diseño de la herramienta, muchas veces hay que hacer doble clic en los componentes para entender qué ocurre dentro, lo cual degrada la legibilidad.

Comparado incluso con Kami Excel, cuya unidad era la hoja de cálculo, el grado de dependencia y de riesgo de deuda es mucho mayor.

Sombra (3): el “sesgo de visualización” que confunde a la dirección

Para la gente técnica es evidente que tarde o temprano aparecerá la “pared profesional”. Pero cuando se muestra a la dirección un flujo dibujado en GUI o una pantalla interactiva, es fácil que piensen “esto cualquiera lo usa”.

¿Por qué? Porque los sistemas suelen ser una caja negra para la alta dirección. Cuando ven procesos conectados con flechas y formularios visibles, sienten que comprenden la complejidad interna.

La realidad es que detrás siguen existiendo la misma lógica de control y los mismos manejos de errores que en un programa. Para que funcione en entornos reales se necesita conocimiento de ingeniería.

La brecha entre la tranquilidad de la dirección y las preocupaciones técnicas alimenta la adopción y, al mismo tiempo, agranda la deuda futura.

Hacia la era de “Kami Excel 2.0”

Con todo lo anterior, RPA y el no-code/low-code siguen el mismo patrón que Kami Excel: salvan a los equipos con su rapidez, convencen a la dirección gracias a lo visible y acaban dejando un peso muerto por la caja negra y la personalización.

La diferencia decisiva es la escala de su impacto. Mientras Kami Excel se limitaba al archivo, el desarrollo ciudadano moderno se integra en la nube y en procesos troncales, convirtiéndose en una deuda que encadena a toda la organización.

Además arrastra un bloqueo aún más rígido que Excel. Ese es el escenario que podríamos llamar “Kami Excel 2.0”.

Conclusiones

  • RPA y el no-code/low-code conquistaron a los equipos y a la dirección gracias a su rapidez y a la fuerza de mostrar resultados tangibles.
  • Pero para soportar operaciones reales se necesitan conocimientos de ingeniería de software —estructuras de control, estructuras de datos, integración de sistemas y operación—, algo que las personas desarrolladoras ciudadanas no pueden sostener por sí solas.
  • Las interfaces específicas de cada plataforma hacen que la migración sea muy difícil y refuerzan el bloqueo con el proveedor.
  • El “sesgo de visualización” de la dirección minimiza estos riesgos.

En definitiva, el desarrollo ciudadano moderno es más potente que Kami Excel, pero también más frágil. En la próxima entrega analizaremos qué sucede cuando a esta dinámica se suma la IA generativa.

Próximo: Los legados que la IA generativa rescata y los que abandona 4/7