164
EL SÍNDROME DEL PAJAR
tendremos que recorrer los pasos de identificar, explotar y subordinar una y otra vez, añadiendo, cada vez, una nueva limitación, hasta que lleguemos al punto en el que al final de la subordinación no se encuentren violaciones de la realidad. Sólo entonces habremos terminado. Esto implica que siempre que tengamos dudas sobre si algo es o no una limitación es mucho más seguro suponer que no lo es. Si no es una limitación, y nosotros declaramos que lo es, vamos a tener que cargar con ella. Pero, si la verdad es una limitación, y en esta fase decidimos ignorarla, no habremos hecho ningún daño, porque llegaremos a cogerla en una de las vueltas siguientes. Así que la cuestión es: ¿qué podemos declarar como limitación desde el principio y con un alto grado de probabilidad? Aparentemente, empezar eligiendo un proveedor o, incluso, un material específico, es demasiado arriesgado. Sólo podemos identificar a un material como limitación cuando comparemos su disponibilidad actual y futura con los plazos y cantidades del consumo requerido. Esto implica que disponemos, desde el principio, de un conocimiento detallado de lo que, de hecho, estamos intentando generar con este proceso: el programa. No, la decisión de empezar con la limitación en el proveedor no es una buena elección, sobre todo cuando recordamos muchos casos en los que no había limitación en los proveedores. ¿Podemos empezar con una limitación en los recursos? Podría ser, pero recordemos que la mayoría de las limitaciones de recursos con las que nos encontramos en la realidad no son cuellos de botella, sino recursos que no tienen suficiente capacidad de protección. La «marca» de un recurso con capacidad de protección insuficiente es que ese recurso, aunque tiene suficiente capacidad media, no es capaz de absorber sus picos de carga. Así pues, sólo lo podremos identificar analizando con detalle los requerimientos en función del tiempo. Volvemos a encontrarnos con una situación en la que para identificar la limitación necesitamos tener el programa. No, no podemos construir un procedimiento general basado en la poco realista suposición de que en toda situación hay, al menos, un recurso que no tiene capacidad suficiente para satisfacer la demanda del mercado. Bueno, las vueltas que hemos dado nos han llevado a algo: la única opción que nos queda es empezar desde las Limitaciones del mercado: los pedidos de los clientes. Pero antes de lanzamos es mejor que comprobemos si es correcto suponer, con una probabilidad alta, que los pedidos de los clientes siempre se pueden tomar como limitaciones. El mero hecho de decir que no queda otra alternativa equivale a suponer que hemos incluido en nuestro análisis todas las posibilidades. Esta suposición, además de ser arrogante, es muy peligrosa. Así que vamos a ignorar el hecho de que ya hemos descalificado todas las otras posibilidades que conocemos, y nos vamos a concentrar en el
IDENTIFICACIÓN DE LAS PRIMERAS LIMITACIONES
165
examen de si podemos o no suponer con seguridad que los pedidos de los clientes siempre son una limitación de nuestra organización. (Por cierto, esto subrayará el hecho de que debemos cambiar de actitud hacia las limitaciones; si los pedidos de los clientes son limitaciones, entonces, las limitaciones no son necesariamente algo malo.) Si no hay limitaciones internas en nuestra organización, entonces, la limitación está en la demanda del mercado (ignoremos por el momento la posibilidad de la limitación en los proveedores), Si internamente tenemos exceso de todo, lo único que nos limita para ganar más dinero es la demanda del mercado. ¿Qué pasa con los casos en los que sí tenemos limitaciones internas de capacidad? ¿No es arriesgado suponer que en estos casos el mercado sigue siendo la limitación? Recordemos que hemos supuesto que no hay limitaciones políticas en lo que respecta a nuestro sistema de información. Vamos a distinguir entre dos casos, cuando de hecho tenemos cuellos de botella, y cuando sólo tenemos limitaciones de capacidad debidas a una insuficiente capacidad de protección. Este último caso es más fácil de tratar, así que empezaremos por él. La cantidad de capacidad necesaria de protección que tiene que tener un recurso está en función de la longitud del buffer de tiempo. Si no se especifica un plazo de entrega (implícita o explícitamente), la longitud del buffer de tiempo no tiene límite y, por lo tanto, no hace falta ninguna capacidad de protección. Así pues, siempre que tratemos con un caso en el que exista un recurso limitado debido a una falta de capacidad de protección, estaremos, por definición, tratando un caso en el que la limitación principal será la demanda del mercado. Lo que nos queda por examinar es el caso del cuello de botella, un recurso que no tiene suficiente capacidad disponible como para satisfacer estrictamente la demanda (como el siguiente análisis del caso del cuello de botella es idéntico al análisis requerido para el caso de una limitación en el proveedor o en un material específico, éste no se detallará separadamente). Nuestro pequeño caso de «Q» y «P» nos enseñó que, cuando un cuello de botella participa en la realización de más de un producto, la demanda del mercado sigue siendo la limitación del sistema para todos los productos, excepto uno. Es más, a diferencia del caso, normalmente tenemos fechas de entrega; tenemos que entregar a nuestro cliente no más tarde de una fecha determinada. En un caso así, el pedido específico será una limitación. Resulta que el único caso en el que no podemos considerar al mercado como limitación es cuando no tenemos que comprometernos con fechas de entrega a clientes. Tenemos un recurso limitado fabricando un solo producto, y cada unidad que ofrecemos la absorbe el mercado inmediatamente. Reconozcamos que es un caso muy raro, así que, si tenemos pedidos