Cómo detectar una replanificación sin versión en ERP

Una secuencia puede cambiar en una pantalla y seguir pareciendo la misma en otra. El equipo ve que una orden pasó del martes al jueves, pero el ERP solo conserva el calendario actual. En ese punto aparece una tentación peligrosa: llamar “replanificación” a todo cambio o tratar la diferencia como un fallo del turno. Ninguna de las dos etiquetas está justificada sin una versión que conecte el antes con el después.

Una replanificación sin versión no permite comparar secuencias con seguridad; primero identifique plan, autoría y momento del cambio. (NIST, medición del rendimiento operativo) Esa es la respuesta corta. El trabajo práctico consiste en congelar los datos que todavía existen, reconstruir qué cambió y pedir la traza mínima que permita a otra persona repetir la revisión.

La página de NIST sobre medición del rendimiento en fabricación inteligente describe métodos para caracterizar sistemas, elegir métricas y analizar datos operativos. No ofrece un detector universal de replanificaciones ni convierte un ejemplo de investigación en obligación para una empresa española. ISA-95 ayuda a discutir objetos y actividades, pero tampoco decide quién puede cambiar una orden en su ERP.

Empiece por distinguir cambio, registro y explicación

Hay tres preguntas distintas:

• Qué cambió: el orden de operaciones, la fecha, el recurso, la cantidad o el estado.
• Cuándo quedó registrado: hora del evento, hora de recepción y hora de consulta.
• Por qué cambió: motivo y autorización, si existen.

Una pantalla que muestra una fecha distinta responde solo a la primera pregunta, y a veces ni siquiera con precisión. Si se consulta después de la ventana de producción, puede estar mostrando una versión que sustituyó a la vigente durante el turno. La hora de consulta no es la hora de cambio.

Escriba el caso con un límite pequeño. Por ejemplo: “Para la orden OF-734, la secuencia de las operaciones 20 y 30 aparece invertida entre una exportación del lunes y la consulta del miércoles; hay que saber si existió una replanificación autorizada o si falta un registro de interfaz”. La frase identifica objeto, comparación y decisión pendiente sin anticipar una causa.

Qué debe contener una versión utilizable

Una versión no es solo un número. Como mínimo, conserve:

| Campo | Para qué sirve | Si falta |

| ————— | –––––––––––––––––––––– | ––––––––––––––––––––––––––––– |

| Identificador | Relaciona una captura con un estado concreto | No se puede asegurar que dos vistas sean comparables |

| Vigencia | Indica cuándo podía usarse | Se confunde un plan futuro con uno operativo |

| Publicación | Sitúa cuándo se hizo visible | No se sabe si el cambio llegó al calendario |

| Autor o rol | Señala quién generó o aprobó | La investigación no tiene una autoridad a la que preguntar |

| Motivo o evento | Explica qué disparó el delta | El cambio queda como una inferencia |

Si el ERP no muestra uno de estos campos, no lo invente con el nombre del fichero o la hora del correo. Puede asignar una referencia técnica para conservar el artefacto, pero márquela como tal. Un archivo plan_final.xlsx no se convierte en versión 4 porque alguien lo guardó cuatro veces.

El estado también importa. “Borrador”, “validado”, “publicado” y “sustituido” pueden gobernar acciones distintas. Un borrador que aparece en un informe no prueba que el turno debiera ejecutarlo. Registre el valor original y la definición local si la hay.

Preserve el plan de referencia antes de investigar

Cuando se sospecha una replanificación, deje de editar la orden y capture lo que la interfaz ofrece. Guarde la exportación, los filtros, la zona horaria y la consulta. Si el procedimiento prohíbe copiar datos productivos, conserve el identificador del informe y la ruta de auditoría autorizada.

Pida dos vistas, no una: el plan que se consideraba vigente en la decisión y el estado que el ERP muestra ahora. En cada vista, anote el horizonte, la unidad, las órdenes incluidas y las exclusiones. Un filtro por centro de trabajo puede quitar la operación que explica el cambio.

El plan de referencia puede ser el original del turno, el plan congelado antes del corte o una versión aprobada para una familia. La elección depende de la pregunta. Si se quiere explicar por qué el turno empezó una orden distinta, comparar con el plan mensual completo no sirve. Escriba qué se pretende decidir y por qué ese plan es el punto de comparación.

Reconstruya el delta sin convertirlo en una causa

Describa el cambio en términos observables. “La operación 30 aparece antes que la 20 en la consulta del miércoles” es un hecho si las dos consultas conservan los filtros. “Se adelantó por falta de material” es una explicación que necesita una orden de material, una alerta o un registro de decisión.

Una tabla de delta ayuda a separar niveles:

No mezcle un delta de cantidad con uno de secuencia. Puede haber una nueva orden parcial que explique la cifra sin alterar el orden original. Del mismo modo, una secuencia diferente puede ser un cambio de recurso con la misma cantidad. Cada línea pide una evidencia distinta.

Ordenar la revisión de una replanificación por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión conserva la procedencia. (NIST, medición del rendimiento operativo) La entidad puede ser la orden, operación o recurso; el propietario es quien puede certificar el dato. Si la tabla no puede rellenarse sin suposiciones, el caso debe pasar a evidencia pendiente.

Busque señales de una versión perdida

Una versión ausente deja rastros, pero ninguno es prueba por sí solo. Revise si aparecen:

1. una fecha de modificación distinta de la publicación;
2. un cambio de secuencia sin cambio de cantidad;
3. un evento de aprobación o liberación sin identificador de plan;
4. una cola de interfaz con reintentos;
5. una orden nueva que hereda parte de la original;
6. un usuario de servicio que escribe fuera de la ventana habitual.

Estas señales sirven para decidir qué log pedir. No convierta un usuario de servicio en culpable ni una hora inusual en prueba de manipulación. Los sistemas automáticos pueden escribir por una regla legítima.

Si existe un registro de auditoría, busque el vínculo entre el objeto cambiado y el objeto anterior. Un evento con order_id pero sin versión puede demostrar que alguien editó una orden, no qué plan usaba. Registre esa limitación literalmente.

Analice la interfaz sin olvidar los relojes

MES y ERP pueden tener relojes o zonas horarias diferentes. Guarde la hora del evento, la hora de recepción y la hora en que cada informe lo hizo visible. Un mensaje recibido a las 00:05 puede pertenecer al día de negocio anterior. Un informe que redondea al minuto puede ocultar dos cambios.

La especificación OPC UA ofrece conceptos para intercambiar información y comprobar conformidad. No dice que su interfaz entregue todos los eventos, conserve el orden o tenga una latencia concreta. Pruebe esas propiedades con los logs locales y con el perfil que la planta haya definido.

Si la cola se reintenta, busque un identificador de correlación. Si no existe, compruebe la regla de idempotencia antes de sumar eventos. Dos mensajes idénticos pueden crear una falsa replanificación si el lector los cuenta como dos cambios.

Use un método de investigación, no un porcentaje de sospecha

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. (NIST, medición del rendimiento operativo) La frase describe un enfoque, no una fórmula para calcular la probabilidad de una replanificación.

Para este caso, caracterice primero el flujo: qué evento crea la versión, qué servicio la publica, qué sistema la consume y qué pantalla la presenta. Seleccione una métrica de observabilidad, como porcentaje de cambios con autoría y hora, pero no la interprete como cumplimiento legal. Analice una muestra de órdenes que comparta el patrón y anote las excepciones.

La muestra debe tener una población definida. Si solo incluye órdenes de una línea en un turno, no extienda la conclusión al mes completo. Documente qué se excluyó y por qué. Un resultado pequeño puede orientar una mejora del dato sin demostrar una tendencia de rendimiento.

Pregunte por la decisión que falta

Un expediente de replanificación debe terminar con una pregunta que alguien pueda responder. Ejemplos:

• ¿Qué versión estaba vigente cuando se liberó la orden OF-734?
• ¿Quién aprobó invertir las operaciones 20 y 30?
• ¿Qué regla partió la cantidad de 400 kg?
• ¿Qué evento de interfaz publicó el cambio en MES?

No pida “la historia completa del ERP”. Una solicitud acotada reduce datos innecesarios y protege información sensible. Indique el identificador, intervalo y sistema. Si el responsable no puede recuperar la versión, registre la limitación y acuerde una mejora para el siguiente turno.

Decida sin sobreinterpretar

Hay cuatro cierres razonables:

Replanificación documentada. Existe una versión anterior, una posterior y una autorización que enlaza el delta. El informe puede explicar la secuencia para el alcance indicado.

Cambio operativo con traza incompleta. Se ve un evento y un usuario, pero falta la versión o la hora. La comparación queda condicionada; no se declara causa.

Diferencia de representación. El plan y el calendario usan objetos, unidades o ventanas distintas. Se corrige la traducción o se limita la comparación.

Evidencia insuficiente. No se puede identificar plan, autoría o momento. Se congela el caso y se solicita la traza mínima.

La salida debe retener la comparación hasta identificar versión, autoría y momento del cambio; si falta evidencia, la hipótesis se mantiene abierta. (ISA-95) Esa decisión puede ser incómoda para una reunión, pero evita que una explicación provisional se convierta en dato histórico.

Compruebe el caso en otra ventana

Una vez localizado el evento, repita el procedimiento con una orden cercana que no sea la original. Busque si el mismo servicio crea versiones, si el estado se publica igual y si la zona horaria se aplica de forma consistente. Una sola orden puede tener una excepción irrepetible.

La comprobación posterior no autoriza una corrección masiva. Solo indica si la trazabilidad que se pensaba encontrar existe en otra muestra. Si falla, cree una acción de mejora, por ejemplo guardar el identificador de versión en el informe de turno, con responsable y fecha de revisión.

Prepare una ficha que resista el cambio de turno

Un caso suele pasar por varias manos. La persona que detecta la diferencia no siempre es quien puede acceder al registro de auditoría. Una ficha corta evita que la investigación empiece de nuevo cada vez que cambia el interlocutor. Incluya el identificador de la orden o familia, los dos artefactos comparados, la versión conocida y la versión que se está buscando. Añada el intervalo exacto y las zonas horarias, porque “durante el martes” puede incluir dos calendarios diferentes.

En otra sección, escriba los hechos en pasado y las preguntas en futuro. Por ejemplo: “La operación 40 se consultó en estado liberado a las 06:10; la consulta de las 14:00 la muestra en espera”. Después: “¿Qué evento cambió el estado y qué versión estaba vigente a las 06:10?”. Separar ambos tiempos evita que una pregunta termine redactada como una causa.

Registre también los pasos que ya se hicieron: exportación del informe, revisión del log de interfaz, consulta al responsable y resultado de cada una. Si un acceso no estaba permitido, anótelo. La ausencia de acceso explica por qué la evidencia sigue pendiente; no prueba que el registro no exista.

Cuando la ficha incluya datos personales o información de cliente, use el identificador interno autorizado y guarde el detalle en el repositorio con control de acceso. El expediente debe permitir una auditoría sin convertir una incidencia operativa en una copia indiscriminada del ERP.

Añada una columna de confianza documental, no una probabilidad de culpa. Puede indicar “versión confirmada”, “evento confirmado, vínculo pendiente” o “solo diferencia visual”. Cada etiqueta debe tener un criterio escrito y una fuente. Así, dos analistas no clasificarán de forma distinta el mismo registro por intuición. Si el estado cambia, conserve la etiqueta anterior y la fecha de la revisión; borrar la primera lectura dificulta entender por qué se mantuvo abierta la comparación.

Qué no debe hacer el analista

No edite el plan para “volver a cuadrar” la secuencia. No cambie la fecha de un evento para probar una hipótesis. No elimine mensajes duplicados antes de conservar los originales. No publique un porcentaje de cumplimiento que mezcla versiones. Esas acciones destruyen la evidencia que se necesita para explicar el caso.

Tampoco atribuya el cambio a una persona por el usuario técnico, ni a una interfaz por la ausencia de un campo. La causa puede estar en una regla de calendario, un maestro revisado o un corte mal definido. El informe debe separar lo que se observó de lo que todavía se investiga.

Límites de las fuentes y del método

La investigación y los métodos no son estadística española ni norma obligatoria; dependen de la caracterización y población local y no prometen optimización ni ahorro. (NIST, medición del rendimiento operativo) NIST aporta un marco para medir y analizar sistemas. ISA-95 y OPC UA aportan vocabulario y conceptos de integración. Ninguno certifica su ERP, prueba una obligación contractual o determina una decisión de inversión.

La guía tampoco decide si la replanificación era correcta, si una orden debía detenerse o si un cambio afecta a calidad, seguridad o cumplimiento. Esas decisiones requieren el procedimiento y la autoridad de su planta. Si la diferencia incide en un producto regulado o en un riesgo operativo, escale antes de tocar datos.

Recursos relacionados

Para una comparación general entre plan y ejecución, consulte cómo comparar el plan ERP con la ejecución MES. Si la pregunta se refiere a carga y órdenes aún abiertas, revise la capacidad real con órdenes ERP abiertas. La guía de conciliación MES-ERP reúne campos y controles que pueden acompañar al expediente.

Preguntas frecuentes

¿Qué indica que una replanificación no tiene versión?

La secuencia o la carga cambia, pero el ERP no ofrece un identificador, estado, autor y momento que permitan relacionar el cambio con un plan anterior. Una captura sin filtro tampoco demuestra una versión.

¿Debo comparar el plan original con el último plan visible?

Solo si la pregunta pide ese contraste y ambos planes están identificados. Para explicar una decisión del turno, conserve la versión vigente en ese momento y la posterior, aunque el sistema solo muestre ahora la última.

¿Una orden adelantada demuestra una replanificación?

No necesariamente. Puede deberse a un cambio de recurso, una operación registrada tarde o una diferencia de zona horaria. Busque el evento de cambio antes de etiquetarla.

¿Qué hago si el usuario del cambio aparece pero no hay hora?

Registre la autoría como dato parcial y retenga la comparación. Solicite la marca temporal o el registro de auditoría; no infiera la versión por el nombre del usuario.

¿Cómo cierro un caso sin versión recuperable?

Declare la evidencia insuficiente, indique qué campos faltan y qué autoridad debe recuperarlos. Puede mejorar la captura para futuros casos, pero no convierta una hipótesis en causa histórica.