Gestión de los esfuerzos
de mejora de procesos locales
Ya nos hemos dado cuenta de que si queremos reducir el precio que pagamos por la protección, tenemos que concentrarnos en los trabajos que llegan más retrasados al origen de buffer. Conseguir que llegue antes un trabajo, que ya iba a llegar a tiempo en todo caso, no nos ayuda en absoluto a mejorar el rendimiento global. Hemos tratado los trabajos retrasados individualmente: puede que consigamos mucho más si atacamos las causas más comunes de estos retrasos.
Vamos a examinar esta idea tan interesante: utilizar el esfuerzo realizado individualmente en los trabajos para determinar las causas más generales de sus retrasos. ¿Cuál es la secuencia de acciones que llevamos a cabo para acelerar trabajos? Primero determinamos qué trabajos se supone que debe de haber en el origen de buffer. «Se supone que debe de haber» significa con una probabilidad más alta que, digamos, un 90 por 100. Después, comprobamos si, de hecho, están en el origen de buffer. Si no encontramos allí alguno de estos trabajos, empezamos el proceso de aceleración. La primera acción es encontrar dónde se ha atascado el trabajo que está retrasado. Una vez encontrado, actuamos para que siga adelante inmediatamente. Pero, ahora vamos a añadir otro pequeño detalle; vamos a registrar dónde (delante de qué recurso) hemos encontrado el trabajo atrasado. La repetición de este proceso con cada trabajo que se retrase resultará en una lista de recursos, y algunos de ellos aparecerán en la lista muchas veces. ¿Cuál es el significado real de esa lista?
Supongamos que hay un problema en un centro de trabajo; es bastante probable que este problema afecte a la mayoría, si no a todos, de los trabajos que hace ese recurso. Es más, si un problema de un recurso afecta a todos los trabajos, y otro problema en otro recurso sólo afecta a un trabajo, ¿qué problema es más importante? Esta línea de razonamiento, que reconoce que muchos problemas finales tienen uno causa común, nos
120 EL SINDROME DEL PAJAR GESTIÓN DE LOS ESFUERZOS DE MEJORA DE PROCESOS LOCALES 121
lleva a reconocer que los recursos que aparecen con frecuencia en nuestra lista no lo hacen por capricho estadístico.
Si un recurso aparece con frecuencia es porque contiene la causa de un problema que es común a muchos trabajos; puede ser un proceso defectuoso, puede ser un ajuste poco fiable, puede ser una falta de capacidad de protección, o puede ser que el recurso simplemente esté mal gestionado. En cualquier caso, si tratamos con el problema de fondo en el nivel del recurso, en vez de en el nivel del trabajo, no tendremos que acelerar una y otra vez. Eliminaremos, hasta cierto punto, las razones de la aceleración. Si hacemos esto, si guiamos nuestros esfuerzos de mejora de JIT y TQM por esta lista de recursos problemáticos, podremos ir reduciendo la longitud de los buffers de tiempo gradual, pero constantemente.
¿Significa esto que la longitud de los buffers de tiempo siempre se reducirá? No necesariamente. Algunas veces (y debido a la reducción del tiempo total de proceso —lead-time— es muy probable) las ventas aumentarán. El aumento en las ventas conducirá a un aumento de las cargas de producción que absorberá parte de la capacidad de protección disponible y, por tanto, para compensar hará falta aumentar la longitud del buffers de tiempo. Si se hace correctamente —sin perder de vista el objetivo de ganar más dinero— este proceso llevará a oscilaciones controladas de los niveles de inventario.
Puede que nos convenga ampliar nuestros esfuerzos para que nuestra lista de recursos problemáticos resulte más fiable. Recordemos que el tiempo que se tarda en encontrar un problema de fondo suele ser más corto que el tiempo necesario para eliminarlo. Así pues, no deberíamos conformarnos con los datos que reunimos durante nuestras actividades de aceleración de trabajos, deberíamos ampliar nuestro seguimiento para cubrir tareas que aún no pretendemos acelerar, tareas que todavía tienen tiempo de sobra, pero que aún no han llegado al origen de buffer aunque haya una probabilidad razonable de que lleguen. Para mantener nuestros esfuerzos en un nivel razonable, vamos a suponer que hacemos un seguimiento (pero sin expeditar todavía) a todo trabajo cuya probabilidad de llegada al origen de buffer haya superado el nivel del 60 por 100. El recurso donde se encuentre el trabajo se añadirá a la lista que generamos cuando estábamos acelerando trabajos.
Probablemente, esta ampliación del trabajo de seguimiento no sólo enriquecerá la estadística, sino que, además, la mejorará. Verán, si empezamos el seguimiento muy tarde, sólo cuando la probabilidad de llegar ha superado el 90 por 100, habrá muchos trabajos que ya no se encuentren en el recurso que causó el retraso. Puede que para entonces ya hayan pasado el recurso problemático, y, por tanto, será raro que nuestra aceleración de trabajos llegue a detectar los recursos problemáticos del principio del
proceso. En cualquier caso, el seguimiento de dónde quedan retenidos los trabajos que se atrasan (no sólo los urgentes) mejorará nuestra estadística considerablemente. No debemos llegar hasta el punto de seguir todos los trabajos desde su lanzamiento; no siempre es mejor hacer más. Si empezamos el seguimiento inmediatamente después del lanzamiento nos encontraremos con más del doble de trabajo, y, además, la validez de la lista resultante se difuminará.
Resumiendo, la gestación de los buffers nos proporciona varios beneficios. Nos permite determinar mejor la longitud requerida de acuerdo con el nivel existente de perturbaciones: «cuantificar el ruido». Nos permite acelerar tareas, sistemática y metódicamente, para reducir el tiempo total de proceso (lead-
time). Después, si localizamos los sitios donde se encuentran los trabajos
retrasados, y asignamos prioridades de acuerdo con el número de veces que aparece en esa lista cada recurso (probablemente con un factor de ponderación que sea adecuado), tendremos una lista de Pareto que debe guiar nuestros esfuerzos de «mejora de la productividad». Pero, además, hay otro beneficio que probablemente es aún más importante.
Lo que debemos tener presente es que, cuando abordemos un recurso problemático, un recurso que aparezca en la lista con frecuencia, nos podemos encontrar con que sus procesos están en perfectas condiciones. Este recurso no aparece en nuestra lista por tener problemas de proceso, sino porque no tiene suficiente capacidad de protección. Así pues, la gestión del buffer nos proporciona el único mecanismo conocido que permite calcular la capacidad de protección que necesitan nuestros recursos.
Cuantificar Murphy es cuantificar la longitud del «buffer» y la cantidad de capacidad de protección que se necesita,
En este punto es necesario hacer una advertencia. Todo lo que se ha dicho hasta ahora se puede hacer fácilmente de forma manual, excepto, quizá, los extensos trabajos de seguimiento, que probablemente deberían hacerse con un informe de recursos más riguroso sobre las transacciones reales. Pero, hay otro punto importante que probablemente no se pueda hacer de forma totalmente manual. Es el tema de superar la necesidad de la parte fluctuante de la capacidad de protección ajustando la longitud de los buffers de tiempo. Vamos a aclarar este tema tan delicado. Cuando estamos tratando con el asunto de la capacidad de protección, tenemos que acordamos de que una de las principales razones del tiempo total de proceso de los trabajos es la «disponibilidad no instantánea» de los recursos. El otro lado de la moneda es que las fluctuaciones en la mezcla de producto pueden afectar significativamente a la necesidad de capacidad de protección, y, por tanto, un recurso puede aparecer frecuentemente en nuestra lista de seguimiento debido a esas fluctuaciones. Lo que debemos
122 EL SÍNDROME DEL PAJAR GESTIÓN DE LOS ESFUERZOS DE MEJORA DE PROCESOS LOCALES 123
tener presente es que este problema no lo causa la protección de las limitaciones, lo que pasa es que se revela gracias a nuestra forma sistemática de trabajar. Pero, quizá ahora, debamos aclarar por qué decimos que es un problema. Es un problema porque la amplitud de la capacidad flexible de protección es bastante limitada, ya que normalmente se reduce a las horas extras que haya disponibles. Hoy en día abordamos esto añadiendo más capacidad permanente, aunque esta capacidad adicional sólo es útil, por definición, durante una parte del tiempo. De hecho, nos vemos obligados a añadir capacidad sobrante. A primera vista parece que estamos condenados a sufrir la naturaleza estocástica de nuestro entorno, y, de hecho, éste es el caso, al menos en lo que se refiere a los cálculos manuales. Pero hay una salida, siempre que contemos con la enorme paciencia de un ordenador para realizar cálculos voluminosos sin morirnos de aburrimiento.
La forma de vencer la necesidad de añadir capacidad permanente, para hacer frente a los cambios frecuentes de la mezcla de producto, emana directamente de la relación que existe entre la capacidad de protección y la longitud de los
buffers. Pero esto requeriría programar de acuerdo con buffer dinámicos, y, por
tanto, es mejor posponer todo este tema hasta el momento que tratemos del bloque de PROGRAMACIÓN.
Si repasamos lo que hemos dicho en este capítulo, parece que hemos conseguido mucho más de lo que pretendíamos al empezar. Puede que debamos continuar y seguir empujando un poco en la misma dirección. Nos disponíamos a «cuantificar Murphy», y lo conseguimos con el mecanismo de control de la longitud de los buffers. Pero, hemos conseguido más, hemos encontrado un mecanismo sistemático para controlar la aceleración de trabajos, no cuando ya se ha hecho el daño, ni a base de «apagar fuegos», sino de forma constructiva, de forma que no apunta a un trabajo urgente específico, sino que se dirige a reducir el lead-time global de todos los trabajos. De hecho, hemos conseguido algo que podríamos empezar a llamar control.
El seguimiento de los puntos que están retrasando los trabajos nos proporciona un mecanismo para construir una lista de Pareto, tanto para guiar nuestros esfuerzos de mejora local como para cuantificar la cantidad de capacidad de protección que se necesita en cada recurso. Como ahora estamos hablando de hacer el seguimiento de un número considerable de tareas atrasadas, podemos hacerlo de forma más efectiva con un informe sobre transacciones, en vez de con el método, más engorroso, de hacer el seguimiento a lo largo de la explosión de los trabajos.
El informe de transacciones acerca aún más el tema al área de control y, al mismo tiempo, hace surgir el bien conocido y preocupante tema de la exactitud de las transacciones, o quizá, debamos decir de la inexactitud de
las transacciones. Normalmente esta inexactitud reduce la utilidad de los datos que hay en los informes de transacciones, pero quizá podamos matar unos cuantos pájaros de un solo tiro. ¿Podemos mejorar significativamente la exactitud y puntualidad de los informes de transacciones y, al mismo tiempo, contestar otra pregunta de dirección que todavía está pendiente?
Reconozcámoslo, la forma de mejorar sustancialmente la puntualidad y la exactitud de los informes de transacciones es convirtiéndolo, de alguna forma, en el principal interés de las personas que tienen que informar. ¿Cuál es el principal interés de una persona sino sus propias medidas? Ya estamos a este nivel, buscando datos sobre los pasos que avanza cada trabajo individual. ¿Por qué no damos otro pequeño paso e intentamos averiguar cómo transformar este esfuerzo en la respuesta al viejo problema de las medidas de rendimiento local?
No olvidemos que la cuestión de cómo medir, objetiva y constructivamente, los rendimientos locales obtenidos es una de las cuestiones más candentes de la dirección. Si conseguimos contestar satisfactoriamente a esta pregunta, podremos llamar control justificadamente, a esta parte de nuestro sistema de información.