Hay un momento en la vida de cualquier empresa distribuidora en el que el Excel deja de ser una herramienta de gestión y se convierte en un problema de gestión. El síntoma es siempre el mismo: el responsable de cada área tiene su propia hoja, los datos no cuadran entre departamentos, y la gerencia toma decisiones con información que tiene entre dos y siete días de retraso. Este era exactamente el punto en el que se encontraba nuestro cliente cuando nos contactó.
La empresa distribuidora de alimentos congelados opera con presencia en tres islas —Gran Canaria, Tenerife y Lanzarote— y factura algo más de 14 millones de euros anuales. Su cartera incluye más de 600 referencias activas: pescados, mariscos, carnes, aves y precocinados. Tiene unos 280 clientes activos entre hoteles, restaurantes, supermercados y colectividades.
Cuando llegamos, el panorama tecnológico era el siguiente: el ERP principal era Oracle SIGES, utilizado para gestión de compras, ventas, facturación y contabilidad. En paralelo, había una base de datos PostgreSQL propia donde el equipo de almacén gestionaba el stock en tiempo real (el módulo de stock de SIGES tenía limitaciones que habían motivado este desarrollo paralelo). Y luego estaban los Excels: al menos ocho hojas distintas que distintas personas del equipo financiero y comercial actualizaban manualmente cada semana a partir de exportaciones del ERP.
El problema central era la ausencia de visibilidad de márgenes. La gerencia sabía cuánto vendía y cuánto compraba de forma global, pero no podía responder a preguntas básicas: ¿Qué categoría de producto tiene mejor margen este mes? ¿Qué isla es más rentable? ¿Qué clientes generan más volumen pero menos margen? Para responder a cualquiera de estas preguntas, el responsable financiero necesitaba entre tres y cinco días de trabajo manual.
Las ventas y compras estaban en Oracle SIGES. El stock real estaba en PostgreSQL. Los precios medios ponderados (PMP) —métrica crítica en distribución para calcular el margen real de cada venta— estaban en Excel. Ningún sistema hablaba con los otros. Para calcular el margen de una venta, había que cruzar manualmente el precio de venta de SIGES con el PMP del Excel correspondiente.
En el mejor caso, los datos disponibles en los dashboards de dirección tenían 24-48 horas de retraso. Las exportaciones de SIGES se hacían manualmente y se procesaban en Excel la mañana siguiente. En la práctica, la mayoría de los informes tenían entre 3 y 7 días de antigüedad.
No había un informe sistemático de margen por categoría de producto, por cliente, por isla o por comercial. El cálculo existía como concepto en el ERP, pero la estructura de tablas de SIGES (en particular la tabla TCABMOVISTOCKS y sus tipos de documento CDCLADOC) hacía complejo extraer directamente un margen por venta sin un proceso ETL específico.
El 90% del conocimiento sobre cómo interpretar los datos estaba en la cabeza de dos personas: el responsable financiero y el responsable de compras. Si cualquiera de los dos faltaba, la información se paralizaba. No había documentación del proceso, ni validaciones automáticas, ni trazabilidad de los cambios en los Excels.
Propusimos una arquitectura basada en tres componentes: un Data Warehouse en AWS Redshift como capa de almacenamiento y transformación, pipelines ETL con Python + Apache Airflow para la extracción y carga de datos desde las fuentes, y Power BI Embedded como capa de visualización accesible desde el navegador sin necesidad de licencias de escritorio.
La extracción de SIGES fue la parte más delicada del proyecto. La base de datos Oracle tiene una estructura de tablas heredada con nomenclatura críptica, y los tipos de movimiento de stock están codificados en el campo CDCLADOC de TCABMOVISTOCKS con valores que determinan si un movimiento es una venta, una devolución, una transferencia entre almacenes o un ajuste de inventario. Fue imprescindible entender bien qué valores de CDCLADOC correspondían a ventas reales (a clientes finales, excluyendo traspasos internos) para construir la cuenta de explotación correctamente.
El pipeline de extracción usa una conexión JDBC a Oracle, se ejecuta cada noche mediante Airflow a las 02:00 AM, y extrae los movimientos del día anterior. Los datos se cargan en una capa de staging en Redshift y luego se transforman mediante DBT (Data Build Tool) en tablas dimensionales del modelo estrella.
El precio medio ponderado es la métrica más importante para una distribuidora: refleja el coste real de cada unidad vendida, ponderado por las distintas compras que conforman el stock disponible. Su fórmula es sencilla en teoría (PMP = (Stock anterior × PMP anterior + Cantidad entrada × Precio entrada) / (Stock anterior + Cantidad entrada)), pero en la práctica depende de una actualización correcta en cada movimiento de entrada.
En SIGES, el PMP se actualiza automáticamente en cada albarán de compra, pero hay situaciones que lo distorsionan: devoluciones de cliente que se reincorporan al stock a precio de venta, regularizaciones de inventario, y compras con descuentos retroactivos. El pipeline ETL incluye una capa de validación del PMP que detecta y alerta sobre anomalías estadísticas (variaciones superiores al 15% en el PMP de una referencia en un solo día).
El resultado final es un conjunto de cuatro vistas principales en Power BI, accesibles desde el navegador con autenticación corporativa:
El impacto más inmediato no fueron los ahorros de tiempo, sino los descubrimientos. En la primera semana de uso del cuadro de mando, la gerencia identificó tres situaciones que no eran visibles con el sistema anterior:
El cierre mensual pasó de requerir cinco días de trabajo manual del responsable financiero a dos horas de revisión y validación del dashboard. El ROI del proyecto se alcanzó en cuatro meses, contando solo el ahorro por la corrección de precios en precocinados y la optimización del stock de marisco.
La complejidad de SIGES era conocida de antemano, pero su magnitud real solo se aprecia cuando te enfrentas al modelo de datos. La nomenclatura de las tablas (TCABMOVISTOCKS, TDETMOVISTOCKS, TARTIGEN, TCLIENTES) responde a una lógica propia que requiere tiempo de comprensión antes de poder construir cualquier extracción fiable. Documentar correctamente qué CDCLADOC utilizar para cada tipo de movimiento fue crítico para que la Cuenta de Explotación cuadrara con la contabilidad oficial.
El segundo aprendizaje fue la importancia de involucrar al equipo financiero desde el día uno. No como validadores al final del proyecto, sino como co-diseñadores del modelo de datos y de los KPIs. Los márgenes que importan al responsable financiero y los que importan al gerente no son los mismos. Tener esa conversación en la semana uno, y no en la semana seis, ahorró dos semanas de rediseño.
Podemos llevarte desde tu situación actual hasta un cuadro de mando ejecutivo con visibilidad de márgenes en tiempo real. Sin importar qué ERP uses.
HablemosHablemos
Cuéntanos tu proyecto y te proponemos la solución más adecuada sin compromiso.