Asignar limpieza a capacidad sin contarla como producción

Una ventana de limpieza suele aparecer en el calendario como una franja única. Para una decisión de capacidad, esa franja necesita más detalle. Preparar herramientas, vaciar una línea, ejecutar el ciclo de limpieza, verificar el resultado y arrancar la siguiente receta no son necesariamente el mismo estado. Si todo se resta como «parada», se exagera la pérdida; si todo se deja como disponible, se promete una producción que la línea no puede comenzar.

La pregunta práctica es más estrecha: ¿qué tramo de esta ventana impide fabricar la orden que se está evaluando?

La ficha local asigna la ventana de limpieza separando preparación, limpieza, verificación, cambio y arranque; descuenta solo el tramo que la regla define como no producible. La respuesta debe usar la definición local de tiempo producible, el calendario, la receta, la calidad y los eventos observados. No se obtiene de una media nacional ni de un estándar sin versión.

Esta ficha prepara un desglose reproducible; no diagnostica mantenimiento, no atribuye causas y no aprueba una inversión.

Para documentar una incidencia puede consultar cuantificar impacto de parada en una orden y la guía de evidencia de paradas y pérdidas. La página actual tiene otra frontera: una limpieza planificada y su relación con la capacidad de una ventana.

Si la limpieza se repite y necesita una vista histórica, consulte priorizar una parada recurrente con evidencia. Esa referencia ayuda a ordenar registros; no convierte una ventana planificada en una pérdida ni sustituye el desglose de esta página.

Lista 1: declare la decisión y la frontera

1. Escriba la pregunta: «¿Qué parte de la limpieza del 12 de agosto debe excluirse de la ventana disponible para la orden F?».
2. Registre window_id, question_version, line_id, recipe_from, recipe_to, calendar_version y decision_owner.
3. Defina la frontera: línea completa, equipo, estación, recurso compartido o ruta de fabricación.
4. Declare qué queda fuera: tiempos de espera de cliente, inventario, transporte o actividades de otro equipo.

La misma limpieza puede bloquear una estación y dejar otra utilizable. No publique una capacidad de línea completa si solo se conoce el estado de una estación. Si una orden atraviesa recursos, conserve la restricción de cada tramo y la regla que decide cuándo la ruta completa está disponible.

Lista 2: divida la ventana en eventos

Use eventos separados, aunque el sistema actual los agrupe:

Evento	Campos mínimos	Pregunta de capacidad
Preparación	prep_start, prep_end, equipo y orden	¿La línea aún podía fabricar?
Limpieza	receta, método, inicio y fin	¿Qué equipo quedó no producible?
Verificación	prueba, resultado y liberación	¿La calidad autorizó arrancar?
Cambio	herramienta, formato y estado	¿El recurso estaba en transición?
Arranque	primera pieza, ajuste y cierre	¿Cuándo comenzó la ventana válida?

Cada evento necesita una fuente, una zona horaria, un estado y un propietario. Si solo existe una marca de inicio y fin, use event_granularity=coarse. No invente fronteras con duraciones estándar. Un evento desconocido puede conservarse como unclassified hasta que mantenimiento, calidad u operaciones lo revisen.

Lista 3: distinga plan, observación y cierre

Guarde planned_start, planned_end, observed_start, observed_end, quality_release_at y capacity_close_at. El calendario puede reservar dos horas y la ejecución durar tres; la diferencia necesita una explicación local. La calidad puede liberar una línea después de que el equipo termine, y el arranque puede comenzar antes de la liberación formal en una prueba no productiva. Mantenga esos estados separados.

Una ventana planificada no es una pérdida observada. Una ventana observada no es una causa. Use plan_status=planned|cancelled|rescheduled, execution_status=started|completed|partial|unknown y release_status=approved|pending|rejected. Si la orden no llegó a la ventana, no convierta la limpieza reservada en producción perdida.

La ECI se diseña como indicador adelantado para seguir la coyuntura industrial; usarla para contexto, no para justificar CAPEX. Ministerio de Industria, ECI La encuesta agrega opinión y expectativas de empresas, pero no mide una limpieza, un equipo o una capacidad local. El dato no sustituye los eventos de la ventana.

Lista 4: defina qué significa «no producible»

Una regla local podría excluir el tiempo en que la línea no puede procesar ninguna orden, pero conservar una preparación que se ejecuta mientras otro recurso trabaja. Otra organización puede considerar toda la ventana bloqueada por seguridad o calidad. Ambas reglas pueden ser válidas para decisiones distintas si están documentadas.

Registre non_producible_rule, rule_version, rule_owner, scope y exceptions. Añada productive_overlap cuando exista trabajo permitido en paralelo. No reste dos veces una limpieza y el cambio que ya está incluido en ella. Si el método no tiene propietario, marque rule_status=pending y no publique una cifra de capacidad.

El resultado debe distinguir:

• blocked_full_window: ningún producto autorizado podía fabricarse.
• blocked_partial_window: solo una parte del equipo o del tiempo quedó bloqueada.
• overlap_allowed: otra operación podía ejecutarse con condiciones explícitas.
• status_unknown: faltan estado, frontera o autorización.

La etiqueta no juzga al equipo. Describe la relación entre ventana, regla y recurso. Si cambia la receta o el nivel de inspección, cree una versión nueva del cálculo.

Lista 5: conecte limpieza con receta y calidad

Una limpieza puede ser obligatoria por cambio de familia, por riesgo de contaminación, por mantenimiento o por una liberación de calidad. Registre cleaning_reason, from_family, to_family, validation_method y quality_owner. No asuma que dos limpiezas con el mismo nombre tienen la misma duración o frontera.

La primera pieza y la liberación de calidad deben tener eventos propios. Un arranque que produce material de prueba no equivale a una salida buena. Conserve first_piece_status, good_qty_after_release, scrap_qty_during_startup y release_decision. Si no hay evidencia, use quality_status=unknown.

Lista 6: use las fuentes como contexto metodológico

NIST distingue datos de órdenes de trabajo y datos generados por equipos, y estudia monitorización/diagnóstico para reducir downtime no planificado. NIST, estrategias de mantenimiento El estudio distingue fuentes y métodos; no demuestra que una limpieza concreta sea downtime no planificado ni que una duración se pueda reducir. La clasificación local sigue siendo necesaria.

ISA describe niveles, objetos e intercambios entre control y empresa; usar para mapear responsabilidades, no para afirmar que una integración cumple ISA-95. ISA-95, resumen El modelo puede ubicar calendario, orden, control y calidad, pero no define cuánto descontar de una ventana local.

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST, medición orientada a operaciones La referencia invita a caracterizar la ventana y sus métricas. No proporciona un estándar español de limpieza ni una cifra de capacidad.

NIST define el gobierno de información manufacturera como principios para procesar y usar datos de forma consistente, repetible y confiable. NIST, information governance La gobernanza exige dueño, versión y revisión. No convierte una regla de cálculo local en una certificación.

Lista 7: calcule la parte que se puede descontar sin doble conteo

Un ejemplo ayuda a fijar la frontera. Suponga que una línea se reserva de 06:00 a 14:00: la preparación ocupa 06:00–06:20, la limpieza 06:20–07:10, la verificación 07:10–07:35 y el arranque controlado 07:35–08:00. No descuente ocho horas por defecto. Guarde cada tramo, indique cuál quedó bloqueado según la regla local y marque si la inspección podía ejecutarse en paralelo.

Si una orden liberada podía entrar a las 07:35 pero calidad no había liberado el lote, la oportunidad sigue pendiente; no la convierta en volumen perdido. El ejemplo debe conservar la zona horaria, las marcas originales y quién confirmó cada frontera.

Cuando falte una marca, el cálculo puede mostrar un intervalo desconocido y pedir la comprobación correspondiente. Esa salida es más útil que rellenar el hueco con una duración estándar.

Una fórmula transparente puede usar window_end - window_start para la duración observada, pero el resultado de capacidad debe aplicar la regla de bloqueo y las superposiciones permitidas. Guarde la duración original y la duración descontada: observed_duration, non_producible_duration, overlap_duration, capacity_excluded_duration. No sustituya la observada por la ajustada.

Si la ventana cruza turnos o medianoche, defina la zona horaria y el corte. Si dos equipos comparten un servicio, indique si el bloqueo es local o común. Si una limpieza termina y la inspección sigue, la capacidad puede continuar bloqueada aunque el equipo ya no esté limpiando. El cálculo debe mostrar esa secuencia.

Pruebe cuatro casos: limpieza cumplida, limpieza prolongada, limpieza cancelada y limpieza con calidad pendiente. Compare el plan y la observación. Un caso sin marca debe producir unknown, no una duración media. La prueba ayuda a saber si el cálculo responde a la decisión o si solo repite el calendario.

Lista 8: prepare una salida auditable

Incluya window_id, línea, receta, orden, eventos, regla, duración observada, duración descontada, estado de calidad, fuente, propietario, revisión y siguiente comprobación. Muestre la evidencia que soporta cada frontera. Si la limpieza aparece como una sola fila, explique qué partes no se pudieron separar.

Una dirección puede recibir un resumen de ventanas por familia, pero la ficha debe conservar el detalle local. No promedie limpiezas de recetas diferentes sin una regla. No compare una planta con otra usando una definición de «limpieza» que no comparten. La salida correcta puede ser «no comparable con datos actuales».

Lista 9: contrato técnico

window_id, line_id, order_id, recipe_from, recipe_to
calendar_version, planned_start, planned_end, timezone
prep_start, prep_end, clean_start, clean_end
verification_start, release_at, change_start, change_end
startup_start, first_piece_status, quality_status
non_producible_rule, rule_version, overlap_allowed
observed_duration, capacity_excluded_duration
source_system, event_granularity, evidence_hash
window_status, decision_owner, review_owner, next_check

Conserve el hash de la versión publicada y el registro original. Un cambio de receta, método de limpieza, frontera o regla de calidad debe abrir una revisión. La humanización del texto no cambia esos campos; si una frase suena causal, vuelva al evento y a la hipótesis.

Lista 10: trate las excepciones sin convertirlas en norma

Una limpieza puede comenzar antes de que termine la orden anterior, ejecutarse en paralelo con una inspección o detenerse por falta de agua, herramienta o autorización. Registre exception_id, condición, inicio, fin, responsable y estado. Una excepción no debe ampliar ni reducir la ventana automáticamente. El owner de la regla decide si el caso pertenece a una categoría existente o si necesita una revisión.

Si una parte del equipo puede trabajar durante la limpieza, indique qué producto, receta y nivel de calidad están permitidos. La capacidad de una estación no equivale a la capacidad de la ruta completa. Conserve parallel_resource, scope y handoff_state. Si el relevo entre equipos no está documentado, marque la frontera como unknown.

La limpieza que se repite por campaña puede tener un patrón, pero un patrón no demuestra una causa. Compare las ventanas solo después de alinear familia, receta, tamaño de lote, calendario y regla de cierre. Una media de duración puede ayudar a planificar, no sustituye el evento observado para descontar capacidad en una decisión concreta.

Lista 11: enlace la ventana con una orden y su oportunidad

Para cada ventana, registre order_before, order_after, campaign_id, demand_window y opportunity_status. Una ventana entre campañas puede no impedir una orden si no había demanda o si la siguiente receta aún no estaba liberada. En ese caso, el tiempo es una reserva planificada, no una pérdida de producción demostrada.

La oportunidad debe tener una definición: una orden liberada que podía usar el recurso, una ventana de entrega que se iba a cumplir o una restricción de secuencia aprobada. Si no existe una oportunidad concreta, mantenga opportunity_status=unknown. No multiplique horas de limpieza por una velocidad nominal para presentar un volumen hipotético.

Cuando la limpieza desplaza una orden, guarde el plan original, el plan revisado y la decisión que autorizó el cambio. Diferencie schedule_shift, material_hold, quality_hold y unplanned_stop. El desplazamiento puede tener varias razones; no seleccione una sin evidencia.

Lista 12: revisión humana y salida para comité

La persona revisora debe contestar: ¿qué receta y frontera entraron?, ¿qué evento marca cada tramo?, ¿qué regla define no producible?, ¿qué orden u oportunidad estaba disponible?, ¿qué calidad autorizó el arranque?, ¿qué parte sigue desconocida? Si una respuesta depende de una suposición, marque el supuesto y su fecha de caducidad.

El resumen para comité puede mostrar ventanas planificadas, observadas, que se pueden descontar y desconocidas. Añada número de órdenes afectadas, estado de calidad, fuente y próxima comprobación. No convierta el resumen en un ranking de líneas ni en una recomendación de inversión. La ficha aporta evidencia y límites; la decisión de mantenimiento o capacidad tiene su propia aprobación.

Lista 13: compruebe la duración y el cierre

No mezcle una duración de reloj con una duración de trabajo. Una pausa del sistema puede cubrir una espera sin que el equipo esté detenido; un registro manual puede comenzar después de que la limpieza haya empezado. Guarde clock_duration, work_duration, system_gap y manual_evidence. Si las señales no coinciden, muestre ambas y deje duration_status=disputed.

El cierre de calidad puede producirse después del arranque, especialmente cuando la primera pieza requiere análisis. Defina si la capacidad se considera disponible al terminar la verificación, al liberar el lote o al iniciar una producción controlada. La regla depende del producto y del riesgo. No use una marca de mantenimiento como sustituto de la liberación de calidad.

La ventana debe sobrevivir a una ejecución repetida. Con el mismo window_id, filtro, zona horaria y versión de regla, el cálculo debe devolver los mismos tramos. Registre query_hash, rule_hash, source_snapshot y generated_at. Si cambia el resultado, explique qué entrada o regla cambió. La idempotencia protege la decisión frente a informes que se regeneran con filtros distintos.

Cuando una limpieza se cancela, no elimine la reserva original. Marque cancelled_at, motivo y autoridad. Cuando se programa de nuevo, enlace la nueva ventana con supersedes. La historia permite explicar por qué una semana tuvo una reserva y la siguiente no, sin contar dos veces el mismo tiempo.

Si la línea comparte agua, vapor, aire o una zona de lavado con otra campaña, registre el recurso común y su ventana. El tramo no producible puede ser mayor que el tiempo del equipo local, pero no debe asignarse sin una regla de reparto. Mantenga la causa como hipótesis y pida al propietario del servicio la comprobación que cierre la frontera.

Pasajes verificables de las fuentes

La ECI se diseña como indicador adelantado para seguir la coyuntura industrial; usarla para contexto, no para justificar CAPEX. Ministerio de Industria, ECI

NIST distingue datos de órdenes de trabajo y datos generados por equipos, y estudia monitorización/diagnóstico para reducir downtime no planificado. NIST, estrategias de mantenimiento

ISA describe niveles, objetos e intercambios entre control y empresa; usar para mapear responsabilidades, no para afirmar que una integración cumple ISA-95. ISA-95, resumen

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST, medición orientada a operaciones

NIST define el gobierno de información manufacturera como principios para procesar y usar datos de forma consistente, repetible y confiable. NIST, information governance

Preguntas frecuentes sobre limpieza y capacidad

¿Toda la limpieza planificada debe descontarse como pérdida?

No. Descuente solo el tramo que la definición local considera no producible para esa orden y ventana. Preparación, inspección o arranque pueden tener reglas distintas y deben conservar sus propios estados.

¿Puedo usar el tiempo estándar de limpieza para calcular capacidad?

Solo como referencia planificada con versión, condiciones y propietario. Para una ventana observada conserve inicio, fin, receta, equipo y estado de calidad; no sustituya el dato real por el estándar.

¿Una limpieza más larga demuestra un problema de mantenimiento?

No por sí sola. Puede coincidir con un cambio de producto, una verificación adicional, una espera de calidad o un evento de material. Registre hipótesis y evidencia separadas antes de atribuir una causa.

¿Qué hago si el arranque se mezcla con la limpieza?

Abra eventos separados o marque la frontera como desconocida. Mantenga el intervalo sin clasificar hasta que una persona autorizada confirme la regla; no asigne todo el tiempo a una sola causa.

¿La ECI valida la capacidad de mi ventana de limpieza?

No. La ECI aporta contexto agregado de coyuntura industrial. No mide telemetría, limpieza, disponibilidad ni causalidad de una línea concreta.