En una institución pública y en una utility, los datos son a la vez una obligación y un activo. Hay que presentar una declaración al regulador en una fecha y un formato concretos, y esos mismos números podrían mostrar por dónde se escapa el dinero y dónde se está acumulando riesgo. El truco está en que los datos rara vez viven en un solo sitio, y unas hojas de cálculo juntadas a mano antes del plazo no dan ni una declaración fiable ni una analítica utilizable.
Por nuestra experiencia, lo difícil no es «sacar el informe», sino construir un proceso repetible y auditable que recalcule cada mes los mismos números a partir de las mismas fuentes. Vamos a enseñarte qué competencias de datos y BI podemos sumar a tu equipo, apoyándonos en la experiencia de RITS Group en Big Data y en la construcción de plataformas de datos (incluidos nuestros equipos de datos e IA dentro de RITS Group).
¿Por qué están tan fragmentados los datos en una institución pública?
Una institución rara vez empieza de cero. Con los años acumula una capa de sistemas de dominio: facturación, GIS, RR. HH., finanzas y contabilidad, sistemas de medida y registros, a menudo de proveedores distintos y de generaciones tecnológicas distintas. Cada uno tiene su modelo de datos, sus diccionarios y su propia idea de lo que es un «cliente» o un «punto de suministro».
A eso se suma que el reporting ha descansado durante años en personas y no en un proceso: un analista exporta datos de varios sistemas, los une en una hoja de cálculo, los arregla a mano y los envía. Ese modelo deja de aguantar en cuanto hay más informes, los plazos son fijos y alguien pregunta de dónde salió un número concreto. Así que el primer paso no es un cuadro de mando nuevo, sino poner orden en las fuentes.
¿Qué es un data warehouse para el sector público y qué te aporta?
Un data warehouse para el sector público es el sitio donde los datos de muchos sistemas aterrizan en un modelo coherente y con una única definición de la verdad. Lo diseñamos para que responda a las preguntas reales de reporting y de gestión, no para copiar todas las tablas de las fuentes. Solemos construirlo en varias capas:
- una capa cruda, en la que cargamos los datos de origen sin cambiarlos, para conservar el rastro del original,
- una capa de modelo, donde limpiamos, unificamos diccionarios y derivamos dimensiones compartidas (tiempo, zona, cliente, punto de suministro),
- una capa de reporting, con tablas listas para declaraciones y cuadros de mando concretos.
Este reparto permite añadir una fuente o un informe nuevos sin rehacerlo todo y, durante una auditoría, es fácil mostrar el camino de un número desde la declaración hasta el registro de origen.
¿Cómo construir pipelines para el reporting obligatorio?
El reporting obligatorio juega con sus propias reglas: no cuenta solo el resultado, sino el hecho de que se haya producido de forma repetible. Así que, en lugar de exportaciones manuales, levantamos pipelines de datos que se ejecutan según un calendario y cargan, transforman y validan los datos por sí mismos.
Automatizamos el ciclo ETL/ELT completo: extracción de datos de las fuentes, transformación al modelo, comprobaciones de calidad y generación de los estados en el formato que exige el regulador. Nos apoyamos en un stack probado (orquestación de flujos, transformaciones en SQL, lógica versionada en un repositorio), elegido para encajar con lo que la institución ya tiene.
Encima de eso incorporamos la auditabilidad, porque la pregunta «¿de dónde ha salido este número?» llega antes o después. Mantenemos el linaje completo de los datos desde una línea de la declaración hasta el registro de origen, versionamos la lógica de transformación (para poder reproducir un informe de hace un trimestre) y garantizamos ejecuciones reproducibles. Entonces una auditoría consiste en mostrar un proceso documentado, no en reconstruir cálculos de memoria.
¿Qué cuadros de mando de gestión merece la pena dar a quien decide?
Una vez ordenados los datos, la capa de gestión se arma rápido. Diseñamos cuadros de mando de gestión que responden a las preguntas de una dirección en vez de sepultarlas en gráficos. Para una utility son métricas de venta y consumo, nivel de pérdidas, cobros y estado de la red; para una institución, ejecución presupuestaria, carga de los procesos y cumplimiento de plazos en los expedientes.
Nos atenemos a la regla de que una pantalla apoya una decisión: en lugar de decenas de tarjetas damos unas pocas métricas con contexto (valor, tendencia, referencia al plan, posibilidad de profundizar). Las alimentamos desde la misma capa de modelo que las declaraciones, para que la dirección y el regulador miren números coherentes y no dos verdades distintas.
¿Cómo publicar open data a través de una API?
Cada vez más instituciones están obligadas a poner datos a disposición del exterior. Open data no es, sin embargo, soltar un CSV en una web, sino un canal de publicación mantenido, documentado y seguro.
Construimos la capa de publicación para que los datos lleguen al portal de open data o a una API desde el mismo almacén que las declaraciones. Nos ocupamos de un esquema estable, de los metadatos y el versionado, de la anonimización allí donde la protección de datos personales lo exige y de la publicación automática. Como resultado, los datos abiertos se mantienen actualizados y coherentes con el reporting oficial.
¿Cómo analizar el consumo y las pérdidas en utilities?
En una utility, el mayor valor se esconde en la analítica de consumo y de pérdidas. Cuando los datos de medida, facturación y red aterrizan en un mismo modelo, puedes comparar lo que se produjo con lo que se facturó y ver la diferencia, es decir, las pérdidas técnicas y comerciales.
Sobre esa base construimos análisis de perfiles de consumo, detección de anomalías (un consumo inusual que apunta a una avería o a un fraude) y previsión de demanda. Donde tiene sentido añadimos una capa de modelos predictivos - las competencias de IA y machine learning existen de verdad dentro de RITS Group - entrenados con los datos de una red concreta y no servidos de serie.
¿Cómo garantizar la calidad y la seguridad de los datos?
Un informe vale lo que valen los datos que tiene debajo. Cableamos comprobaciones automáticas en los pipelines: reglas de completitud, coherencia y validez que frenan los datos defectuosos antes de que lleguen a una declaración.
La seguridad en el sector público no es negociable. Vinculamos los accesos a roles, ciframos los datos sensibles, separamos los entornos y registramos las operaciones sobre datos personales para cumplir con el RGPD. Diseñamos además la retención y la anonimización, para que los datos analíticos y abiertos no se conviertan en una puerta trasera a registros sensibles.
¿Qué competencias aportamos a un proyecto de datos?
Aunque no tengamos un caso de éxito de un organismo concreto, sí podemos poner en tu equipo a las personas que construyen sistemas así. Cubrimos roles ajustados a la fase del proyecto:
- un arquitecto de datos / de almacén que diseña el modelo y las capas,
- un ingeniero de datos que construye y mantiene los pipelines,
- un especialista de BI que se hace cargo de los informes y los cuadros de mando,
- un analista o ingeniero de ML cuando entran en juego la predicción y la detección de anomalías.
Trabajamos en modelo de refuerzo de equipo (body leasing) o como equipo dedicado, según si cubrimos huecos o asumimos toda el área. Como partner nearshore desde Polonia, entramos rápido en tu ritmo de trabajo.
¿Cómo lo hacemos en RITS?
Nos apoyamos en competencias reales de datos y BI dentro de RITS Group, no en historias sobre despliegues ajenos. Diseñamos un almacén y un modelo de datos para reporting y analítica, automatizamos el reporting obligatorio con auditabilidad completa, desarrollamos cuadros de mando, open data y analítica de consumo sobre una misma capa y añadimos competencias de IA/ML allí donde de verdad salen rentables. Lo más habitual es hacerlo como software a medida construido por nuestro equipo y, cuando hay que completar personas rápido, como refuerzo de equipo.
¿Por dónde empezar con el reporting y la analítica?
Empieza por el informe que más duele: averigua de qué fuentes sale, cuáles son sus definiciones y dónde se sigue haciendo hoy a mano. Eso define el alcance de la primera versión del almacén, los primeros pipelines y los roles que necesitas. Los informes siguientes se montan sobre un cimiento que ya funciona. Las diferencias entre los modelos de colaboración las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir el reporting obligatorio o la analítica en una institución o en una utility? Hablemos - ajustamos un equipo y una arquitectura a tus datos.