Saltar al contenido
← Volver al blog
Automatización

Cómo evoluciona un sistema de análisis de automatizaciones

Hace ya más de 3 años monté mi primera automatización y fue precisamente un sistema para recoger y evaluar las peticiones de automatización de procesos de mis compañeros, de modo que todo quedara canalizado y además agilizara la toma de requisitos de cada solicitud. La idea eran 3 sencillos pasos: el usuario rellenaba un formulario básico con su petición, cada nueva solicitud se enviaba a un LLM que la evaluaba y me enviaba una propuesta de cómo automatizar ese proceso. Lo cierto es que funcionó pero hoy lo montaría completamente distinto.

A estas alturas de mi carrera tengo claro que con independencia de que tu equipo sea más o menos numeroso, lo cierto es que siempre va a haber tareas que son repetitivas, que no aportan nada a quien las hace pero que son necesarias dentro de la compañía.

A menudo esto se hace más notorio cuando los equipos son pequeños y las tareas se acumulan, porque las que tienen ese caracter repetitivo son percibidas cada día como más “robatiempo” frente a otras en las que sí hay valor añadido.

En este contexto, un equipo con muchas tareas y muchas de ellas sistemáticas, decidimos lanzarnos a automatizar procesos para aligerar la carga en todos los departamentos pero para evitar convertirme en un cuello de botella y poder controlar todos esos nuevos procesos, comencé por crear una herramienta que me ayudara en la primera parte, para recoger las peticiones, evaluarlas y proponer el modo más óptimo de llevar a cabo esa automatización.

Cómo fue la versión inicial

El flujo como se puede ver era bastante sencillo:

Lo primero el Formulario: aprovechando que usábamos Slack como herramienta básica de comunicación, monté un formulario sencillo allí, de modo que todo el mundo tenía siempre disponible el gestor de peticiones; ese formulario almacenaba los envíos en un sheets y a la vez enviaba un webhook al escenario en el que sucedía la “magia”.

Cada vez que se recibía una petición el escenario arrancaba: el sistema miraba la información volcada en el sheets y a partir de ahí, se recorría dos caminos: por un lado, enviaba un mensaje al usuario de que se había recibido correctamente su formulario y por otro, enviaba la información a ChatGPT para que la evaluara, elaborara una propuesta de acción y me devolviera un mensaje a mí con dicha propuesta, para finalmente actualizar el sheets con el análisis inicial. Esta es la foto:

Lo que funcionaba bien:

  • Era un sistema completamente automático, sin intervención manual
  • El equipo lo tenía disponible siempre y podía usarlo sin fricción
  • El modelo LLM era suficiente para el nivel de análisis que se pedía.

Lo que no funcionaba tan bien:

  • Google Sheets como base de datos: sé que esto es lo habitual en muchísimas organizaciones y lo entiendo, es de Google, se incluye con el Workspace y es hermano de Excel. ¿A quién no le va a gustar?, sin embargo, siendo realistas, una hoja de cálculo nunca será una base de datos, no tienes trazabilidad real, no puedes moldearla y su capacidad de lanzar avisos complejos pasa por escribir scripts en código e implementarlos.
  • No había un sistema de fallback de modo que si alguna petición no se procesaba como debía el escenario se paraba.
  • No había panel de control: para ver el estado de todas las solicitudes tenías que ir a la hoja.

Cómo es la versión que tengo funcionando hoy

Hoy tengo una base de datos formal: Airtable; sigo usando sheets en mi día a día pero no como base de datos ni para procesos complejos. A partir de ahí todas las piezas encajan mejor y además me permite ajustarlo a las herramientas de cada organización, si usan Slack puedo mantener el formulario allí y enviar los datos a Airtable; si no, uso un formulario directamente en AT. En ambos casos, una vez que se recibe la petición, se envía directamente desde allí a Make y partir de ahí de nuevo el proceso funciona solo:

  1. Primero miramos si es una petición nueva o una actualización de información.
  2. Si es nueva petición, Claude revisa la información y si no hay suficiente detalle solicita más información usuario o genera una propuesta que me envía a mí.
  3. Si es una respuesta de usuario, analiza la información y genera la propuesta que me envía.
  4. Actualiza el estado de la solicitud en Airtable.
  5. En el caso de que alguno de los módulos falle, está configurado para que no se pare el circuito, actualiza el estado de la petición y todo se mantiene funcionando para que el siguiente registro pueda procesarse.

Qué gana cada cambio:

  • Airtable frente a Sheets: panel de control real, vistas personalizadas y filtradas, formulario nativo, registro histórico, etc.
  • Claude frente a GPT-4o-mini: esto reconozco que es evolución personal y que cada uno tendrá su modelo preferido; en mi caso Claude es me da prompts más ricos, mejor razonamiento técnico, respuestas más estructuradas y específicas para Make.
  • Control de errores: aquí sí está implementado el error handler en los módulos críticos para evitar un bloqueo ante posibles fallos puntuales del proceso.

Esta es la foto final del sistema:

Mi conclusión:

Es un sistema mucho más robusto y seguro, está preparado para soportar peticiones de 1 a n usuarios y ahora mismo está funcionando a coste cero incluso el modelo de IA. Por supuesto, se puede llevar más allá pero por ahora es lo que necesito.

Si quieres probarlo, aquí tienes el enlace al formulario: solicitud de automatización y si quieres que te comparta alguno de los blueprints, escríbeme y te lo envío.

¿Qué cambiarías tú de tus primeras automatizaciones a las actuales?

¿Te ha resultado útil? Compártelo: