Cómo mapear dependencias de recurso antes de programar

Una orden puede parecer lista para entrar en el plan hasta que se mira la estación que necesita. Quizá comparte un útil con otra operación, necesita una limpieza previa o solo puede ejecutarse en una ventana de mantenimiento ya reservada. Si se programa primero y se investiga después, la secuencia queda apoyada en una suposición que luego es difícil explicar.

El mapa de dependencia pone esa relación delante de la secuencia. Describe qué operación necesita qué recurso, durante qué ventana y bajo qué estado. No decide qué pedido se protege ni declara un cuello de botella. Es un paso de evidencia para que la persona que programa conozca las condiciones antes de colocar la orden.

Mapear una dependencia antes de programar exige registrar recurso, operación y ventana dependiente; no basta con el nombre de la estación. (NIST, medición del rendimiento operativo) La regla deja abierta la causa y obliga a revisar el dato local.

Defina la pregunta y el nivel de detalle

La pregunta no debería ser “¿puedo meter esta orden?”. Una formulación útil es: “¿Qué operación de OF-602 requiere la estación compartida S-4 en la ventana del turno B y qué otra carga depende de ella?”. La pregunta fija orden, operación, recurso y periodo.

Escriba si se analiza una operación, una orden, una familia o una campaña. Una dependencia de familia puede ocultar operaciones alternativas. Una dependencia de orden puede ser demasiado detallada para un plan mensual. El nivel elegido debe aparecer en el mapa y en la fuente.

La ficha inicial puede usar estos campos:

No rellene la alternativa porque aparezca en un catálogo. Puede estar bloqueada para el producto, el turno o la calidad. La autorización local decide si es válida.

Describa la estación compartida

Una estación compartida puede ser una máquina, un útil, un laboratorio, una persona cualificada o una interfaz de prueba. Registre el identificador técnico y el nombre que usa planificación. Si hay alias, conserve ambos con su versión.

Anote la capacidad en una unidad que se pueda comprobar: horas de recurso, lotes, ciclos o piezas compatibles. Evite mezclar una capacidad nominal con una ventana disponible sin explicar pausas, cambios y mantenimiento.

Si la estación solo se puede usar con una receta o una configuración, convierta esa condición en un campo de dependencia. “S-4” no basta si la operación requiere el cabezal H-2. El mapa debe mostrar la combinación que bloquea o permite la programación.

Conserve la ventana y la secuencia provisional

Una dependencia tiene una ventana. La operación puede ocupar la estación de 08:00 a 10:00, o solo necesitarla para una fase corta dentro de un lote. Guarde inicio, fin, zona horaria, precisión y fecha de negocio. Si el plan usa una semana y el recurso un turno, documente la regla de traducción.

No confunda una ventana dependiente con una prioridad. La operación puede tener una fecha temprana y aun así disponer de una alternativa. La prioridad requiere un criterio de negocio; el mapa solo expone la relación y el intervalo.

Incluya mantenimiento, limpieza y cambio de formato cuando afecten a la disponibilidad. Si el calendario no los tiene versionados, marque la capacidad como parcial. Una orden puede caber en la suma de horas y no caber en la secuencia real.

Clasifique la dependencia

Use tres estados para empezar:

• Confirmada: la operación, recurso y ventana aparecen en fuentes compatibles y el propietario puede validar la relación.
• Parcial: hay una relación probable, pero falta el tiempo de preparación, la versión del maestro o la autorización de una alternativa.
• No comparable: los sistemas usan objetos, unidades o periodos que no se pueden cruzar con seguridad.

El estado no es una puntuación de riesgo. Es una descripción de evidencia. Una dependencia parcial no debe convertirse en una reserva de horas para completar el plan.

Construya un pequeño grafo de dependencias

Una tabla permite ver relaciones que una lista de órdenes oculta:

El grafo no tiene que ser una herramienta nueva. Puede ser una tabla en el repositorio de planificación, siempre que conserve la versión y el propietario. Si hay dos recursos posibles, dibuje las dos ramas y la condición que decide cuál es válida.

Ordene la revisión antes de secuenciar

Ordenar la revisión de una dependencia por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión conserva la procedencia. (NIST, gobierno de información) La entidad puede ser una operación, un recurso o una ventana; escriba cuál se está revisando.

Después de ordenar, pida una evidencia concreta para cada dependencia parcial. Por ejemplo, el maestro de cambios de formato, la versión del calendario de mantenimiento o la autoridad que aprueba una alternativa. No solicite “todos los datos de la estación”; el alcance amplio dificulta la respuesta.

La procedencia también incluye la fecha de la consulta. Una dependencia puede estar confirmada el lunes y pendiente el miércoles si cambia el calendario. Conserve las dos lecturas y el motivo de la revisión.

Use métodos de medición sin convertirlos en una receta

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. (NIST) Para una dependencia, esto sugiere medir cobertura, tiempo de espera o porcentaje de relaciones con propietario, siempre con una población y una ventana definidas.

Una métrica de cobertura no demuestra que la secuencia sea óptima. Puede señalar que muchas operaciones carecen de un tiempo de preparación o de una unidad comparable. Use el resultado para pedir una mejora del dato, no para prometer productividad.

Decida qué puede entrar en el plan

Hay tres salidas prudentes. Si la dependencia está confirmada y la ventana es compatible, la operación puede pasar a la secuencia provisional según el procedimiento local. Si es parcial, se conserva como hipótesis y se solicita la evidencia que falta. Si no es comparable, se detiene la colocación hasta que el propietario defina una relación válida.

La salida debe registrar recurso, operación y ventana dependiente antes de colocar la orden en el plan; si falta evidencia, mantener la hipótesis abierta. (NIST) Añada quién decide y cuándo se vuelve a comprobar. El mapa no autoriza a cambiar una orden ni a proteger un pedido.

Ejemplo: un útil que dos operaciones reclaman

OF-602 necesita el útil H-2 para la operación 30 y OF-603 lo necesita para la operación 10. El calendario muestra ambas en el mismo turno, pero la vista mensual no incluye los veinte minutos de preparación. El programador podría colocarlas consecutivas y asumir que encajan.

El mapa conserva la dependencia de cada operación, la ventana y el tiempo de cambio de útil como dato pendiente. La comprobación descubre que el maestro de proceso tiene dos versiones: una antigua con veinte minutos y otra actualizada con treinta. No se elige una por conveniencia. Planificación valida qué versión estaba vigente y, mientras tanto, la secuencia queda provisional.

El caso no demuestra un cuello. Demuestra una dependencia compartida cuya ventana no estaba definida. Si el útil tiene una alternativa, se registra como otra rama con su propia autorización y tiempo de preparación.

Diferencie dependencia y prioridad

Una dependencia dice “esta operación necesita este recurso”. Una prioridad dice “esta comprobación o pedido se atiende antes”. La primera se basa en la relación técnica y temporal; la segunda puede incluir compromiso, calidad, seguridad o negocio. Mezclarlas hace que el mapa parezca una decisión que nadie aprobó.

Si una orden prioritaria no tiene dependencia confirmada, el compromiso no rellena el hueco. Si una dependencia está confirmada pero el pedido no tiene autoridad, el programador no debe inventar una prioridad. Documente ambos aspectos por separado.

Proteja datos y versiones

Los mapas pueden contener nombres de productos, pedidos y recursos. Guarde solo lo necesario y use el repositorio autorizado. Conserve la versión del maestro, del calendario y de la consulta que generó la relación.

Cuando cambie un recurso, registre la fecha de vigencia. No reescriba el mapa anterior: una auditoría puede necesitar saber qué dependencia se conocía al programar. Las correcciones deben dejar una nota de motivo y propietario.

Compruebe otra orden

Repita el mapa con una orden diferente que use la misma estación. Compruebe si la unidad, la ventana y la alternativa se interpretan igual. Si aparecen dos reglas, registre la excepción y pida una decisión de modelo.

La segunda muestra no convierte la relación en universal. Solo muestra si el mapa es útil para otro caso. Mantenga una fecha de revisión y un responsable.

Prepare el mapa para una reunión de secuencia

Una reunión de planificación necesita una salida que se pueda leer en pocos minutos y ampliar si surge una objeción. Lleve el identificador de la orden, el recurso y la operación afectados; después muestre la ventana, el estado y el dato que todavía falta. No abra primero un listado de cientos de órdenes: empiece por el vínculo que cambia la decisión.

Puede presentar cada relación con cuatro frases:

1. Hecho: la operación O-30 necesita el útil H-2 en el turno B, según el maestro de proceso v12.
2. Consecuencia de planificación: la orden O-31 usa el mismo útil en la ventana que se solapa.
3. Límite: el tiempo de cambio de H-2 figura con dos versiones y no está confirmado cuál regía.
4. Siguiente paso: el propietario del maestro valida la versión antes de fijar el orden.

Esta forma evita que “comparten recurso” se interprete como “una orden bloquea a la otra”. El solape puede resolverse con otra ventana, una alternativa autorizada o una secuencia distinta. La decisión pertenece a quien tiene autoridad sobre el plan y debe quedar registrada.

Trate las alternativas como relaciones independientes

Una alternativa no es una nota al pie. Si la operación puede ejecutarse en S-5 en lugar de S-4, registre qué cambia: receta, herramienta, cualificación, tiempo, transporte, inspección o riesgo. Dos recursos con el mismo nombre comercial pueden no ser equivalentes para un producto concreto.

Mantenga la alternativa en estado pendiente hasta que el responsable la apruebe. Si ya existe autorización, copie su identificador y fecha de vigencia; no se limite a la palabra “equivalente”. Cuando una alternativa depende de una condición (por ejemplo, una calibración reciente), esa condición forma parte de la dependencia.

El mapa puede tener varias ramas:

No cuente las tres ramas como tres capacidades. Son opciones de una misma operación y solo una puede confirmar la secuencia.

Registre cambios de modelo y excepciones

Los nombres de recursos, unidades o familias suelen cambiar. Si el ERP llama “S-4” a una estación y el MES usa “CELL04”, conserve la tabla de equivalencias con fecha y fuente. No fusione identificadores parecidos sin que el propietario de datos confirme que representan el mismo objeto.

Las excepciones también merecen un estado: una orden urgente puede usar una ventana reservada, una limpieza puede adelantarse o un lote puede dividirse. Describa la regla que permite la excepción y su fecha de caducidad. Cuando la excepción deja de ser válida, cierre la relación y no la reutilice por inercia.

Si el modelo cambia, publique una nueva versión del mapa. Mantenga la anterior para saber qué evidencia estaba disponible cuando se colocó la orden. Un historial corto con motivo y aprobador suele ser más útil que un archivo único que borra decisiones anteriores.

Compruebe la lógica con datos de prueba

Antes de usar el mapa en una reunión crítica, pruebe casos sencillos: una orden con un recurso, dos órdenes con una estación compartida, una alternativa autorizada y un recurso sin ventana. Verifique que cada caso produce el estado esperado y que una ausencia de dato no se convierte en cero.

La prueba puede ser manual, pero debe anotar entrada, versión y resultado. Si varias personas interpretan de forma distinta “ventana disponible” o “alternativa válida”, convierta la diferencia en una decisión de glosario. El mapa no resolverá una definición que la organización todavía no ha acordado.

También conviene probar una relación que no deba existir. Por ejemplo, dos nombres parecidos de equipo pueden pertenecer a plantas distintas. Si el mapa los conecta por una coincidencia textual, el control de identidad ha fallado. Corrija la regla antes de utilizar el dato para secuenciar.

Anote además quién puede aprobar una excepción y qué fecha obliga a revisar el mapa, para que la secuencia no dependa de memoria informal.

Incluya ese control en la agenda de revisión del plan y en el registro de cambios.

Separe disponibilidad, capacidad y prioridad

Una estación puede aparecer libre en el calendario y seguir sin capacidad útil para una operación. Antes de ordenar, separe tres preguntas: ¿está disponible en la ventana?, ¿puede ejecutar la operación con el útil, el personal y la condición requeridos?, ¿hay una regla que dé prioridad a una orden? Mezclarlas convierte una ausencia de dato en una decisión de secuencia.

Para cada relación, conserve una fila que responda a esas preguntas:

Por ejemplo, dos órdenes pueden compartir una estación durante la misma hora, pero una puede requerir un útil que todavía está en limpieza. La relación de recurso existe en ambos casos; la capacidad disponible no. Registre el estado del útil, la persona que lo verificó y la hora de corte. Si el plan cambia, conserve la versión anterior para poder explicar por qué la ventana parecía libre.

Esta separación también ayuda en la reunión. Operaciones puede validar la condición del equipo, planificación puede revisar la ventana y la autoridad de la secuencia puede decidir qué regla aplica. El mapa aporta la relación y su evidencia; no asigna prioridad por su cuenta.

Límites de esta guía

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) El IPI del INE tampoco mide la capacidad de una estación concreta. Las fuentes aportan contexto, no una secuencia industrial.

Esta página no decide qué pedido proteger, no aprueba una inversión y no garantiza una fecha de entrega. Si la dependencia afecta a seguridad, calidad o producto regulado, interviene la función competente. Si no se puede demostrar la relación, se bloquea la programación hasta recibir evidencia.

Para una decisión de cuello, consulte preparar la decisión sobre cuello de botella. Para comparar un plan con su ejecución, revise comparar el plan ERP con la ejecución MES y revisar la capacidad real con órdenes ERP abiertas. La guía de reporting operativo y KPIs industriales ayuda a fijar propietarios y definiciones.

Preguntas frecuentes

¿Qué es una dependencia de recurso?

Es la relación entre una operación y el equipo, estación o capacidad que necesita dentro de una ventana. Puede incluir una alternativa autorizada y condiciones de preparación.

¿Una dependencia equivale a un cuello de botella?

No. Una dependencia puede existir sin saturación. Para hablar de cuello hace falta revisar carga, capacidad, estados y ventana con datos locales.

¿Cómo trato una estación que comparten dos órdenes?

Registre ambas operaciones, sus ventanas y la regla de exclusión o solape. No ordene las órdenes solo por la fecha visible sin confirmar la autoridad de la secuencia.

¿Qué hago si no conozco el tiempo de cambio de formato?

Marque la dependencia como parcial y solicite el maestro o una observación autorizada. No complete el hueco con un promedio inventado.

¿Qué evidencia debe quedar antes de programar?

Recurso, operación, ventana, alternativa, estado, versión del plan, propietario, fuente de cada dato y comprobación posterior sobre otra orden.