De Excel caótico a dashboard en tiempo real: un caso de transformación

Cuando llegamos, la operación funcionaba con una arquitectura de datos que, siendo generosos, llamaríamos «distribuida»: una docena de hojas Excel en carpetas compartidas, versiones enviadas por email cada mañana y una persona que dedicaba media jornada, todos los días, a consolidarlo todo en un «master» para la dirección.

El problema no era la falta de datos. Tenían demasiados y en demasiados sitios. Y convertirlos en información útil llevaba tanto tiempo que, cuando el informe llegaba a dirección, ya era historia.

El contexto: logística con datos fragmentados

La empresa gestionaba transporte de mercancías para clientes B2B. Su operación incluía:

• Varios almacenes que introducían datos en sistemas locales.
• Una flota de vehículos con hojas de ruta en papel y en Excel.
• Un departamento de mantenimiento con registros en Access.
• Facturación en un programa contable desconectado de las operaciones.
• Clientes que preguntaban «¿dónde está mi carga?» y respuestas que tardaban horas en llegar.

El sistema de reporting era este: cada almacén enviaba un Excel por email al responsable de reporting a las 9:00. Él lo consolidaba a mano, aplicaba fórmulas, generaba gráficos y enviaba un PDF a dirección hacia el mediodía. Para entonces, los datos tenían entre 3 y 15 horas de antigüedad.

Los problemas eran previsibles: versiones contradictorias (alguien reenvía un Excel antiguo por error), errores humanos al consolidar, imposibilidad de profundizar (¿por qué sale este número? toca abrir los Excel originales uno por uno) y la frustración constante de operar con información desfasada.

Análisis previo: entender antes de construir

Antes de proponer ninguna tecnología, dedicamos 2 semanas a entender 3 cosas.

Qué decisiones se toman con qué datos. Dirección quería ver la ocupación de los almacenes, el rendimiento de las rutas, las incidencias y el flujo de caja operativo. Operaciones necesitaba visibilidad en tiempo real de la carga pendiente y de los problemas en curso.

Dónde viven los datos originales. Algunos estaban en un software de gestión de almacén con API. Otros seguían en Excel porque no existía ningún sistema. Y otros nacían en papel y alguien los tecleaba después en Excel.

Qué pasos eran realmente necesarios. Muchos pasos de consolidación existían solo porque los sistemas no se hablaban entre sí, no porque aportaran valor. Si un paso solo sirve para copiar datos de un sitio a otro, es candidato a desaparecer.

La solución: una arquitectura de datos unificada

Diseñamos un sistema en 3 capas.

Capa 1: ingesta de datos

• Conexiones por API: los sistemas que ya tenían API (el software de almacén y el GPS de la flota) se conectaron directamente. El almacén se sincronizaba cada hora; el GPS, cada pocos minutos.
• Carga estructurada: para los datos que seguían en Excel (mantenimiento), plantillas estandarizadas con validación que se subían a la base de datos central. Si faltaba un campo o una fecha no tenía sentido, el sistema lo rechazaba en el momento.
• Formularios digitales: una app móvil sencilla sustituyó el papel de los conductores y alimentaba directamente la base de datos.

Capa 2: base de datos central y procesamiento

Una base de datos PostgreSQL donde convergían todos los datos, con procesos automáticos de:

• Limpieza y normalización (el mismo cliente aparecía escrito de varias formas según la fuente).
• Cálculos derivados (rendimiento por ruta, porcentaje de ocupación).
• Histórico (conservar la evolución en el tiempo para poder comparar semanas y temporadas).

Capa 3: dashboard y reporting

• Dashboard operativo: Metabase (open source) con los KPI actualizados automáticamente, accesible desde el navegador y desde el móvil.
• Alertas automáticas: cuando la ocupación de un almacén supera el 90%, cuando una ruta acumula más de 30 minutos de retraso, etc. Avisos por email y Telegram.
• Informes programados: envío automático de PDF diarios y semanales sin intervención humana.

Implementación: fases y aprendizajes

Fase 1 (mes 1): resultados rápidos

Conectamos las API existentes y creamos un dashboard básico de ocupación de almacenes. Valor visible desde el primer mes, y eso generó la confianza y el impulso necesarios para lo que venía después.

Fase 2 (meses 2 y 3): datos manuales

Sustituimos los Excel sueltos por formularios estructurados. Fue la parte más tediosa: convencer a operaciones de que el nuevo proceso era mejor e iterar los formularios hasta que fueran realmente cómodos de usar.

Lección: la resistencia al cambio no era tecnológica, era de hábito. Cada uno tenía «sus» Excel y confiaba más en ellos que en cualquier sistema nuevo. Ganamos esa confianza demostrando, durante semanas, que el dashboard mostraba exactamente lo mismo que ellos veían en su Excel local.

Fase 3 (meses 3 y 4): app móvil para conductores

Sustituimos las hojas de ruta en papel por una app sencilla (una PWA, no una app nativa, para acortar plazos y no depender de las tiendas de aplicaciones). Permitía marcar entregas, reportar incidencias con foto y consultar la siguiente parada.

Ese fue el punto de inflexión. Tener la posición de cada vehículo y el estado de las entregas en tiempo real cambió la operación: el centro de control veía dónde estaba cada camión y podía gestionar las incidencias antes de que el cliente llamara.

Fase 4 (mes 5): automatización del reporting

Con los datos fluyendo, eliminamos la consolidación manual. La persona que dedicaba media jornada al reporting pasó de mover datos de un lado a otro a analizarlos y proponer mejoras operativas. Cambio de rol, no eliminación del puesto.

Resultados medidos

A los 6 meses de completar la implementación:

Tiempo de reporting: de unas 4 horas diarias de consolidación manual a 0. Los informes se generan solos.

Antigüedad de los datos: de entre 3 y 15 horas (según el momento del día) a menos de 1 hora en la mayoría de las métricas, y tiempo real en la posición de la flota.

Errores por versiones contradictorias: eliminados. Hay una única fuente de verdad.

Respuesta a clientes: de «te lo confirmo en 1 o 2 horas» (mientras alguien buscaba en los Excel) a «ahora mismo veo que tu carga está en tal punto y llega a tal hora».

Decisiones operativas: capacidad de ver tendencias (por ejemplo, carga acumulándose en un almacén) y actuar antes, en lugar de reaccionar a problemas ya ocurridos.

Retorno: la inversión total en desarrollo rondó los 25.000 €. El tiempo de consolidación recuperado, sumado a menos errores y a respuestas más rápidas, la justificó en menos de un año.

Qué hicimos bien

• Empezar simple y ampliar. No intentamos resolverlo todo en el primer lanzamiento. Los resultados rápidos nos dieron margen para las fases difíciles.
• Implicar a operaciones desde el principio. No fue «tecnología impuesta desde arriba», sino «una herramienta que resuelve los problemas que tú ya tienes».
• Mantener Excel donde tenía sentido. No lo sustituimos por sustituir. Para análisis puntuales y escenarios hipotéticos, Excel siguió disponible, ahora alimentado con datos fiables.
• Documentar procesos. El nuevo sistema tenía documentación clara, algo que el caos de Excel nunca tuvo. Es una parte que muchos proyectos se saltan y que sale cara más adelante.

Qué haríamos diferente

• Más formación al principio. Subestimamos cuánta formación necesitaban algunos usuarios no técnicos. Una sesión de presentación no basta: hace falta acompañamiento las primeras semanas y una guía corta a mano.
• Permisos más granulares desde el inicio. Tuvimos que rehacer parte del modelo de permisos cuando surgieron necesidades del tipo «este departamento no debería ver esos datos».
• Copias de seguridad probadas, no solo configuradas. Un incidente menor de corrupción de datos nos recordó que una copia automática no vale nada si nunca se ha probado a restaurarla.

Aplicabilidad a otros casos

Este patrón (datos dispersos, consolidación, dashboard y automatización) sirve para muchas empresas:

• Retail: consolidar las ventas de varios canales (tienda física, tienda online, marketplaces).
• Industria: conectar máquinas, inventario y planificación.
• Servicios: horas de los equipos, estado de los proyectos y facturación.
• Marketing: reunir las métricas de varias plataformas en un único informe.

Los detalles cambian, pero la arquitectura de 3 capas (ingesta, procesamiento, visualización) es sólida y replicable. Y no siempre exige cambiar de sistema: muchas veces basta con conectar lo que ya existe, como contamos en cómo automatizar el reporting de tu ERP sin cambiar de sistema. Si quieres identificar primero qué información debería moverse sola en tu empresa, empieza por qué datos de tu negocio deberían actualizarse solos.

Conclusión

La transformación no consistió en «dejar Excel». Consistió en dejar de usar Excel para lo que Excel hace mal: ser un sistema de datos multiusuario y en tiempo real. Excel es magnífico para el análisis exploratorio; como base de datos operativa es un problema.

El valor real no estuvo en la tecnología (PostgreSQL y Metabase son estándar y asequibles). Estuvo en entender qué datos alimentan qué decisiones y en diseñar flujos que los conecten sin fricción.

Si tu empresa vive en un laberinto de Excel compartidos por email y sospechas que hay una forma mejor de trabajar, probablemente la haya. Cuéntanos cómo funciona hoy tu operación y te diremos, con números, qué tendría sentido conectar primero.