Aquí va la conclusión: la retención de datos WCS se reduce a tres frases. Una: guarda datos crudos de nivel segundo por 30–90 días, agregados de nivel minuto por un año, y resúmenes diarios más eventos críticos para siempre. Dos: almacénalo en tres niveles — el PC industrial local solo guarda datos calientes, un servidor edge guarda agregados y la ventana de un año, y la nube es solo para archivo frío. Tres: los registros de alarmas y logs de auditoría de operación se separan y se guardan según requisitos regulatorios y contractuales — una política de retención completamente distinta de los logs de equipo. Abajo está por qué está configurado así, y el paso a paso para aterrizarlo antes del go-live.

Por qué la retención de datos WCS se divide así: empieza con quién viene a buscar

Solo tres tipos de personas consultan datos WCS. Primero, investigadores de incidentes: algo se estrelló, la mercancía se dañó, una línea se detuvo, y necesitan reconstruir "qué pasó exactamente". Eso necesita datos crudos de nivel segundo — los agregados no pueden reconstruir la escena. Segundo, analistas de OEE y eficiencia: efectividad de equipo, distribución de downtime. Quieren agregados; nadie calcula el OEE mensual desde puntos de nivel segundo, eso es autoflagelación. Tercero, auditores y cumplimiento: quieren "quién reconoció esta alarma, y cuándo" y "quién cambió qué parámetro". Registros de operación, todos y cada uno.

La política de retención se diseña al revés desde esos tres usuarios. Averigua quién consulta, con qué granularidad, y qué tan atrás — la matriz prácticamente se dibuja sola. Por el contrario, quien te diga "guarda todo, algún día será útil" nunca ha corrido operaciones. Datos que nadie consulta son datos que nunca almacenaste.

Aquí está la llamada contraintuitiva de entrada: lo más valioso para guardar para siempre no son los logs de equipo — son los registros de cambios de configuración y los registros de reconocimiento de alarmas. Los logs de equipo responden "qué pasó". Los cambios de configuración responden "por qué pasó". Nueve de cada diez revisiones de incidentes que he corrido terminaron en "quién cambió qué parámetro". He visto esta trampa tres veces: todos los datos estaban ahí, pero nadie pudo encontrar quién cambió el retardo de un sensor fotoeléctrico de 200ms a 800ms, y la reunión de revisión se convirtió en una sesión de culpas.

Ahora la matemática. Aquí está la fórmula — mete los números de tu propio almacén:

Volumen diario ≈ conteo de puntos × 86,400 (segundos/día) × bytes por registro

Ejemplo trabajado: 2,000 puntos, muestreo de 1 segundo, 50 bytes por registro — unos 8.6 GB por día, aproximadamente 780 GB en 90 días. Por eso los datos crudos no se pueden guardar para siempre: no porque el almacenamiento sea inasequible, sino porque nadie los consulta. Guardarlos es solo cavar una tumba para tu SSD. 780 GB de datos calientes en un PC industrial local significa consultas lentas y respaldos dolorosos — y un día llena el disco, que es exactamente la trampa número uno abajo.

Retención de datos WCS, paso a paso: cinco cosas antes del go-live

  1. Inventaria tus tipos de datos. Los datos WCS caen en exactamente cinco cubetas — una fila por cubeta, sin saltarse: logs de puntos PLC, registros de alarmas, trayectorias de tareas, logs de auditoría de operación, cambios de configuración/programa. Mientras inventarías, anota la fuente de cada cubeta (qué PLC, qué servicio lo escribe). Cuando algo se rompa después, lees primero la tabla en vez de agitar los brazos.

  2. Dibuja la matriz de retención de datos. Usa este formato; llena los números de tu propio sitio:

| Tipo de dato | Granularidad cruda | Retención cruda | Agregación | Retención de agregados | Dónde | | Logs de puntos PLC | Nivel segundo | 30–90 días | Prom/min/max de nivel minuto | 1 año | Local → servidor edge | | Registros de alarmas | Nivel evento | Según regulación/contrato | Reporte diario | Permanente | Servidor edge → nube | | Trayectorias de tareas | Por tarea | 90 días | Resumen diario | 1 año | Servidor edge | | Auditoría de operación | Nivel evento | Permanente (solo anexar) | — | — | Servidor edge → nube | | Cambios de config/programa | Nivel versión | Permanente | — | — | Servidor edge → nube |

Dos notas: la retención cruda de registros de alarmas no lleva un número fijo de días — escribe "según regulación/contrato", porque industrias y contratos de clientes difieren, y un número fijo se vuelve una responsabilidad cuando los contratos cambian. La auditoría de operación y los cambios de config son permanentes pero de volumen minúsculo, así que guárdalos con confianza — esto es lo "más valioso para guardar para siempre" de la sección anterior.

  1. Define los niveles de almacenamiento. El SSD del PC industrial local solo guarda 7–30 días de datos calientes, para que las consultas sigan funcionando durante un corte de red. El servidor edge guarda agregados y la ventana de un año. La nube hace solo archivo frío. Una regla: no pongas datos calientes en la nube — las tarifas de egress y consulta te darán una lección. Si no estás seguro, corre primero la fórmula de volumen, compárala contra una inversión única en servidor edge, y decide con la matemática, no con la intuición.

Un costo oculto más del archivo frío: la recuperación. El archivo frío es barato, pero recuperar datos toma horas a un día — una eternidad durante una investigación urgente de incidentes. Así que "guardado para siempre" no significa "en línea cuando quieras". Al definir la política de retención de datos, confirma primero el SLA de recuperación con auditores y clientes: todo lo que tolere recuperación al día siguiente va al archivo frío; todo lo que no, se queda en el servidor edge. Resuelve este trade-off antes del go-live — migrar datos archivados después es mucho más trabajo de lo que crees.

  1. Automatiza limpieza y archivado. Trabajos programados más alertas de marca de agua del disco: alerta al 80% lleno, archiva automáticamente los datos más viejos al 90%. Envía la alerta de marca de agua a donde un humano realmente lea — el grupo de chat de guardia, el teléfono de turno — no a un buzón público que nadie abre. Cada corrida de archivado escribe un log: cuánto archivó, cuánto borró. Los libros deben cuadrar.

  2. Documentación de entrega. Tres entregables para el equipo de operaciones, todos obligatorios: la matriz de retención (firmada por stakeholders — una firma significa "esta política está acordada"); la lista de trabajos de limpieza/archivado (programa, responsable, runbook de fallos); y un registro de simulacro de restauración de archivo (prueba de que los datos archivados realmente se pueden leer de vuelta — un simulacro nunca hecho es un archivo que existe solo en papel).

Línea de conveyors WCS con gabinetes de control

Modos de fallo comunes: los he visto los cuatro

Primero: sin política de retención en el go-live. Octubre de 2024, un gran almacén de e-commerce en el este de China: dos semanas antes del pico del Día de los Solteros, el disco local del PC industrial WCS se llenó de logs y el sistema se congeló. Recuperación: cuatro horas de downtime, exportación y archivado de emergencia, limpieza programada añadida, alertas de marca de agua parcheadas. He visto esta trampa tres veces, cada una más cara que la anterior — primero en un ambiente de prueba, segundo en temporada baja, tercero casi durante el pico. La lección en una frase: la política de retención pertenece a la lista del go-live, no a la lista de "ya lo resolveremos después" de operaciones.

Segundo: lógica de agregación congelada en código, datos crudos borrados. Un sitio borró datos de nivel segundo después de 90 días; seis meses después la gerencia quiso una fórmula OEE distinta, y la materia prima se había ido. Todo lo que pudieron hacer fue recalcular desde los agregados viejos — mal en todas las direcciones. Lección: antes de borrar datos crudos, confirma que las definiciones de agregación están congeladas. Si no estás seguro, extiende la retención cruda a 180 días. Duplicar el costo de almacenamiento te compra seguro contra arrepentimientos, y es un seguro barato.

Tercero: registros de alarmas mezclados con logs de operación. Un 3PL guardó registros de alarmas solo 30 días; cuatro meses después un cliente reclamó daño de mercancía y pidió los registros de alarmas y trayectorias de tareas de ese día — no disponibles, así que pagaron en los términos del cliente. Define la retención de registros de alarmas antes de firmar contratos de clientes, y anéxala al contrato. Arreglarlo después cuesta diez veces planificarlo antes.

Cuarto: trabajos de limpieza que nadie vigila. Las alertas de marca de agua iban al buzón de alguien que se había ido tres años antes; el disco se llenó antes de que nadie lo notara, y el trabajo de archivado llevaba tres meses fallando sin que nadie lo notara. La lista de entrega debe nombrar al destinatario de la alerta, nombrar al sucesor cuando se vaya, y conseguir la firma del sucesor. Es anticuado. Funciona.

Lista del go-live nocturno — añade estas tres líneas al final: matriz de retención aprobada por stakeholders; trabajo de limpieza corrido manualmente una vez, logs verificados de archivado y borrado; un simulacro de restauración de archivo, sacando aleatoriamente un archivo de tres meses y leyéndolo de vuelta. Una vez hechas esas tres líneas, puedes decir que los datos son de ciclo cerrado. Si no están hechas, ve a hacerlas ahora.

Por Lin Xiao, consultor de implementación WMS

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.