Status LED Codes

Algunos temas residuales

¿Podemos empezar a construir ya el procedimiento de subordinación? Todavía no, todavía tenemos algunos puntos que hay que refinar.

Cuando hablamos de nivelar los picos hacia atrás en el tiempo, ¿Cómo vamos a tratar un pico creado por una actividad de una línea roja? Si pasamos esa actividad a una fecha anterior, también tendremos que mover el bloque correspondiente, es decir, la actividad que hace la limitación. Yo pensaba que subordinar no significaba modificar, sino seguir.

Bien, es evidente que los picos creados por una actividad en línea roja, «picos de línea roja» para abreviar, necesitan una atención especial.

Primero tenemos que comprobar si esta situación se da de verdad en nuestro pico de línea roja, en otras palabras, si la nivelación del pico crea la necesidad de mover el bloque correspondiente. Esto sólo ocurrirá cuando no haya «holgura», cuando la fecha del bloque no sea anterior a la fecha de envío menos al buffer de envío. Como ya dijimos, o al menos indicamos, este no es siempre el caso. A veces, el bloque está situado mucho antes debido a un pico de carga en la limitación. Otras veces, un pedido genera más de un bloque, y si la fecha de entrega del pedido se cambia debido a la existencia de un bloque rojo, todos los demás bloques tendrán «holgura».

Si hay suficiente holgura, el pico de línea roja no requiere un tratamiento especial. Si no la hay, tendremos que ocuparnos de él.

Primero, recordemos que en estos casos extremos nos conformamos con la mitad del buffer. Si dejamos el pico como está, este trabajo generará un agujero en el origen de buffer; por cada hora sobre la capacidad disponible (en la fecha del pico) el agujero penetrará una hora en el origen del buffer. Esto equivale, de hecho, a nivelar hacia adelante, sacrificando la protección.

Supongamos que hemos usado este margen al máximo y todavía tenemos el agujero. Ahora usamos el permiso para hacer horas extras, si está disponible. Si esto tampoco ayuda, avisamos al usuario. El usuario tendrá

216 _{EL SÍNDROME DEL PAJAR} ALGUNOS TEMAS RESIDUALES 217

que elegir entre autorizar horas extras adicionales (el sistema tendrá que decir cuántas más hacen falta), desviar el trabajo a otro recurso (el sistema tendrá que decir cuál es la cantidad mínima que hay que desviar), o retrasar el pedido (el sistema tendrá que decir hasta qué fecha). ¿Hay más posibilidades? Puede que el usuario sepa que el problema ha ocurrido porque los datos son erróneos, y puede que decida indicar al sistema que ignore el pico y que continúe.

Pero, ¿qué sucede si es un problema real? ¿Qué puede hacer el usuario si ninguna de las posibilidades que se han mencionado son factibles? Entonces, parece que tenemos una limitación adicional, ¿no es sí? El recurso que tiene el pico se debe considerar como limitación, y el sistema debe abandonar todo intento de continuar en esta fase. Hemos conseguido un objetivo intermedio: hemos identificado otra limitación. El sistema debe pasar a la siguiente fase, resolver los conflictos entre las limitaciones identificadas.

Parece que esto suena bien. Pasemos a otro punto pendiente. Me gustaría preguntar cómo tenemos en cuenta el tiempo que hace falta para realizar la operación en sí. Entiendo que estamos teniendo en cuenta el impacto que tienen los tiempos de proceso sobre el tiempo total de proceso (lead-time), a través de las cargas que suponen para los recursos. También entiendo, y estoy de acuerdo, que la contribución directa del tiempo de proceso es bastante pequeña, pero aun así, los tiempos de proceso contribuyen en alguna medida. Si tenemos los datos necesarios, ¿por qué no tenemos en cuenta esta contribución directa?

Veamos. Lo que se sugiere es calcular el tiempo que se tarda en hacer un lote en cada operación, multiplicando el tiempo de proceso unitario por el número de unidades requeridas, añadir el tiempo de cambio y, después, sumar los resultados a lo largo de la secuencia de operaciones necesarias para hacer el trabajo. Observen lo que sucederá si seguimos esta sugerencia.

Supongamos que estamos tratando con una línea industrial. Supongamos que la línea tiene diez centros de trabajo distintos, y que el tiempo de proceso de una unidad varía de menos de un minuto a más de dos minutos entre los distintos centros de trabajo. Ahora tomemos un caso en el que el pedido es de varios cientos de unidades. ¿Qué conseguiremos si seguimos esa sugerencia? Como el tiempo de proceso de todo el pedido en cada centro de trabajo es, aproximadamente, de un día, obtendremos la impresión de que, aunque no haya perturbaciones, tardaremos en terminar el pedido, aproximadamente, una semana. Es ridículo, sabemos que sólo se tarda un día, más o menos.

Si tenemos en cuenta el tiempo necesario para hacer todo un lote en cada operación, estamos ignorando la posibilidad de solapar los lotes entre

las distintas operaciones. Como en el caso de una línea de montaje, aunque se tarde un día en terminar el pedido en un centro de trabajo, eso no impide que el siguiente centro de trabajo empiece a trabajar en cuanto esté terminada la primera unidad. Como pueden ver, si nos preguntamos cuál es la contribución directa de los tiempos de proceso, resulta que es aún más pequeña de lo que pensábamos. Si, como en el caso de una línea de montaje, no hay problemas de disponibilidad de recursos, y Murphy no existe, entonces el tiempo que se tarda en terminar el pedido es casi igual al tiempo requerido para procesar el pedido en un solo centro de trabajo: el que tenga el tiempo de proceso más largo. Si queremos ser aún más precisos, el tiempo que se tarda en hacer el pedido es igual al tiempo que se tarda en hacerlo entero en la operación más larga, más la suma del tiempo que se tarda en hacer una unidad en cada una de las demás operaciones. Esto siempre resulta ser ridiculamente pequeño comparado con la disponibilidad no instantánea y con Murphy. ¿Por qué nos tenemos que molestar en calcularlo sólo porque los datos estén disponibles?

Lo que se ha dicho no suena mal, pero se está presumiendo la capacidad de solapar actividades a lo largo de todas las operaciones necesarias para realizar el trabajo. Esto no siempre es posible. No me estoy refiriendo a entornos en los que, sin duda, es posible, pero en los que está prohibido por alguna política ridicula que se escuda en la falsa pretensión de un mejor control. No, en esos entornos deberían elevarse las limitaciones políticas. Me refiero a situaciones en las que el solape no es práctico por limitaciones técnicas. Por ejemplo, un horno que funcione por lotes enteros, en el que una vez que entra el lote y se cierra la puerta, todas las unidades del lote tienen que esperar hasta que se termine el proceso y se abra la puerta. El transporte es otro caso en el que de ninguna manera podemos dedicar una camioneta a cada unidad. En los casos en los que se procesa junto todo el lote, técnicamente no existe la posibilidad de solapar.

Así pues, la contribución del tiempo real de proceso al tiempo total de proceso (lead-time) es el tiempo necesario para procesar el lote en la operación más larga, más el tiempo necesario para procesar el lote en las operaciones que

no se pueden solapar, más el tiempo de proceso de una unidad en el resto de las

operaciones. Tenemos todos los datos necesarios, ¿por qué no los usamos? Bien, si insisten. ¿Podemos empezar ya con el mecanismo de subordi- nación, o hay algo más?

Una última pregunta, si aún le queda paciencia. ¿Debemos intentar ahorrar tiempos de cambio durante la fase de subordinación?

¿Por qué íbamos a tener que hacerlo? ¿Cuál es el propósito de ahorrar tiempos de cambio? ¿Qué es lo que en realidad estamos ahorrando? No es

218 EL SÍNDROME DEL PAJAR ALGUNOS TEMAS RESIDUALES 219

dinero, sino tiempo. ¿Podemos hacer algo con este tiempo? ¿Nos ayudará a incrementar los ingresos netos? Los ingresos netos vienen determinados por las limitaciones de la organización, y aquí sólo estamos tratando con los recursos no limitados. Si un recurso no tiene suficiente capacidad por culpa de los tiempos de cambio, lo consideramos como limitación y tratamos los tiempos de cambio consecuentemente. Así que, ¿por qué nos tenemos que preocupar de los tiempos de cambio durante el proceso de subordinación?

Los ingresos netos no son lo único que afecta a nuestro resultado. También tenemos que considerar, aunque en menor medida, el inventario y los gastos operativos. Veamos si esto nos obliga a considerar el ahorro de tiempos de cambio, incluso en la fase de subordinación.

Siempre que intentamos ahorrar tiempo de cambios tenemos que «saltan» un lote que de no ser así, se haría en un futuro más remoto. Al ahorrar cambios aumentamos el inventario, y las consideraciones sobre inventario nos aconsejan alejamos de los intentos de ahorrar tiempo de cambios.

A menos que la contribución del tiempo de cambio sea tan grande que cree una limitación, por supuesto. Si este es el caso, tenemos que pagar con inventario para proteger de las perturbaciones a la limitación. Decidamos hacer dos cosas. La primera es intentar ahorrar cambios antes de considerar una segunda limitación en los recursos. Recordemos que al identificar el primer recurso limitado utilizamos el mínimo tiempo de cambios (un cambio por cada código de pieza/operación, no por cada pedido), que es equivalente al máximo ahorro posible de tiempos de cambio.

¿En qué momento intentamos identificar una limitación adicional en los recursos? Cuando hemos terminado la fase de subordinación y tenemos un pico de carga que no podemos nivelar hacia el pasado. En este punto examinaremos todos los lotes del pico e intentaremos conseguir todos los ahorros posibles en los tiempos de cambio. Dudo que esto vaya a suponer mucho, pero, probablemente, nos ayudará a reducir la cantidad de horas extras y de desvíos que harían falta para resolver el pico sin tener que considerarlo como recurso limitado.

Además, podemos hacer otra cosa. Si los cambios son importantes en nuestro entorno, entonces, vamos a identificar muy pronto un recurso limitado que requerirá que «peguemos» muchos de sus bloques. Si en la subordinación, en vez de considerar cada bloque original por separado, tratarnos una serie de bloques pegados como si fuera un solo bloque, ahorraremos muchos cambios en los recursos que alimentan a la limitación. En este caso ya habremos pagado la mayoría de la penalización por inventario, ya que el programa de la limitación tuvo que desplazar los bloques. La penalización adicional que supone tratar los bloques pegados

como si fueran un solo bloque es relativamente pequeña, y la posibilidad de ayudar es relativamente grande.

¿Podemos ahorrar tiempos de cambio para reducir su impacto en los gastos operativos? esto sería ir demasiado lejos, la única forma efectiva de influir en los gastos operativos es reduciendo la necesidad de horas extras. ¿Dónde permitimos las horas extras? En el tambor (programa de la limitación), donde, de todas formas, ya estamos intentando ahorrar cambios; en los picos de carga del primer día, donde, de nuevo, ya hemos decidido ahorrar cambios; y en los picos de líneas rojas. En este último caso, de todas formas, no podemos desplazar el lote hacia el pasado. Así que, ¿de qué estamos hablando en realidad?

Bien, ya es suficiente. Vamos a construir un procedimiento que permita que la subordinación tenga en cuenta, adecuadamente, la capacidad de los recursos no limitados.