Sistema SMED: cómo sostener el estándar después del cambio

Sistema SMED: cómo sostener el estándar después del cambio

Cuando una línea ya usa SMED, la pregunta diaria no es cómo volver a implantarlo desde cero. Es si el estándar que dejó el equipo sigue describiendo el cambio, qué evidencia permite revisar una desviación y qué mejora merece atención. Un sistema en funcionamiento puede apoyarse en listas específicas, ayudas visuales y comprobaciones funcionales. Trietsch describe esos recursos en su informe de 1992, pero no prescribe una revisión universal por turno ni un formato para una línea concreta.

(Trietsch, Some Notes on the Application of SMED, pp. 14–16 impresas / PDF pp. 22–24)

La propuesta de esta página es un registro de turno con la versión del estándar, el cambio realizado, el tiempo observado, la desviación, las comprobaciones y la acción acordada. Es un diseño editorial hipotético. No procede de Trietsch ni describe datos reales de WizeeMind. El valor está en que otra persona pueda reconstruir qué se comparó y qué quedó pendiente, no en convertir la lista en una auditoría ritual.

Qué significa mantener un sistema ya implantado

Un sistema SMED no es una hoja aislada con pasos escritos. En una operación estable, suele haber una combinación local de estándar de cambio, materiales o útiles preparados, roles, instrucciones visuales y criterios de aceptación. La forma exacta depende del equipo. Esta página no prescribe esos elementos como paquete obligatorio; los usa para formular una pregunta práctica: cuando el cambio termina, ¿qué sabe el siguiente turno de lo que se hizo y de qué forma se apartó del estándar?

El alcance es el seguimiento de un estándar que ya existe. La definición de SMED, la separación completa entre actividades internas y externas y el estudio de un tiempo de cambio tienen páginas propias. Aquí se da por hecho que la organización ya tiene un método local y que el equipo competente ha autorizado su uso. El registro no cambia permisos, condiciones de seguridad ni controles de calidad.

El primer paso es identificar qué versión del estándar se aplicó. «Cambio habitual» no basta si hay variantes, herramientas distintas o condiciones especiales. Una referencia de documento, fecha o revisión ayuda a comparar registros que pertenecen al mismo método. Si el estándar cambia durante el turno, conserva qué versión estuvo vigente en cada operación; no sobrescribas el pasado para hacerlo coincidir con el documento nuevo.

Un registro tampoco convierte la desviación en fallo. A veces el estándar describe una condición ideal y el cambio real tuvo una excepción que fue aprobada. Otras veces no se ejecutó una comprobación, el equipo no estaba en las condiciones esperadas o el dato se anotó de otra manera. Primero se describe lo ocurrido. La causa se investiga aparte y solo se incorpora cuando hay evidencia.

Las herramientas descritas por Trietsch

Trietsch comenta listas de comprobación específicas para el setup, controles visuales y comprobaciones funcionales. También señala que conviene cuestionar continuamente por qué cada actividad permanece en la lista. Esa observación no ordena borrar tareas: plantea revisar su propósito y su relación con el cambio. La decisión de modificar un estándar debe seguir el proceso aprobado de la organización y no depender de una nota de turno.

Una checklist puede ayudar a que no se omita una operación acordada, pero su presencia no demuestra por sí sola que el sistema funcione. Una casilla marcada no enseña qué condición se comprobó, qué versión se usó o qué ocurrió cuando el resultado no coincidió con lo esperado. La ayuda visual puede hacer más legible una secuencia, pero no sustituye la formación ni una instrucción de fabricante.

Una comprobación funcional aporta evidencia solo si está definida y autorizada en el estándar local.

Por eso la pregunta «¿por qué sigue esta actividad en la checklist?» se puede convertir en una conversación concreta: qué objetivo cubre, qué riesgo o condición controla, en qué momento se ejecuta y qué registro muestra su cumplimiento. Si nadie puede contestar, el elemento merece revisión. Eso no autoriza a quitarlo durante el turno. La respuesta puede ser que la actividad sigue siendo necesaria, que está duplicada, que la instrucción requiere aclaración o que falta consultar al responsable.

Trietsch es una nota técnica de 1992: contextualiza estas herramientas, pero no es un procedimiento vigente ni describe la línea del lector. Para ejecutar el cambio, prevalecen el manual OEM y los procedimientos aprobados del centro.

Un registro de turno que se pueda leer al día siguiente

El ejemplo siguiente organiza la información que puede ayudar a revisar un cambio. No es un formato de Trietsch ni una obligación del método. Cada planta debería adaptarlo y aprobarlo antes de incorporarlo a un sistema de trabajo.

Los campos «inicio» y «fin» no son universales. Si se comparan cambios, ambos registros tienen que usar la misma definición del intervalo y condiciones relevantes; la página de medición de SMED aborda esa cuestión con más detalle. Aquí basta con dejar claro que una cifra sin límites declarados no permite interpretar una diferencia. Si se usa un indicador agregado, define su denominador: «cambios registrados» no significa «cambios con todas las comprobaciones documentadas».

No rellenes una meta solo para completar la tabla. LEI describe «single digit» como objetivo del método, no como garantía para cada cambio. Si existe una meta local aprobada, identifica su origen; si no, deja el campo vacío. (LEI, definición de SMED)

En una entrega entre turnos, separa el hecho y la interpretación: «la plantilla de apoyo no estaba donde indica ST-CMB-04; se usó la alternativa autorizada Q-7; falta verificar por qué no estaba preparada». Así se deja la causa abierta y se indica qué puede revisar el responsable: instrucción, inventario o registro de preparación.

Si no hubo desviación, el registro puede decir qué estándar se siguió y qué comprobación se completó. «Sin incidencias» es menos útil cuando no se sabe qué cubría el término. Si una comprobación no se hizo, déjalo visible con su motivo y la ruta de revisión. La diferencia entre «no aplica», «no observado» y «resultado conforme» importa, porque el lector no debe inferir que una tarea se realizó cuando no ocurrió.

Qué hacer con una desviación repetida

Una desviación que aparece varias veces es una señal para revisar, no una causa raíz. Primero confirma que los registros comparados describen el mismo estándar, el mismo equipo o una variante equivalente y los mismos límites de medición. Después identifica qué se repite: una demora, una falta de material, una comprobación incompleta, una variación de resultado o simplemente una manera distinta de registrar. Sin esa clasificación, el equipo puede agrupar casos que no tienen la misma explicación.

La matriz siguiente es un recurso de conversación, no un método diagnóstico:

Regla editorial del ejemplo: revisar primero una desviación repetida o una actividad que quedó pendiente, si ese criterio se ha acordado localmente. Trietsch no prescribe esta prioridad ni un umbral por turno.

Distinguir capacidad y plazo antes de cambiar la checklist

Trietsch denomina bottleneck al recurso que limita la capacidad del sistema y time bridge a un recurso del camino crítico que determina la duración. Las categorías pueden coincidir, pero no significan lo mismo; sus ejemplos son de astillero, no de una planta actual. Un time bridge puede tener capacidad suficiente: lo que determina su importancia es su lugar en la secuencia. (Trietsch, Some Notes on the Application of SMED, PDF pp. 40–43 / impresas pp. 32–35)

Una misma actividad puede cumplir ambos papeles; registra por separado cada resultado que se quiera comprobar. El límite del sistema importa: Trietsch muestra que un departamento puede parecer libre de restricciones cuando se lo analiza solo, aunque el astillero completo sí tenga un recurso limitante. Anota qué proceso se observa, dónde empieza y termina, qué demanda se considera y qué evidencia lleva a plantear la hipótesis.

Que una tarea dure mucho o se repita una incidencia justifica investigar, pero no demuestra por sí solo que ese recurso limite la operación. (Trietsch, PDF pp. 40–41 / impresas pp. 32–33)

El tipo de recurso también cambia la pregunta. Si una máquina limita la capacidad, Trietsch da más peso a las etapas que ahorran tiempo en esa máquina; por sí sola, la preparación externa no añade capacidad al sistema. Si el recurso escaso es el personal, el análisis incluye tanto el setup interno como el externo porque ambos usan ese tiempo de trabajo. Esto no decide quién debe asumir una tarea ni autoriza a moverla.

Sirve para registrar qué recurso se intenta liberar y qué cambio tendría que comprobarse. (Trietsch, PDF pp. 41–42 / impresas pp. 33–34)

Para revisar una desviación, anota cuatro cosas: qué ocurrió, qué resultado se busca, qué recurso o secuencia podría explicarlo y qué comparación permitiría comprobarlo. Mantén la causa como hipótesis hasta que haya evidencia. Si el setup forma parte de una cadena de actividades, define también el intervalo que se va a medir; una espera antes del equipo y el tiempo de ejecución del cambio no son la misma observación.

Trietsch analiza además los buffers que protegen un recurso limitante de quedarse sin trabajo. Su discusión relaciona esos buffers con la variabilidad de los recursos que lo alimentan y señala que SMED puede hacer más predecible el setup. Para el registro, conviene dejar visible si el tiempo anotado incluye una espera o un buffer, en vez de atribuir todo el intervalo a la checklist.

El informe no prescribe cambiar el tamaño de un buffer en una planta concreta; esa decisión requiere los datos y la autorización locales. (Trietsch, PDF pp. 42–43 / impresas pp. 34–35)

Cuando los recursos considerados son máquinas, Trietsch propone este orden lógico de prioridades: (1) recursos que son bottleneck y time bridge; (2) otros bottlenecks; (3) time bridges que alimentan recursos con ambos papeles; (4) otros time bridges; (5) actividades que alimentan esos recursos; (6) actividades que alimentan otros bottlenecks; y (7) las demás.

(Trietsch, PDF p. 43 / impresa p. 35) El orden supone que aumentar capacidad pesa más que acortar el plazo, y acortarlo más que reducir inventario cuando esa reducción no afecta el plazo. (Trietsch, PDF p. 43 / impresa p. 35) Si los recursos considerados son personas, el informe propone centrarse en actividades de etapa 3 en todos los procesos.

(Trietsch, PDF p. 43 / impresa p. 35) La nota aclara que ese orden se aplica a la inversión en hardware; las ideas de thoughtware pueden alentarse al margen de la jerarquía. (Trietsch, PDF p. 44 / impresa p. 36) Los ejemplos son de astillero y dependen del límite del sistema: no son una secuencia universal ni instrucciones para cambiar una checklist. Como aplicación editorial al registro, anota qué recurso alimenta cada tarea.

Trietsch también distingue la reducción del tiempo de setup del beneficio de calidad que pueden aportar mejores ajustes y menos scrap; su análisis de prioridades se concentra en el primer objetivo. Si la revisión local busca calidad, mantenla como resultado separado de capacidad y plazo. No uses una mejora en una medida como prueba automática de las otras. (Trietsch, PDF p. 39 / impresa p. 31)

Cuando la revisión detecta que el estándar está incompleto, registra la propuesta de cambio, la evidencia y la aprobación necesaria. No conviertas una nota en versión vigente. Si se decide modificar la checklist, actualiza el documento por el flujo de control de cambios local y deja una fecha de aplicación. Así, los registros anteriores siguen explicando qué instrucción se usó en su momento.

Si se concluye que no hay que cambiar nada, también puede ser útil registrar por qué se mantiene el elemento. La respuesta reduce la posibilidad de que una pregunta razonable se repita en cada turno. Pero esa explicación debe proceder de la revisión local, no de una afirmación general atribuida al informe de Trietsch.

Preguntas frecuentes

¿Qué conviene estandarizar cuando SMED ya está implantado?

La versión del estándar, el cambio realizado, las comprobaciones acordadas y las desviaciones que requieren revisión. Trietsch describe checklists, ayudas visuales y comprobaciones funcionales, no un registro único para todas las líneas.

¿Hay que revisar el tiempo de cambio en cada turno?

Trietsch no fija una frecuencia universal por turno. La cadencia debe definirse localmente; si se comparan tiempos, hay que declarar el mismo inicio y fin y las condiciones relevantes.

¿Qué datos puede dejar un ejemplo de registro de turno?

El ejemplo propone versión del estándar, equipo, cambio, tiempo observado, desviación, comprobaciones y acción. Es un esquema hipotético, no un formato prescrito por Trietsch.

¿Una checklist por sí sola demuestra que el sistema SMED funciona?

No por sí sola. Puede recordar tareas específicas, pero el registro debe mostrar qué se comprobó y con qué criterio. La lista no prueba un resultado de tiempo ni sustituye una validación local.

¿Cómo se elige la siguiente mejora?

Esta página propone revisar primero una desviación repetida si ese criterio se acordó localmente. Es una regla editorial del ejemplo, no una fase SMED ni una instrucción de Trietsch.