Un fabricante de maquinaria de envasado de tamaño medio, con sede en Europa Central, tenía un problema de informes que se hacía visible a las 06:00. La actualización nocturna de los datos de planta y del ERP tardaba unas nueve horas en un hiperescalar estadounidense y, las noches de más carga, se alargaba hasta el turno de mañana. Al mismo tiempo, los costes de salida de datos (egress) y los cargos por consulta empujaban la factura mensual cada vez más arriba. El cliente quería dejar su hiperescalar estadounidense y pasar a una plataforma de datos industrial con costes predecibles, en datacenters de la UE.

Quienes lo notaban primero eran los directores de planta. Abrían la reunión de la mañana con cifras de dos turnos atrás, o con un informe a medias y una nota que decía que el proceso seguía en marcha. Los ingenieros de calidad no podían fiarse de las cifras de desechos y retrabajos del turno anterior hasta bien entrada la mañana.

El reto: tres fuentes y una sola ventana nocturna

Los informes del cliente se alimentaban de tres tipos de datos. Los datos de máquina procedían de los controladores de sus líneas de montaje y de pruebas, los datos de calidad de las estaciones de inspección y del sistema de gestión de la calidad, y los datos comerciales del ERP. Cada fuente acababa en un almacén distinto, y el trabajo nocturno los llevaba todos a una capa de informes en el hiperescalar.

Dos cosas hacían crecer a la vez la factura y el tiempo de ejecución. Cada informe que cruzaba datos de máquina con pedidos del ERP movía datos entre servicios y hacia las herramientas de los analistas, y de ahí venían los cargos de salida de datos. Además, el proceso reprocesaba mucho más histórico del necesario: recalculaba por completo los cruces cada noche, porque nadie podía decir con seguridad qué particiones habían cambiado.

Queremos ser justos con el hiperescalar. La plataforma hacía aquello para lo que fue diseñada, y su elasticidad habría podido absorber las nueve horas a cambio de una factura mayor. Lo que el cliente cuestionaba era el modelo de precios para esta carga de trabajo (un movimiento interno constante de los mismos datos) y que sus datos de producción y de pedidos estuvieran bajo una matriz estadounidense.

Qué construimos: una plataforma de datos industrial en un solo lugar

Definimos el alcance con los equipos de control de gestión, calidad y TI de planta del cliente, y después construimos, y ahora operamos, una plataforma de datos para ellos. Está en el centro de la UE que el cliente eligió, como un tenant aislado que pertenece solo a ellos, con copias de seguridad incluidas. La orquestación, un data lake, los notebooks y los dashboards funcionan sobre nuestra infraestructura, de modo que los datos que circulan entre esas capas se quedan dentro de una misma red y no cruzan ninguna frontera de facturación.

El diseño tuvo cuatro partes.

  • Una única zona de aterrizaje para las tres fuentes. Los datos de máquina, calidad y ERP llegan al data lake en el mismo formato en bruto, con las mismas marcas de tiempo y los mismos identificadores de planta y de línea, así que un cruce ya no empieza con un paso de conciliación.
  • Procesamiento incremental. La capa de orquestación registra qué particiones han cambiado desde la última ejecución y recalcula solo esas. El recálculo completo de cada noche ha desaparecido.
  • Etapas ordenadas. La ingesta, la limpieza, los cruces y las tablas de informes se ejecutan como etapas separadas con dependencias explícitas, de modo que una extracción tardía del ERP solo retrasa lo que depende de ella.
  • Dashboards sobre tablas ya preparadas. Los directores de planta consultan tablas que ya están construidas, en lugar de lanzar cruces pesados al abrir un informe.

La migración de los informes del ERP

La migración de los informes del ERP fue la pieza más arriesgada, porque control de gestión y finanzas dependían de las definiciones de informe existentes. No las reescribimos de una vez. Reconstruimos los informes en la nueva plataforma, los ejecutamos en paralelo con las versiones del hiperescalar durante varias semanas y comparamos los resultados línea por línea.

Las diferencias se registraron y se rastreó su causa: una regla de redondeo, una fecha de conversión de divisas, un tratamiento de los pedidos cancelados. Los responsables de control de gestión del cliente decidieron qué comportamiento era el correcto en cada caso, y nosotros codificamos esa decisión una sola vez en la capa de transformación. Solo cuando la ejecución en paralelo coincidió se apagaron los informes antiguos.

Un trabajo de nueve horas rara vez es un problema de recursos de computación: normalmente son los mismos datos movidos y recalculados cada noche porque nada registra qué ha cambiado.

Analítica de planta al empezar el turno

Con el procesamiento incremental y una única zona de aterrizaje, la actualización nocturna termina ahora en menos de dos horas, frente a las nueve aproximadas de antes. Los directores de planta tienen las cifras del turno anterior cuando llegan: producción por línea, rendimiento a la primera, paradas por causa y pedidos abiertos frente al plan. Esa es la ganancia práctica en analítica de planta para este cliente: la reunión de la mañana parte de los mismos números en todas las plantas.

La ventana más corta también cambió la forma en que el cliente trabaja con los datos. Los ingenieros de calidad usan los notebooks de la plataforma para analizar los resultados de inspección de esa misma noche, en lugar de esperar a la actualización del día siguiente. Repetir la ejecución tras una extracción del ERP tardía o corregida ya no es algo que se descarte: lleva menos de dos horas en lugar de consumir la mañana.

Costes de salida de datos y factura mensual

El gasto mensual del cliente en su plataforma de datos bajó aproximadamente una cuarta parte. Una parte es estructural: el tráfico de informes entre el lake, las etapas de procesamiento y los dashboards se queda dentro de un único entorno, así que no hay cargos de salida de datos por los informes internos del cliente. Otra parte es trabajo que ya no se hace, porque las ejecuciones incrementales procesan una fracción de los datos que procesaba el recálculo completo.

El gasto también es más fácil de prever. El cliente puede ver lo que cuesta la plataforma sin tener que estimar cuántas consultas lanzarán los analistas ni cuántos datos moverá cada una.

Qué puede hacer ahora el cliente

  • Abrir la reunión de la mañana de cada planta con las cifras del turno anterior.
  • Repetir un informe tras una extracción del ERP tardía o corregida sin perder la mañana.
  • Exportar sus datos de la plataforma cuando quiera, sin cargos por cambio de proveedor ni por salida de datos, para que el próximo cambio de plataforma no sea una repetición de este.
  • Encomendarnos la operación de la plataforma, como ha hecho, y conservar las definiciones de los informes bajo el control de sus propios responsables de control de gestión.

Los datos de producción y de pedidos del cliente están ahora en datacenters de la UE que operamos nosotros mismos, con acceso a la infraestructura solo para personal autorizado de DIVERSITY en la UE y sin ninguna sociedad matriz por encima de nosotros a la que pudiera notificarse una orden de un tercer país.

Si tus informes funcionan sobre un hiperescalar y el proceso nocturno es lo primero que revisas cada mañana, podemos analizar el pipeline contigo bajo NDA y decirte adónde se van las horas.