Supuestos de reorganización sin prometer capacidad

Una reorganización de familias de producto suele empezar como una hipótesis de trabajo: quizá una línea pueda recibir una referencia que hoy se fabrica en otra, quizá el calendario necesite una secuencia distinta o quizá una restricción temporal obligue a preparar una alternativa. El problema aparece cuando la hipótesis se presenta como un plan confirmado. Documentar supuestos permite explorar la pregunta sin convertir una posibilidad en una promesa de capacidad, ahorro o servicio.

El expediente debe distinguir tres cosas. Un hecho tiene una fuente, una fecha y un alcance que otra persona puede revisar. Un supuesto es una condición provisional que hace posible dibujar un escenario. Una decisión es una autorización con propietario y controles. Mezclarlos en una única cifra borra qué está demostrado y qué necesita validación. Esta página ayuda a ordenar el primer expediente; no aprueba mover una familia, cambiar una receta o modificar un contrato.

La intención es informativa y está dirigida a dirección industrial y operaciones. Para separar el efecto del mix puede consultar comparar líneas sin mezclar el mix. Para contrastar escenarios de producción sin convertirlos en una promesa, revise comparar escenarios de producción sin prometer resultado. Esas guías aportan contexto, no sustituyen la gobernanza local de calidad, seguridad, personas, logística, clientes y contratos.

La guía de decisión industrial con KPI de planta ayuda a ordenar la conversación de dirección antes de evaluar el expediente. Aquí el enlace solo aporta marco; los supuestos de la posible redistribución deben seguir identificados y pendientes de validación local.

Defina la pregunta de reorganización

Empiece con una frase que indique qué se está estudiando y qué no. «¿Qué tendríamos que comprobar para estudiar el traslado de la familia F de la línea A a la B durante el cuarto trimestre?» es una pregunta acotada. «¿Podemos fabricar F en B?» ya suena a autorización y puede ocultar dependencias. Añada question_version, decision_owner, request_date y decision_scope. Si cambia la pregunta, abra una revisión nueva.

El escenario necesita un identificador estable, por ejemplo scenario_id=F-A-B-q4-v1. El identificador no debe codificar una conclusión como scenario-best. Guarde parent_scenario, supersedes, created_at, review_due y status. status admite draft, evidence_ready, validation_required, blocked, reversible_test, approved_by_owner y retired. La etiqueta «aprobado» solo puede emplearse si la autoridad está documentada; un borrador no se vuelve aprobado porque tenga una cifra.

Declare el horizonte: fechas, ciclos de planificación y vigencia de la demanda que se está usando. Un dato anual, un plan mensual y una ventana de turno responden a preguntas distintas. No mezcle un supuesto de largo plazo con una restricción de la próxima semana sin señalar el cambio de horizonte. Si hay varias escalas, registre un escenario por escala y explique cómo se relacionan.

Separe hechos, supuestos y preguntas abiertas

Un registro útil tiene una fila por condición. Incluya assumption_id, descripción, tipo, valor, unidad, fuente, fecha efectiva, propietario, nivel de confianza, fecha de expiración y prueba de confirmación. El tipo puede ser fact, assumption, dependency, unknown o decision. El valor «desconocido» es preferible a un cero inventado: cero significa que se observó ausencia; desconocido significa que la evidencia falta.

La redacción debe preservar el matiz. «La línea B tiene 20 horas libres» no es defendible si solo se observó un calendario. «El calendario de B muestra 20 horas programadas sin orden asignada en la extracción del 8 de agosto; queda por comprobar disponibilidad técnica y de personal» separa el hecho de la incertidumbre. No use un porcentaje de confianza si la organización no ha definido cómo se calcula.

Para cada supuesto escriba también una condición de rechazo. Si la receta, la herramienta o la autorización de calidad cambia, el supuesto deja de aplicar. Esa cláusula evita que un escenario se mantenga vivo por inercia. Conserve la versión retirada y el motivo; no reescriba la fila original para que parezca que siempre fue correcta.

Dibuje el perímetro de la familia

Una familia no es solo un prefijo de SKU. Registre referencias, formatos, materiales, rutas, tolerancias, limpieza, inspecciones y clientes cuando cambien la secuencia o el control. Añada family_scope_version y una lista de exclusiones. Si una referencia tiene un requisito regulado o un cliente que exige validación previa, esa dependencia debe quedar visible aunque el volumen sea pequeño.

Especifique línea de origen, destino y recursos alternativos. asset_boundary debe decir si incluye equipos compartidos, laboratorio, almacén, transporte, software y personal certificado. Una reorganización puede parecer viable al mirar la máquina y dejar de serlo al incluir una cámara de curado o una inspección que solo existe en la línea de origen. No asuma que un recurso compartido se duplica porque aparezca en dos diagramas.

La unidad y la regla de calidad también forman parte del perímetro. Mantenga unidades locales y reglas de conversión con versión, propietario y vigencia. No transforme kilogramos en unidades mediante un factor de una presentación antigua. Si la familia utiliza tamaños distintos, construya escenarios separados o deje la comparación en validation_required.

Catalogue restricciones y dependencias

Las restricciones son condiciones que limitan el escenario; las dependencias son pasos o decisiones de terceros que deben ocurrir antes. Use constraint_id, tipo, recurso, ventana, propietario y estado. Ejemplos: capacidad de horno, herramienta crítica, liberación de calidad, contrato de suministro, formación, seguridad, espacio de almacén o ruta de cliente. No asigne causalidad si solo se sabe que la condición existe.

Una dependencia debe tener un evento de salida: prueba de proceso, aprobación de calidad, validación de seguridad, confirmación logística o aceptación del cliente. Registre dependency_status=pending|met|rejected|unknown. Si la dependencia no tiene propietario, el escenario no está listo para una decisión. Es mejor mostrar una casilla bloqueada que publicar una capacidad hipotética.

Considere restricciones energéticas y de servicios, pero no reparta datos agregados entre familias. La encuesta cubre combustibles usados por la industria; electricidad y gas son los principales productos energéticos en 2024. INE, consumos energéticos La fuente sirve para contexto sectorial y tiene alcance agregado; no demuestra que la línea B tenga una potencia disponible ni que el traslado reduzca un coste. Para decidir se necesitan submedición, condiciones de operación y revisión local.

Mantenga una línea base y escenarios aislados

La línea base describe cómo se fabrica la familia ahora. Incluya la ventana, el mix, la ruta, la unidad, el cierre y las restricciones observadas. No elija como base un día excepcional sin explicarlo. baseline_id debe apuntar a una extracción reproducible y a un hash del conjunto de datos; el hash no convierte el dato en verdadero, solo permite saber qué versión se revisó.

Cada escenario cambia una condición a la vez cuando sea posible. scenario_id, change_set, horizon, expected_effect y unknowns ayudan a evitar comparaciones ambiguas. «B recibe F» es insuficiente; «B recibe F en la ventana de octubre, con la receta v3, una prueba de lote y el mismo requisito de inspección» es un escenario comprobable. Si se cambian receta, calendario y proveedor simultáneamente, registre las interacciones o cree escenarios separados.

No ordene escenarios por una cifra sintética si no existe una regla de decisión aprobada. Puede presentar un mapa de opciones con columnas de evidencia, dependencias, reversibilidad y preguntas abiertas. El objetivo del primer expediente es saber qué hay que validar, no elegir un ganador. Una opción de prueba reversible puede ser más informativa que una predicción de volumen, pero debe tener límites, duración y autorización.

Revise transición, calidad y servicio

Mover una familia implica una transición. Registre transition_start, transition_end, inventario en curso, limpieza, formación, documentación, pruebas y plan de retorno. El escenario no debe suponer que la línea de destino puede producir mientras se valida la receta. Si la prueba requiere material o tiempo de laboratorio, añada esa dependencia y su propietario.

La calidad tiene su propio estado de decisión: not_started, in_test, accepted, rejected o expired. No confunda una primera pieza correcta con una validación completa. Revise especificaciones, trazabilidad, retención, muestreo y liberación. Si existe un cliente con homologación, documente su paso. La reorganización no queda aprobada porque el KPI de salida se parezca al de la línea de origen.

El servicio y la logística también deben quedar en el escenario. Indique rutas, tiempos de transporte, almacenes, etiquetado, fechas de entrega y contingencias. Un traslado puede cambiar la secuencia de expedición aunque la máquina tenga tiempo disponible. Registre la condición «sin cambio de promesa al cliente» como supuesto que requiere confirmación, no como hecho. Evite prometer un nivel de servicio basado en una simulación no validada.

Use evidencia externa solo como contexto

El IPI mide la evolución mensual de la actividad productiva; el último dato visible en la consulta fue mayo de 2026. INE, IPI El índice describe una población agregada y puede tener datos provisionales. No mide la capacidad de una línea ni prueba que una familia deba trasladarse. Úselo para fechar el contexto de actividad, manteniendo separado el registro local.

Las ventas de productos manufactureros de 2025 y su distribución territorial sirven como contexto de mercado, no como prueba de capacidad individual. INE, Encuesta Industrial Anual de Productos La encuesta aporta una visión anual y agregada. No permite inferir disponibilidad, mix, calidad o logística de las líneas del escenario. Si el supuesto depende de demanda, adjunte la fuente comercial autorizada y su horizonte, no una cifra nacional como sustituto.

La ECI se diseña como indicador adelantado para seguir la coyuntura industrial; usarla para contexto, no para justificar CAPEX. Ministerio de Industria, ECI Una señal de coyuntura no autoriza una inversión ni una reorganización. La encuesta TIC del INE describe analítica, nube e IA por sector, pero no demuestra que las fuentes internas del escenario estén integradas.

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST, operations-driven performance measurement La investigación ayuda a formular una caracterización y a discutir compromisos, pero no ofrece un resultado para una reorganización española. La aplicación local sigue requiriendo datos, autoridad y revisión humana.

NIST define el gobierno de información manufacturera como principios para procesar y usar datos de forma consistente, repetible y confiable. NIST, foundations of information governance El alcance es metodológico y no sustituye las normas, controles de privacidad, calidad o seguridad de la organización. Use la referencia para ordenar definiciones y responsabilidades, no para afirmar conformidad.

Establezca puertas de decisión

Una puerta de decisión es una comprobación con entrada, propietario, salida y criterio de bloqueo. Ejemplos: «calidad confirma la receta y la trazabilidad», «mantenimiento valida la herramienta», «logística confirma la ruta» o «planificación verifica la ventana». Evite puertas vagas como «revisar capacidad». Especifique qué documento o prueba cerrará la puerta y cuándo caduca.

Un escenario puede tener cuatro salidas: continuar a validación, mantener como hipótesis, ejecutar una prueba reversible o bloquear. blocked_reason debe explicar la dependencia, no culpar a un área. reversible_test necesita alcance y retorno: lote limitado, ventana, condición de parada y responsable. La prueba tampoco garantiza la capacidad futura; solo produce evidencia para la siguiente revisión.

Registre una decisión con decision_id, decision_owner, fecha, versión del escenario, fuentes y límites. Si cambia una condición material, no edite la decisión histórica. Abra scenario-v2, vuelva a calcular el conjunto de evidencias y pida la autoridad correspondiente. El historial evita que una recomendación provisional aparezca después como un compromiso firme.

Plantilla de expediente y revisión humana

scenario_id, scenario_version, status
family_scope_version, origin_line, destination_line
horizon_start, horizon_end, baseline_id
assumption_id, statement, type, source, as_of
owner, expires_at, confidence, verification
constraint_id, dependency_id, resource, window, state
quality_state, safety_review, logistics_review, customer_review
change_set, unknowns, reversibility, blocked_reason
decision_owner, review_due, input_hash, content_hash

Antes de compartir el documento, una persona revisora debe contestar: ¿qué es un hecho?, ¿qué es un supuesto?, ¿qué fuente y fecha soportan cada afirmación?, ¿qué cambia entre línea de origen y destino?, ¿qué dependencia bloquea?, ¿qué se puede revertir?, ¿qué decisión no está autorizada? Si una respuesta no está en el expediente, añada una pregunta abierta en lugar de rellenar el campo.

La revisión final debe conservar el original, la transformación y la salida publicada. Anote claims_revalidated, reviewed_at y el hash de bytes de la versión. La humanización del texto no cambia el contrato factual: si una frase suena demasiado segura, vuelva a escribirla para mostrar la condición y el límite, y vuelva a revisar el claim que la sostiene.

Haga una prueba de sensibilidad sin inventar cifras

Una revisión de sensibilidad no necesita fabricar un pronóstico. Puede preguntar qué ocurre con el escenario si cambia una condición: la fecha de liberación, el tamaño de lote, la disponibilidad de una herramienta, la ruta logística o la caducidad de un supuesto. Registre cada variante como scenario_child, indique qué campo cambió y marque el resto como constante solo si existe una razón documentada. Si no se puede mantener constante, explique la interacción y no ordene las variantes.

La salida puede ser cualitativa: stable, sensitive, unknown o blocked. «Sensitive» significa que la decisión depende de ese supuesto y requiere una prueba; no es una probabilidad de éxito. Para cada variante, conserve la evidencia que se mantiene, la evidencia que falta y el propietario de la siguiente comprobación. Así la dirección ve qué dato merece atención antes de pedir una simulación o una inversión.

Pasajes verificables de las fuentes

El IPI mide la evolución mensual de la actividad productiva; el último dato visible en la consulta fue mayo de 2026. INE, IPI

Las ventas de productos manufactureros de 2025 y su distribución territorial sirven como contexto de mercado, no como prueba de capacidad individual. INE, Encuesta Industrial Anual de Productos

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 desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST, operations-driven performance measurement

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

Preguntas frecuentes sobre supuestos de reorganización

¿Documentar un supuesto significa que la reorganización está aprobada?

No. El registro hace visible qué se está suponiendo y qué falta comprobar. La aprobación requiere los controles y autoridades de la organización, incluidos calidad, seguridad, personas, contratos, logística y clientes.

¿Puedo usar la producción histórica para demostrar capacidad de destino?

No por sí sola. La producción histórica describe una ventana y unas condiciones concretas. La capacidad de destino exige una definición local, recursos disponibles, calidad, mantenimiento, materiales y una revisión autorizada.

¿Qué diferencia hay entre un hecho y un supuesto?

Un hecho tiene fuente, fecha y alcance verificables. Un supuesto es una condición que se adopta provisionalmente para explorar un escenario y que debe tener propietario, caducidad y prueba de confirmación o rechazo.

¿Cómo trato un escenario que no puede ejecutarse todavía?

Marque el escenario como bloqueado, explique la dependencia y defina el siguiente paso permitido. No rellene el vacío con una cifra estimada ni lo mezcle con un escenario aprobado.

¿Cuándo debo retirar un supuesto?

Cuando expire su fecha, cambie la receta, el contrato, la demanda, el recurso o la evidencia, o cuando la revisión lo confirme o lo rechace. Conserve el historial y abra una versión nueva en lugar de sobrescribirlo.