Udesa — Informe de Formación y Requerimientos TIC
Documentación técnica generada a partir de las sesiones de formación impartidas por Alejandro Torrado Quintela
Informe de Formación Udesa
Síntesis de las cuatro sesiones de formación
1. Resumen Ejecutivo
Se han realizado cuatro sesiones de formación impartidas por Alejandro Torrado Quintela, responsable de Udesa, dirigidas al equipo de la consultora TIC que acometerá los próximos desarrollos de software para la distribuidora. El objetivo global de estas jornadas ha sido proporcionar el contexto de negocio, normativo y técnico necesario para que el equipo de desarrollo pueda dimensionar correctamente los proyectos futuros.
Evolución de las sesiones
▼| Sesión | Duración aprox. | Foco principal |
|---|---|---|
| Sesión 1 | ~1 h 32 min | Visión general de Udesa, su modelo de negocio, contexto de regulación y necesidad de digitalización |
| Sesión 2 | ~1 h 15 min | Recorrido por la normativa (CNMC), introducción a los formatos de telegestión y switching |
| Sesión 3 | ~1 h 31 min | FTPs de medidas y switching, arquitectura de sistemas, gestión de infraestructura con ITELSIS |
| Sesión 4 | ~1 h 31 min | Arquitectura de sistemas de Udesa: Datalake "Panóptico" como elemento central, 2 servidores físicos (TI y telecontrol), concentrador secundario, segmentación de red, medida real vs facturada, integración FTP telegestión, Power BI/SharePoint workaround, prioridades CRM y medida real |
Conclusiones transversales
▼- Udesa es una distribuidora eléctrica de pequeño tamaño en la provincia de A Coruña, con un territorio de concesión fijo y sin expectativas de crecimiento territorial.
- El sector eléctrico está sometido a una regulación creciente por parte de la CNMC, lo que genera una carga cada vez mayor de informes, auditorías y control.
- La empresa necesita digitalizar y automatizar procesos para no quedar en déficit operativo.
- Se ha creado Multiservicios como empresa vinculada para diversificar ingresos y mantener la plantilla.
- Los próximos desarrollos deben dejar de ser "estándar" (CRM, ERP) y pasar a ser específicos de distribuidora, con conocimiento profundo de formatos homologados por Red Eléctrica y la CNMC.
- El Datalake "Panóptico" es la iniciativa central de la arquitectura: su objetivo es centralizar todos los datos de los procesos básicos de distribución, permitir acceso a cualquier dato y servir como piedra angular de todos los desarrollos futuros.
- La estrategia arquitectónica busca transicionar desde plataformas propietarias separadas (actualmente Neurophi para facturación, contratación y switching) hacia un modelo de aplicaciones propias centralizado en el Datalake.
- El enfoque es record-driven: el objetivo final de casi cualquier proceso TI es publicar información a alguien (CNMC, Red Eléctrica, abonados, comercializadoras).
- El Datalake debe actuar como proxy/bypass de APIs de terceros a través de una sola IP, para simplificar el control de accesos de proveedores externos.
- El servicio no se limita a Udesa: se da servicio a 3 distribuidoras (Udesa, Guadiela y Gayoso), por lo que los desarrollos pueden tener que ser multi-distribuidora.
- La nueva circular CNMC de febrero 2026 obligará a evolucionar el CRM con más información al abonado, requiriendo desarrollos nuevos integrados con el Datalake.
- Se requieren sesiones adicionales para profundizar en switching y completar el proyecto del CRM (Real Decreto febrero 2026).
- La infraestructura física se compone de 2 servidores (TI y telecontrol) gestionados por ITELSIS, con segmentación de red por seguridad (red Core, red Panóptico, red M2M de telegestión).
- El concentrador secundario es una aplicación legacy (protocolo ~2001) que publica ficheros de medida a Red Eléctrica; se quiere simplificar progresivamente.
- La integración del FTP de telegestión (medida real) en el Datalake es el siguiente desarrollo grande, ligado a los cambios del CRM por el Real Decreto de febrero 2026.
- El workaround actual de Power BI (scripts → CSV → SharePoint) funciona pero debe sustituirse por acceso directo al Datalake.
- Prioridades actuales: 1) CRM (Real Decreto, deadline junio 2026 no cumplido), 2) Medida real en Datalake, 3) Dashboard/Power BI (prioridad personal de Alejandro).
2. El Sector Eléctrico y el Papel de Udesa
Introducción
▼Antes de abordar la realidad operativa y tecnológica de Udesa, es necesario comprender el funcionamiento general del sector eléctrico español. La distribución eléctrica forma parte de un ecosistema altamente regulado en el que participan distintos actores con responsabilidades claramente diferenciadas. El conocimiento de estas relaciones resulta fundamental para entender los procesos de medida, switching, facturación, calidad de servicio y cumplimiento normativo que condicionan el desarrollo de cualquier solución tecnológica para una distribuidora eléctrica.
Cadena de Valor del Sistema Eléctrico
▼El suministro eléctrico al consumidor final es el resultado de la interacción coordinada de cuatro actividades principales:
Generación
Las empresas generadoras producen la energía eléctrica mediante distintas tecnologías (hidráulica, eólica, solar, térmica, nuclear, etc.). La energía producida se comercializa en un mercado mayorista gestionado por OMIE, donde los precios se determinan mediante mecanismos regulados.
Transporte
La red de transporte, gestionada por Red Eléctrica de España (REE), constituye la infraestructura de alta tensión que conecta los grandes centros de generación con las redes de distribución. REE actúa además como Operador del Sistema, garantizando el equilibrio permanente entre generación y demanda.
Distribución
Las distribuidoras, como Udesa, son responsables de la infraestructura de media y baja tensión que lleva la energía hasta los puntos de consumo. Entre sus funciones principales se encuentran:
- Operación y mantenimiento de la red.
- Gestión de acometidas y puntos de suministro.
- Lectura y validación de medidas.
- Gestión de incidencias y calidad de servicio.
- Intercambio de información con comercializadoras y organismos reguladores.
La distribuidora no vende energía al cliente final; proporciona el acceso físico a la red eléctrica.
Comercialización
Las comercializadoras adquieren energía en el mercado y la venden a los consumidores finales. Son las responsables de la relación contractual de suministro y de la facturación energética al cliente. En España operan aproximadamente 700 comercializadoras, lo que convierte los procesos de intercambio de información entre distribuidoras y comercializadoras en uno de los elementos más complejos del sector.
Consumidor Final
El consumidor mantiene simultáneamente dos relaciones distintas:
- Un contrato de acceso a la red con la distribuidora.
- Un contrato de suministro con una comercializadora.
Esta separación explica gran parte de los procesos regulados que aparecen posteriormente en este documento, especialmente los relacionados con switching, contratación y gestión de medidas.
Udesa como Distribuidora Regulada
▼Udesa opera como distribuidora eléctrica dentro de un marco regulatorio definido por la CNMC. A diferencia de una empresa comercializadora, su actividad se desarrolla en régimen de monopolio natural dentro de una zona concesional determinada. Por este motivo, su crecimiento no depende de captar nuevos clientes fuera de su ámbito territorial, sino de gestionar eficientemente sus activos y garantizar la calidad del servicio prestado.
La retribución de la compañía está estrechamente vinculada a factores como:
- El volumen y estado de la infraestructura eléctrica.
- La calidad del suministro.
- La disponibilidad de la red.
- El cumplimiento de los procedimientos regulatorios.
- La correcta gestión de la información remitida a los organismos supervisores.
En consecuencia, los sistemas de información adquieren una importancia estratégica al convertirse en la base para justificar inversiones, demostrar el cumplimiento regulatorio y sostener los procesos operativos de la compañía.
Diferenciación entre Udesa y Multiservicios
▼Durante las sesiones de formación se destacó la necesidad de distinguir entre la actividad regulada desarrollada por Udesa y la actividad de crecimiento impulsada a través de Multiservicios (también identificada comercialmente como Enerxe).
Mientras que Udesa se centra en la distribución eléctrica dentro de su ámbito concesional, Multiservicios actúa como brazo tecnológico y de servicios del grupo, proporcionando capacidades de digitalización, mantenimiento y desarrollo tecnológico tanto para Udesa como para otras distribuidoras como Guadiela y Gayoso.
Esta diferenciación resulta especialmente relevante para comprender la estrategia tecnológica descrita en las siguientes secciones, donde iniciativas como el Datalake "Panóptico", la integración de sistemas o el desarrollo de aplicaciones propias tienen vocación de reutilización en múltiples distribuidoras del grupo.
3. Contexto de Negocio de Udesa
Descripción de la compañía
▼Udesa (Unión Distribuidora Eléctrica, S.A.) es una empresa gallega dedicada a la distribución de energía eléctrica en la provincia de A Coruña. Es una distribuidora de pequeño tamaño que opera en un territorio de concesión fijo, otorgado mediante pliegos administrativos.
Ámbito geográfico
▼- Provincia de A Coruña (Galicia). Zonas principales: Ordes, Cerceda y entorno del aeropuerto de Lavacolla.
- El territorio se obtuvo mediante pliegos administrativos que no acotan un plazo de duración específico (se mencionó la posibilidad de pliegos de hasta 40 años).
- No hay expectativas de crecimiento territorial; el negocio está "estancado" en ese sentido, aunque con la tranquilidad de unos ingresos fijos.
- Udesa opera como red "aguas abajo" de la infraestructura de Fenosa, lo que genera una dependencia técnica y económica directa con la red de transporte de la que recibe la energía.
Posición de Udesa dentro del Sistema Eléctrico
▼Udesa desarrolla su actividad como distribuidora eléctrica dentro de un sector altamente regulado. A diferencia de las comercializadoras, que compiten por captar clientes y vender energía en el mercado libre, las distribuidoras operan sobre una infraestructura física esencial cuya gestión está sometida a regulación y supervisión permanente.
La compañía actúa en régimen de monopolio natural dentro de su ámbito concesional, siendo responsable de la operación, mantenimiento y desarrollo de las redes de media y baja tensión necesarias para garantizar el suministro eléctrico a los consumidores de su zona de distribución.
Su actividad no se centra en la venta de energía, sino en proporcionar acceso a la red, gestionar los puntos de suministro, obtener y validar las medidas de consumo, mantener la calidad del servicio y garantizar el cumplimiento de los procedimientos regulatorios establecidos por los organismos supervisores.
La retribución de la distribuidora está vinculada principalmente a la correcta gestión de sus activos eléctricos, la calidad del suministro prestado y el cumplimiento de los requisitos regulatorios definidos por la CNMC. Por este motivo, la información técnica, operativa y administrativa constituye un activo estratégico para la organización.
En este contexto, la digitalización de procesos, la gobernanza del dato y la integración de sistemas adquieren una relevancia creciente, ya que permiten optimizar la operación diaria, reducir costes de gestión y responder con mayor eficiencia a las obligaciones regulatorias del sector.
Udesa no vende energía al consumidor final. Su función es operar y mantener la infraestructura eléctrica que hace posible el suministro, gestionar la medida y garantizar el acceso a la red dentro de su territorio de distribución. Las comercializadoras son las responsables de la relación comercial y la facturación de la energía consumida.
Modelo operativo
▼- Ingreso fijo basado en la retribución regulada por la CNMC por la actividad de distribución. La viabilidad financiera se sustenta en los peajes de acceso (ATR) publicados en el BOE, que sufragan el mantenimiento preventivo y correctivo. Es vital que el ERP identifique correctamente los costes para que el regulador reconozca las inversiones en la retribución anual.
- Cada vez hay más supervisión, informes, control y auditoría por parte del regulador.
- La empresa opera sistemas en campo (OT) muy distribuidos que necesitan ser centralizados y cohesionados.
- Mantiene sistemas ya desarrollados por la consultora: un CRM (página web de área de clientes) y un ERP, ambos con características específicas pero de naturaleza estándar.
- Usa Neurophi (plataforma propietaria de terceros) para facturación, gestión de contratación y switching.
- Se ha iniciado un proyecto de Datalake (nombre interno: "Panóptico") para centralizar datos de la distribuidora y servir como base de todos los desarrollos futuros.
- Infraestructura en cloud: Microsoft 365 para ofimática, SharePoint/OneDrive para documentación.
- Infraestructura on-premise: 2 servidores físicos separados (TI y telecontrol), gestionados por ITELSIS. Segmentación de red: red Core (servicios generales), red Panóptico (Datalake) y red M2M (telegestión, 300 concentradores en campo vía Telefónica).
- Concentrador secundario: aplicación legacy (protocolo ~2001) en 3 máquinas, publica ficheros de medida a Red Eléctrica. Usado por 10+ distribuidoras. Se quiere simplificar.
- Bitwarden para gestión de contraseñas del equipo. Máquina específica para firma de facturas Neurophi (certificado digital in-house).
- GIS de Traza (A-Plus) desplegado on-premise en Udesa; Gayoso usa Traza en cloud.
- SCADA / Sismored: gemelo digital de la red. Permite maniobras remotas y mide indicadores de calidad (TIEPI/NIEPI).
- GISFE (Meter APP): gestión cartográfica y apoyo a lecturas manuales (~5% de puntos sin telegestión).
El CUPS como elemento central de la operación
▼El Código Universal de Punto de Suministro (CUPS) constituye el identificador único e invariable de cada punto de suministro eléctrico dentro del sistema eléctrico español. De forma análoga a una matrícula en el ámbito de la automoción, el CUPS permite identificar de manera inequívoca una instalación independientemente de los cambios de titularidad, comercializadora o contratos asociados.
Para una distribuidora eléctrica, el CUPS representa uno de los activos de información más importantes de toda la organización, ya que actúa como referencia común para la práctica totalidad de los procesos operativos y regulatorios.
En la arquitectura de sistemas de Udesa, el CUPS funciona como la clave principal de integración entre diferentes dominios de información:
- Información geográfica de la red (GIS).
- Datos técnicos e infraestructura eléctrica.
- Sistemas de medida y telegestión.
- Procesos de switching con comercializadoras.
- Sistemas CRM de atención al abonado.
- Sistemas ERP y procesos administrativos.
- Informes regulatorios remitidos a organismos supervisores.
La correcta identificación y trazabilidad del CUPS permite relacionar la ubicación física de un suministro, sus características técnicas, las lecturas de consumo, los contratos asociados y las distintas interacciones con comercializadoras y organismos reguladores. Esta capacidad de integración resulta esencial para garantizar la coherencia de la información y el cumplimiento de los procesos regulados del sector eléctrico.
Desde el punto de vista de la evolución tecnológica, el CUPS constituye también uno de los principales elementos de referencia para la estrategia de centralización de datos impulsada mediante el Datalake "Panóptico", permitiendo consolidar información procedente de múltiples fuentes bajo un identificador común y consistente.
El CUPS es la pieza que conecta negocio, operación y tecnología. Cualquier proceso relacionado con contratación, medida, switching, atención al abonado, regulación o explotación de datos termina apoyándose en este identificador como elemento común de integración.
Infraestructura física de distribución
▼La actividad de distribución eléctrica de Udesa se sustenta sobre una infraestructura física extensa y altamente distribuida que debe ser operada, mantenida y supervisada de forma continua. El conocimiento de esta realidad es fundamental para comprender la criticidad de los sistemas de información, la importancia de la telegestión y el volumen de datos generado diariamente por la operación de la red.
Magnitudes principales de la red
| Activo | Magnitud aproximada |
|---|---|
| Red de Media Tensión (MT) | ~400 km |
| Red de Baja Tensión (BT) | ~600 km |
| Infraestructura total | ~1.000 km |
| Centros de Transformación | ~300 |
| Puntos frontera | 8 |
| Suministros activos | ~9.200 |
Los puntos frontera constituyen elementos especialmente críticos, ya que representan las conexiones mediante las que la energía entra en la red de distribución de Udesa desde infraestructuras de terceros. Su supervisión y control resultan esenciales para garantizar la continuidad del suministro y la correcta operación de la red. Un punto crítico de la operación es la recepción de energía a 15 kV en una de estas fronteras, lo que exige que Udesa realice una elevación técnica a 20 kV para homogeneizar su red de distribución.
La gestión del dato debe reflejar fielmente la realidad física que sustenta la Base de Activos Retribuida: el conjunto de infraestructuras eléctricas sobre las que la CNMC reconoce la retribución de la compañía. La correcta documentación y trazabilidad de los activos es fundamental para justificar inversiones ante el regulador.
La dimensión de esta infraestructura hace necesaria una estrategia creciente de digitalización, automatización y monitorización, apoyada en sistemas de medida, telegestión, GIS, SCADA y plataformas de explotación de datos como el Datalake Panóptico.
Servicio a múltiples distribuidoras
▼El servicio no se limita a Udesa. Actualmente se da servicio a 3 distribuidoras además de a Udesa. Esta realidad multi-cliente debe considerarse en el diseño de los desarrollos: las soluciones pueden necesitar ser reutilizables entre distribuidoras.
Udesa
Cliente principal
A Coruña
Guadiela
Distribuidora servida
Gayoso
Recientemente incorporada
Procesos replicados de Udesa
Estrategia de futuro y necesidad de digitalización
▼Estrategia de futuro: Multiservicios
- Se ha creado Multiservicios, una empresa vinculada que permite diversificar ingresos y mantener la plantilla.
- Udesa contrata con Multiservicios el desarrollo de sistemas (CRM, etc.) y parte de la retribución va a nóminas.
- La CNMC controla cada vez más la retribución, lo que limita el margen de Udesa.
- La tendencia del sector es que las pequeñas distribuidoras, por asfixia regulatoria, acaben vendiendo y centralizándose en pocas compañías.
Necesidad de digitalización
- El incremento de requerimientos informativos y de control hace que una pequeña distribuidora "se quede coja".
- Hay que digitalizar y automatizar para no quedar en déficit operativo.
- Los próximos desarrollos deben ser específicos de procesos de distribuidora, con conocimiento de formatos homologados por Red Eléctrica y la CNMC.
4. Desglose Sesión por Sesión
Sesión 1: Visión General y Contexto de Negocio
| Objetivo | Proporcionar una visión general de Udesa, su negocio y las necesidades de software, especialmente para los miembros nuevos del equipo (Patricia, Iván) |
| Ponente | Alejandro Torrado Quintela |
| Participantes | Pilar Rivas Pereiro, Daniel Zas Dacosta, Patricia Blázquez García, César Vicente Cabañas |
Temas clave explicados:
- Recorrido general de Udesa: Presentación de la compañía, su modelo de negocio y su papel como distribuidora eléctrica.
- Proyectos pasados vs. futuros: Los desarrollos anteriores (CRM, ERP) eran relativamente estándar. Los próximos serán específicos de procesos de distribuidora, con formatos homologados por Red Eléctrica y la CNMC.
- Datalake: Sistema para centralizar datos, surgido por iniciativa del propio equipo. Actualmente agnóstico: recopila y almacena datos.
- Control de calidad y normativa: La validación y el control de calidad deben ir en paralelo a lo que marca la normativa.
- Sistemas de campo (OT): Sistemas distribuidos en campo que necesitan centralización y cohesión.
- Contexto regulatorio: Cada vez hay más informes, control y auditoría. La CNMC supervisa cada vez más.
- Multiservicios: Empresa vinculada para diversificar ingresos y mantener nóminas. Udesa no da margen; hay que buscar oportunidades fuera.
- Tendencia del sector: Las pequeñas distribuidoras pueden acabar vendiendo por asfixia regulatoria; el sistema busca centralizar la red en pocas compañías.
- Territorio: Se obtuvo mediante pliegos sin acotación temporal clara. No hay expectativas de crecimiento territorial.
Conclusiones:
- El equipo necesita conocimiento de negocio suficiente para acometer proyectos específicos de distribuidora.
- La digitalización y automatización son indispensables para la viabilidad de Udesa.
- El Datalake es una pieza clave para centralizar la información.
Sesión 2: Normativa, Telegestión y Switching
| Objetivo | Recorrer la normativa del sector eléctrico e introducir los formatos de telegestión y switching |
| Ponente | Alejandro Torrado Quintela |
| Participantes | Pilar Rivas Pereiro, Daniel Zas Dacosta, Patricia Blázquez García, César Vicente Cabañas, Ignacio Valverde Hernández, Jesús Gábana de Vega |
Temas clave explicados:
- Normativa CNMC: La CNMC (Comisión Nacional de los Mercados y la Competencia) es el organismo que más regula el sector eléctrico. La normativa es compleja, abundante y cambiante.
- Dos FTPs regulados:
- Telegestión: XMLs con formato establecido, regulados por CNMC.
- Switching: XMLs con formato establecido, regulados por CNMC. Canal principal de intercambio entre comercializador y distribuidor.
- Switching (cambio de comercializador):
- Proceso mediante el cual un cliente quiere cambiarse de comercializadora.
- El comercializador envía al distribuidor (Udesa) un fichero XML de tipo C1 (cambio de comercializador) vía FTP.
- El XML se recibe en el FTP y aparece en la plataforma de gestión de switching, donde se parsea y tramita.
- Es similar al CRM pero muy procedimentado, homologado y definido por la CNMC.
- Comunicaciones PLC y calidad de lectura:
La infraestructura de telegestión utilizada por las distribuidoras eléctricas se basa principalmente en tecnologías PLC (Power Line Communications), que permiten transmitir datos utilizando los mismos conductores destinados al transporte de energía eléctrica.
A diferencia de las redes TCP/IP convencionales, las comunicaciones PLC operan sobre una infraestructura diseñada originalmente para transportar potencia eléctrica y no información digital. Como consecuencia, las comunicaciones están expuestas a diversos fenómenos que afectan a la calidad de la transmisión.
Entre los factores que pueden degradar la calidad de las comunicaciones destacan:
- Interferencias electromagnéticas generadas por instalaciones industriales.
- Armónicos producidos por determinados equipos eléctricos.
- Inversores asociados a instalaciones fotovoltaicas.
- Perturbaciones propias de la red eléctrica.
Estas circunstancias provocan pérdidas de comunicación, lecturas incompletas y múltiples reintentos de lectura por parte de los concentradores de telegestión. Como resultado, los sistemas generan grandes volúmenes de información y mecanismos específicos de validación y estimación de datos.
El sistema Breo supervisa la salud y calidad de las comunicaciones de campo, permitiendo monitorizar el estado de los concentradores y detectar incidencias en la telegestión.
- Principales tipos de ficheros XML de telegestión:
La operación diaria de la distribuidora genera múltiples intercambios de información mediante mensajes XML normalizados. Entre los ficheros más relevantes se encuentran los siguientes:
Tipo Función principal S02 Curvas horarias de carga S05 Cierres diarios S04 Cierres mensuales y facturación S09 Eventos de red S23 Detección de fraude y manipulaciones S26 Calidad de tensión Importancia del S04: El fichero S04 constituye la principal fuente de información utilizada para los procesos de facturación regulada y representa una de las referencias operativas más relevantes dentro del ciclo de medida de la distribuidora.
- Mensajería principal de Switching:
El proceso de switching se apoya en un conjunto de mensajes XML normalizados (protocolo CNMC v3.0) que permiten intercambiar información entre distribuidoras y comercializadoras siguiendo procedimientos definidos por la regulación sectorial. Entre los mensajes más habituales destacan:
Mensaje Finalidad A3 Altas de suministro C1 / C2 Cambios de comercializador o modificaciones asociadas M1 Modificaciones contractuales B1 Bajas de suministro La complejidad de estos procedimientos viene determinada no solo por la normativa aplicable, sino también por el elevado número de comercializadoras concurrentes que interactúan con la distribuidora. Udesa gestiona intercambios de información con más de 95 comercializadoras, lo que exige elevados niveles de automatización, trazabilidad y control de calidad en los sistemas de información.
Facturación F1: Un hito crítico del switching es la generación de facturas F1, que distingue entre:
- Series P (Peajes): ingresos por cargos regulados de acceso a red.
- Series C (Conceptos de obra): facturación por intervenciones técnicas, extensiones o nuevas instalaciones.
Esta distinción en el flujo de datos es fundamental para la correcta integración en el ERP y la contabilidad regulatoria.
- Datalake: Todo lo que se pueda meter en el Datalake, meterlo ahora "a cholón" (en grandes cantidades). Posteriormente se extraerá información de valor.
- Próximos pasos: En la siguiente sesión se entraría en detalle en los formatos de telegestión y switching. Se presentaría también un mapa de sistemas (dónde están los FTPs, con quién se comunican, cómo están securizados).
Conclusiones:
- El conocimiento de los formatos es importante para el equipo de desarrollo.
- El switching y la telegestión son las áreas con más volumen de datos e información.
- El Datalake es el repositorio central para toda la información de la distribuidora.
- Se necesita un mapa de sistemas para entender la arquitectura de comunicaciones.
Sesión 3: FTPs, Arquitectura de Sistemas y Gestión de Infraestructura
| Objetivo | Repasar los FTPs de medidas y switching, y plantear la necesidad de conocer la arquitectura de sistemas real |
| Ponente | Alejandro Torrado Quintela |
| Participantes | Ignacio Valverde Hernández, César Vicente Cabañas, Jesús Gábana de Vega, Pilar Rivas Pereiro |
Temas clave explicados:
- FTPs de medidas y switching: Repaso de los dos FTPs comentados en sesiones anteriores (medidas/telegestión y switching).
- Bajada al mundo real: Necesidad de pasar de la teoría normativa a la realidad de los sistemas: qué se tiene, cómo se trabaja, dónde está el FTP, qué servidores y máquinas virtuales existen.
- Arquitectura de sistemas:
- Udesa tiene un servidor y máquinas virtuales.
- ITELSIS es la empresa que gestiona el servidor y las máquinas virtuales.
- El equipo de la consultora debe tener capacidad de hablar con ITELSIS para solicitar máquinas virtuales, abrir puertos, integrar servicios, etc. (siempre con autorización previa).
- La arquitectura de sistemas condiciona la planificación y el diseño de cualquier solución.
- Dashboard de medidas: Se mencionó como ejemplo de desarrollo que requiere conocimiento de los sistemas existentes para saber dónde montarlo.
- Gestión por parte del equipo de consultoría: La idea es que el equipo gestione en parte los sistemas, con capacidad de solicitar recursos a ITELSIS.
- Próximas sesiones:
- Se necesitan 1-2 sesiones más.
- Temas pendientes: switching en detalle, mapa de sistemas, arquitectura real.
- Difícil agendar antes de septiembre por vacaciones.
Conclusiones:
- Hasta ahora todo ha sido teoría normativa; hace falta bajar a la arquitectura real de sistemas.
- El equipo de consultoría debe tener capacidad de gestión de infraestructura (coordinación con ITELSIS).
- La arquitectura de sistemas es clave para el diseño de cualquier solución.
- Se prevén sesiones adicionales en septiembre.
Sesión 4: Arquitectura de Sistemas — El Datalake "Panóptico"
| Objetivo | Presentar cómo está montada la arquitectura de sistemas de Udesa, partiendo del conocimiento de negocio ya adquirido en sesiones previas. El Datalake como elemento central. |
| Ponente | Alejandro Torrado Quintela |
| Participantes | Pilar Rivas Pereiro, Patricia Blázquez García, Daniel Zas Dacosta, Ignacio Valverde Hernández, David Lozano Núñez, Pablo Guerrica Echevarría Basterretxea, Iván Pardal Coca |
| Materiales | Presentación PowerPoint generada con Copilot. Alejandro se compromete a compartir todos los materiales y descripciones de procesos con el equipo. |
Temas clave explicados:
- Objetivo de la formación: Que el equipo tenga un conocimiento único del contexto de negocio y sistemas, de modo que al plantearse cualquier nuevo requisito o desarrollo se pueda hablar "con un conocimiento único" y evitar el coste de explicar el contexto en cada proyecto.
- Datalake "Panóptico": Nombre interno del Datalake. Su finalidad es "poder ver y acceder a cualquier dato". Es el elemento central de toda la arquitectura y la piedra angular de todos los desarrollos futuros.
- Transición arquitectónica: El objetivo es transicionar desde un modelo de varias plataformas propietarias separadas ("Vendor Lock-in" — dependencia de proveedores externos y centros de datos particionados) hacia un modelo centralizado en el Datalake. Todos los desarrollos futuros deben tener el Datalake como base.
- Independencia de proveedores: Reducir la dependencia de plataformas propietarias de terceros. Si un proveedor cambia su plataforma y no interesa a Udesa, la operativa queda "muy atada".
- Visión de aplicaciones propias: Disponer de desarrollos propios que den servicio a toda la operativa de Udesa. Cuanta más aplicación propia, mejor: hecha como interesa a Udesa, ciclo de vida gestionable y coste de mantenimiento menor que una licencia comercial.
- Neurophi (plataforma actual): Todos los procesos de facturación, gestión de contratación y switching se hacen con Neurophi (solución cloud, en sus servidores). Están contentos, pero dar servicio a Gayoso requiere otra licencia con coste extra. Con una aplicación propia sería inversión inicial pero mayor margen posterior.
- Ventaja y riesgo de terceros: Neurophi se adapta a cambios normativos automáticamente (ventaja), pero su adaptación puede no valer a Udesa o suponer un coste extra no previsto.
- Servicio a múltiples distribuidoras: Se da servicio a 3 distribuidoras: Mudesa, Guadiela y Gayoso. Varios procesos se hacen igual que en Udesa también con Gayoso.
- Actores del ecosistema: Clientes (abonados de red), comercializadoras (clientes de Udesa a quienes se factura), Udesa, y organismos reguladores: Red Eléctrica, Ministerio de Industria, Xunta y sobre todo la CNMC.
- Interoperabilidad y API-first: Los datos accesibles desde cualquier aplicación (Power BI, web, etc.), siempre a través de API. El Datalake tiene una API propia que deberá ampliarse.
- Capa proxy/bypass del Datalake (urgente): El Datalake debe actuar como proxy/bypass hacia cualquier API de terceros (Neurophi, Breo, etc.) a través de una sola IP. Simplifica control de accesos, políticas de seguridad y restricciones. Ya implementado para algunos endpoints de Neurophi.
- Gobernanza del dato: Diferenciar tipologías de datos (contratos, medidas, etc.) y permitir crecer a propio ritmo, sin depender de terceros.
- Soberanía del dato como principio estratégico: Uno de los principios tecnológicos que guía la evolución de la arquitectura de Udesa es la búsqueda de una mayor soberanía sobre sus datos y procesos críticos. La estrategia corporativa persigue reducir la dependencia de plataformas externas mediante la centralización de la información dentro del Datalake Panóptico y la creación progresiva de capacidades propias de integración, análisis y explotación de datos. Esta filosofía se materializa mediante:
- Centralización de la información corporativa.
- Uso de APIs gobernadas por Udesa.
- Integración directa de fuentes de datos propias.
- Control sobre la medida real de la red.
- Generación interna de informes regulatorios.
- Evolución hacia aplicaciones propias que reduzcan la dependencia tecnológica de terceros.
- Enfoque record-driven: El objetivo final de casi cualquier proceso TI es publicar información a alguien: informes a la CNMC (Excel/CSV vía cargador electrónico), informes a Red Eléctrica (vía concertador secundario), información a abonados (vía CRM), información a comercializadoras (vía FTP switching).
- SIPS: Informe mensual de cambios de comercializador por CUPS. Actualmente lo genera Neurophi y se sube manualmente a la CNMC. Objetivo: generarlo también desde el Datalake.
- Data Warehouse: Los datos del Datalake probablemente tendrán que moverse hacia un modelo más cohesionado (data warehouse) para extraer valor.
- Infraestructura física — 2 servidores: Servidor 1 (clásico): Windows Server, máquinas del Panóptico/Datalake (Pro, Pre, Gayoso), CRM preproducción, máquinas de desarrollo, Active Directory, telefonía IP. Servidor 2 (sala de telecontrol): control de la red física (transformadores, líneas, alarmas). Más crítico que el Datalake. Ambos gestionados por ITELSIS.
- Segmentación de red: Máquinas del Panóptico en una red, demás servicios en "red Core". FTP de telegestión + 300 concentradores en campo en red M2M de Telefónica (10.x.x.x). Redes visibles entre sí pero segmentadas por seguridad.
- Concentrador secundario: Aplicación en 3 máquinas. Recibe ficheros de medida de Neurophi y los publica a Red Eléctrica mediante un servidor web público. RE consulta cada minuto y descarga ficheros nuevos, devolviendo OK o BAD (validación de formato). Protocolo antiguo (~2001). Desarrollado por Alejandro. Usado por 10+ distribuidoras. Se quiere simplificar progresivamente.
- Valor estratégico del concentrador secundario: Aunque el concentrador secundario se apoya en tecnologías heredadas y protocolos históricos del sector eléctrico, su relevancia estratégica para Udesa es especialmente elevada. La compañía dispone de una infraestructura propia para la publicación de medidas eléctricas hacia los sistemas de Red Eléctrica, una capacidad que únicamente está presente en unas 9 entidades en España (principalmente las grandes eléctricas). Esto permite reportar directamente al SIMEL sin depender de concentradores de terceros (CIVE o Nexus), evitando riesgos operativos y sobrecostes de intermediación. Entre sus principales ventajas destacan:
- Control directo sobre los procesos de intercambio de medidas.
- Comunicación directa con los sistemas de Red Eléctrica (SIMEL).
- Reducción de la dependencia de plataformas intermediarias.
- Mayor capacidad de evolución tecnológica propia.
- Incremento de la soberanía sobre los datos generados por la actividad de distribución.
- Inventario de servicios: Panóptico (Pro, Pre, Gayoso), ERP (Odoo + Pymesoft antiguo), Active Directory, Terminal Server, FTPs (switching, telegestión), Bitwarden, máquina de firma de facturas Neurophi (certificado digital in-house), máquinas de desarrollo (Linux), concentrador secundario (3 máquinas), GIS de Traza.
- SCADA / Sismored: Gemelo digital de la red. Permite maniobras remotas y mide indicadores de calidad (TIEPI/NIEPI). Sistema esencial para la supervisión en tiempo real de la infraestructura de distribución.
- GISFE (Meter APP): Aplicación de gestión cartográfica y apoyo a lecturas manuales. Aproximadamente el 5% de los puntos de suministro no tienen telegestión y requieren lectura manual.
- Firma de facturas Neurophi: Neurophi envía facturas a una máquina de Udesa con certificado digital, se firman in-house y se devuelven. Así el certificado no sale de la infraestructura de Udesa.
- Criticidad de servicios: ESXi (crítica), Panóptico (crítica, creciente), FTP switching (alta, casi crítica — 95 comercializadoras llaman), CRM (alta — 3000 abonados), FTP telegestión (alta, recuperable), ERP (media), SharePoint/365 (media), concentrador (baja).
- Mapa de integraciones: CRM → Panóptico (todo lo que entra por CRM acaba en el Datalake), ERP → Datalake, Neurophi → Datalake (vía API), Traza → Datalake. FTP telegestión → Panóptico: NO INTEGRADO (brecha clave). Comercializadoras → Switching FTP. Concentrador → SIMEL (Red Eléctrica).
- Medida real vs facturada: La medida real (cruda del FTP de telegestión) no está integrada en el Datalake. Neurophi la procesa (procedimiento P.10.5) y devuelve la facturada (siempre "completa", rellena huecos). La real tiene huecos y es lo que realmente leyó el contador. Se necesita la real para: mostrarla en el CRM, terceros proveedores, control de calidad, mapas de calor de conectividad.
- Procedimiento P.10.5: Procedimiento de estimación de medida descrito en un BOE de 120 páginas. Si faltan 2 horas: interpolación. Si falta más: estimación por coeficientes. Si falta curva completa: estimación por histórico. Lo hace Neurophi (antes Datacenter, mal). Udesa tiene conocimiento teórico pero nunca lo implementó. No es prioridad inmediata.
- Necesidad de medida real (caso UTE): Hace 2 meses, en una UT con otras empresas, un partner pidió acceso a la medida cruda. No se pudo dar fácilmente. Neurophi no la da real, Breo tampoco. Solo está en el FTP de telegestión. Decisión: integrar el FTP de telegestión directamente en el Datalake (origen más fiable, infraestructura propia, protocolo estable).
- Power BI y explotación de datos (workaround actual): Power BI no se conecta directamente al API del Datalake (problema de paginación). Solución intermedia: scripts Bash/Python en cada máquina generan CSVs diariamente vía cron. Un cliente Python consulta endpoints del Datalake. Los CSVs se recogen vía SCP/RSync y se depositan en una carpeta de SharePoint ("central de datos"). Power BI lee de esa carpeta. Sirve como control de operatividad e informes ad-hoc.
- Streamlit app: Alejandro creó una interfaz en Streamlit (con 3 prompts a IA) para operar la aplicación de recolección de CSVs. Puede servir como prototipo/referencia para futuras capas de visualización o ETL intermedio.
- SharePoint "central de datos": Carpeta de SharePoint donde se depositan CSVs generados por scripts + informes descargados de aplicaciones. Contiene datos que aún no están en el Datalake. Objetivo: eliminar este paso intermedio en el futuro; todo debería estar centralizado en el API del Datalake.
- Flujo maestro de datos: Desde que alguien pide un suministro nuevo (alta en CRM) → asignación de CUPS → contrato con comercializador (switching) → validación (potencia vs acometida) → activación → lectura de medida (telegestión → FTP) → Neurophi facturación → FTP switching (comercializador) + CRM (abonado) + concentrador secundario (Red Eléctrica).
- Tipos de contrato: ATR (alta de suministro, entre abonado y distribuidor, en CRM) y suministro (entre abonado y comercializador, mercado libre). Los contratos de suministro llegan vía switching.
- Nueva circular CNMC (febrero 2026): Requiere mostrar más información a los abonados en el CRM y mayor capacidad de comunicación distribuidor-abonado. El usuario debe poder acceder a su lectura real en cualquier momento. Deadline era junio 2026 (no cumplido). Necesita desarrollos específicos integrados con el Datalake. Reunión monográfica la semana siguiente.
- Prioridades actuales: 1) CRM — cambios por Real Decreto de febrero 2026 (urgente, deadline pasado). 2) Medida real integrada en el Datalake (desde FTP de telegestión). 3) Dashboard/Power BI — prioridad personal de Alejandro, no de la empresa.
- MQTT: Hay un servidor MQTT que recibe datos de campo. Se explota de forma muy básica (mirar mensajes en Mosquitto). Pendiente de integrar en el Datalake.
- Bitwarden: Gestor de contraseñas usado por el equipo. Cada miembro tiene cuenta.
- Traza (GIS): Aplicación de trazas. A-Plus despliega su aplicación en el servidor de Udesa (on-premise). Gayoso usa Traza en cloud (traza.plus.es).
- Próximas sesiones: Sesión la semana siguiente (media hora) para demo del dashboard/Power BI y aplicación de recolección. Reunión separada para el proyecto del CRM (Real Decreto). Sesión específica de switching cuando se vaya a desarrollar algo concreto.
Conclusiones:
- El Datalake "Panóptico" es el eje de la estrategia arquitectónica: centralización, interoperabilidad via API, gobernanza del dato y proxy/bypass de APIs de terceros.
- La dirección es clara: transicionar hacia aplicaciones propias que sustituyan progresivamente a Neurophi, empezando por la generación de informes regulatorios.
- La integración del FTP de telegestión (medida real) en el Datalake es el siguiente desarrollo grande, ligado a los cambios del CRM por el Real Decreto de febrero 2026.
- El workaround actual de Power BI (scripts → CSV → SharePoint) funciona pero debe sustituirse por acceso directo al Datalake.
- La infraestructura física se compone de 2 servidores (TI y telecontrol) gestionados por ITELSIS, con segmentación de red por seguridad.
- El concentrador secundario es una aplicación legacy que se quiere simplificar progresivamente.
- Prioridad 1: CRM (Real Decreto). Prioridad 2: medida real en Datalake.
5. Glosario de Términos Propios de Udesa
| Término / Sigla | Definición |
|---|---|
| Udesa | Unión Distribuidora Eléctrica, S.A. Empresa gallega de distribución de energía eléctrica en la provincia de A Coruña. |
| Multiservicios | Empresa vinculada a Udesa creada para diversificar ingresos y mantener la plantilla. Udesa contrata con Multiservicios el desarrollo de sistemas. |
| Enerse / Multiservicios Udesa | Empresa que tiene a Udesa como cliente principal. Es la que da servicio a la distribuidora. Difícil de distinguir de Udesa en el día a día. |
| Udesa | Distribuidora eléctrica a la que se da servicio. |
| Guadiela | Distribuidora eléctrica a la que se da servicio, además de a Udesa. |
| Gayoso | Distribuidora eléctrica a la que recientemente se ha empezado a dar servicio. Varios procesos se hacen igual que en Udesa. |
| CNMC | Comisión Nacional de los Mercados y la Competencia. Organismo regulador del sector eléctrico español. Es el que más regula a Udesa. |
| Red Eléctrica / REE | Red Eléctrica de España. Operador del sistema eléctrico. Define formatos de ficheros homologados que las distribuidoras deben usar. |
| Telegestión | Sistema de lectura y gestión remota de contadores eléctricos. Usa XMLs con formato establecido intercambiados por FTP, regulado por la CNMC. |
| Switching | Proceso de cambio de comercializador por parte de un cliente. Se realiza mediante ficheros XML (tipo C1) intercambiados por FTP entre el comercializador y el distribuidor. Regulado por la CNMC. |
| FTP / FTPs | Canales de intercambio de ficheros XML entre actores del sector eléctrico. Udesa tiene al menos dos FTPs: uno de telegestión/medidas y otro de switching. |
| C1 | Tipo de fichero XML para solicitudes de cambio de comercializador en el proceso de switching. |
| Datalake | Repositorio centralizado de datos de Udesa. Actualmente agnóstico: recopila y almacena datos. Objetivo: meter toda la información posible y posteriormente extraer valor. |
| Panóptico | Nombre interno del Datalake de Udesa. Su finalidad es "poder ver y acceder a cualquier dato". Es el elemento central de la arquitectura de sistemas. |
| OT | Órdenes de Trabajo. Sistemas que están en campo, muy distribuidos, que necesitan ser centralizados y cohesionados. |
| ITELSIS | Empresa externa que gestiona el servidor y las máquinas virtuales de Udesa. La consultora debe coordinarse con ellos para solicitar recursos de infraestructura. |
| CRM | Sistema de gestión de relaciones con clientes ya desarrollado para Udesa (página web de área de clientes). |
| ERP | Sistema de planificación de recursos empresariales ya desarrollado para Udesa. Tiene mucha historia y muchas características específicas. |
| Pliego | Documento administrativo mediante el cual se otorgan territorios de distribución eléctrica. No acota plazo de duración de forma clara. |
| Retribución | Ingreso regulado que recibe Udesa por su actividad de distribución. La CNMC controla cada vez más la retribución. |
| Dashboard de medidas | Panel de visualización de lecturas/medidas de contadores. Mencionado como ejemplo de desarrollo que requiere conocimiento de la arquitectura de sistemas. |
| Parseo | Proceso de lectura e interpretación automática de ficheros XML en la plataforma de gestión de switching. |
| Mapa de sistemas | Representación de la arquitectura de sistemas de Udesa: dónde están los FTPs, con quién se comunican, cómo están securizados. Pendiente de presentar. |
| NeuroPhi | Plataforma propietaria de terceros usada actualmente por Udesa para facturación, gestión de contratación y switching. Están satisfechos con el servicio, pero cada nueva distribuidora requiere una licencia adicional. La estrategia es sustituirla progresivamente por desarrollos propios. |
| SIPS | Sistema de Información de Puntos de Suministro. Informe mensual de cambios de comercializador por CUPS. Actualmente lo genera Neurophi y se sube manualmente a la CNMC. Objetivo: generarlo también desde el Datalake. |
| CUPS (Código Universal de Punto de Suministro) | Identificador único e invariable de un punto de suministro eléctrico. Actúa como clave principal para relacionar información geográfica, técnica, contractual y de medida. Constituye uno de los activos de información más relevantes de la distribuidora y es la referencia principal utilizada en procesos de contratación, switching, facturación, regulación y explotación de datos. |
| Concertador secundario | Canal a través del cual Udesa envía informes y datos a Red Eléctrica de España. |
| Data Warehouse | Modelo de datos más cohesionado hacia el que se prevé mover los datos del Datalake para extraer valor. |
| API | Interfaz de programación de aplicaciones. El Datalake debe tener una API propia y actuar como proxy de APIs de terceros. Preferible siempre integrarse vía API. |
| Proxy / Bypass | Capa del Datalake que permite redirigir peticiones a APIs de terceros (Neurophi, Breo, etc.) a través de una sola IP. Simplifica el control de accesos de proveedores externos. Ya implementado para algunos endpoints de Neurophi. |
| Record-driven | Enfoque arquitectónico basado en que el objetivo final de casi cualquier proceso TI de la distribuidora es generar y publicar un informe o datos a alguien (CNMC, Red Eléctrica, abonados, comercializadoras). |
| Microsoft 365 | Suite ofimática en cloud usada por Udesa. Fundamental para la operativa diaria. |
| SharePoint / OneDrive | Plataformas de Microsoft usadas por Udesa para almacenar y gestionar la documentación. En proceso de migración. |
| Circular CNMC febrero 2026 | Nueva normativa que requiere mostrar más información a los abonados en el CRM y mayor capacidad de comunicación entre distribuidor y abonado. Necesitará desarrollos específicos y afectará al Datalake. |
| S0.4 / S0.5 | Tipos de ficheros de medida del FTP de telegestión. |
| Breo | Plataforma de terceros mencionada como ejemplo de API a integrar a través del proxy del Datalake. |
| Concentrador secundario | Aplicación en 3 máquinas que publica ficheros de medida a Red Eléctrica. Recibe ficheros de Neurophi, los publica vía web server público. RE consulta cada minuto. Protocolo antiguo (~2001). Desarrollado por Alejandro. Usado por 10+ distribuidoras. Se quiere simplificar. |
| SIMEL | Sistema de Medidas Eléctricas de Red Eléctrica. Canal por el que RE consulta y descarga los ficheros publicados por el concentrador secundario. |
| ESXi / VMware | Hipervisor que gestiona todas las máquinas virtuales de Udesa. Servicio crítico: si cae, todas las máquinas quedan inaccesibles. Gestionado por ITELSIS. |
| Red Core | Segmento de red donde están la mayoría de servicios TI (Windows Server, VoIP, FTPs, etc.). Distinta de la red del Panóptico y de la red M2M de telegestión. |
| Red M2M | Red de Telefónica (10.x.x.x) donde están los 300 concentradores de campo y el FTP de telegestión. Diferenciada por seguridad. |
| Bitwarden | Gestor de contraseñas usado por el equipo de Udesa. Cada miembro tiene cuenta. |
| Odoo | ERP actual de Udesa. Sustituyó a Pymesoft. |
| Pymesoft | ERP antiguo de Udesa, aún en una máquina para acceso a datos históricos. |
| P.10.5 | Procedimiento de estimación de medida descrito en un BOE de 120 páginas. Interpolación y estimación de huecos en curvas de consumo. Lo hace Neurophi (antes Datacenter, mal). Udesa tiene conocimiento teórico pero no lo implementó. |
| Medida real / cruda | Lectura tal cual la lee el contador, con huecos e incompleta. Está en el FTP de telegestión (XML S0.2, S0.4, S0.5). No está integrada en el Datalake. Neurophi la procesa y devuelve la facturada (completa). |
| Medida facturada | Medida procesada por Neurophi aplicando el procedimiento P.10.5 (rellena huecos, estima faltantes). Es la que se usa para facturación y publicación a Red Eléctrica. |
| ATR | Alto de Suministro. Contrato entre abonado y distribuidor, gestionado en el CRM. |
| Contrato de suministro | Contrato entre abonado y comercializador (mercado libre). Llega a Udesa vía switching. |
| Datacenter | Proveedor anterior de servicios de facturación y estimación de medida. Sustituido por Neurophi. También envía ficheros al concentrador secundario para otras distribuidoras. |
| Streamlit | Framework Python usado por Alejandro para crear una interfaz web de la aplicación de recolección de CSVs. Hecha con 3 prompts a IA. |
| SharePoint "central de dato" | Carpeta de SharePoint donde se depositan CSVs generados por scripts + informes descargados de aplicaciones. Contiene datos que aún no están en el Datalake. Power BI lee de ahí. |
| MQTT / Mosquitto | Protocolo de mensajería ligero. Hay un servidor MQTT que recibe datos de campo. Se explota de forma muy básica. Pendiente de integrar en el Datalake. |
| A-Plus | Empresa que desarrolla Traza (GIS). Despliega su aplicación en el servidor de Udesa (on-premise). Gayoso usa Traza en cloud. |
| Sala de telecontrol | Sala con pantallas de control de la red física (transformadores, líneas, alarmas). Servidor crítico separado del de TI. Gestionado por ITELSIS. |
6. Prioridades de Udesa hacia Sixtema
A partir de las declaraciones explícitas de Alejandro en las cuatro sesiones, se extrae el siguiente listado de necesidades ordenadas por prioridad. Las citas literales se incluyen para preservar la trazabilidad.
CRM: cambios por Real Decreto de febrero 2026 URGENTE — deadline junio 2026 no cumplido
▼"Para mí me preocupa más ahora mismo lo que hay que hacer en el CRM a raíz de este real decreto." (Sesión 4, min 1:14:21)
"El Real Decreto nos obligaba a tener ya esos cambios hechos en junio. Que no los tenemos." (Sesión 4, min 1:14:13)
Qué necesita: Desarrollos en el CRM para mostrar más información a los abonados (incluida la lectura real del contador) y mayor capacidad de comunicación distribuidor-abonado. Todo debe pasar por el Datalake.
Requisitos relacionados: REQ-042, REQ-043, REQ-046, REQ-047
Integración de la medida real (FTP telegestión) en el Datalake Alta
▼"Me preocupa más que la medida esté integrada de alguna forma. Y que sea usable por nosotros." (Sesión 4, min 1:14:21)
"Yo diría de atacar siempre a ese origen [FTP de telegestión]. Es más complejo, sí, más fiable también." (Sesión 4, min 1:19:49)
Qué necesita: Parsear los XML S0.2, S0.4, S0.5 del FTP de telegestión, señalizarlos y meterlos en el Datalake. Accesible vía API. Atacar al FTP directamente (no vía Breo/Neurophi) porque es el origen más fiable y propio.
Requisitos relacionados: REQ-046, REQ-047, REQ-056
Capa proxy/bypass del Datalake (primera fase) Alta
▼"Una primera necesidad que vamos a dar con Data Lake es que este pueda replicar como una especie de proxy... es básicamente un bypass." (Sesión 4, min 0:69)
"Data Lake, primera fase o digamos la más inmediata, eso replicar... centralizar el acceso a las demás APIs." (Sesión 4, min 1:18:11)
Qué necesita: Una capa en el Datalake que actúe como proxy/bypass hacia APIs de terceros (Neurophi, Breo) a través de una sola IP. Ya está hecho parcialmente para algunos endpoints de Neurophi.
Requisitos relacionados: REQ-033, REQ-034
Coordinación con ITELSIS y gestión de infraestructura Media
▼"Mi idea es que en parte los gestionéis vosotros. Imaginaos, si le hace falta una máquina virtual... que tengáis la capacidad también de hablar con ITELSIS." (Sesión 3, min 1:30:28)
"Esa arquitectura de sistemas es importante porque de eso también depende mucho de la planificación y el diseño de cualquier solución." (Sesión 3, min 1:30:48)
Qué necesita: Que el equipo de Sixtema tenga capacidad de solicitar recursos a ITELSIS (máquinas virtuales, abrir puertos, integraciones) con autorización de Udesa. Conocimiento de la arquitectura para planificar y diseñar soluciones.
Requisitos relacionados: REQ-053, REQ-054
Integración de más fuentes de datos en el Datalake Media
▼"Todo lo que se pueda meter en Datalake, ahí por lo menos meterlo ahora así a Cholón." (Sesión 2, min 1:13:09)
"Siempre va a haber de repente una nueva origen de datos y habrá que meterlo en el Datalake." (Sesión 4, min 1:20:29)
Qué necesita: Además del FTP de telegestión (Prioridad 2), integrar otras fuentes: MQTT (datos de campo), y cualquier nuevo origen que surja. El Datalake debe ser la centralización de toda la información.
Requisitos relacionados: REQ-001, REQ-051
Generación de informes regulatorios desde el Datalake Media
▼"Yo quiero generar ese informe aparte de que me lo de en euro... primero para ver qué funciona y después porque oye, pues en algún momento, si prescindimos de Neurophi, podemos hacerlo igual nosotros." (Sesión 4, min 0:90)
Qué necesita: Capacidad de generar informes regulatorios (SIPS para CNMC, informes para Red Eléctrica) directamente desde el Datalake, como alternativa a descargarlos de Neurophi. Primero para validar, después como sustitución progresiva.
Requisitos relacionados: REQ-040, REQ-041
Acceso directo de Power BI al Datalake (eliminar workaround) Media
▼"Todo debería estar centralizado en el API del data lake." (Sesión 4, min 1:21:10)
"El objetivo es que el Datalake tenga toda la información y luego poder desarrollar cosas para explotarla." (Sesión 4, min 1:20:29)
Qué necesita: Eliminar el workaround actual (scripts → CSV → SharePoint → Power BI). El API del Datalake tiene paginación que dificulta la conexión directa desde Power BI. Habrá que desarrollar una aplicación web o capa intermedia que permita explotar los datos del Datalake de forma eficiente.
Requisitos relacionados: REQ-049, REQ-055
Dashboard unificado de control de servicios Baja — prioridad personal
▼"El dashboard lo hago para mí. Entonces no es una prioridad para la empresa. Para mí sí, y lo hago yo." (Sesión 4, min 1:14:21)
"Mi idea es llegar cada día, abrir un dashboard y ver dónde está en rojo. Ese es mi ideal de trabajo." (Sesión 4, min 1:11:54)
Qué necesita: Un dashboard que muestre el estado de todos los servicios (FTPs, Datalake, CRM, concentrador) con KPIs operativos (ficheros recibidos, servicios activos). Incluir Zabbix, Nagios, Airflow. Alejandro ya tiene un prototipo en Power BI. No es prioridad para la empresa.
Requisitos relacionados: REQ-055
Switching en detalle Baja — futuro
▼"El switching... compensa verlo cuando vaya a hacerse algo en concreto con ello." (Sesión 4, min 1:11:36)
Qué necesita: Sesión específica de switching cuando haya un desarrollo concreto que hacer. No es prioritario ahora, pero será necesario cuando se acometa un proyecto de switching.
Requisitos relacionados: REQ-014 a REQ-020
Sesión demo de dashboard/Power BI Formativa — próxima semana
▼"Hacemos otra sesión... la semana que viene si queréis hacemos una sesión. A lo mejor en media hora lo podemos ver." (Sesión 4, min 1:21:34)
Qué necesita: Sesión de ~30 minutos para enseñar la aplicación de recolección de CSVs, el dashboard de Power BI y el workaround actual. Compartirá el código en Git. Es formativa, no es un desarrollo.
Resumen ejecutivo
| # | Necesidad | Urgencia | Requisitos | Origen |
|---|---|---|---|---|
| 1 | CRM — Real Decreto febrero 2026 | Urgente | REQ-042, 043, 046, 047 | Sesión 4 |
| 2 | Medida real (FTP telegestión) en Datalake | Alta | REQ-046, 047, 056 | Sesiones 2, 3, 4 |
| 3 | Proxy/bypass del Datalake | Alta | REQ-033, 034 | Sesión 4 |
| 4 | Coordinación con ITELSIS | Media | REQ-053, 054 | Sesiones 3, 4 |
| 5 | Integración más fuentes en Datalake | Media | REQ-001, 051 | Sesiones 2, 4 |
| 6 | Informes regulatorios desde Datalake | Media | REQ-040, 041 | Sesión 4 |
| 7 | Power BI acceso directo a Datalake | Media | REQ-049, 055 | Sesión 4 |
| 8 | Dashboard unificado de control | Baja | REQ-055 | Sesiones 3, 4 |
| 9 | Switching en detalle | Baja | REQ-014–020 | Sesiones 2, 4 |
| 10 | Sesión demo dashboard | Formativa | — | Sesión 4 |
7. Conocimiento de negocio imprescindible para futuros desarrollos
Las sesiones de formación han puesto de manifiesto que el éxito de los futuros desarrollos tecnológicos depende tanto del conocimiento técnico como de la comprensión del negocio de distribución eléctrica. Los siguientes conceptos constituyen la base mínima de conocimiento recomendada para cualquier miembro que participe en proyectos relacionados con Udesa.
Aspectos fundamentales
▼- Diferencia entre distribuidora eléctrica y comercializadora.
- Papel regulador de la CNMC y Red Eléctrica.
- Importancia estratégica del CUPS como identificador único.
- Funcionamiento de la telegestión y de la calidad de medida.
- Procesos de switching entre distribuidoras y comercializadoras.
- Gestión de la medida real frente a la medida facturada.
- Función del concentrador secundario dentro del ecosistema eléctrico.
- Arquitectura basada en el Datalake Panóptico.
- Gobernanza y soberanía del dato.
- Requisitos regulatorios asociados a la actividad de distribución.
- Diseño de soluciones multi-distribuidora para Udesa, Guadiela y Gayoso.
Conclusión
▼La estrategia tecnológica de Udesa no persigue únicamente desarrollar nuevas aplicaciones, sino construir una plataforma de información capaz de soportar de forma sostenible la operación de varias distribuidoras eléctricas, garantizando el cumplimiento regulatorio, la calidad del dato y la independencia tecnológica a largo plazo.
8. Próximos Pasos
- Recibir materiales de la sesión 4: Alejandro se compromete a compartir el PowerPoint y las descripciones de procesos.
- Sesión demo de dashboard/Power BI (semana del 15-19 sept): Media hora. Alejandro enseñará la aplicación de recolección de CSVs, el dashboard de Power BI y cómo funciona el workaround actual. Compartirá el código (Git).
- Reunión monográfica CRM (Real Decreto febrero 2026): Cambios del CRM para mostrar lectura real al abonado. Integración con el Datalake. Análisis de requisitos. Prioridad 1.
- Integración FTP telegestión en Datalake: El siguiente desarrollo grande. Medida real (XML S0.2, S0.4, S0.5) debe integrarse en el Datalake para ser accesible y explotable. Ligado a los cambios del CRM.
- Switching en detalle: Sesión específica cuando se vaya a desarrollar algo concreto con switching.
- Coordinación con ITELSIS: El equipo de consultoría debe establecer el canal de comunicación con ITELSIS para la gestión de infraestructura.
- Definición de backlog: A partir de los requerimientos extraídos (ver sección de Requerimientos TIC), priorizar y planificar los desarrollos.
- Reunión de validación: Aclarar los puntos abiertos identificados en el documento de requerimientos.
- Validación del contenido: Confirmar con Udesa que no se ha omitido ningún requerimiento en los tramos no transcritos de las sesiones 1-3 (ver PA-10). La sesión 4 ya está completamente transcrita.
Requerimientos Funcionales TIC
Backlog Inicial Udesa
Matriz de Requerimientos
| ID | Módulo / Área | Funcionalidad / Requerimiento | Tipo | Sesión | Prioridad |
|---|---|---|---|---|---|
| REQ-001 | Datalake | Centralización de todos los datos de los procesos básicos de distribución en un repositorio único ("Panóptico"). Recopilación y almacenamiento masivo de datos provenientes de telegestión, switching, medidas y otros sistemas. El Datalake es el elemento central de la arquitectura. | Funcional | 1, 2, 4 | Alta |
| REQ-002 | Datalake | Mecanismos de extracción de información y valor a partir de los datos almacenados en el Datalake (BI, dashboards, informes). | Funcional | 2 | Media |
| REQ-003 | Telegestión | Recepción y procesamiento de ficheros XML de telegestión vía FTP, con formato establecido y regulado por la CNMC. | Funcional | 2 | Alta |
| REQ-004 | Telegestión | Validación de formato y control de calidad de los ficheros XML de telegestión según normativa CNMC. | Regulatorio | 1, 2 | Alta |
| REQ-005 | Switching | Recepción y procesamiento de ficheros XML de switching vía FTP, con formato establecido y regulado por la CNMC. Incluye ficheros tipo C1 (cambio de comercializador). | Funcional | 2 | Alta |
| REQ-006 | Switching | Plataforma de gestión de switching con parseo automático de XML y tramitación procedimentada de solicitudes entre comercializador y distribuidor. | Funcional | 2 | Alta |
| REQ-007 | Switching | Validación de formato y control de calidad de los ficheros XML de switching según normativa CNMC. | Regulatorio | 2 | Alta |
| REQ-008 | Switching | Gestión del catálogo de tipos de mensajes XML de switching (C1 y otros) con campos definidos por la CNMC. | Funcional | 2 | Media |
| REQ-009 | Integración CNMC | Cumplimiento de procedimientos estandarizados definidos por la CNMC para todos los procesos de distribuidora. | Regulatorio | 1, 2 | Alta |
| REQ-010 | Integración CNMC | Generación y envío de informes regulatorios requeridos por la CNMC (auditorías, control, supervisión). | Regulatorio | 1 | Alta |
| REQ-011 | Integración Red Eléctrica | Soporte de formatos de ficheros homologados por Red Eléctrica de España (REE) para intercambio de información. | Integración | 1 | Alta |
| REQ-012 | Gestión de OT | Centralización y cohesión de sistemas de campo (Órdenes de Trabajo) distribuidos geográficamente. | Funcional | 1 | Media |
| REQ-013 | Dashboard de Medidas | Desarrollo de dashboard de visualización de medidas/lecturas de contadores, integrado con los sistemas existentes. | Funcional | 3 | Media |
| REQ-014 | Arquitectura de Sistemas | Elaboración de mapa de sistemas: localización de FTPs, flujos de comunicación entre sistemas, securización de canales. | No Funcional | 2, 3 | Alta |
| REQ-015 | Arquitectura de Sistemas | Capacidad de gestión de infraestructura: solicitud de máquinas virtuales, apertura de puertos e integración de servicios mediante coordinación con ITELSIS (con autorización previa de Udesa). | No Funcional | 3 | Alta |
| REQ-016 | Arquitectura de Sistemas | Documentación de la arquitectura real: servidores, máquinas virtuales, ubicación de FTPs y servicios existentes. | No Funcional | 3 | Alta |
| REQ-017 | Digitalización y Automatización | Automatización de procesos manuales de la distribuidora para reducir costes de estructura y personal. | Funcional | 1 | Alta |
| REQ-018 | Control de Calidad | Implementación de validación y control de calidad en paralelo a lo que marca la normativa para todos los desarrollos nuevos. | No Funcional | 1 | Alta |
| REQ-019 | CRM (Evolución) | Mantenimiento y evolución del CRM existente (área de clientes web) con nuevas funcionalidades específicas de distribuidora. | Funcional | 1 | Media |
| REQ-020 | ERP (Evolución) | Mantenimiento y evolución del ERP existente, que tiene muchas características específicas y historia acumulada. | Funcional | 1 | Media |
| REQ-021 | Portal de Clientes | Área de clientes web con funcionalidades específicas de distribuidora (ya existente, pendiente de evolución). | Funcional | 1 | Media |
| REQ-022 | Gestión de Retribución | Seguimiento y control de la retribución regulada por la CNMC, incluyendo los costes de estructura y personal. | Regulatorio | 1 | Media |
| REQ-023 | Multiservicios | Soporte de la facturación y retribución entre Udesa y Multiservicios para desarrollo de sistemas y servicios. | Funcional | 1 | Baja |
| REQ-024 | Formatos XML | Conocimiento y soporte de todos los formatos XML homologados (telegestión y switching) con campos definidos por la CNMC. | Integración | 2 | Alta |
| REQ-025 | FTP / Comunicaciones | Gestión y monitorización de los FTPs regulados (telegestión y switching) con securización de canales. | No Funcional | 2, 3 | Alta |
| REQ-026 | Procesos de Distribuidora | Desarrollo de funcionalidades específicas de procesos de distribuidora que sustituyan los desarrollos estándar actuales. | Funcional | 1 | Alta |
| REQ-027 | Gestión de Infraestructura | Interfaz/procedimiento para que el equipo de consultoría pueda solicitar recursos a ITELSIS (máquinas virtuales, puertos, integraciones) con autorización de Udesa. | No Funcional | 3 | Alta |
| REQ-028 | Dimensionamiento de Proyectos | Capacidad de dimensionar correctamente los desarrollos (ni extralimitarse ni quedarse cortos) basándose en el conocimiento de negocio y sistemas. | No Funcional | 3 | Media |
| REQ-029 | Multi-distribuidora | Soporte multi-distribuidora: los desarrollos deben poder servir para múltiples distribuidoras (Udesa, Guadiela, Gayoso), no solo para Udesa. Varios procesos se replican entre distribuidoras. | Funcional | 4 | Alta |
| REQ-030 | Arquitectura de Sistemas | Transición desde plataformas propietarias separadas hacia un modelo centralizado en el Datalake "Panóptico". Reducción de la dependencia de proveedores terceros para evitar que la operativa quede atada a aplicaciones que no se controlan. | No Funcional | 4 | Alta |
| REQ-031 | Arquitectura de Sistemas | Principio rector: cualquier dato que afecte a los procesos básicos de la distribución debe estar centralizado en el Datalake. | No Funcional | 4 | Alta |
| REQ-032 | Materiales y Documentación | Recepción y catalogación de los materiales formativos (PowerPoint, descripciones de procesos) que Alejandro Torrado se compromete a compartir con el equipo. Estos materiales cubren el contenido de la sesión 4 no transcrito. | No Funcional | 4 | Alta |
| REQ-033 | Datalake | Capa proxy/bypass en el Datalake que permita redirigir peticiones a APIs de terceros (Neurophi, Breo, etc.) a través de una sola IP (la del Datalake). Simplifica el control de accesos, políticas de seguridad y restricciones de proveedores externos. Ya implementado parcialmente para algunos endpoints de Neurophi. | Funcional | 4 | Alta |
| REQ-034 | Datalake | API propia del Datalake con endpoints específicos para integración con cualquier plataforma. Ampliación progresiva según necesidades. Preferible siempre integrarse vía API. | Funcional | 4 | Alta |
| REQ-035 | Datalake | Interoperabilidad: los datos del Datalake deben ser accesibles desde cualquier aplicación que interese en cada momento (Power BI, aplicación web, etc.) para operar con ellos (consultar, dar de alta/baja, etc.). | Funcional | 4 | Alta |
| REQ-036 | Datalake | Gobernanza del dato: capacidad de diferenciar tipologías de datos (contratos, medidas, etc.) y permitir crecer a propio ritmo sin depender de terceros. | No Funcional | 4 | Alta |
| REQ-037 | Datalake | Evolución hacia un Data Warehouse: mover los datos del Datalake hacia un modelo de datos más cohesionado para extraer valor. | Funcional | 4 | Media |
| REQ-038 | Aplicaciones Propias | Desarrollo de aplicaciones propias que sustituyan progresivamente a plataformas propietarias de terceros (Neurophi). Objetivo: dar servicio integral a cualquier distribuidora sin depender de licencias comerciales. | Funcional | 4 | Alta |
| REQ-039 | Aplicaciones Propias | Sustitución progresiva de procesos de Neurophi por desarrollos propios basados en el Datalake, empezando por la generación de informes regulatorios. Mantener Neurophi en paralelo durante la transición. | Funcional | 4 | Alta |
| REQ-040 | Informes Regulatorios | Generación propia del informe SIPS (Sistema de Información de Puntos de Suministro) desde el Datalake: informe mensual de cambios de comercializador por CUPS. Actualmente lo genera Neurophi y se sube manualmente a la CNMC. | Funcional | 4 | Alta |
| REQ-041 | Informes Regulatorios | Capacidad de generar cualquier informe regulatorio (CNMC, Red Eléctrica) desde el Datalake, independientemente de plataformas de terceros. Enfoque record-driven: el objetivo final de cualquier proceso TI es publicar información. | Funcional | 4 | Alta |
| REQ-042 | CRM (Evolución) | Evolución del CRM según nueva circular CNMC de febrero 2026: mostrar más información a los abonados y aumentar la capacidad de comunicación entre distribuidor y abonado. La información a mostrar debe venir del Datalake. | Funcional | 4 | Alta |
| REQ-043 | CRM (Evolución) | Visualización de curvas de consumo de los abonados en el CRM, cargadas en formato CNMC. Evolución hacia datos provenientes del Datalake. | Funcional | 4 | Media |
| REQ-044 | Infraestructura Cloud | Migración y mantenimiento de la ofimática a Microsoft 365 y de la documentación a SharePoint/OneDrive. | No Funcional | 4 | Baja |
| REQ-045 | Arquitectura de Sistemas | Mapa general de arquitectura de Udesa: cloud (Microsoft 365, SharePoint), página web, CRM, Neurophi, Datalake, FTPs. Identificación de todas las áreas y servicios. | No Funcional | 4 | Alta |
| REQ-046 | Datalake (Medida) | Integración del FTP de telegestión (medida real/cruda, XML S0.2, S0.4, S0.5) en el Datalake. Los XML deben parsearse, señalizarse y ser accesibles vía API. Es el siguiente desarrollo grande del Datalake. | Funcional | 4 | Alta |
| REQ-047 | Datalake (Medida) | Acceso a medida real (cruda, con huecos) para terceros proveedores y partners (ej. UTE). La medida real no está actualmente en el Datalake; Neurophi la procesa y devuelve la facturada (completa). | Funcional | 4 | Alta |
| REQ-048 | Concentrador Secundario | Simplificación progresiva del concentrador secundario (aplicación legacy ~2001, 3 máquinas) hacia un servicio web puro. Actualmente publica ficheros de medida a Red Eléctrica (SIMEL). | Funcional | 4 | Media |
| REQ-049 | Datalake (Power BI) | Acceso directo de Power BI al API del Datalake, eliminando el workaround actual (scripts → CSV → SharePoint). El API tiene paginación que dificulta la conexión directa desde Power BI. | Funcional | 4 | Media |
| REQ-050 | Medida (Estimación) | Conocimiento y capacidad propia para ejecutar el procedimiento P.10.5 (estimación de medida, BOE 120 páginas). Actualmente lo hace Neurophi. No es prioridad inmediata, pero necesario para independencia futura. | Funcional | 4 | Baja |
| REQ-051 | Datalake (IoT) | Integración del servidor MQTT (datos de campo) en el Datalake. Actualmente se explota de forma muy básica (Mosquitto). | Funcional | 4 | Baja |
| REQ-052 | Seguridad (Firma) | Mantenimiento de la firma digital de facturas in-house (certificado digital no sale de la infraestructura de Udesa). Neurophi envía facturas, se firman en máquina propia y se devuelven. | No Funcional | 4 | Media |
| REQ-053 | Infraestructura (Red) | Segmentación de red por seguridad: red Core (servicios generales), red Panóptico (Datalake), red M2M (telegestión, 300 concentradores vía Telefónica). Mantener y documentar la segmentación. | No Funcional | 4 | Media |
| REQ-054 | Infraestructura (Continuidad) | Plan de criticidad y continuidad de servicios: ESXi y Panóptico (críticos), FTP switching y CRM (alta), ERP y SharePoint (media), concentrador (baja). Definir SLAs y procedimientos de recuperación. | No Funcional | 4 | Media |
| REQ-055 | Datalake (Dashboard) | Dashboard unificado de control de servicios: estado de FTPs, Datalake, CRM, concentrador, etc. Mostrar KPIs operativos (ficheros recibidos, servicios activos). Prioridad personal de Alejandro. | Funcional | 4 | Baja |
| REQ-056 | Datalake (ETL) | Capa ETL intermedia para transformar XML complejos (FTP telegestión) a JSON/CSV antes de su carga en el Datalake. La app Streamlit actual puede servir como prototipo. | Funcional | 4 | Media |
Puntos Abiertos / Dudas a Aclarar
A continuación se listan las cuestiones que resultan ambiguas o incompletas en las transcripciones y que requieren una reunión de validación con Udesa antes de iniciar el desarrollo:
Descripción: Se mencionan ficheros XML tipo C1 para switching, pero no se detalló el catálogo completo de tipos de mensajes (C2, C3, etc.) ni los formatos específicos de telegestión.
Sesión: 2
Descripción: Se explicó el concepto general de switching y el fichero C1, pero no se detalló el flujo completo del proceso (estados, validaciones, plazos, respuestas del distribuidor).
Sesión: 2, 3
Descripción: En la sesión 4 se presentó el mapa general de arquitectura (cloud, página web, CRM, Neurophi, Datalake, FTPs) y se explicaron los principios arquitectónicos (centralización, proxy/bypass, API-first, record-driven). La transcripción completa de la sesión 4 ya cubre el detalle de servidores (2 físicos: TI y telecontrol), segmentación de red (Core, Panóptico, M2M), concentrador secundario, inventario de servicios y criticidad. Queda pendiente el PowerPoint con el mapa visual.
Sesión: 2, 3, 4
Descripción: Se indicó que el equipo de consultoría debe poder hablar con ITELSIS para solicitar recursos, pero no se definió el procedimiento formal (canales, autorizaciones, SLAs).
Sesión: 3
Descripción: Se mencionó que el Datalake debe almacenar "todo lo que se pueda", pero no se definieron las fuentes de datos concretas, los formatos de ingesta, ni los casos de uso de extracción de valor.
Sesión: 1, 2
Descripción: Se mencionó que hay cada vez más informes y auditorías, pero no se detalló qué informes específicos debe generar Udesa ni con qué periodicidad.
Sesión: 1
Descripción: Se mencionó brevemente la necesidad de centralizar y cohesionar sistemas de campo (OT), pero no se detalló qué sistemas son, qué datos generan ni cómo se integran actualmente.
Sesión: 1
Descripción: Se mencionó el dashboard de medidas como ejemplo, pero no se definió qué datos debe mostrar, qué nivel de detalle, ni qué usuarios lo consumirán.
Sesión: 3
Descripción: Se mencionó que el CRM y el ERP ya están desarrollados pero que los próximos desarrollos deben ser más específicos de distribuidora. No se detalló qué nuevas funcionalidades se requieren sobre estos sistemas.
Sesión: 1
Descripción: Las transcripciones de las sesiones 1-3 presentan saltos temporales significativos (el contenido intermedio de cada sesión no fue capturado por la herramienta de transcripción automática). Es posible que se hayan mencionado requerimientos o detalles técnicos que no constan en las transcripciones. La sesión 4 ya está completamente transcrita.
Sesión: 1, 2, 3
Descripción: La transcripción de la sesión 4 ya está completa (1 h 31 min). Alejandro se comprometió a compartir el PowerPoint (generado con Copilot) y las descripciones de procesos que complementarían la formación.
Sesión: 4
Descripción: Alejandro mencionó una nueva circular CNMC publicada en febrero de 2026 que requiere mostrar más información a los abonados en el CRM y aumentar la capacidad de comunicación entre distribuidor y abonado. El deadline era junio 2026 y no se ha cumplido. Indicó que se hará una reunión monográfica específica sobre este tema, ya que requerirá desarrollos nuevos que afectan al Datalake. No se detallaron los requisitos concretos de la circular.
Sesión: 4
Descripción: Alejandro propuso una sesión de ~30 minutos la semana siguiente para enseñar la aplicación de recolección de CSVs, el dashboard de Power BI y el workaround actual (scripts → CSV → SharePoint). Compartirá el código en Git.
Sesión: 4
Descripción: Se mencionó que el API de Breo publica la medida real, pero se comprobó que tampoco la da de forma fiable (Breo pidió acceso a Neurophi para sacar la curva real). La medida real solo está disponible en el FTP de telegestión. Decisión: integrar el FTP de telegestión directamente en el Datalake como origen más fiable.
Sesión: 4