Cómo reducir el cierre mensual de 2 semanas a 2 horas

El cierre mensual que tarda días no es un problema de personas. Es un problema de infraestructura de datos. Acá explicamos cómo resolverlo.

Hay algo que casi toda empresa mediana tiene en común: el cierre mensual es un evento traumático.

Empieza unos días antes de que termine el mes. Alguien del equipo financiero manda el primer mail pidiendo datos. Empieza una cadena de pedidos: ventas manda su Excel, logística manda el suyo, el ERP hay que exportarlo manualmente, el sistema de cobranzas tiene su propio formato. Alguien cruza todo en un Excel maestro que tiene 47 hojas y macros que nadie entiende del todo. A mitad del proceso aparece algún número que “no cierra”. Se busca el error. Se descubre que en ventas contaron una devolución como venta. Se corrige. El informe llega al CEO con 10 días de atraso y tres versiones distintas que nadie sabe cuál es la final.

Esto no es un problema de eficiencia de los equipos. Es un problema de infraestructura.

¿Por qué el cierre mensual tarda tanto?

El cierre mensual tarda porque la información que necesita está distribuida en múltiples sistemas que no se hablan entre sí:

• ERP: tiene las compras, los costos, los pagos a proveedores
• CRM: tiene las ventas, los clientes, el pipeline
• Sistema de logística: tiene los envíos, las devoluciones, los tiempos de entrega
• E-commerce o POS: tiene las transacciones directas
• Planillas: tienen el resto —lo que no entra en ninguno de los sistemas anteriores

Para construir el P&L mensual, alguien tiene que exportar datos de cada sistema, cruzarlos manualmente, resolver las inconsistencias (el mismo cliente con dos nombres distintos, una transacción que aparece en dos sistemas con fechas distintas), y consolidar todo en un formato coherente.

Ese proceso tarda días porque es esencialmente manual. Y es frágil: si la persona que sabe hacerlo está de vacaciones, está enferma o renunció, el proceso se paraliza.

¿Cuánto le cuesta realmente a la empresa?

El costo del cierre lento no aparece en el P&L, pero existe.

Un proceso de cierre de 10 días que involucra a 5 personas que dedican el 50% de su tiempo durante esas dos semanas son 10 personas/día de trabajo. Si esas personas tienen un costo mensual promedio de $3.000 cada una, el costo directo en tiempo humano es ~$7.000 por mes, solo en el proceso de cierre.

Pero hay un costo mayor: las decisiones que se toman sobre información de 30-45 días de antigüedad. Cuando el cierre de marzo llega el 20 de abril, las decisiones de pricing, de inventario y de contratación para mayo se están tomando con datos casi de dos meses atrás. En mercados que se mueven rápido, ese lag es una desventaja competitiva real.

¿Cómo se resuelve?

La solución existe, está probada, y no requiere presupuesto de empresa grande. Es arquitectura de datos aplicada correctamente:

Paso 1: Centralizar los datos (capa Bronze)

En lugar de exportar CSVs cada vez que alguien los necesita, se configura un pipeline que extrae los datos de cada sistema automáticamente y los almacena en un lugar centralizado. Este es el concepto de capa Bronze en la arquitectura Medallion: los datos raw, tal como llegan de cada fuente, sin tocarlos.

Esto se hace una sola vez. Una vez que el pipeline está funcionando, los datos de todos los sistemas llegan solos cada noche —o cada hora, según la necesidad.

Paso 2: Limpiar y cruzar los datos (capa Silver)

Sobre los datos raw, se aplican transformaciones estándar:

• Normalización de nombres y formatos
• Deduplicación de registros
• Resolución de conflictos entre sistemas (qué pasa cuando dos sistemas tienen un valor distinto para el mismo campo)
• Cálculo de IDs únicos por entidad (un cliente = un ID, sin importar en qué sistema está)

Esta capa Silver es donde los datos dejan de ser una colección de fuentes y se convierten en información coherente. Las reglas de resolución de conflictos están escritas en código, en SQL estándar versionado en Git. No dependen de que alguien recuerde cómo se hacía.

Paso 3: Modelar para el negocio (capa Gold)

Sobre los datos limpios, se construyen las vistas del negocio:

• P&L por canal, por zona, por producto
• Márgenes reales (ventas - costo de mercadería - logística - devoluciones)
• KPIs de ventas: ticket promedio, tasa de conversión, retención
• Métricas financieras: flujo de caja, cuentas por cobrar, cuentas por pagar

Estas vistas están pre-calculadas. Cuando alguien necesita el cierre mensual, no exporta nada: consulta directamente el dashboard o corre la query en segundos.

Paso 4: Automatizar el reporte

El último paso es conectar estas vistas a una herramienta de reporting (puede ser Power BI, Metabase, Looker, o incluso Excel con una conexión directa). El reporte se genera automáticamente. El cierre mensual pasa de ser un proceso de 10 días a ser un dashboard que se actualiza solo.

Un caso concreto: antes y después

Una empresa de distribución con operaciones en 3 provincias tenía este proceso de cierre:

• 12 personas involucradas en el proceso
• 8-10 días hábiles de duración
• 3-4 versiones del informe final
• Errores frecuentes que se descubrían semanas después

El problema raíz: cinco fuentes de datos (ERP, e-commerce, sistema de depósito, CRM, planillas de vendedores) que nadie había conectado entre sí. Cada área construía su propia versión del número.

Después de implementar la arquitectura Medallion con las cinco fuentes:

• 2 personas involucradas (para revisión y validación, no para construcción)
• 2 horas para el cierre completo, disponible el día 2 de cada mes
• 1 sola versión del informe, generada automáticamente
• Los errores se detectan durante el pipeline, no después

El tiempo de implementación fue de 6 semanas. El ROI se recuperó en el primer mes por el tiempo de trabajo que se dejó de invertir en el proceso manual —sin contar el valor de las decisiones más rápidas.

¿Por qué no se resuelve con más herramientas?

El reflejo habitual es agregar una herramienta. Comprar Snowflake. Implementar Power BI. Contratar a alguien que “haga el BI”.

El problema es que ninguna herramienta de reporting puede compensar datos que no están integrados. Power BI puede visualizar cualquier cosa, pero si los datos que alimentan la visualización son inconsistentes, la visualización muestra información inconsistente con una presentación bonita.

La solución tiene que empezar en la capa de datos, no en la capa de presentación.

Tampoco se resuelve contratando más personas para el proceso manual. Si hay 5 personas procesando datos manualmente, contratar una sexta reduce el tiempo un 20%, no lo elimina. Y el proceso sigue siendo frágil porque sigue dependiendo de personas, no de sistemas.

¿Tu empresa tiene este problema?

Las señales de que el cierre tiene un problema de infraestructura y no de personas:

• El cierre tarda más de 3 días hábiles
• Hay más de 3 personas involucradas en construir el informe
• Existe un “Excel maestro” que nadie quiere tocar
• Aparecen regularmente discrepancias entre sistemas (“en ventas dice X, en el ERP dice Y”)
• El informe final tiene errores que se descubren después
• No existe una única versión de la verdad

Si reconoces alguna de estas señales, el problema no es la gente. Es que la información no está conectada.

Preguntas frecuentes

¿Cuánto tiempo lleva implementar este tipo de pipeline?

Para una empresa mediana con 3-7 fuentes de datos, la implementación completa toma entre 4 y 8 semanas. Las primeras semanas se conectan las fuentes y se construye Bronze. Las semanas intermedias se trabaja en las transformaciones Silver y el modelado Gold. Al final de la semana 6-8 hay un primer dashboard de cierre funcional. Después viene la iteración para agregar nuevas métricas y fuentes.

¿Requiere reemplazar el ERP o los sistemas actuales?

No. La arquitectura de datos funciona como una capa por encima de los sistemas existentes, sin modificarlos. El ERP, el CRM y el sistema de logística siguen operando exactamente igual. El pipeline lee los datos de esos sistemas (vía API, exportación programada o conexión directa) sin interferir en su operación.

¿Qué pasa si una fuente de datos cambia su formato?

El pipeline tiene que ser actualizado para reflejar el cambio. Esto es trabajo de mantenimiento esperado, pero es trabajo acotado: actualizar el script de ingesta de esa fuente específica, sin tocar el resto del pipeline. Con dbt y Dagster bien configurados, los cambios en una fuente no se propagan automáticamente a las capas superiores: el pipeline falla visiblemente y el equipo recibe una alerta, en lugar de propagar datos incorrectos silenciosamente.

¿Es necesario migrar datos históricos?

Depende del caso de uso. Para el cierre mensual, generalmente alcanza con tener datos de los últimos 12-24 meses bien integrados. La migración de datos históricos es útil para análisis de tendencias y proyecciones, pero no es un bloqueador para tener el primer cierre automatizado funcionando.

---

Si tu cierre mensual todavía tarda más de 3 días, agenda una llamada. Te decimos exactamente qué está bloqueando el proceso y qué hace falta para cambiarlo.