Para organizaciones cuyas finanzas todavía viven en Excel.
Del Excel artesanal al dato gobernado
El resultado: una compañía que cerraba sus finanzas con más de dos semanas de retraso —y sin confiar del todo en sus cifras— pasó a un modelo de gobierno del dato diseñado para entregar información financiera certificada al día siguiente del cierre. El cierre deja de ser una carrera de limpieza manual y se convierte en un proceso trazable, medible y automatizable.
En 30 segundos
| Pregunta | Respuesta |
|---|---|
| Problema | La organización cerraba tarde porque sus reportes dependían de exportaciones manuales, Excel intermedios y definiciones no gobernadas. |
| Riesgo | Cifras contradictorias, errores detectados al final del cierre, falta de responsables del dato y poca trazabilidad. |
| Solución | Diagnóstico AS-IS, Operating Model de datos, Data Contracts, Golden Records, Data Owners y arquitectura Medallion sobre Microsoft Fabric. |
| Estado del caso | Diagnóstico y diseño verificados; MVP de construcción en ejecución con objetivos cuantitativos definidos. |
| Diferencial Abbalalla | No construimos tableros sobre datos frágiles: instalamos el mecanismo de gobierno que permite confiar en los números. |
Una multinacional de servicios con presencia regional cerraba sus resultados financieros más de dos semanas después del cierre mensual y dedicaba una porción alta del tiempo de su equipo financiero a limpiar datos en Excel para que los reportes cuadraran. Abbalalla diseñó el modelo de gobierno del dato y la arquitectura Medallion para convertir ese proceso manual en un flujo certificado, trazable y automatizable.
| Ficha | |
|---|---|
| Perfil | Multinacional de servicios con presencia regional |
| Foco | Estrategia y gobierno de datos sobre arquitectura Medallion |
| Plataforma objetivo | Microsoft Fabric |
| Tipo de impacto | Confiabilidad financiera, trazabilidad, reducción de reprocesos y base para automatización/IA |
El reto
La compañía operaba con un ecosistema tecnológico heterogéneo: un ERP operativo local para nómina y facturación, un ERP financiero-contable corporativo, un sistema de contratación y operaciones, y una capa de reportería construida sobre descargas manuales y hojas de cálculo. No existía un bus de integración unificado entre estos sistemas; los flujos dependían de exportaciones manuales, archivos Excel intermedios y procesos por lotes no monitoreados.
El diagnóstico realizado por Abbalalla —más de diez semanas de levantamiento estructurado con áreas financieras y operativas— reveló un patrón consistente: la información fluía entre sistemas y archivos manuales sin una capa intermedia que certificara la calidad del dato antes de llegar al reporte financiero.
Síntomas concretos identificados:
| Patología de dato | Qué significaba en la práctica |
|---|---|
| Sin propietario del dato | Ninguna métrica tenía un dueño formal responsable de su calidad y frescura. |
| Definiciones en la cabeza de las personas | Un mismo indicador podía significar cosas distintas según el área. |
| Calidad validada al final | Los errores se descubrían durante el cierre, cuando ya habían impactado el reporte. |
| Ausencia de linaje | Nadie podía rastrear con precisión por qué una cifra cambiaba desde el origen hasta el reporte ejecutivo. |
| Sin Golden Record de maestros | Dimensiones clave como cliente, empleado, unidad de negocio o centro de costo vivían en varios sistemas con criterios distintos. |
| Cartera con dos versiones | Dos archivos podían mostrar cifras contradictorias de manera simultánea. |
El costo oculto del proceso manual: el cierre financiero se extendía más de dos semanas y la mayor parte del retraso se originaba en la falta de validación de los insumos antes de llegar al reporte.
Nuestro enfoque
Abbalalla planteó el proyecto con una tesis clara: esto no era un proyecto de reportería, sino el establecimiento del mecanismo fundacional de gobierno del dato. Construir tableros bonitos sobre datos sin gobernar solo automatiza el error. El verdadero entregable es un Operating Model de datos.
1. Arquitectura Medallion como mecanismo de gobierno
Diseñamos una arquitectura Lakehouse de tres capas sobre Microsoft Fabric, donde cada capa cumple una función explícita de gobierno:
| Capa | Función | Control de calidad |
|---|---|---|
| RAW | Ingesta fiel de la fuente, sin transformación. | Completitud, puntualidad e integridad inicial. |
| SILVER | Modelado, homologación de dimensiones y codificación de lógica de negocio. | Validaciones de negocio, reglas de conciliación y control de excepciones. |
| GOLD | Dataset certificado, listo para consumo ejecutivo. | Consistencia, linaje, sello de calidad, responsable y marca de tiempo. |
2. Government by Iteration
En lugar de un «big bang», definimos un modelo de gobierno iterativo. Cada iteración expande el perímetro de datos gobernados siguiendo el mismo patrón, sin rediseñar la arquitectura. El MVP arranca por el dominio financiero ancla —un conjunto acotado de reportes de mayor prioridad— y demuestra el patrón sobre fuentes reales antes de escalar.
3. Artefactos de gobierno tangibles
- Data Contracts versionados por reporte: definición oficial, fórmula, sistema fuente, periodicidad, SLA y criterios de calidad.
- Golden Record por dimensión maestra: sistema de origen definido, sincronización auditada y regla de resolución de conflictos.
- Linaje nativo: trazabilidad de cada campo desde la fuente hasta el reporte.
- Data Owners formalizados: responsabilidad explícita sobre calidad, frescura y definición del dato.
- Matriz de riesgos de dato: priorización de patologías según impacto financiero, frecuencia y complejidad de corrección.
4. La automatización como consecuencia
Identificamos procesos manuales repetitivos —descargas de FTEs, consolidación de nómina, construcción de aging de cartera— como candidatos inmediatos a automatización. Pero la automatización se construye sobre dato gobernado: primero se certifica la calidad, luego se automatiza el flujo.
Principio rector: lo que distingue a una empresa ordenada en datos no es la cantidad de reportes que produce, sino la certeza con la que puede responder tres preguntas sobre cualquier número: ¿de dónde viene?, ¿quién responde por su calidad? y ¿cuándo fue validado por última vez?
Resultados
El programa se estructuró como un MVP de seis meses. A la fecha de este caso, los resultados verificables corresponden a la fase de diagnóstico y diseño: la base sobre la que se construye el valor cuantitativo del MVP. Reportamos con transparencia qué está logrado y qué es objetivo del programa.
Logrado y verificable
| Resultado | Detalle |
|---|---|
| Diagnóstico integral de gobierno del dato | Mapa de patologías, gaps de gobernanza, zonas grises y riesgos en dominios financieros prioritarios. |
| Modelo objetivo de gobierno | Definición de Data Ownership, Data Contracts, reglas de calidad, linaje y Golden Records. |
| Arquitectura Medallion diseñada | Blueprint Lakehouse en Microsoft Fabric con estrategia de ingesta, aislamiento de cargas y gestión de capacidad. |
| Reportes financieros priorizados | Alcance del MVP confirmado con el área financiera y documentación fuente-reporte-gap. |
| Candidatos a automatización identificados | Procesos manuales repetitivos mapeados como oportunidades IPA inmediatas. |
Objetivos cuantitativos del MVP en ejecución
| Métrica | Punto de partida | Objetivo del programa |
|---|---|---|
| SLA de disponibilidad del dato financiero | Más de dos semanas tras el cierre | Dato certificado al día siguiente del cierre |
| Tiempo del equipo financiero en limpieza manual | Alto consumo operativo | Reducción sustancial vía certificación y automatización |
| KPIs con contrato y sello de calidad | Sin gobierno formal | Mayoría de KPIs críticos con contrato y responsable |
| Datasets certificados | No medido | Alta disponibilidad, con frescura dentro de SLA |
Nota de transparencia: las cifras de «punto de partida» provienen del diagnóstico AS-IS. Las de «objetivo» son metas del programa y deben verificarse con telemetría al cierre del MVP.
Este diagnóstico es para tu organización si...
- El cierre financiero depende de Excel.
- Dos áreas reportan cifras distintas para el mismo indicador.
- Nadie sabe con certeza quién es dueño de un KPI.
- Los errores aparecen al final del cierre, no antes.
- Tus tableros existen, pero la dirección no confía completamente en ellos.
- Quieres usar IA, pero tus datos todavía no están listos para soportarla.
¿Tu operación financiera también vive en Excel?
Si reconoces tu organización en este patrón, el problema no es de reportería: es de gobierno del dato. Y tiene solución.
En Abbalalla diseñamos el modelo de gobierno, la arquitectura de datos y las automatizaciones que convierten el dato disperso en un activo confiable, trazable y listo para la IA. Empezamos por un diagnóstico que muestra exactamente dónde está el riesgo y qué MVP puede demostrar valor con tus datos reales.