Un proveedor de autopartes en Aguascalientes y las entregas justo a tiempo

Resumen:

• El programa de producción y el calendario de embarques eran dos documentos sin relación entre ellos.
• El pizarrón no falla por ser pizarrón: falla por ser una copia única consultable en un solo lugar.
• La ventana de andén es la restricción real, no el plazo promedio de entrega.
• Una alerta sin destinatario con autoridad para actuar es ruido.

Un taller de inyección de plástico en Aguascalientes, proveedor de segundo nivel para la industria automotriz. Alrededor de cincuenta personas, doce máquinas y entregas a cuatro clientes de primer nivel con ventanas de andén definidas.

El taller producía bien y entregaba mal. La diferencia entre esas dos cosas es lo que nos pidieron resolver.

El costo de perder una ventana

En este tipo de cadena, la entrega no se juzga por el día: se juzga por la ventana. Llegar cuatro horas antes puede ser tan problemático como llegar dos horas tarde, porque el andén del cliente está programado y no hay espacio para recibir fuera de tiempo.

El taller tenía dos documentos y ninguna relación entre ellos. Un programa de producción en un pizarrón, escrito por el jefe de planta cada semana y corregido a mano todos los días. Y un calendario de embarques que el jefe de logística llevaba en una hoja de cálculo propia.

Los dos documentos eran correctos por separado. El problema aparecía en el cruce, y aparecía tarde.

Órdenes liberadas en el orden equivocado. Se producía primero lo que estaba primero en el pizarrón, sin considerar cuál ventana de embarque vencía antes. Una pieza con embarque el jueves se adelantaba a otra con embarque el martes.

Cambios de molde mal colocados. Un cambio de molde consume tiempo de máquina. Al no ver el calendario de embarques, el programa agrupaba por conveniencia de moldes y a veces ese agrupamiento dejaba una ventana sin cubrir.

Embarques parciales improvisados. Cuando no alcanzaba, se mandaba lo que había. Cada embarque parcial generaba una llamada al cliente, una nota en el sistema de calidad del cliente y, al acumularse, una revisión del estatus de proveedor.

Fletes extraordinarios. Perder una ventana obligaba a mover material fuera de programa. No vamos a hablar del impacto económico, pero conviene decir que la frecuencia era semanal y que ese era el síntoma que llevó a la dirección a actuar.

Lo que se intentó antes

Dos intentos, los dos con la misma falla de fondo.

El primero fue pasar el pizarrón a una hoja de cálculo compartida. Mejoró el acceso y empeoró la actualización: el jefe de planta seguía corrigiendo en el pizarrón porque estaba en planta y la hoja estaba en la oficina. A las dos semanas había dos programas distintos.

El segundo fue una junta diaria de media hora entre planta, logística y ventas para alinear. Funcionó mientras duró la disciplina, unos tres meses. El problema es que una junta diaria sincroniza una vez al día y los cambios ocurren varias veces al día.

Ese antecedente definió un requisito: cualquier cosa que construyéramos tenía que actualizarse desde el piso y ser consultable desde el andén. Un sistema que requiera ir a una computadora de oficina reproduce el problema del pizarrón con más pasos.

La decisión central: la ventana de embarque manda

La primera decisión fue invertir la relación entre los dos documentos. El calendario de embarques dejó de ser una consecuencia del programa de producción y pasó a ser su restricción de entrada.

En términos de modelado: cada requerimiento del cliente se carga con su ventana de andén. Una orden de producción no existe suelta, existe ligada a uno o varios embarques. El sistema calcula, para cada embarque, la hora límite en la que la producción debe estar terminada y empacada, descontando el tiempo de empaque, inspección y traslado.

Esa hora límite es lo que se muestra al liberar órdenes. El jefe de planta sigue decidiendo el orden, pero decide viendo cuál es la hora límite real de cada pieza y no una fecha de entrega genérica.

El requerimiento del cliente se carga como archivo, no por integración directa con el portal. Fue una decisión deliberada. La integración era técnicamente posible y se descartó para esta etapa por dos razones: los portales de los cuatro clientes son distintos y mantener cuatro integraciones es un costo permanente; y más importante, automatizar la entrada antes de ordenar el proceso interno habría acelerado el desorden en lugar de resolverlo. Quedó anotada para cuando el proceso esté estable.

La liberación de órdenes con el molde como restricción

La segunda decisión fue cómo representar la capacidad. Una inyectora no es intercambiable con otra: depende del molde, del tonelaje y del material.

Se modelaron tres restricciones y se dejaron fuera varias más.

• Compatibilidad molde-máquina. Qué moldes pueden montarse en qué inyectoras. Es un dato fijo y conocido.
• Tiempo de cambio de molde. Estimado por par de moldes, porque cambiar entre dos moldes parecidos no cuesta lo mismo que entre dos distintos.
• Material cargado. Cambiar de material implica purga, y producir dos piezas del mismo material seguidas ahorra ese tiempo.

Lo que se dejó fuera: optimización automática de la secuencia. Se construyó un prototipo que proponía la secuencia óptima considerando las tres restricciones y las ventanas. Técnicamente funcionaba. En la práctica el jefe de planta lo ignoraba, y tenía razón: el modelo no sabía que una máquina estaba sonando raro, que un operador con experiencia en un molde específico estaba incapacitado, ni que el material de un lote venía con humedad.

Se cambió el enfoque. El sistema no propone la secuencia: muestra el costo de la secuencia que el jefe de planta está armando. Si al mover una orden una ventana queda en riesgo, lo dice en el momento. La decisión sigue siendo humana y está informada.

Ese cambio de alcance fue el que hizo que el sistema se usara.

Las alertas: pocas, con dueño y con tiempo

La tercera decisión fue el diseño de las alertas, y es donde más fácil se arruina un proyecto de este tipo.

La primera versión tenía nueve alertas. En dos semanas el grupo donde llegaban estaba silenciado por todos. Es el resultado esperable: una alerta que llega muchas veces al día deja de ser información y se vuelve fondo.

Se rediseñó con tres criterios estrictos. Una alerta solo existe si llega con tiempo suficiente para hacer algo, si tiene un destinatario individual responsable de ese algo, y si no se repite por el mismo hecho.

Tres alertas. Las otras seis se convirtieron en columnas de una pantalla que se consulta, no en mensajes que interrumpen. La distinción entre lo que empuja y lo que se consulta fue la decisión de diseño más importante de todo el proyecto.

Los errores que cometimos

Además del optimizador que nadie usó y de las nueve alertas, hubo dos errores con costo.

Calculamos la hora límite con tiempos promedio. La primera versión descontaba un tiempo fijo de empaque e inspección. En la realidad el empaque de una pieza con requisito de inspección dimensional toma mucho más que el de una pieza sencilla. Las alertas de ventana en riesgo llegaban tarde para las piezas con inspección, que son justo las críticas. Se pasó a tiempos por familia de pieza, medidos durante tres semanas.

Pusimos la pantalla solo en la oficina. Repetimos el error del pizarrón al revés. La información existía y no estaba donde se toman las decisiones. Se agregaron dos pantallas, una en planta y una en el andén, y una vista para teléfono que es la que más se usa.

Cómo se midió el resultado

Se midieron tres cosas, con dos meses de base manual antes de arrancar.

1. Cumplimiento de ventana. Medido como la hora en que la unidad quedó cargada y lista contra la ventana comprometida. Se eligió la hora de listo y no la de salida para no mezclar el desempeño del taller con el del transportista.
2. Embarques parciales. Conteo simple por semana, con la causa anotada.
3. Movimientos extraordinarios. Cuántos envíos fuera de programa hubo que organizar.

El indicador que más información dio no fue ninguno de los tres, sino un subproducto: la distribución de las causas de los embarques parciales. Antes se asumía que la causa principal era capacidad de máquina. Con tres meses de datos, la causa principal era material que llegaba tarde de un proveedor propio, y la segunda era el orden de liberación.

El primer hallazgo no se resolvía con software y se atendió con el proveedor. El segundo era exactamente lo que el sistema estaba hecho para resolver.

Preguntas frecuentes

¿Por qué falla un programa de producción en pizarrón?

No falla por estar en un pizarrón: falla porque es un documento de una sola copia que solo existe en un lugar físico y solo lo entiende quien lo escribió. Nadie puede consultarlo desde el andén, no conserva historia y cuando cambia no queda registro de qué se movió ni por qué.

¿Hay que conectarse al portal del cliente para programar?

No necesariamente, y conviene no hacerlo como primer paso. El requerimiento del cliente se puede cargar como archivo y procesarse. La integración directa tiene valor cuando los cambios son muy frecuentes, pero construirla antes de ordenar el proceso interno solo automatiza el desorden.

¿Qué alerta sirve y qué alerta se vuelve ruido?

Sirve la alerta que llega con tiempo para actuar y que tiene un destinatario con autoridad para hacerlo. Se vuelve ruido la que avisa de algo ya consumado, la que se dispara varias veces por el mismo hecho y la que se manda a un grupo donde nadie es responsable.

¿Esto sustituye al MRP?

No. El cálculo de requerimientos de material sigue donde esté. Lo que se agrega es la capa que liga la liberación de órdenes al calendario real de embarques, que es justo lo que un MRP no ve porque trabaja con plazos promedio y no con ventanas de andén.

¿Cómo se mide el cumplimiento de ventana de embarque?

Comparando la hora en que la unidad quedó cargada y lista contra la ventana comprometida, no la hora en que salió del patio. Medir la salida mezcla el desempeño de la planta con el del transportista y deja sin dueño el incumplimiento.

Si estás en una situación parecida

Si en tu operación de entregas pasa algo similar, el primer paso no es elegir tecnología: es ordenar el proceso y saber qué datos ya tienes. Podemos revisarlo contigo.

Cuéntanos tu caso en westribe.com.mx/solicitar/ o escríbenos por WhatsApp al +52 312 554 2845.