Plataforma de flujos de trabajo multiequipo

Una plataforma web que hace avanzar capas vectoriales SIG por los equipos que las elaboran y revisan, con archivos, notificaciones y una entrega verificada a un sistema de operaciones. Luego generalizada en un framework reutilizable.

Rol: Diseño y desarrollo
Período: 2025–2026
Servicios: Mapas, dashboards y apps
Flujos de datos

La tabla principal de la plataforma en vista de progreso. Cada fila es un registro con su flujo, región, número, nombre, estado general (completado o en proceso) y el equipo a cargo, como una etiqueta de color. Una línea de íconos recorre los pasos, desde la elaboración por las revisiones, correcciones y aprobación hasta el registro final: tics verdes para los pasos terminados, flechas para las correcciones omitidas, un reloj para el paso actual (rojo si está atrasado) y círculos vacíos para los que faltan. Arriba, un buscador, un filtro por equipo asignado y un interruptor entre la vista de progreso y la de resumen. Debajo, cinco gráficos de retrasos: el retraso promedio por paso en cada uno de los dos flujos, los días de retraso por registro y dos gráficos de anillo con los pasos atrasados en este momento, por equipo y por región. — Todos los registros y en qué punto está cada uno, en la vista de progreso, con los gráficos de retrasos de la vista de resumen debajo. Interfaz real, datos inventados.

Un organismo público nacional producía capas vectoriales SIG (shapefiles) a través de una cadena de equipos regionales y centrales: cada registro pasaba por elaboración, revisión, correcciones y un registro final en el sistema de operaciones del organismo, todo coordinado por correo y planillas compartidas. Diseñé y construí la plataforma que reemplazó esa coordinación, y después la generalicé en un framework para cualquier proceso del mismo tipo.

Cómo funciona

Una vista de cada registro. Una tabla lista cada registro con su paso actual, su plazo y el equipo a cargo. Al abrir uno, un stepper muestra el flujo completo: los pasos terminados muestran lo que entregó cada equipo, y el paso actual muestra su formulario al equipo responsable.
Plazos y retrasos. Cada paso tiene un plazo acorde al trabajo que implica. Una vista de resumen grafica los retrasos por paso, registro, equipo y región, tanto en el periodo como en este momento.
Una máquina de estados para el flujo. Los pasos y su orden son configuración guardada en la base de datos. Un motor de flujo hecho de funciones puras decide cada transición, incluidas ramas como las correcciones, y emite acciones (completar un paso, cerrar un registro, copiar un archivo) que ejecuta el backend.
Archivos directo a Google Drive. Los archivos van del navegador a una carpeta de Drive del organismo como subidas reanudables que nunca pasan por el backend, así incluso los archivos grandes no consumen tiempo de servidor. La plataforma verifica que cada shapefile esté completo, y nombra y ordena cada subida por su cuenta.
Notificaciones. Cada paso enviado avisa por correo al siguiente equipo responsable, con copia a todos los involucrados, desde la cuenta de la plataforma y con plantillas hechas en React Email.
Acceso solo autenticado. Inicio de sesión con Google, con los permisos de acceso y de administrador como custom claims de Firebase, que se aplican tanto en el backend como en las reglas de seguridad de Firestore.
Administración. Un panel para gestionar usuarios y equipos, ciclos de vida de los registros, carpetas de almacenamiento y respaldos de la base de datos, más una herramienta de línea de comandos para cargar y descargar colecciones.

Una entrega verificada

El último paso registra los archivos finales en el sistema de operaciones del organismo, que la plataforma solo podía leer. Para probar que lo registrado era exactamente lo que los equipos habían aprobado, les pedí a quienes mantienen ese sistema que guardaran una huella SHA-256 de cada archivo subido. La plataforma calcula la misma huella al empaquetar el ZIP final y, antes de dejar cerrar un registro, la compara con la que publica el sistema de operaciones, junto con la superficie registrada. Si alguna difiere, el registro sigue abierto y el equipo ve exactamente qué no coincide.

De una app a un framework

Las partes que no eran propias de este proceso se convirtieron en un framework para cualquier proceso hecho de pasos ordenados a cargo de equipos. Un núcleo rígido es común a todos los despliegues: identidad y acceso, ciclo de vida de los casos, motor de flujo, formularios, archivos adjuntos, notificaciones, dashboard, panel de administración, registro de auditoría, analítica e internacionalización. Cada proceso se conecta como un dominio, hecho de configuración y datos iniciales, sin tocar nunca el núcleo. La plataforma original es su dominio de referencia.

Resultados

Usada por 36 personas de cinco equipos regionales y centrales, que pasaron de correos y planillas a un flujo compartido, con videotutoriales integrados en la plataforma.
Ninguna entrega sin verificar: un registro solo se cierra cuando sus archivos coinciden con lo que registró el sistema de operaciones.
Infraestructura gratuita: funciona completamente con planes gratuitos en la nube (Firebase, Vercel, Deno Deploy y Google Drive).
Con pruebas: 325 pruebas automatizadas cubren la plataforma, y el núcleo del framework tiene sus propias pruebas unitarias y una prueba de humo de un proceso completo de punta a punta.