Unimos los datos de planta (OT) y de los sistemas de negocio (IT) en una arquitectura sobre Azure Fabric, con reglas claras de calidad y acceso. Así los reportes coinciden entre áreas, porque todos salen de la misma fuente.
De la fuente al reporte
La señal de que hace falta trabajo de datos casi siempre es la misma: dos áreas llegan a la reunión con cifras distintas para lo mismo. Producción dice una cantidad, comercial dice otra, y cuando se revisa, las dos están bien. Cada una sacó el número de su propia fuente, con su propio corte de hora y su propia definición de qué cuenta como producido.
El origen del problema no es técnico sino de acuerdo. Mientras cada área mantenga su propia extracción, cada reporte va a ser correcto por separado e incompatible con el resto. Por eso la primera parte del trabajo no es construir nada: es dejar por escrito qué significa cada indicador y quién es el dueño de esa definición.
Sobre esa base levantamos una arquitectura por capas en Azure Fabric. Los datos entran crudos y sin transformar, se depuran en una capa intermedia donde se aplican las reglas de calidad, y recién después se modelan para el negocio. Separar las tres capas permite corregir una regla sin volver a pedir los datos al origen, y rastrear cualquier cifra del reporte hasta el registro que la produjo.
La otra mitad del trabajo es de gobierno: cada dato con un responsable, una regla de calidad y un catálogo que diga de dónde viene. Sin eso, una arquitectura correcta vuelve a degradarse a los pocos meses, cuando alguien agrega una fuente nueva sin avisar y el indicador cambia sin que nadie sepa por qué.
Planta y negocio conectados en un solo modelo.
Limpieza y trazabilidad automáticas.
Datos en capas: crudos, depurados y listos.
Indicadores que se actualizan solos.
Cada dato con dueño y regla de calidad.
Funciona mientras haya pocas fuentes y un solo usuario. Se rompe cuando cada área arma su propia conexión: ahí empiezan a convivir varias definiciones del mismo indicador y nadie puede decir cuál es la correcta. Además, consultar directamente los sistemas de producción les agrega carga justo cuando más se usan. La capa intermedia existe para resolver las dos cosas.
No necesariamente todo, y no de una vez. Lo habitual es partir por el dominio donde hay un dolor concreto, por ejemplo producción, y dejar el resto donde está hasta que haya una razón para moverlo. Hay datos que conviene mantener en planta por latencia o por política interna, y la arquitectura tiene que poder convivir con eso en vez de exigir una migración completa como condición de entrada.
No se fuerzan a la misma frecuencia. El dato de proceso se guarda con su detalle y su marca de tiempo original, y se agrega al nivel que el indicador necesita, normalmente por turno o por día, que es el nivel en que el sistema de negocio tiene sentido. El error típico es promediar el dato de planta demasiado temprano: una vez agregado, el detalle no se recupera.
No. Ninguno de los dos se toca. Ambos siguen siendo los sistemas donde se opera; la arquitectura de datos los lee para construir los indicadores. De hecho, conviene que los sistemas de origen no cambien: mientras más estable la fuente, menos mantención necesita todo lo que está aguas abajo.
Preferimos entregar un dominio acotado funcionando completo, de la fuente al tablero, antes que toda la arquitectura a medias. Un primer indicador en producción sirve para validar las definiciones con quienes lo van a usar, que es donde aparecen las correcciones. Con el patrón ya probado, los dominios siguientes avanzan bastante más rápido.
Casi siempre vienen con algún problema, y encontrarlo es parte del valor del proyecto. Las reglas de calidad no lo arreglan en silencio: dejan el registro marcado y visible, para que el área dueña del dato pueda corregirlo en el origen. Tapar el problema en la capa intermedia hace que el reporte se vea bien mientras el dato sigue malo donde se captura.
¿Tus reportes no coinciden entre áreas? Conversemos.
Conversemos de tu proyecto →