Recogida de datos de planta de fábrica: guía 2026 para fábricas hispanohablantes
La recogida de datos de planta de fábrica es la disciplina de capturar lo que está pasando en producción en una forma que otros sistemas puedan usar. En una fábrica en 2026 eso significa una stack de sensores automáticos, taps en PLC, cámaras de visión y una capa residual de datos introducidos por los operarios, todo alimentando MES, ERP y una cantidad creciente de analítica en nube y modelos de IA.
Este texto es para el responsable de operaciones o TI en una fábrica de tamaño medio que está reconstruyendo su capa de datos y quiere un framework práctico. El patrón español tiene forma parecida pero detalles propios respecto al estadounidense, y la mayoría de las guías publicadas online asumen implícitamente normas norteamericanas. Abajo encontrarás una versión que parte del contexto manufacturero español, con las referencias a las diferencias relevantes cuando importan.
Qué cubre de verdad la «recogida de datos de planta de fábrica»
Cuatro capas, de la más bruta a la más refinada.
La capa de sensores captura señales físicas (temperatura, presión, vibración, corriente, posición) y las transforma en flujos time-series. En una fábrica española los protocolos dominantes son Profinet y Profibus en el parque Siemens, EtherNet/IP en parques Rockwell y Allen-Bradley, Modbus en máquinas más antiguas, con una migración constante a OPC UA en las máquinas más nuevas.
La capa de eventos captura eventos discretos de los PLCs y de las cámaras de visión (una parada, una pieza contada, un defecto detectado, un setup iniciado). La forma del evento es la que la mayoría de los sistemas MES fueron construidos para consumir.
La capa de transacciones captura las acciones business-relevantes que exigen trazabilidad (un lote abierto, una tarjeta de operario escaneada, un hold de calidad levantado). Es la capa que hace interfaz con el ERP, y es donde auditores y clientes dedican más atención.
La capa de contexto captura los campos introducidos a mano que ningún sensor puede producir (un código de motivo de parada que el operario tiene que elegir, una observación de calidad, una nota de turno, un problema que el jefe de mantenimiento ha notado y apuntado). Es la capa menor en volumen de datos y con frecuencia la más valiosa para la root cause analysis.
Un programa de recogida de datos de planta de fábrica bien hecho cubre las cuatro capas. La mayoría de las fábricas españolas de tamaño medio en 2026 cubre bien las dos primeras, de forma discontinua la tercera, y mal la cuarta.
Por qué la recogida de datos de planta de fábrica importa en 2026
La razón por la que esta disciplina importa más en 2026 que hace cinco años es que la stack de manufacturing operations por encima de ella se ha vuelto mucho más exigente. Industria 4.0 era la etiqueta de marketing. Smart manufacturing es la versión práctica. En cualquier caso, las herramientas de analítica, IA y optimización de proceso que hoy se espera que la fábrica use asumen todas que la capa de datos de debajo sea limpia, completa y consistente.
Una lista corta de lo que la capa de recogida de datos alimenta en una fábrica moderna. El MES consume eventos y órdenes de trabajo. El ERP consume transacciones y órdenes de producción. El data historian guarda los datos de máquina en alta frecuencia para la revisión de ingeniería. El SCADA guarda la vista operativa de la fábrica para la sala de control. El data warehouse en nube guarda la analítica cross-línea y cross-fábrica. El cuadro de mando de OEE traduce eso en un score diario. Las herramientas de reporting de producción lo traducen en una revisión semanal para el liderazgo.
Cada uno de esos consumidores quiere los mismos datos modelados de forma distinta. La capa de recogida de datos es el sustrato compartido que permite a todos trabajar sin tener que reconstruir la captura para cada uno. Si el sustrato está bien, la conversación sobre eficiencia operativa se vuelve seria. Si está mal, cada consumidor reconstruye su propia versión de la realidad, los cuellos de botella se esconden dentro del trabajo de reconciliación, y la fábrica pierde la narrativa de operational excellence que el liderazgo está tratando de contar.
Patrones españoles (y dónde difieren del mundo anglo)
Algunos elementos distinguen la recogida de datos de planta de fábrica en plantas españolas de los patrones norteamericanos de las guías genéricas.
Siemens y Rockwell conviven en el parque instalado español, con Siemens claramente dominante. Profinet es el default en muchas plantas de automoción, cerámica y química. EtherNet/IP domina parques Rockwell, especialmente en food and beverage y bienes de consumo envasados. Schneider Electric (con raíces francesas pero gran presencia en Iberia) ocupa una fracción significativa de utilities y procesos. Cualquier programa de recogida de datos que no hable con fluidez los tres parte en desventaja. Beckhoff y Mitsubishi están en pockets (frecuentemente en plantas con matriz alemana o japonesa).
Restricciones regulatorias específicas. En pharma las buenas prácticas de fabricación EU GMP Annex 11 (vigiladas en España por la AEMPS) y los requisitos de Data Integrity suben el listón en las capas de transacciones y contexto. En food el Reglamento UE 178/2002 sobre trazabilidad y las disposiciones de AESAN empujan en el mismo sentido. El RD 1644/2008 que traspone la Directiva de Máquinas y la normativa de PRL (Ley 31/1995 y desarrollos) tocan tanto la captura de los eventos de seguridad como el periodo de retención de los registros.
Coste laboral y rotación. Las plantas españolas típicamente tienen una rotación más baja que las estadounidenses y más cercana a las alemanas en los núcleos industriales (Cataluña, Comunidad Valenciana, País Vasco, Madrid, Castilla y León). La implicación para la recogida de datos es que la capa de inserción manual es relativamente estable y que el investment en ergonomía del terminal compensa de todas formas: una UX que funciona al primer toque acelera el onboarding de los nuevos turnos y reduce el log perezoso a códigos genéricos.
Cloud-friendliness. La cultura de TI española se ha vuelto bastante cloud-tolerant en los últimos cinco años. AWS, Azure y Google Cloud tienen base instalada significativa. Snowflake y Databricks crecen rápido en equipos de datos industriales. En contrapartida, las obligaciones del RGPD sobre el tratamiento de datos (incluidos datos de imagen captados por cámara en planta) piden una definición clara de finalidad y retención. Eso pesa en las elecciones de software de recogida de datos, principalmente en sectores regulados.
Las elecciones que de verdad importan
Cuatro elecciones determinan si un programa de recogida de datos de planta de fábrica funciona o queda frágil.
Qué automatizas primero. La tentación es automatizarlo todo de golpe. El resultado es que nada queda automatizado bien. El patrón que funciona: empieza por los eventos que el operario registra a mano hoy y que dejaría de buen grado si el sistema los hiciera en su lugar (recuentos, paradas por encima de 30 segundos, tiempos de ciclo básicos). Deja los más difíciles (códigos de motivo, observaciones de calidad) para después de que los fáciles estén en vivo y creídos.
Dónde aterrizan los datos. La elección es entre un historian on-premise (PI, Ignition, Wonderware), un data warehouse en nube (Snowflake, Redshift, BigQuery) y un híbrido en que el historian es local y datos selectivos van a la nube. Para la mayoría de fábricas españolas de tamaño medio en 2026 la respuesta correcta es el híbrido. El historian para los datos operativos en alta frecuencia, la nube para analítica e IA, con un contrato claro entre los dos.
Cómo los operarios interactúan con el sistema. El terminal junto a la línea determina si la capa de inserción manual se llena de verdad de datos útiles. La elección es entre PCs industriales fijos en cada estación, tablets ruggedizados y smartphones personales en modo BYOD (menos común en plantas españolas por cuestiones de compliance y política corporativa). La opción del PC fijo sigue como default seguro en los sectores regulados. El tablet está ganando cuota en bienes de consumo y food.
El modelo de datos. La decisión aislada más consecuente y menos glamurosa. ¿Qué es un «evento» en tu modelo de datos? ¿Cuál es el identificador canónico del SKU? ¿Los códigos de motivo de parada son flat o jerárquicos? ¿El scrap se carga a la línea o al SKU? Si aciertas en la fase de diseño, la analítica funciona durante una década. Si fallas, la reconstruyes cada dos años.
Los cuatro errores que aparecen en auditoría
Patrones que se ven recurrir en auditorías de datos de plantas españolas.
Uno: hueco de retención. Los datos se capturan pero solo se conservan 90 días porque nadie definió la política. Cuando un cliente o un regulador pide los batch records del año pasado, los datos ya no están.
Dos: drift de los códigos de motivo. Los motivos de parada definidos en el lanzamiento han decaído en una lista larga en la que el 60% de las paradas se codifica como «Otro» o «Problema de proceso». Los datos siguen fluyendo. Los datos ya no son útiles.
Tres: workarounds manuales sin dueño. Una hoja Excel que el jefe de QA mantiene aparte, un log en papel que se reteclea cada semana, un dispositivo personal que recoge lecturas porque el sistema oficial es demasiado lento. Esos workarounds son el canario de un sistema de recogida de datos que no se adhiere al trabajo.
Cuatro: sistemas paralelos con números en conflicto. El MES dice 4.200 piezas. El ERP dice 4.175. El tracker de paradas dice que la línea rodó 7 horas y 12 minutos. El cuadro de mando de OEE dice 7 horas y 38 minutos. Nadie sabe en cuál creer. El trabajo de reconciliación consume semanas de tiempo de analista cada trimestre y erosiona la confianza en los datos.
Los tres primeros son higiene operativa. El cuarto es un problema arquitectural que se vuelve más difícil de arreglar cuanto más tiempo lo dejas.
Un programa de 12 meses para una fábrica de tamaño medio
Una secuencia gruesa que se ha visto funcionar, dimensionada en una fábrica con 5-10 líneas.
Meses 1-3. Inventario de la captura existente. Identifica las dos primeras líneas por output y por paradas. Define el modelo de datos (eventos, códigos de motivo, identificadores SKU y lote). Elige la stack de plataforma (herramienta de adquisición, historian o nube, terminales junto al usuario).
Meses 4-6. Deploy en la primera línea. Pon las capas de sensores y eventos rodando limpias. Corre un sistema de códigos de motivo en paralelo con los operarios durante dos semanas antes de apagar el log legado.
Meses 7-9. Deploy en la segunda línea. A estas alturas la primera línea tiene datos fluyendo al historian y al data warehouse en nube. Construye la primera capa de analítica (un informe de OEE diario, un Pareto de paradas semanal, una vista de scrap-por-SKU mensual).
Meses 10-12. Rollout a las líneas restantes usando el template ya probado. Aprieta la política de retención. Configura los controles de acceso al data warehouse. Documenta el modelo de datos para la próxima generación de ingenieros que lo va a heredar.
Es más rápido que el patrón típico de intentar hacer rollout en todas las líneas a la vez y más lento que la promesa consultiva de los seis meses. El camino del medio es el que de verdad llega a la meta.
Qué hace de verdad la analítica con los datos
Una vez que las cuatro capas fluyen, la capa de analítica puede hacer trabajo que era imposible en la fase de la inserción manual.
La tasa de producción y el output de producción se calculan en tiempo real a partir de la capa de eventos en vez de reportarse al final del turno desde el log del operario. El score de OEE, el número de overall equipment effectiveness que el plant manager cita en la revisión semanal, se convierte en un cuadro de mando en vivo sobre el cual la planta puede actuar, no un post-mortem del lunes por la mañana. El Pareto de paradas se vuelve una herramienta de trabajo para el jefe de mantenimiento, no una diapositiva para la revisión trimestral.
La conversación sobre control de calidad también cambia. Los eventos de defecto que vienen de las cámaras de visión se casan con las órdenes de producción en curso, con los operarios en turno, con el lote de materia prima y con las lecturas de parámetro aguas arriba. La root cause analysis que pedía tres semanas de trabajo en hojas Excel ocurre en una tarde. Los sistemas ERP que son dueños de los holds de calidad reciben la señal correcta en tiempo casi real.
Los casos de uso de IA son donde viven hoy los insights accionables de mayor palanca. Un modelo entrenado en los datos casados de sensores, eventos y transacciones puede señalar la firma temprana de un cuello de botella en formación antes de que la línea pare. Un modelo de visión puede mantener el listón de inspección en un nivel que el ojo humano pierde en el tercer turno. Nada de eso funciona si la capa de recogida de datos de debajo es frágil. Todo funciona si las cuatro capas (sensores, eventos, transacciones, contexto) están limpias.
Las fábricas que aciertan en esto salen de una cultura de revisión de eficiencia operativa a una de optimización de proceso que se acumula, en la que el trabajo de analítica de cada trimestre deja a la fábrica un paso medible por delante de donde había empezado.
FAQ
¿Cuál es la diferencia entre recogida de datos de planta de fábrica y MES? El MES es uno de los consumidores de la capa de recogida de datos. La capa de recogida de datos alimenta también ERP, historian, data warehouse en nube, herramientas de BI y modelos de IA. El MES queda aguas abajo de la capa de recogida de datos en una stack bien arquitectada.
¿Necesito storage en nube para los datos de planta de fábrica? No necesariamente. El historian se diseñó para eso y sigue haciéndolo bien. La razón por la que la mayoría de las fábricas mueve una parte de los datos a la nube es por los casos de uso de analítica e IA, no por la captura primaria. Un patrón híbrido con historian on-premise y sincronización selectiva a la nube es el patrón español dominante en 2026.
¿Se puede usar un smartphone para la recogida de datos de planta de fábrica? Sí, con caveats. Para la inserción de datos junto a la línea, los smartphones funcionan. Para la captura en alta frecuencia y para entornos regulados, el hardware dedicado sigue siendo la elección más segura. La monitorización por cámara con un smartphone en posición fija (un patrón Enao Vision con iPhone) es un caso de uso aparte y cada vez más común.
¿Cuánto tiempo tengo que retener los datos de planta de fábrica? Depende del sector. Pharma bajo EU GMP Annex 11 / AEMPS típicamente pide al menos tres años para los batch records, muchas veces más por contrato. Food bajo el Reglamento UE 178/2002 y AESAN pide al menos dos años para la trazabilidad. Clientes de automoción frecuentemente piden siete años para los datos de pieza. Configura la política de retención en el despliegue, no en el tercer año.
Empieza por las cuatro capas
La recogida de datos de planta de fábrica no es la compra de un producto único. Es la disciplina de capturar lo que pasa en planta de un modo que otros sistemas puedan usar sin perder el significado por el camino. Sensores, eventos, transacciones, contexto. Construye en ese orden. Elige las herramientas adecuadas a tu contexto (fluidez en Profinet y EtherNet/IP en el parque mixto Siemens/Rockwell/Schneider español, stack híbrida cloud-friendly con cuidados de RGPD, retención de sector regulado). Después haz la auditoría de los cuatro errores una vez al año para mantener el sistema honesto.
Para la guía más profunda de las herramientas, mira software de adquisición de datos de máquina. Para cómo encaja en el marco más amplio de visibilidad, mira sistema de monitorización de producción. Para la disciplina operativa que depende de estos datos, mira paradas no planificadas.
Empieza gratis
¿Quieres ver cuánto puede mejorar tu recogida de datos de planta de fábrica en pocas semanas? Crea una cuenta gratuita y conecta tu primera máquina en minutos.
Únete a la comunidad Enao
Compara patrones de recogida de datos de planta de fábrica, modelos de datos y elecciones de stack con otros ingenieros de procesos en la comunidad Enao.
