Documentos de Académico
Documentos de Profesional
Documentos de Cultura
El Sindrome Del Pajar Eliyahu M Goldratt PDF
El Sindrome Del Pajar Eliyahu M Goldratt PDF
Eliyahu M. Goldratt
DAZ DE SANTOS
Contenido
15.Demostracin del impacto del nuevo proceso de decisin sobre algunos 28.Establecimiento de los criterios para un programa aceptable . . 157
aspectos tcticos............................................................................................ 73
29.Identificacin de las primeras limitaciones.............................................. 63
16.Demostracin de que la inercia es una causa de las limitaciones
de procedimiento................................................................................. 79 30.Cmo trabajar con datos muy inexactos................................................... 171
31.Localizacin de los conflictos entre las limitaciones identificadas ......... 177
SEGUNDA PARTE
TERCERA PARTE
PROGRAMACI
N
3
4 EL SNDROME DEL PAJAR DATOS, INFORMACIN Y PROCESO DE DECISIN. COMO SE RELACIONAN 5
del proveedor es, sin duda, informacin. Podemos decir que el contenido de un abarcar todas las preguntas que puedan surgir. Es cierto que, en los ltimos
almacn es un dato, pero se convierte en informacin cuando pretendemos saber aos, los ordenadores personales y la posibilidad de trabajar en lnea han
si podemos servir el pedido urgente de un cliente. El mismo conjunto de eliminado este fenmeno hasta cierto punto, pero no han desaparecido las ideas
caracteres que definimos como datos puede convertirse en informacin si se dan subyacentes que nos llevaron hasta l.
ciertas circunstancias. Parece que la informacin existe o no dependiendo de En Israel se cuenta una historia que no puedo confirmar como cierta, aunque
quin la est mirando. no me sorprendera que lo fuera. Hace diez aos, los listados eran la nica forma
Estamos dando vueltas sin avanzar? No necesariamente. Entendemos, prctica de sacar la informacin de un ordenador. En aquella poca, el
intuitivamente, que la informacin es la parte de los datos que influye en departamento central de ordenadores del ejrcito israel estaba considerando,
nuestras acciones, o que puede que influya en nuestras acciones si falta o no est como posible respuesta a sus oraciones, la entonces nueva tecnologa de la
disponible. Para distintas personas, o, incluso, para la misma persona en gigantesca impresora lser. Un capitn de ese departamento, probablemente muy
distintos momentos, el mismo conjunto de caracteres puede ser un dato, o puede arrogante y algo irresponsable, decidi atacar el problema de una forma un tanto
ser informacin. No podemos evitar darnos cuenta de que la diferencia entre original. Sin pedir aprobacin alguna, orden que se dejara de imprimir y enviar
dato e informacin no reside en el contenido de un conjunto de caracteres dado. todo listado que tuviera ms de cien pginas. En aquella poca, la
Ms bien reside en su relacin con la decisin requerida. Si no sabemos con descentralizacin de los sistemas de ordenador era slo un sueo, y se enviaban
muchas copias de los listados desde el sitio central hasta muchos puntos del
antelacin qu tipo de decisin vamos a tomar, si no sabemos qu vamos a
ejrcito. La leyenda cuenta que slo se recibi una queja desde los puntos de
necesitar exactamente, entonces, todo dato podra llegar a considerarse como
recepcin. El que protestaba era un individuo cuyo trabajo consista en archivar
informacin en algn momento. Resulta extrao que sea tan difcil distinguir
ordenadamente los listados.
entre una base de datos y un sistema de informacin?
Cualquier directivo de una organizacin grande puede identificarse
Dado lo cambiante de nuestro mundo actual, podemos llegar a situarnos en
fcilmente con esta historia. Y, aunque esta historia sea una leyenda, hay muchas
una posicin desde la que podamos distinguir, a priori, qu es informacin? Es similares que, sin duda, son ciertas. Adems, de qu nos estamos quejando? De
de verdad posible disear algo que se pueda llamar, sin reservas, sistema de que nos estamos ahogando en un mar de datos. La situacin actual ha llegado a
informacin, especialmente cuando pretendemos que el sistema no se use slo tal extremo que siempre que sugiero, durante algn acto pblico, que
para tomar un tipo de decisin o para servir slo a un rea de gestin? deberamos conectar directamente las impresoras con las mquinas destructoras
Nos gustara tener un sistema que facilitara informacin a todos los de papel, la audiencia responde con risas y vtores. En algn punto del camino
directivos de una organizacin, para todo tipo de decisiones. Por lo que hemos hemos perdido el rumbo. En algn punto del camino debe de haber algn error
dicho hasta ahora, parece ser que, en un momento dado, la mayora del lgico. Puede que los sistemas de informacin no eliminen la necesidad de tener
contenido de ese sistema estara formado, simplemente, por datos. Y qu? Si es bancos de datos, pero, ciertamente, tendrn que ser algo muy distinto de stos.
capaz de proporcionar la informacin, qu nos importa eso? S queremos que sean efectivos, no pueden ser idnticos a nuestras bases de
Este es, exactamente, el tipo de razonamiento que nos ha conducido hasta los datos actuales.
sistemas de informacin actuales. Se puede suponer que el siguiente paso lgico Volvamos al punto donde establecimos la diferencia entre datos o
es empezar a preguntamos sobre el tipo de cuestiones al que nos vamos a tener informacin. Hemos intentado definir la informacin como los datos que hacen
que enfrentar. Y no slo nosotros, sino todas las reas de la organizacin. As, falta para tomar la decisin. Este intento no nos llev muy lejos, pero, aun as,
saltamos alegremente al paso siguiente: intentamos determinar qu parte de los sentimos, intuitivamente, que la informacin slo se puede definir dentro del
datos/informacin necesitaremos. marco de la toma de decisiones. Quiz no debamos definir la informacin como
Desde ah slo hay que dar un paso muy pequeo para encontrarnos "los datos necesarios para responder a una pregunta, sino, como la respuesta
totalmente inmersos en el esfuerzo de decidir los formatos precisos para a lo que se ha preguntado.
introducir los datos, la estructura de los ficheros, las rutinas de bsqueda, etc. Esto no es una simple distincin semntica. Si lo pensamos durante un par de
Hemos abierto el camino hacia la monstruosa tarea de recopilar y mantener minutos, esto nos har sentirnos un poco incmodos. En el momento en el que
un mar de datos. Esta misma tendencia influir en los formatos de los informes definimos la informacin como la respuesta a lo que se ha preguntado, estamos
que saquemos. Sern muy voluminosos, pretendiendo diciendo que la informacin no es lo que entra (da
6 EL SNDROME DEL PAJAR
1.Qu es lo verdaderamente nuevo en estas nuevas filosofas globales de Vamos a empezar por la meta de la organizacin. Probablemente se habrn
direccin? Cuando considerbamos estos movimientos como tcnicas encontrado, como a m me ha ocurrido, con que, en algunos casos, resulta
locales, entendamos con facilidad las novedades que aportaban. Pero, ahora, bastante difcil conseguir una definicin precisa. Vamos a emplear un poco de
nuestra intuicin ha aceptado una frase muy exigente: nueva filosofa global tiempo en intentar aclaramos con este tema. Quin tiene derecho a determinar
de direccin. Esto no es fcil de digerir, Ciertamente, las nuevas tcnicas la meta de la organizacin? No hace falta ser un fenmeno para encontrar la
locales no justifican estas palabras tan altisonantes. De entrada, estos respuesta ms obvia. Los nicos que deben decidir la meta de una organizacin
movimientos se circunscriben principalmente al rea de produccin. son sus propietarios. Cualquier otra respuesta nos obligara a redefinir el
Entonces, por qu usamos la palabra global? Adems, aun siendo de gran significado de la palabra propiedad.
fuerza, todava no se merecen el nombre de filosofas de direccin, Si Aqu nos encontramos ante un problema. Sabemos por experiencia que casi
queremos justificar nuestra intuicin, necesitamos expresar mejor lo que todas las organizaciones se enfrentan a grupos de presin. Un grupo de presin
estos movimientos nos han aportado. es aquel que tiene el poder de destruir, o de daar seriamente, a la organizacin
2.Cuntas filosofas nuevas de direccin hay? Una o tres? Hasta que no si no le gustan algunos aspectos del comportamiento de esta. Aparentemente,
expresemos nuestro entendimiento actual con palabras precisas, no estaremos tenemos que dejar que esos grupos opinen, Pero, si les dejamos opinar,
en disposicin de ver si nos encontramos o no ante un dilema. entonces, los propietarios no son los nicos que tienen derecho a establecer la
meta. Un callejn sin salida.
Mientras no contestemos a las dos preguntas que se han hecho arriba, Podemos salir de esta dicotoma distinguiendo claramente entre la meta de
seguiremos estando en la situacin actual, donde al sndrome del final de mes una organizacin y las condiciones necesarias que se imponen a su
hemos aadido, ahora, lo que solamente podemos describir como el proyecto de comportamiento. La organizacin debe esforzarse por alcanzar su meta dentro
mejora del principio de mes. de los lmites impuestos por los grupos de presin, esforzndose por cumplir su
Es obvio por dnde hay que buscar las respuestas a estas preguntas. Una propsito sin violar ninguna de las condiciones necesarias que se le han
impuesto desde fuera. Es indudable que, para una empresa industrial, los
frase como nueva filosofa global de direccin slo se justifica cuando se da un
clientes son un grupo de presin. Imponen condiciones necesarias, como el nivel
gran cambio en los fundamentos. Ninguna mejora sobre un aspecto parcial, por
mnimo de servicio al cliente y el nivel mnimo de calidad del producto. Si no se
grande que sea, puede justificar un ttulo tan exigente como se.
cumplen estas condiciones mnimas, los clientes dejarn de comprar en la
Es posible que la pregunta ms fundamental que nos podamos hacer sea por
organizacin, y sta correr el riesgo de extinguirse. Pero, ciertamente, nadie
qu se crea una organizacin? No creo que haya ninguna organizacin que se
nos podr sugerir que nuestros clientes tienen derecho a dictaminar o interferir
haya creado solamente para su propia existencia. Toda organizacin se ha hecho en la meta de nuestra organizacin.
para conseguir un propsito. As, siempre que consideremos una accin en
Los empleados de la organizacin son otro grupo de presin. Imponen
cualquier parte de cualquier organizacin, la nica forma lgica de considerarla condiciones necesarias, como una mnima seguridad en el empleo y un mnimo
ser juzgando el impacto de esa accin en el propsito global de la organizacin. en los salarios. Si la organizacin viola estas condiciones necesarias, corre el
Bastante trivial. Pero, con este breve argumento se nos revela la base de toda riesgo de enfrentarse a una huelga. Pero esto no significa que los empleados
organizacin. Lo primero que debe estar claramente definido es el propsito tengan derecho, como tales empleados, a determinar la meta de la organizacin.
global de la organizacin, o su meta, como yo prefiero denominarlo. Lo segundo El gobierno es un grupo de presin. Los gobiernos, incluso a nivel local,
son las medidas. Y no cualquier medida, sino aquellas que nos permitan juzgar imponen condiciones necesarias, como los niveles mximos de contaminacin
el impacto de una decisin local sobre la meta global. del aire o del agua. Si una planta viola estas condiciones necesarias, se enfrenta
Si queremos buscar algo significativo debemos empezar por la meta de la a la amenaza de cierre, por muy rentable que sea. Pero esto no significa que el
organizacin, y si ah no encontramos ningn cambio, debemos buscar en sus gobierno tenga derecho a decirnos cul debe ser la meta de nuestra organizacin.
medidas. La meta de una empresa slo est en manos de sus dueos. Si hablamos de
una sociedad, los dueos de la empresa son los accionistas. As
10 EL SNDROME DEL PAJAR
13
sabemos que, en muchos sitios, parece que las medidas predilectas dependen
fuertemente del humor del jefe, del da de la semana o, incluso, del tiempo
atmosfrico. En vez de eso, es ms simple, y tambin ms fructfero, dedicarnos
a hacer ejercicios mentales.
Este tipo de ejercicio mental es una de las herramientas ms poderosas que
se usan en fsica. Se llaman experimentos Gedunken. Son experimentos que
nunca se llevan a cabo en la realidad, slo se piensan (Gedunken significa
pensar, en alemn). La propia experiencia es lo suficientemente amplia como
para indicar los resultados con exactitud, as que no es necesario llevarlos a
cabo. Hagamos un experimento Gedunken.
Primero, debemos describir la empresa. Nos interesa encontrar las medidas
para una empresa cuya meta es ganar ms dinero ahora y en el futuro. Qu es
lo que genera esta empresa? Metales en bruto? Equipos electrnicos
sofisticados? Mercancas diversas? Importa, en realidad? S. Lo que debemos
entender es que todos los ejemplos que se han puesto arriba describen el
producto material de la empresa, no lo que sta genera. Mientras definamos la
meta como lo hemos hecho, lo que la empresa genera (o debe generar), es slo
una cosa: dinero. Por tanto, podemos definir tranquilamente a la empresa como
una mquina de hacer dinero.
Ya estamos de acuerdo en la meta: hemos decidido que nos gustara tener
una mquina de hacer dinero. Imaginemos que hemos entrado en la nica tienda
en la que venden estas mquinas. Hay muchas mquinas de hacer dinero en la
tienda, y, desde luego, queremos elegir una de ellas. Qu informacin
necesitamos que nos d el vendedor para poder elegir? Cuando hayamos
expresado con palabras la informacin que necesitamos, habremos expresado
las medidas.
Pero, adems de las medidas, tambin podramos expresar algunas
condiciones necesarias. Pero, como en este experimento se trata de encontrar las
medidas, y como las condiciones necesarias pueden variar mucho de una
empresa a otra, vamos a suponer que todas las mquinas de la tienda cumplen
nuestras condiciones necesarias. Por tanto, si podemos expresar claramente lo
que necesitamos saber para hacer nuestra eleccin, habremos expresado, de
hecho, las medidas necesarias. Vamos a aclarar que lo que esperamos del
vendedor es que nos d informacin sobre cada mquina. No debemos esperar,
ni desear, que esta persona elija por nosotros.
La primera informacin necesaria que nos viene a la mente es: Cunto
dinero hace la mquina? Pero, debemos tener cuidado. Supongamos que el
vendedor nos dice: esta mquina hace un milln de dlares, esta otra slo medio
milln. Supongamos que hemos elegido la primera mquina y nos encontramos
que hace el milln de dlares, pero, tarda diez aos. La otra
genera medio milln en tan slo un ao. Deberamos enfadamos con el
vendedor? Por qu? El nos respondi exactamente a lo que le preguntamos. El
problema no es del vendedor, es nuestro. No hemos preguntado lo que
pretendamos saber.
Qu es lo que de verdad queremos saber? El ritmo. A qu ritmo genera la
mquina el dinero? Supongamos que el vendedor nos dice que hay una mquina
que genera dinero al ritmo de un milln de dlares al mes, y que hay otra que
genera slo medio milln al mes. Elegimos la primera, y nos encontramos con
que se desintegra a los tres meses, mientras que la otra sigue funcionando para
siempre. Nos caer bien el vendedor?
Una vez ms, tenemos que aclarar lo que, de verdad, queramos decir con
nuestra pregunta. Por supuesto, nuestra intencin no era preguntar solamente
por el ritmo actual de generacin de dinero, preguntbamos el ritmo como
funcin del tiempo. Si nos hubiramos explicado con claridad, el vendedor se
habra visto obligado a decimos que el ritmo de la primera mquina desciende a
cero despus de tres meses. No hay por qu perder tiempo culpando a los
dems, cuando podemos evitarnos estos problemas simplemente expresndonos
con ms claridad.
Hay otro punto que debemos aclarar. Nos gustara conocer la probabilidad
que existe de que se cumplan las predicciones del vendedor. Toda respuesta
numrica es slo una estimacin. Deberamos exigirle conocer la fiabilidad de
sus predicciones. Bajo este aspecto, debemos entender nuestra pregunta a qu
ritmo genera la mquina el dinero?
Es esto suficiente? Desde luego que no. Tambin tenemos en mente el coste
de la mquina. Pero, para variar, seamos cuidadosos. Qu queremos decir
cuando decimos coste? Coste es una de esas peligrossimas palabras que
tienen ms de un significado. Podemos preguntar por el coste de la mquina
refirindonos a su precio de compra. O podemos hacer la misma pregunta y
referimos al gasto operativo, cunto cuesta hacerla funcionar. Una interpretacin
es del reino de la inversin, la otra, del reino del gasto. Son significados bien
distintos. Recordemos que podemos llegar a ser muy ricos a base de invertir con
prudencia, pero no a base de gastar dinero. Pero, aun as, ambos significados son
de vital importancia.
Cmo debemos redactar nuestra pregunta? Preguntar el precio de compra
de la mquina no es suficiente. Podramos tener que enfrentamos a algunas
sorpresas desagradables si nos encontramos con que sus dimensiones fsicas nos
obligan a modificar un edificio, o con que la cantidad de inventario que la
mquina se traga es an ms cara que su precio de compra. Yo sugerira que
preguntramos: cunto dinero consigue la mquina? Y, una vez ms, insistamos
en obtener una respuesta que est en funcin del tiempo y que tenga una
probabilidad adecuada.
14 EL SNDROME DEL PAJAR
Que la mquina consiga dinero no significa que ste no sea nuestro. Slo
significa que, en el momento que quitemos, aunque slo sea una parte de ese 4
dinero, la mquina ser incapaz de continuar produciendo, o, al menos, se
degradar su rendimiento. Esto es muy distinto de la siguiente pregunta que
todava tenemos que hacer: cunto dinero tendremos que meter continuamente
en la mquina para que sta funcione?
La definicin
de los ingresos netos
17
19
20 EL SNDROME DEL PAJAR ELIMINACIN DEL SOLAPE ENTRE EL INVENTARIO Y EL GASTO OPERATIVO 21
ni del marketing, estas funciones las lleva la divisin que, en nuestro caso, est Por cierto, qu gratificacin hemos conseguido? Por qu estamos buscando
situada en otro estado. otro trabajo? Muchos directores de fbrica se han encontrado en esta enigmtica
El ao pasado nuestra planta slo consigui un 1 por 100 de beneficio neto. situacin. Han hecho cosas que tienen sentido, y, de repente, se ven sorprendidos
La gratificacin que nos dieron fue tan pequea que nos hizo falta un cuando los informes financieros condenan las acciones que han llevado a cabo.
microscopio para poder verla. Nuestra esposa nos est presionando para que nos Cul ser el juicio financiero del caso que hemos descrito arriba? Por qu la
mudemos a una casa ms grande, y nuestro hijo acaba de entrar en un colegio corporacin dio instrucciones a las plantas para que redujeran el inventario?
carsimo. Definitivamente, necesitamos ms dinero. Estamos decididos a Porque el inventario es un pasivo. Pero, cuando entran a juzgar los resultados al
conseguir una buena gratificacin este ao. final del ao, en qu columna encontramos al inventario en los informes
La previsin de ventas de nuestra planta es igual que la del ao pasado. No financieros? En la columna de activos. El activo es exactamente lo opuesto del
podemos hacer nada al respecto. El departamento de ventas, como ya hemos pasivo.
dicho, no depende de nosotros. Pero la corporacin nos est indicando (de una Reducido el inventario, es un pasivo. Bien, ya lo habis reducido! Pues,
manera bastante segura), que va a considerar la reduccin del inventario como ahora, vamos a cambiar las reglas. De repende se convierte en un activo, y
una medida importante del resultado. ltimamente, la direccin parece haberse tenemos el hacha apuntando hacia nuestro cuello. Dnde est escondida la
dado cuenta de que el inventario es un pasivo. El inventario s est bajo nuestro diferencia? Vamos a examinarlo un poco ms de cerca.
control, as que este ao nos hemos concentrado en reducirlo, pero sin El inventario se registra en nuestra hoja de balance como un activo, pero
perjudicar a los otros resultados de la empresa. con qu valor? En lo que se refiere a material en proceso y a producto acabado,
Gracias a nuestro trabajo hemos conseguido reducir el nivel de inventario de el valor que se usa no es slo el precio de la materia prima, sino, tambin, el
material en proceso y de producto acabado a la mitad de lo que tenamos al valor aadido al producto. Cuando se reducen las compras, slo se convierte en
empezar el ao. Lo hemos conseguido sin perjudicar las ventas ni el servicio al dinero el precio de los materiales que no se han comprado. El valor aadido no
cliente. De hecho, hemos mejorado el servicio al cliente. Adems, hemos se compensa, con lo que aparecer como una prdida en los resultados de este
conseguido estos resultados sin hacer ningn tipo de inversin. No hemos ao.
comprado ms equipos, ni hemos instalado un nuevo y sofisticado sistema de El punto de vista local de aadir valor al producto hace que muchas
ordenadores. Ni siquiera hemos aumentado los gastos operativos, ni hemos empresas retrasen considerablemente sus trabajos de reduccin del inventario de
contratado a un rebao de consultores para que nos ayudaran a hacer el trabajo. materiales. El nico momento en el que la empresa se puede permitir una accin
Por otro lado, tampoco hemos reducido los gastos operativos. de este tipo es cuando las ventas han subido lo suficiente como para compensar
Cmo hemos conseguido la reduccin del inventario? Ya que las ventas el impacto negativo de la reduccin del inventario. Este fenmeno se puede
eran constantes, nos hemos limitado a reducir, durante un tiempo, las compras y observar a gran escala por toda Europa y Estados Unidos. No es de extraar.
la produccin. En efecto, nuestra mano de obra no estuvo a plena ocupacin Slo debemos recordar el impacto de una distorsin en las medidas.
durante ese perodo transitorio, pero no podamos despedir a nadie. Si lo
hacamos, no slo corramos el riesgo de tener problemas con el comit, adems, Dime cmo me mides, y te dir como me comporto. Si me mides
nos arriesgbamos a no poder recontratarlos. Nuestra gente es muy buena y no de forma ilgica, no te quejes si me comporto de forma ilgica.
les resulta difcil encontrar otro empleo. Como directores de fbrica, tenemos la La serpiente del valor aadido tambin levanta su fea cabeza, de otra manera,
suficiente experiencia como para despedirlos y encontrarnos, seis semanas ms que causa un efecto an ms devastador. A principios de los aos ochenta haba
tarde, con que tenemos que entrenar a los nuevos que hayamos contratado. una empresa americana que facturaba unos 9.000 millones de dlares, y que
As que vamos a resumir nuestros resultados: las ventas y el servicio al acab el ao con una pequea prdida. Esto sucedi tras muchos aos de dar
cliente no se perjudicaron, las inversiones no aumentaron, los gastos operativos beneficios, y fue totalmente inesperado.
se mantuvieron constantes y el inventario de material en proceso y producto Pueden imaginarse que Wall Street no reaccion de forma favorable. No se
acabado sufri un agradable descenso. Cualquier director se sentira orgulloso de puede decir que los accionistas estuvieran contentos. En un lapso de tiempo
estos resultados. sorprendentemente corto rod la cabeza del director ejecutivo y se contrat a
otro director ms duro.
22 EL SNDROME DEL PAJAR ELIMINACIN DEL SOLAPE ENTRE EL INVENTARIO Y EL GASTO OPERATIVO 23
27
Hemos definido tres medidas. Son las que nos hacen falta? Nos permitirn
estas medidas juzgar el impacto de una decisin local en la meta global?
Sentimos intuitivamente que son adecuadas, pero debemos reconocer que ni
siquiera hemos empezado a demostrar esta afirmacin.
Cualquier intento de enjuiciar una decisin local saca a la luz, inmedia-
tamente, la necesidad de descomponer cada medida en sus componentes.
Cules son los componentes de los ingresos netos de la empresa? Los ingresos
netos de la empresa resultan de la venta de un tipo de producto, ms la venta de
otro tipo de producto, etc. Los productos pueden ser servicios prestados. As
que, el ingreso neto de la empresa es la suma del ingreso neto obtenido a travs
de las ventas de cada producto individual.
Lo mismo se puede hacer con los gastos operativos. Gastamos dinero para
convertir el inventario en ingresos netos. A quin damos este dinero? A los
trabajadores y directivos por su trabajo, a los bancos por los intereses, a las
compaas suministradoras de energa, a las empresas de seguros, etc. Hay
muchas categoras de gastos. Debemos hacer notar que el producto no es una de
estas categoras. Han pagado dinero a un producto alguna vez?
Asimismo, es importante hacer notar que los proveedores de material
productivo tampoco son una categora de gasto operativo. El dinero que se les
paga no es gasto operativo, es inventario. As, el gasto operativo total de la
empresa es simplemente la suma de cada una de las categoras individuales de
gasto operativo.
La descomposicin del inventario en sus factores resulta obvia. Estas
descomposiciones introducen una posible dificultad en el uso de estas medidas
para las decisiones a nivel local. Al final, el juicio se basa en el beneficio neto y
en el rendimiento de la inversin. Ahora vamos a ver la
29
30 EL SNDROME DEL PAJAR DESCUBRIENDO LOS FUNDAMENTOS DE LA CONTABILIDAD DE COSTES
31
35
37
L
a
Vamos a repasar dnde estamos. Todava estamos intentando encontrar por
e
qu nuestra intuicin eligi una frase tan exigente como nueva filosofa global
de direccin. Expresamos la meta, al menos en lo referente a negocios que
s
cotizan en bolsa, y no pudimos encontrar nada nuevo. Despus, nos sumergimos
en el tormentoso tema de las medidas, y nos dimos cuenta de que, aunque en
c
este tema haga falta una buena limpieza, bsicamente no hay nada nuevo.
Ingresos netos, inventario y gastos operativos se conocan y se usaban mucho
antes de que existieran los nuevos movimientos.
a Lo nico seguro, la nica pista que todava tenemos, es la invalidez de la
contabilidad de costes. Quiz haya alguna distorsin en nuestra forma de ver las
medidas. Podra ser que lo nuevo no son las medidas en s, sino la escala de
importancia que les asignamos? Existe alguna escala de importancia
a
convencional? Ciertamente, no se ha expresado formalmente, pero, existe en la
prctica? Intentemos aproximarnos al tema sistemticamente.
El juicio definitivo, como ya hemos dicho muchas veces, lo dan el beneficio
neto y el retorno de la inversin. Los ingresos netos y los gastos operativos
d
influyen en ambos elementos, mientras que el inventario influye slo en el
ltimo de los dos. Naturalmente, esto sita a los ingresos netos y a los gastos
e
operativos en un nivel ms importante que el inventario. Y qu hay de la
relacin entre ingresos netos y gastos operativos? A primera vista, ambos
parecen tener la misma importancia, ya que el resultado lo da la diferencia entre
ellos. Pero esto no es realmente as. Estamos acostumbrados a dar ms
importancia a lo que parece ms tangible. Recordemos que en el pensamiento
convencional de los directivos, los gastos operativos se consideran ms tangibles
m
que los ingresos netos. Los ingresos netos dependen de factores externos que no
controlamos: nuestros clientes y nuestros mercados. Los gastos operativos se
p
conocen mucho
39
o
a
40 EL SNDROME DEL PAJAR LA ESCALA DE IMPORTANCIA DE LAS NUEVAS MEDIDAS
41
mejor, estn mucho ms bajo nuestro control. Por lo tanto, nuestra tendencia
natural es situar los gastos operativos a un nivel ligeramente ms alto que los
ingresos netos.
AI evaluar la escala convencional de importancia, debemos tener cuidado de
que no nos influyan los vientos de cambio de los ochenta. Llegados a este punto,
no nos permitamos distorsionar el anlisis de la escala convencional slo porque
nuestra intuicin de que los ingresos netos son dominantes haya sido reforzada
en los ltimos cinco aos. Y menos an ahora que tenemos que mirar con valor
a la realidad que nos rodea.
En cualquier empresa, las medidas dominantes no son las del resultado. Estas
slo son dominantes en la estrecha zona de la alta direccin. Pero, a medida que
bajamos por la pirmide, las medidas se disuelven ms y ms hacia el tipo de
medida de la contabilidad de costes. Qu es coste? Es slo un sinnimo de
gastos operativos. As, todos los procedimientos de coste estn construidos para
que asignen un valor a las acciones que impactan en los gastos operativos.
Como resultado de esto, las acciones que tienen su efecto dominante sobre los
ingresos netos se clasificarn como intangibles.
Consideremos, por ejemplo, las acciones que tienen como objetivo la mejora
del servicio al cliente, o la reduccin del tiempo total de fabricacin; acciones
que, hoy en da, la alta direccin considera como muy importantes. A pesar de
esto, cuando se quiere invertir en equipo para conseguir esos resultados, y el
equipo no reduce, adems, los costes, la direccin de nivel medio se encuentra
en una posicin difcil. Cuando elaboran la peticin de fondos para el equipo
que se necesita para el proyecto, deben justificarlo bajo el encabezamiento de
intangible. Ya hemos aprendido que no tangible no es sinnimo de no
importante. Intangible es slo una expresin que usamos cuando no podemos
asignar un valor numrico. La contabilidad de costes obliga a usar este ttulo
para toda accin que est dirigida a aumentar los ingresos netos futuros. El
coste, al ser casi sinnimo de gastos operativos, est ciego en lo que respecta a
los ingresos netos.
A pesar de los esfuerzos de la alta direccin, se considera que los gastos
operativos son mucho ms tangibles que los ingresos netos, y se sitan en una
primera posicin dominante en la escala de importancia. Los ingresos netos les
siguen a mucha distancia. Limtese a echar un vistazo a lo que piden los bancos
y otros prestatarios cuando una empresa tiene que presentar un plan de
recuperacin. Los recortes, la reduccin de los gastos operativos, son
obligatorios.
Y qu ocurre con el inventario? Debido al difcil concepto de valor aadido
al producto, la reduccin de inventario perjudica al resultado, en vez de
beneficiarlo. El inventario queda en la escala en un tercer lugar muy
distante. La escala convencional de importancia es pues: primero, los gastos
operativos, los ingresos netos en un segundo puesto, y el inventario en un remoto
tercer puesto. Para los nuevos movimientos, esta escala de importancia es como
ensear un capote a un toro. Llenos de celo, se toman grandes molestias para
atacar y condenar esta escala. Vamos a aclarar la escala de importancia de
nuestras medidas que recomiendan los tres movimientos, JIT, TOC y TQM. Los
tres tienen en comn una frase dominante. Si hablamos con los discpulos de
cualquiera de ellos, oiremos siempre la misma cancin: un proceso de mejora
continua. De hecho, deberamos haber tenido este lema desde hace mucho.
Recordemos que la meta de la empresa no es slo hacer dinero, es hacer ms
dinero, ahora y en el futuro. El proceso de mejora continua se deriva
directamente de la definicin de la meta.
Cul de las tres avenidas, ingresos netos, inventario y gastos operativos,
parece ms prometedora, si lo que estamos buscando es un proceso de mejora
continua? Si pensamos un momento, la respuesta es tan clara como el agua. Nos
esforzamos en disminuir tanto el inventario como los gastos operativos. Por
tanto, ambos ofrecen slo una oportunidad limitada para mejorar continuamente.
Ambos estn limitados por cero.
No es este el caso de la tercera medida, los ingresos netos. Nos esforzamos
por aumentarlos. Los ingresos netos no tienen ninguna limitacin intrnseca,
deben ser la piedra angular de todo proceso de mejora continua. Deben ser los
primeros en la escala de importancia.
Entonces, qu pasa con el inventario y los gastos operativos 7 Cul de los
dos es ms importante? A primera vista no parece que nuestro anlisis previo
tenga ningn fallo. Los gastos operativos influyen en las dos medidas del
resultado, mientras que el inventario slo influye directamente en una de ellas.
Pero esta argumentacin no puede ser definitiva, porque nuestra eleccin de
beneficio neto y retomo de la inversin fue completamente arbitraria. Si
hubiramos elegido la pareja alternativa, productividad y rotacin del inventario,
esta argumentacin caera por s misma.
El fallo bsico que se comete al situar los gastos operativos por encima del
inventario se deriva del hecho de que slo hemos tenido en cuenta el impacto
directo del inventario, y no el indirecto. La sabidura convencional estaba
totalmente concentrada en los gastos operativos, y por eso reconoca solamente
uno de los canales indirectos del inventario: la forma en que ste influye en el
resultado a travs de los gastos operativos. Si nos referimos a la parte del
inventario que incluye a las mquinas, este canal indirecto se llama depreciacin.
Si nos referimos a la parte del material, se llama coste financiero.
Los tres nuevos movimientos han reconocido la existencia de otro canal
indirecto considerablemente ms importante. El canal indirecto por el que
42 EL SNDROME DEL PAJAR
mundo del coste al mundo del valor? Pero, antes de hacer exactamente eso, no
debemos olvidar que hemos dejado pendiente de resolver un enorme problema.
Las medidas financieras son esenciales mientras la meta de nuestra empresa sea
ganar dinero ahora y en el futuro, no podemos continuar sin ellas. Si
abandonamos la contabilidad de costes nos quedaremos sin una forma numrica
de juzgar muchos tipos de decisiones. Esto abre la puerta a las medidas no
financieras, que ya estn empezando a colarse.
JIT se equivoca al ignorar este problema. TQM es an peor, porque
recomienda la utilizacin de medidas no financieras. Recordemos que una de las
bases para dirigir una organizacin es la capacidad de juzgar cmo impactar
una decisin local en el resultado. Si intentamos medir con tres o ms medidas
no financieras, bsicamente habremos perdido el control. Las medidas no
financieras equivalen a la anarqua. Simplemente, no se pueden comparar
naranjas, manzanas y pltanos, y, desde luego, no se pueden relacionar con el
resultado. La meta es ganar dinero. Por definicin, toda medida debe contener el
signo del dinero.
Recordmonos que condenar las soluciones que aport la contabilidad de
costes puede ser muy importante, pero esta accin no nos da, por s misma, una
solucin al problema. El problema original todava subsiste. Cmo podemos
juzgar el impacto de una decisin que estamos considerando? Cmo podemos
juzgar, por ejemplo, si debemos lanzar o no un producto nuevo? Cul ser su
influencia en el resultado?
Intentemos atacar este problema. Supongamos que estamos tratando la
cuestin de lanzar un nuevo producto cuando tenemos exceso de todo. Tenemos
exceso de mercado, de clientes y de recursos. Cuando se da esta situacin, qu
impacto tendr el lanzamiento del nuevo producto en las ventas de los dems?
Absolutamente ninguno.
Qu impacto tendr el lanzamiento del nuevo producto en los gastos
operativos? En el caso descrito, ninguno, ya que tenemos recursos excedentes en
todas las reas, recursos que ya estamos pagando. Cundo tendr influencia en
otras cosas el lanzamiento de un nuevo producto? Cuando no tengamos bastante.
Si no tenemos bastante mercado y lanzamos un nuevo producto, dirigido a los
mismos clientes para satisfacer las mismas necesidades que ya satisface el resto
de nuestros productos, debemos esperar una reduccin de las ventas de esos
productos.
Si el producto nuevo necesita un recurso que no tiene bastante capacidad. la
nica forma posible de ofrecerlo es, o bien reduciendo la oferta de los dems, o
aumentando las inversiones y los gastos operativos para conseguir que ese
recurso tenga ms capacidad.
En resumen, el nico caso en el que de verdad nos enfrentamos a un
problema, el nico caso en el que el lanzamiento de un producto nuevo
influye en otras cosas, es cuando hay algo de lo que no tenemos bastante. Cmo
llamamos a algo de lo que no tenemos bastante, hasta el punto de que limita el
rendimiento de toda la empresa? Limitacin es un nombre adecuado. Otra vez, la
misma palabra.
En el mundo del valor, la clasificacin esencial se hace por limitaciones,
sustituyendo el papel que desempeaban los productos en el mundo del coste.
Parece que si continuamos explorando las ramificaciones del mundo del valor
podremos resolver el problema de encontrar un sustituto para la contabilidad de
costes.
11
Formulacin del proceso de
decisin del mundo del valor
49
50 EL SNDROME DEL PAJAR FORMULACIN DEL PROCESO DE DECISIN DEL MUNDO DEL VALOR 3l
53
Con el cuarto paso tambin hemos conseguido mover la empresa hacia contrar las razones que hay tras estos procedimientos tan torpes (y la verdad es
adelante. Podemos pararnos aqu, o debemos aadir un quinto paso? Una vez que algunas veces casi hay que organizar una expedicin arqueolgica), nos
ms, la respuesta es intuitivamente obvia. Si elevamos la limitacin, si aadimos encontramos con que hace ms o menos treinta aos, cuando estos
ms y ms de las cosas de las que no tenamos bastante, debe llegar un momento procedimientos se pusieron en prctica, tenan mucho sentido. Hace mucho que
en que ya tengamos lo suficiente. Se ha roto la limitacin. Aumentar el han desaparecido las razones que los originaron, pero los procedimientos siguen
rendimiento de la empresa, pero, saltar hasta el infinito? Obviamente no. El con nosotros. Cinco pasos: un procedimiento de enfoque sencillo, intuitivamente
rendimiento de toda la empresa se ver ahora restringido por alguna otra cosa. obvio. Todo el mundo los conoca ya, todos se dan cuenta de que tienen sentido.
La limitacin habr cambiado de sitio. As que el quinto paso es: No es de extraar, ya que nuestra intuicin surge de nuestra experiencia en el
mundo real, y nuestro mundo real es el mundo del valor. A pesar de esto, de
5. Si en los pasos previos se ha roto una limitacin, hay que volver al primer verdad usan los directivos estos pasos? Puede que los usen en alguna
paso. emergencia. Y en otros casos? La garra de la educacin del mundo del coste
Pero esto no es todo el quinto paso. Debemos aadirle una advertencia muy es demasiado fuerte. A pesar de nuestra clara intuicin de sentido comn,
importante. La limitacin impacta en el comportamiento de todos los dems nuestras acciones se ven mucho ms dirigidas por los procedimientos formales
recursos de la empresa. Todo se debe subordinar al nivel de mximo del mundo del coste que por los cinco pasos de enfoque, directos y totalmente
rendimiento de la limitacin. Por tanto, debido a la existencia de la limitacin, obvios, del mundo del valor.
surgen muchas reglas en la empresa, tanto formales como intuitivas. Ahora se ha
roto una limitacin. Resulta que, en la mayora de los casos, no retrocedemos
para volver a examinar esas reglas. Quedan atrs. Hemos creado una limitacin
poltica. As pues, debemos ampliar el quinto paso:
55
56 EL SNDROME DEL PAJAR CUAL ES EL ESLABN 57
PERDIDO?
muy fiable, y tenemos problemas de absentismo. Tenemos piezas malas, en de lo que nunca habramos podido soar. Supongamos que hemos resuelto cada
parte por los procesos, en parte por los trabajadores. Y nuestros supervisores no problema de la lista con un xito espectacular. Ya no existe en nuestra fbrica
son totalmente disciplinados, les decimos lo que tienen que hacer, pero ellos ninguno de los problemas de la lista anterior. Ahora tenemos lo que algunos
creen que saben ms que nosotros. La lista puede seguir, y seguir, y seguir. Es podran llamar una fbrica perfecta. Todo est arreglado, cada dato se conoce
falta de informacin? Ms bien parece una lista de quejas: con precisin. Tenemos la informacin? Sabemos con precisin cunto
Los clientes cambian de opinin. beneficio neto va a tener nuestra empresa en el prximo trimestre?
Vendedores poco fiables. Procesos Vamos a describir nuestra fbrica perfecta. Vamos a dar todos los datos que
poco fiables. Mquinas poco fiables. alguien pueda pensar que son necesarios. En nuestra fbrica, hemos
racionalizado nuestra gama de productos hasta dejarla slo en dos: los vamos a
Personal sin entrenamiento. Gestin
llamar P y Q. Son productos muy buenos, y nuestro personal est muy bien
poco disciplinada.
entrenado para fabricarlos. Nuestra tasa de defectos es cero, no una parte por
Si miramos esta lista, hay algo que de verdad nos empieza a preocupar. milln. Cero.
Todos sabemos cmo se reconoce una excusa. Una excusa se reconoce por: es El precio de venta de estos dos productos se ha fijado hasta el centavo.
culpa de otro. Han notado qu es lo que tiene esta lista en comn? S. El Hemos superado el sndrome de las ofertas que tiene todo vendedor. Ahora son
responsable es otro. Los clientes, los proveedores, las mquinas, el personal... personas disciplinadas. Pueden imaginarse un mundo as? El precio de venta de
Nosotros somos perfectos, ellos tienen la culpa. No creen que es un poco P es, digamos, 90 dlares por unidad, y el de Q un poco ms alto, 100 dlares
sospechoso? por unidad.
Es esto una lista de razones por las que no podemos responder a la pregunta Qu hay de la previsin de ventas? Aqu nos espera una gran sorpresa. La
de cunto beneficio neto vamos a tener el prximo trimestre, o es slo una lista previsin ya no est hecha a ojo. Es precisa hasta la ltima unidad. Llamamos a
de excusas? Esta pregunta es muy importante, porque si repasamos la lista esta previsin el potencial del mercado. El potencial del mercado para P es de
podremos ver que es un resumen muy bueno de todos los esfuerzos que estamos 100 unidades por semana, y para Q, de slo 50 unidades por semana. Vamos a
haciendo actualmente para mejorar nuestra empresa. aclarar lo que queremos decir con potencial de mercado. No es lo que nos hemos
Nos estamos esforzando por mejorar nuestra previsin de ventas. Se estn comprometido a entregar, Somos tan buenos que no nos tenemos que
haciendo grandes esfuerzos para mejorar las relaciones con los clientes, y comprometer a nada. Estos nmeros representan lo que el mercado nos
tenemos un amplio programa llamado programa de proveedores. En cuanto a comprar, si nosotros lo servimos. Por supuesto, el hecho de que P tenga un
nuestras mquinas, nos hemos embarcado decididamente en el mantenimiento potencial de mercado de 100 unidades por semana significa que, si producimos
preventivo, y tambin hemos invertido mucho en nuevos equipos para mejorar la ms de 100, se nos quedarn colgadas como inventario de producto acabado.
fiabilidad. En cuanto a los procesos, estamos entrenando y volviendo a entrenar Ahora vamos a ver los datos de ingeniera. El producto P se fabrica
a cada trabajador en los mtodos del control estadstico de procesos, etc. ensamblando una pieza, que compramos fuera, con dos piezas que fabricamos
Si esto slo es una lista de excusas, y no es el problema real, no nos estamos en casa. Cada una de las piezas que nosotros fabricamos se hace a partir de
enfrentando a un problema, sino a dos. El primero es que estamos utilizando material comprado, en dos procesos distintos (vase Fig. 12.1).
como excusa la falta de informacin y, por tanto, puede que la razn de que no Fjense en que esta misma estructura podra describir diferentes entornos, ya
tengamos suficiente informacin derive simplemente de que no la hayamos sean un diagrama de diseo de producto, un proyecto, o, incluso, un proceso de
definido correctamente. El segundo problema es la diversidad de enfoques con decisin. Todo tiene el mismo aspecto. Tenemos que ser fieles a una
los que la empresa pretende conseguir mejoras. Puede que sea un error. Cmo terminologa especfica, porque, si no, nada se entender claramente, pero esto
podemos comprobarlo? no significa que necesariamente estemos tratando con un entorno de produccin.
Puede que la mejor forma sea un experimento Gedunken otra vez. Lo que de verdad estamos intentando describir aqu es el caso genrico de
Supongamos que nuestros esfuerzos actuales de mejora tienen ms xito utilizar recursos para realizar tareas con objeto de conseguir un objetivo
predeterminado. Ahora, necesitamos algunos datos numricos. Esto,
ciertamente, nos va a obligar a meternos en
58 EL SNDROME DEL PAJAR CUAL ES EL ESLABN PERDIDO? 59
$ 90/Unidad $ 100/Unidad
Tienen cambios de modelo? Si la
100 U/semana 50 U/semana
D D
15 min/U 5 min/U
Pieza
comprada C C B
$5 U 10 min/U 5 min/U 15 min/U
A B A
15 min/U 15 min/U 10 min/U
MP + 1 MP + 2 MP + 3
MP = Materia prima $20/U $20/U $20/U
Fig. 12.1. Nuestra empresa artificial de la que se han eliminado todas las
incertidumbres.
61
62 EL SNDROME DEL PAJAR DEMOSTRACIN DE LA DIFERENCIA ENTRE EL MUNDO DEL COSTE
63
ci neto. Para llegar al beneficio neto, tenemos que restar los 6.000 dlares de
los gastos operativos (ya nos hemos ocupado del dinero pagado a los
proveedores) El beneficio neto por semana ser:
Muy sencillo. Es asombroso cmo esta respuesta es, por mayora, la ms comn.
La gente no obedeci a su intuicin, sino a su educacin. Cul debera ser
siempre el primer paso cuando nos aproximamos a cualquier sistema? Ya lo
hemos acordado antes: identificar las limitaciones del sistema. Antes de hacer
eso, cualquier clculo que se haga ser slo un ejercicio sin contenido.
En el clculo anterior hemos supuesto que el mercado es la nica limitacin.
Por qu? Puede que haya una limitacin interna? En este caso, desde luego
que la hay, y puede que usted ya la haya identificado. A pesar de todo, vamos a
seguir los pasos sistemticamente (sistemticamente no significa
correctamente). En este caso, vamos a usar los nmeros, los datos, para
identificar las limitaciones. En la vida real, tenemos que ser conscientes de que
los datos suelen ser pura basura.
Todo experto en MRP sabe que, si se tiene que comprobar el tiempo de
proceso de una pieza, es mejor preguntar al encargado que al ingeniero.
Probablemente el encargado nos engaar en un 30 por 100, pero, por lo menos,
sabemos con qu tendencia nos est engaando. El ingeniero puede equivocarse
en un 200 por 100, y ni siquiera sabremos cul es la tendencia. Cualquier
sistema de informacin que valga para algo tendr que identificar los muy pocos
datos de los que se ha derivado la informacin. Estos datos deben ser verificados
cuidadosamente. Si no es as, tendramos que comprobar la validez de todos los
datos, lo que es una imposibilidad, como han podido comprobar miles de
empresas. Hemos invertido tanto tiempo y esfuerzo durante los ltimos veinte
aos para llegar a darnos cuenta de esto, que sera una pena desperdiciar el
conocimiento adquirido.
Pero, en este experimento hemos establecido que los datos son absolu-
tamente exactos, as que podemos continuar. Lo que tenemos que hacer es
encontrar si hay alguna limitacin fsica interna. Puede que haya otro tipo de
limitacin, limitaciones polticas, pero no se pueden encontrar a partir de los
datos. Para encontrarlas directamente necesitamos el mtodo cientfico de
identificacin de problemas, la tcnica efecto-causa-efecto. Las limitaciones
polticas se "encuentran fuera del campo de los sistemas de informacin, y por
eso todo sistema de informacin debe partir de la atrevida base de que no hay
limitaciones polticas. Para identificar las Limitaciones internas de los recursos,
simplemente calculamos la carga que
el programa asigna a cada uno, y la comparamos con la disponibilidad de cada
recurso. Para el recurso A la carga del producto P es de 100 piezas por semana
multiplicadas por 15 minutos por pieza, 1,500 minutos. El producto Q supone
una carga adicional para el recurso A de 50 piezas por 10 minutos, lo que
convierte el total de carga en 2.000 minutos por semana. La disponibilidad del
recurso A es de 2.400 minutos por semana. Aqu no tenemos ningn problema.
Recurso B: El producto P supone una carga semanal de 100 unidades por 15
minutos por unidad, o sea, 1.500 minutos. El producto Q supone una carga de 50
unidades por 30 minutos. S, solamente 30 minutos, aunque se procesen dos
trabajos distintos. Ya hemos establecido que el tiempo de cambio era cero. La
carga total en este caso es de 3.000 minutos, lo que excede con mucho la
disponibilidad. Ciertamente, tenemos una limitacin en un recurso. Si hacemos
el mismo clculo para los recursos C y D veremos que la carga es de slo 1.750
minutos por semana para cada uno. Absolutamente ningn problema. B es el
nico recurso limitado y destaca enormemente, igual que en la vida real cuando
existe un verdadero cuello de botella.
Ahora nos enfrentamos a una decisin. Es obvio que no podemos satisfacer
todo el potencial del mercado, no tenemos suficiente capacidad en el recurso B.
As que, tenemos que elegir qu productos vamos a ofrecer al mercado, y cunto
vamos a ofrecer de cada uno. La mayora de los directivos que han alcanzado
este punto del experimento (no cayeron en la primera trampa), continuaron de la
forma siguiente: no podemos satisfacer todo el mercado, as que vamos a ofrecer
al mercado el producto ms rentable que tenemos, la estrella. Si nos queda
alguna capacidad residual, ofreceremos el perro. Tiene sentido.
Bien, cul es el producto ms rentable? Vamos a examinarlo desde ms de
un punto de vista. Veamos, primero, el precio de venta; P se vende a 90 dlares
por unidad, y Q se vende a 100 dlares por unidad. Si sta fuera la nica
consideracin, qu producto nos gustara vender? Ciertamente Q.
Ahora, vamos a examinarlo desde el punto de vista del material: P requiere
que paguemos a nuestros proveedores 45 dlares por unidad; Q slo requiere 40
dlares por unidad. As que, si sa fuera nuestra nica consideracin, qu
producto preferiramos vender? De nuevo, la misma respuesta, Q.
Tambin podemos mirar los ingresos netos, que son el precio de venta menos
el precio de la materia prima. Nos lleva al mismo sitio. El ingreso neto de P es
45 dlares, mientras que el de Q es 60 dlares. Pero stas no son las nicas
consideraciones. Normalmente miramos la cantidad de trabajo que se necesita
para fabricar un producto para el mercado.
64 DEMOSTRACIN DE LA DIFERENCIA ENTRE EL MUNDO DEL COSTE
EL SNDROME DEL PAJAR
65
Si calculamos la cantidad de trabajo para el producto P, llegamos al nmero: terminologa equivocada del beneficio del producto. En el mundo del valor no
existe el beneficio del producto, slo existe el beneficio de la empresa.
15 + 15 + 10 + 5 + 15 = 60 minutos de trabajo. Vamos a intentarlo otra vez. Cmo debemos calcular el beneficio neto? Ya
hemos descrito el proceso que debe utilizarse, en cualquier cuestin de
En el producto Q, los mismos clculos nos llevan a: direccin. Decidir cmo explotar la limitacin. Qu hemos intentado explotar?
El esfuerzo de la mano de obra. Por qu? Porque no tenemos suficiente A o C
15 + 10 + 5 + 15 + 5 = 50 minutos de trabajo. o D? No. Entonces, por qu hemos hecho el clculo que se ha descrito arriba?
Porque no tenemos bastante del recurso B.
Desde el punto de vista del trabajo, qu producto preferiramos vender? Una Qu significa explotar la limitacin? No significa tenerla trabajando todo
vez ms, el mismo producto, Q. Es muy importante que nos demos cuenta de el tiempo. Recordemos que la meta de la empresa no es hacer trabajar a los
que, como las tres consideraciones nos han llevado, en nuestro caso, a la misma empleados, es hacer ms dinero ahora y en el futuro. Lo que queremos es sacar
conclusin, cualquier sistema de costes que pueda existir nos dara la misma el mximo dinero de las cosas que nos limitan, de las limitaciones. Cuando
respuesta fuera cual fuera el factor de gastos generales que utilizramos: ofrecemos al mercado el producto P, el mercado paga 45 dlares por el esfuerzo
indudablemente, Q es un producto ms rentable que P. de la empresa. Recordemos que 45 dlares de los 90 dlares del precio de venta
De acuerdo. Utilizando esto como gua, vamos a calcular el beneficio neto. se pagan por el esfuerzo de los proveedores. Pero, cuntos minutos de la
El primer producto que ofrecemos es Q. Podemos vender 50 unidades de Q a la limitacin tenemos que invertir para conseguir los 45 dlares de ingreso neto? B
semana. Cada una de estas 50 unidades demanda 30 minutos de nuestra tiene que invertir 15 minutos. As que, cuando ofrecemos al mercado el producto
limitacin (el recurso B), lo que absorbe 1.500 minutos de su tiempo disponible P, obtenemos 3 dlares de ingreso neto (45$/15:00) por cada minuto de nuestra
cada semana. Esto slo deja 900 minutos para que se usen en la produccin de P. limitacin.
Cuntos P podemos producir en 900 minutos? Cada P requiere 15 minutos del Cuando ofrecemos Q al mercado, la empresa obtiene 60 dlares de ingreso
recurso B, as que slo podremos fabricar y ofrecer al mercado 60 unidades, por neto, pero tenemos que invertir 30 minutos de la limitacin. As, cuando se
semana, del producto P. S, el mercado quiere 100 unidades por semana, pero no ofrece Q al mercado, slo recibimos 2 dlares (60$/30:00) por cada minuto de
podemos hacer nada. No tenemos suficiente capacidad. nuestra limitacin. Vean que estos 2 y 3 dlares no tienen nada que ver con el
La mejor mezcla que podemos ofrecer al mercado es de 50 Q y 60 P por coste, son contribuciones a los ingresos netos. Con estos nmeros frente a
semana. El producto Q nos reportar 50 unidades x 60 dlares = 3.000 dlares nosotros, y estando convencidos de la necesidad de explotar la limitacin, qu
de ingresos netos, y el producto P nos reportar 60 unidades x 45 dlares = preferimos vender ahora? Exactamente el opuesto a la respuesta de todos los
2.700 dlares de ingresos netos. Los ingresos netos totales sern 5.700 dlares sistemas de coste del mundo.
por semana, menos los gastos operativos, que son 6.000 dlares... Vaya! Vamos Quin tiene razn? Todos los sistemas de costes, o nuestra intuicin de
a perder 300 dlares por semana. Bueno, qu le vamos a hacer? Los japoneses sentido comn? Slo hay un juez posible, el resultado. As que, vamos a calcular
cul ser el resultado si seguimos nuestra intuicin. Primero ofrezcamos P al
han entrado en nuestros mercados y...
mercado. Cuntos P podemos vender por semana? 100 unidades. Cuntos
Intente imaginar lo que puede pasar a un directivo que promete a su
minutos de la limitacin se necesitan? Mil quinientos minutos. Ahora, slo
corporacin unas ganancias de 1.500 dlares por semana, y que acaba dando
quedan 900 minutos para Q. Cada Q necesita 30 minutos de la limitacin. Por
unas prdidas semanales de 300 dlares. Cunto durar esta situacin antes de
tanto, slo se ofrecern al mercado 30 Q. Ahora, la mezcla es de 100 P y 10 Q
que se vea obligado a visitar la agencia de colocacin ms cercana? Podemos
por semana.
ignorar nuestras limitaciones, pero ellas nunca nos ignorarn. Pero, un momento. De verdad entendemos el significado de esta ltima
Pero, un momento, este ltimo clculo no est en lnea con el mundo del afirmacin? Ensenme un directivo que sea capaz de levantarse y decir: si
valor. No es suficiente con utilizar la terminologa de las limitaciones. Tenemos tenemos una estrella y un "perro, vamos a ignorar a la estrella y vamos a
que librarnos de los bloqueos mentales que ha implantado el mundo del coste. apoyar al perro, todo lo que podamos. Si nos queda alguna capacidad residual,
Como sin duda habrn notado, este ltimo clculo usa la entonces, graciosamente, tambin ofreceremos la estrella. Creen ustedes que
este directivo tendra muchas oportunida-
66 EL SNDROME DEL PAJAR
des de promocin? Gracias a Dios que aqu slo estamos tratando con un caso
supuesto, as que, sigamos.
El producto P generar unos ingresos netos de 100 * 45 = 4.500 dlares
14
semanales, mientras que Q aadir otros 30 * 60 = 1.800 dlares de ingresos
netos semanales. Ahora, los ingresos netos totales de la empresa sern 6.300
dlares. Si restamos los 6.000 dlares de gastos operativos semanales, el
Aclarando la confusin
beneficio neto de esa misma empresa es, ahora, 300 dlares ms semanales. Ms entre datos e informacin.
o menos, qu importa?
A quin le afecta lo que acabamos de hacer? Sin duda, a los accionistas, a la Algunas definiciones
alta direccin y al departamento de finanzas. Y a quin ms? A la gente de
produccin? En absoluto. A nuestro equipo de ventas. Pinsenlo. Actualmente, fundamentales
qu producto tendra la comisin ms alta? El producto Q, por ser el ms
rentable. Si la comisin de Q es ms alta que la de P, qu producto preferir
promocionar nuestro equipo de ventas? Aunque nosotros sepamos que es mejor
vender P, si ellos han vendido Q ya es demasiado tarde. Tendremos que entregar
lo que ellos han vendido.
En realidad, a produccin no le importa tener que fabricar ms de esto o ms Cul era la informacin que necesitbamos en realidad? La cantidad de
de aquello. El trabajador B est trabajando a toda velocidad en cualquier caso. beneficio neto que bamos a tener. Antes de conseguir la respuesta, tuvimos que
Lo que nos indica el ltimo clculo es que. en el intento de ganar ms dinero, tomar una decisin: qu mezcla de productos debemos ofrecer al mercado?
necesitamos iniciar un cambio drstico en nuestros planes de comisiones de Esta decisin, a su vez, se bas en la identificacin de las limitaciones de la
ventas. Esto es el significado de dependencia; puede que estemos tratando con, empresa. Este ltimo paso es el nico que depende de lo que solamos llamar
por ejemplo, produccin, pero las conclusiones pueden afectar principalmente a datos. Cosas como tiempo de proceso de una unidad, disponibilidad de recursos
cualquier otro departamento, en este caso al personal de ventas. y previsin de ventas. Empieza a emerger una cadena, una cadena en la que
Un pequeo ejemplo de la diferencia entre el mundo del coste y el cada eslabn se puede considerar tanto dato como informacin, dependiendo del
pensamiento en lnea con la realidad del mundo del valor. Pero, ahora. volvamos lado desde el que lo miremos.
atrs y hagamos lo que pretendamos hacer originalmente, evaluar las Para aclarar esta ltima afirmacin, hagmonos, una vez ms, la pregunta
ramificaciones de nuestro problema de informacin. clave de nuestra discusin: qu son datos y qu es informacin? Qu fue lo
que dijimos al principio de nuestra discusin? El contenido de un almacn es un
dato, pero, para la persona que tiene que responder al pedido urgente de un
cliente, es informacin. Ya tenamos la impresin de que la misma serie de
caracteres poda ser tanto un dato como una informacin. Creo que ahora
nuestro entendimiento es un poco ms profundo. La relacin datos-informacin
es an ms intrigante de lo que pareca al principio.
Vamos a examinarlo ms cuidadosamente. El recurso B es una limitacin.
Esto es un dato o una informacin? Para el director de produccin, seguro que
es informacin. Responde a su pregunta principal: a qu recurso tenemos que
prestar ms atencin? Pero, al mismo tiempo, para el director de ventas es slo
un dato. La pregunta del director de ventas es: a que producto debemos
apoyar ms en el mercado? Est claro que, para el director de ventas, la mezcla
de productos deseada, primero P y despus Q, es informacin. Se puede
derivar sin saber que B es una
67
68 EL SNDROME DEL PAJAR ACLARANDO LA CONFUSIN ENTR DATOS E INFORMACIN
69
limitacin? No. B es una limitacin es, por tanto, un eslabn que, para un
director, es informacin y, al mismo tiempo, para otro director es un dato
necesario.
Pero se no es el nico eslabn de nuestra cadena. Por ejemplo, la pregunta
de la alta direccin era cunto beneficio neto vamos a tener? La respuesta a
esta pregunta, 300 dlares, es informacin, mientras que la afirmacin es mejor
vender P que vender Q no es informacin, es un dato.
Parece que la informacin no es el dato que hace falta para contestar a la
pregunta, sino que es la propia respuesta. Los datos parecen ser los trozos que
hacen falta para contestar a la pregunta. Qu hay de nuestra definicin anterior:
cualquier conjunto de caracteres que describa algo sobre nuestra realidad?
Parece que vamos a tener que hacer otra distincin, entre dato y dato
requerido. Un momento, esto es importante. Un error en el nivel de las
definiciones bsicas puede llevar la discusin al caos. Deberamos volver a
examinar nuestras definiciones en situaciones menos complicadas, en
situaciones de la vida diaria, donde nuestra intuicin es ms fuerte. Debemos
comprobar si las definiciones formales de datos e informacin que se han
propuesto coinciden con nuestra percepcin intuitiva de estas palabras.
Tomemos un caso en el que preguntamos a nuestra secretaria algo como:
cul es la mejor forma de ir a Atlanta hoy? Yo esperara una respuesta como:
deberas coger este vuelo. A una respuesta as le llamaramos, sin duda,
informacin. Por supuesto que si este vuelo en particular no va a Atlanta,
seguira siendo informacin. Simplemente sera informacin errnea. Por otra
parte, si en vez de darnos una contestacin directa, nos da todo el horario de
vuelos, no estaramos tan satisfechos. Hemos recibido datos en vez de
informacin. Para la secretaria, el mismo horario de vuelos es informacin. Su
pregunta es: cules son todos los vuelos posibles para ir a Atlanta? Incluso, en
este caso tan simple, vemos que lo que se considera dato y lo que se considera
informacin depende de la pregunta que se haya hecho: lo que se considera
informacin en un nivel puede ser slo un dato en otro nivel.
Qu palabras usaramos si se nos entregara un horario de vuelos caducado?
No dejan de ser datos. Ni siquiera los podemos llamar datos errneos.
Recordemos que un dato es cualquier serie de caracteres que describa algo sobre
nuestra realidad. Parece que sera muy til aadir el trmino datos requeridos.
S, ahora las definiciones anteriores parecen estar mucho ms en lnea con
nuestro entendimiento intuitivo.
Creo que ahora estamos en una situacin mejor para darnos cuenta de la
validez de lo que dijimos nada ms empezar nuestra discusin: lo que es dato y
lo que es informacin depende de quin lo mire. Necesitbamos emplear todo
este tiempo en analizar la nueva filosofa, slo para
conseguir un entendimiento un poco ms profundo? Creo que la respuesta es
ciertamente s. Definir la informacin como: la respuesta a lo que se ha
preguntado significa que la informacin slo se puede deducir como resultado de
la utilizacin de un proceso de decisin. Los datos requeridos son lo que entra en
el proceso de decisin, la informacin es lo que sale, y el mismo proceso de
decisin debe estar integrado en un sistema de informacin. No, ciertamente no
hemos perdido el tiempo tratando de formalizar el nuevo proceso de decisin.
Hay una palabra clave escondida en lo que acabamos de decir que no nos
debe pasar inadvertida. Hemos llegado a la conclusin de que la informacin se
dispone de forma jerrquica, que en cada nivel la informacin se deduce de los
datos. La palabra deducir es un trmino clave. Nos revela que, para poder derivar
la informacin, necesitamos algo ms que los datos, necesitamos el proceso de
decisin.
Qu fue lo que nos ense claramente el caso anterior? Disponamos de
todos los datos que nos hacan falta. A pesar de ello, fuimos incapaces de deducir
la informacin deseada: el beneficio neto. An peor, fuimos desviados hacia una
respuesta errnea.
Se deben cumplir dos condiciones para adquirir informacin. Ciertamente, los
datos son una de las condiciones, pero, es igual de importante el proceso de
decisin en s mismo. Sin un proceso de decisin adecuado no hay forma de
deducir de los datos la informacin necesaria. En el pasado estbamos inmersos
en el mundo el coste, del proceso de decisin era totalmente inadecuado, y por
eso ramos incapaces de conseguir la informacin deseada.
Nuestra frustracin nos ha llevado a intensificar nuestros esfuerzos, pero se
han orientado en la direccin equivocada. En vez de buscar el proceso de decisin
adecuado, nos hemos limitado a gastar nuestro esfuerzo en reunir ms datos y,
despus, cuando esto no result til, datos ms precisos. Los procedimientos de
decisin detallados, y, por tanto, el proceso genrico de decisin, deben ser parte
integral de un sistema de informacin.
Los cinco pasos de enfoque parecen darnos el proceso de decisin genrico
necesario para subir por la escalera de la informacin: del dato bsico al siguiente
nivel, el de identificacin de las limitaciones del sistema, y, luego, al nivel ms
alto de deduccin de respuestas tcticas, que, por fin, nos lleva a la informacin
financiera del resultado.
Puedo or sus comentarios: un pequeo ejemplo y, sin dudarlo un momento,
esta persona tan extraa salta a conclusiones globales. Pero, un momento, estas
conclusiones no se han derivado del ejemplo, proceden directamente de los cinco
pasos de enfoque de la intuicin del sentido comn. El ejemplo era solamente una
ilustracin del tema. En cualquier caso, no importa, tendremos muchos ms
ejemplos que podremos discutir.
70 EL SNDROME DEL PAJAR ACLARANDO LA CONFUSIN ENTRE DATOS E INFORMACIN
71
Lo que debemos tener presente es que los cinco pasos no son suficientes por
si mismos. Para poder subir por la escalera de la informacin tenemos que
desarrollar los procedimientos detallados que se derivan de ellos. Por ejemplo, la
forma en que utilizamos el segundo paso, el concepto de explotar, no fue
precisamente trivial. El procedimiento para determinar la mezcla apropiada de
productos, de acuerdo con los dlares de ingreso neto por unidad de limitacin
es muy sencillo, pero no es fcil de encontrar. Adems, los dos sabemos que este
procedimiento no se puede generalizar. Todava no se ha terminado la bsqueda
de la mezcla de productos ms apropiada.
Antes de seguir explorando las ramificaciones de los cinco pasos de enfoque
en otras cuestiones tcticas, antes de examinar ms el alcance de los procesos de
decisin resultantes, puede que debamos dedicar algo de tiempo al tema de los
datos. Llevamos tanto tiempo intentando desesperadamente conseguir la
informacin necesaria a base de ampliar nuestros esfuerzos de recoleccin de
datos, que puede que nos hayamos sobrepasado en esa direccin. Puede que
estemos exagerando en nuestra propia percepcin de cuntos datos se necesitan
de verdad y de cunto esfuerzo hay que dedicar, de hecho, a aumentar su
precisin.
Repasemos lo que hemos hecho en el supuesto anterior. Necesitbamos
datos, pero no todos los datos. Pregntese si necesitbamos saber el coste por
hora de cada uno de los recursos. Para qu se emplea hoy en da tanto tiempo y
esfuerzo en intentar determinarlo? Para controlar nuestros gastos necesitamos
saber cuanto dinero pagamos en cada categora, o cunto dinero pagamos a los
trabajadores por salarios y beneficios, pero el coste por hora? Este es un
eslabn intermedio que se decidi que haca falta en el proceso de decisin del
coste. Este paso resulta totalmente superfluo en el nuevo proceso de decisin.
Cuntos ms anacronismos como ste existen? Tendremos que estar muy alerta
para ir eliminndolos.
Repasemos una vez ms estas conclusiones tan importantes.
Respire hondo y sumrjase en esta larga cadena de conexiones lgicas. Qu
fue lo que dijimos? Como la informacin tiene una construccin jerrquica, y
como el propio proceso de decisin es el que nos permite subir de un nivel de
informacin al siguiente, esto implica que cualquier cambio en el proceso de
decisin puede dejar obsoleto a todo un nivel de informacin. Algo que se
consideraba como un eslabn dato/informacin, algo que se tena que deducirce
los datos para permitir la derivacin a un nivel superior de informacin, puede
ser completamente innecesario cuando se cambia el modo de deduccin.
Ya habamos empezado a sospechar que esto, de hecho, era as cuando
examinamos la necesidad del coste por hora, pero, puede que merezca la pena
buscar si hay ms ejemplos as, o si esto era slo un caso aislado.
Una de las clases de datos ms buscada es el coste del producto. Los
directores financieros e informticos a veces se desesperan intentando resolver
bien el tema. Para qu necesitamos este dato? Para determinar el precio de
venta? Esta no puede ser la razn, porque el precio del producto no lo decidimos
nosotros, lo determinan nuestros mercados. Para encontrar el precio que
tenemos que poner al producto tenemos que mirar hacia fuera. Si miramos
dentro, en nuestra propia fbrica, no llegaremos a ninguna parte.
Para qu necesitamos el coste del producto? Para poder tomar decisiones
como determinar qu producto debemos favorecer en el mercado y qu producto
no debemos favorecer. S, sta es la nica razn, pero reconozcamos que el caso
anterior nos ha enseado claramente que no hay forma de tomar esta decisin
utilizando la nocin de coste del producto. Todos los sistemas de coste habran
indicado que haba que favorecer a Q en el mercado, nuestros resultados nos
ensearon justo lo contrario. Como ya indicamos antes, el coste del producto es
un concepto que debe eliminarse junto con su creador, el proceso de decisin
que se basa en el mundo del coste.
Qu hay de la precisin de los datos? De verdad que nos incumbe conocer
cada dato con absoluta precisin? Pregntese lo siguiente: de todos los tiempos
de proceso que aparecan en nuestro supuesto, cul era el que tena que ser
exacto? No nos hizo falta mucha exactitud para identificar la limitacin? A
quin le importa si el recurso D va a estar ocupado 1.000 minutos por semana
2.000 minutos? Slo necesitbamos ser precisos hasta el nivel en el que
pudiramos determinar si un recurso era o no una limitacin.
Necesitbamos mucha ms exactitud en los tiempos de proceso de B. Los
utilizamos como dato para un nivel superior de informacin: para determinar la
mezcla de productos que desebamos. Pero, ni siquiera aqu hace falta exagerar:
tampoco necesitamos una exactitud muy grande. Habramos llegado a la misma
conclusin, aunque el tiempo de proceso hubiera sido de 17 minutos en vez de
15. Slo cuando estamos tratando con el nivel ms alto de informacin, cul
ser el beneficio neto?, y slo entonces, necesitamos que esos tiempos de
proceso sean exactos. Su exactitud determinar la exactitud de la informacin
que se derive de ellos. Los dems tiempos de proceso podran haber tenido
grandes inexactitudes sin afectar para nada al resultado final.
Esto es algo a lo que nos tendremos que acostumbrar. En el mundo del coste
tenamos la impresin de si aumentbamos la exactitud de cualquier dato
requerido, aumentaramos tambin la exactitud del resultado final. La lucha por
conseguir una mayor exactitud se convirti en una forma de vida. Este va no es
el caso. En el mundo del valor, la mayora de los datos
72 EL SNDROME DEL PAJAR
73
74 EL SNDROME DEL PAJAR DEMOSTRACIN DEL IMPACTO DEL NUEVO PROCESO DE DECISIN
75
Ayudo a la empresa si produzco ms? Ciertamente no. Las piezas de sobra que tenemos que recopilar bastante menos datos, y los requerimientos de
no se convertirn en ingreso neto. Lo que determina el ingreso neto es la exactitud se reducen. Pero, sta no es la cuestin. De verdad piensan que
capacidad de B. La produccin adicional slo contribuir a engordar el podemos cambiar la cultura a base de cambiar las medidas de rendimiento local?
inventario. Pero, cunto tiempo necesito yo para producir completamente sus No es tan fcil. Hemos dicho antes: dime cmo me mides y te dir cmo me
requerimientos? 1.500 + 300 = 1.800 minutos. Cunto tiempo tengo disponible comporto. Pero, ahora, tenemos que recordar la otra mitad de la historia:
en mi centro de trabajo? Dos mil cuatrocientos minutos. As que, si hago cambia mis medidas por unas nuevas que no entiendo bien, y ni siquiera yo s
exactamente lo que usted me ha pedido que haga, qu pasar con mi eficiencia? cmo me comportare.
Mi eficiencia caer. Qu pasar con mi cabeza7 Probablemente, tambin caer. No podemos cambiar una cultura simplemente cambiando sus medidas de
Si hago exactamente lo que usted me ha pedido, ser castigado. As que, rendimiento.
qu cree usted que voy a hacer en realidad? Hablar con mis amigos. el que La transformacin desde el mundo del coste hasta el mundo del valor, el
hace el programa o el jefe de almacn. Si hace falta, robar el material. Voy a nuevo proceso de decisin, nos permite construir, por primera vez, un sistema
hacer mis propios clculos. Y recuerde, el muerto no se va a encontrar en mi de informacin relativamente simple, pero su utilizacin depende por completo
departamento, el inventario se acumular ms adelante, en piezas acabadas o en de la capacidad que tenga la empresa de transformar su cultura.
producto acabado. En tierra de nadie. Llegados a este punto, tomemos nota de que tenemos que desarrollar las
Qu otra opcin me deja? Hacer lo correcto y recibir un castigo, o jugar con nuevas medidas de rendimiento local, ciertamente, una de las piezas clave del
los nmeros y ser un hroe. Qu cree usted que soy, un santo? O lo que es peor, sistema de informacin que necesitamos. Pero continuemos, por ahora,
un mrtir? explorando las ramificaciones del cambio, para que podamos llegar a ver el
El concepto del mundo del valor que dicta el tercer paso de enfoque, cuadro completo.
subordinar todo lo dems a la decisin anterior, implica un cambio drstico en Supongamos que ya hemos desarrollado todos los instrumentos necesarios
nuestras medidas de rendimiento local. Durante cunto tiempo podemos seguir para la nueva tica de trabajo. Las empresas que ya han hecho el cambio han
recompensando la estupidez, y castigando las actuaciones correctas? Cunto descubierto que, en contra de lo que se cree normalmente, los trabajadores
dinero, tiempo y esfuerzo se gasta hoy en da en recopilar datos para medir el buscan trabajo. Algunas empresas han llegado al extremo de poner estanteras
rendimiento local, slo para que el resultado final distorsione el comportamiento con peridicos en la fbrica, pero esto no ha supuesto ninguna ayuda. El tiempo
de la gente que estamos midiendo? ocioso, resultado inevitable de forzar a los recursos no limitados a que se
Si hoy decimos: fabrica slo 100 de stas, luego, 30 de aqullas y, luego, abstengan de sobreproducir, se debe llenar con algo significativo. La solucin
prate. Qu creen que se registrar en la mente de los trabajadores? Cundo natural podra ser utilizar el tiempo libre para mejorar los procesos locales.
fue la ltima vez que la direccin les dijo que dejaran de trabajar? Cinco Desgraciadamente, nuestros trabajadores suelen ser mucho ms inocentes que
minutos antes de que empezara una reduccin de plantilla! Cada uno de los nosotros, no se engaan a s mismos tan fcilmente. Darles programas de
trabajadores bajar su ritmo, instintivamente, para probar que se les necesita. El mejora sin sentido, que no lleven a una verdadera mejora de los resultados de la
tema que acabamos de tocar es un tema muy sensible, el cambio de las medidas empresa, no puede ser una solucin a largo plazo.
del rendimiento local se aproxima mucho al cambio de la tica de trabajo. Debemos disear el procedimiento que nos proporcione, de forma con-
tinuada, la capacidad de identificar cules son las actividades locales de mejora
Cul es la tica de trabajo actual? Creo que la podemos resumir en la
que ms se necesitan. Esta necesidad no es nueva, pero, en el entorno del mundo
siguiente frase:
del valor esta informacin se convierte en algo casi obligatorio. As que, vamos
Si un trabajador no tiene nada que hacer, hay que buscarle algo que hacer! El
a explorar el tema de la mejora de procesos, pero, para hacer el tema ms
concepto de subordinacin est en contradiccin directa con el comportamiento
animado, vamos a enfocarlo de la siguiente manera:
actal. No nos engaemos pensando que el cambio de las medidas locales ser
Vamos a suponer que yo. Ahora, soy un ingeniero de procesos. Antes era
tarea fcil. Es verdad que podemos, sin mucha complicacin, disear los
encargado, pero he estado estudiando, he conseguido el ttulo, y ahora me han
procedimientos para conseguir la informacin vital de que es lo que cebe hacer
promocionado a ingeniero de procesos. Ya no soy un encargado,
cada uno. De hecho, nos encontraremos cor.
76 EL SNDROME DEL PAJAR
DEMOSTRACIN DEL IMPACTO DEL NUEVO PROCESO DE DECISIN
77
79
80 EL SNDROME DEL PAJAR
DEMOSTRACIN DE QU LA INERCIA ES UNA CAUSA
81
83
contratado a otra persona. El beneficio neto es de 1.100 dlares por semana. dlares en el beneficio neto semanal. Casi el doble de lo anterior. Por culpa de la
Pero no podemos utilizar todo este dinero para recuperar la inversin que hemos inercia, nos habamos dejado la mitad del dinero encima de la mesa.
hecho en la mquina. Ya tenamos beneficios anteriormente. Slo podemos Entendemos ahora el significado de la inercia? Desgraciadamente la
utilizar el incremento de beneficio neto que ha resultado de la compra de la respuesta todava es que no. En el mundo del coste existe el concepto de coste
nueva mquina. El incremento de beneficio neto es de 1.100 - 300 - 800 dlares del producto. Mientras no cambiemos el diseo del producto, o los salarios de
por semana. Como el precio de la mquina era de 100.000 dlares, los trabajadores, no cambiar el coste del producto. Pero, en el mundo del valor
recuperaremos la inversin en 125 semanas exactamente. Correcto? No. no existen ni el coste del producto ni el beneficio del producto. No tenemos
Vamos a recordar el quinto paso de enfoque, SI en los pasos anteriores hemos que evaluar el impacto de un producto, sino el impacto de una decisin. Esta
roto una limitacin... Es exactamente donde nosotros estamos, no? Acabamos evaluacin se debe hacer a travs de su impacto en las limitaciones del sistema.
de romper una limitacin... Hay que volver al paso nmero uno, pero sin Por eso, el primer paso siempre es la identificacin de las limitaciones del
permitir que la inercia cause una limitacin de sistema. Esta advertencia se hace sistema. Si las limitaciones han cambiado, hay que volver a examinar las
para situaciones como la nuestra. Le hemos hecho caso? Vern, en el mundo decisiones.
del coste casi todo es importante, por eso, si cambiamos una o dos cosas, no Por qu decidimos vender P en Japn? Porque tenamos la impresin de que
cambia mucho el cuadro total. Pero, en el mundo del valor no es ste el caso. P era el producto ms rentable. Esta impresin es una extrapolacin del mundo
Aqu hay muy pocas cosas que sean de verdad importantes. Si cambiamos una del coste. Producto rentable es la terminologa del pasado. S, habamos
cosa importante tenemos que volver a evaluar toda la situacin. decidido que la venta de P sera ms rentable para la empresa. Por qu
Por qu decidimos no ir a Japn? Porque nos habra reportado menos de 2 llegamos a esta conclusin? Porque B era una limitacin. Pero ya no lo es.
dlares por minuto de limitacin. Qu limitacin? Ya la hemos roto! Intentemos vender Q en Japn. Utilicemos los 400 minutos residuales de A
La compra de la nueva mquina ha generado exceso de capacidad en todos para la produccin de Q. Podemos fabricar 40 unidades, ya que Q slo necesita
los recursos. Ahora, la nica limitacin es el mercado. Vayamos inmediatamente 10 minutos de limitacin por unidad. El ingreso neto de cada Q que se venda en
a Japn para vender nuestro exceso de capacidad. Toda la diferencia entre el Japn es 80 dlares (el precio de venta en Japn es un 20 por 100 ms bajo),
precio de venta y el precio de materia prima, el ingreso neto adicional, ser menos 40 dlares de la materia prima, lo que es igual a 40 dlares. Por tanto, la
beneficio neto. Los gastos operativos son fijos, aunque ahora estn a un nivel venta de Q en Japn aadir otros 1.600 dlares a nuestro beneficio neto, en vez
ms alto. de los 700 dlares que ganbamos vendiendo P. Un aumento de 900 dlares en
Si vamos a Japn, qu se convertir en la limitacin interna? Cul es el el resultado. Ya que vamos a ir a Japn, por qu no vender el producto
siguiente recurso en nivel de ocupacin? El recurso A, por supuesto. As que, correcto? Inercia!
vamos a rehacer los clculos. La venta de 100 P en el mercado nacional nos Entendemos ahora lo que significa la inercia? Nos damos perfecta cuenta
proporcionar 4.500 dlares de ingreso neto, pero requerir 1.500 minutos del de sus devastadores riesgos? La respuesta todava es no. Por qu decidimos
recurso A. Cincuenta unidades de Q, en el mercado nacional, nos que primero tenamos que exprimir el mercado nacional, y, slo despus,
proporcionarn 3.000 dlares adicionales de ingreso neto, y requerirn 500 examinar la posibilidad de exportar? Porque al principio la exportacin no
minutos adicionales del recurso A. Esto nos deja con un excedente de 400 estaba en el cuadro. Inercia!
minutos ociosos en el recurso A... vamos a largarlos en Japn. Vuelva al primer paso, no permita que haya inercia. Vuelva al paso 1 y mire al
sistema como s nunca lo hubiera visto. Es un sistema nuevo. Recordemos una
Cuntos P podemos producir en 400 minutos del recurso A? Unas 26
vez ms que, en el mundo del coste el cambio de una o dos cosas no influyen
unidades. El ingreso neto por unidad ya no es 45 dlares, estamos vendiendo en
mucho. En el mundo del valor, el cambio de una limitacin lo cambia todo.
Japn. Es slo 72 - 45 = 27 dlares. As que, la venta de P en Japn aadir otros
Lo que tenemos que hacer es volver a examinar qu producto contribuye
700 dlares de ingreso neto. Deberamos molestarnos por una cantidad tan
ms, a travs de la limitacin. Ahora, la limitacin es A, no B. Ya se ha descrito
pequea? Veamos. Ahora los ingresos netos totales son 8.200 dlares, menos
antes la forma de calcularlo, dlares de ingreso neto divididos por minutos de
6.400 dlares de gastos operativos, menos el beneficio neto anterior de 300 limitacin. Hagan ustedes mismos los clculos, les espera una sorpresa.
dlares, nos lleva a un cambio de 1.500
SEGUNDA PARTE
La arquitectura de un sistema
de informacin
17
Escrutando la estructura
inherente de un sistema
de informacin. Primer intento
Ya nos hemos dado cuenta de que la informacin se dispone en una extraar, cuando pasamos de la nocin de que casi todo es importante a la
estructura jerrquica en la que la informacin de los niveles superiores se puede nocin de que son pocas cosas las que de verdad influyen, las cosas se
deducir de los niveles inferiores a travs de un proceso de decisin. No tenemos simplifican maravillosamente. Ya hemos notado que tenemos tan metida la
la informacin necesaria porque no hemos usado los procesos de decisin mentalidad del mundo del coste que nos enmascara la realidad. Va a ser
adecuados. Esto implica que el sistema de informacin que estamos buscando ciertamente divertido derribar tantos bloques mentales desarrollando esos
debera estar orientado, principalmente, hacia los niveles superiores de la procedimientos que hemos necesitado desesperadamente durante tanto tiempo.
informacin. Es una conclusin interesante, entremos un poco ms o fondo. Pero, no olvidemos el propsito principal de esta discusin. Era hacer un
Cuando la pregunta se poda contestar sin necesidad de un proceso de esquema de la estructura y composicin de un sistema de informacin completa
decisin, simplemente localizando el dato necesario, ya lo hemos hecho. La y fiable. Podemos hacer esto antes de disear todos los procesos de decisin
mayora de nuestros esfuerzos anteriores se han orientado en ese sentido. No es necesarios?
sorprendente que llamemos a nuestros sistemas actuales sistemas de datos. No Por suerte, ya hemos establecido las directrices de las que se pueden derivar
es que no intentramos contestar a las preguntas del nivel ms alto; la lista de los procesos de decisin que hacen falta para contestar a las preguntas de
preguntas que hemos descrito antes siempre ha estado ante nuestros ojos, los direccin. Son, simplemente, los cinco pasos de enfoque. Puede que podamos
sistemas de coste son un buen ejemplo de nuestros intentos anteriores. Pero, encontrar la estructura del sistema de informacin requerido examinando
durante nuestra discusin, hemos descubierto que estos intentos no nos llevaban solamente una o dos de esas preguntas. Puede que haya un patrn general. Si
a ninguna parte porque se basaban en procesos de decisin equivocados. ste es el caso, podemos construir la estructura ahora e ir rellenndola despus,
Dada esta situacin, deberamos reservar el nombre de sistemas de infor- cuando vayamos tratando con cada pregunta especfica. As, podemos conseguir
macin para los sistemas que son capaces de responder a preguntas que implican grandes beneficios mucho ms pronto. Adems, en cualquier caso tendremos
el uso de un proceso de decisin. Los sistemas que se orientan hacia la que ir introduciendo esos conceptos gradualmente en nuestras organizaciones.
contestacin de preguntas ms directas se deberan llamar sistemas de datos. La transicin completa desde el mundo del coste hasta el mundo del valor no se
Esta ltima decisin implica que el sistema de informacin no se debera ocupar va a realizar en un solo da.
consultando datos disponibles, sino que debera suponer que existe un sistema Bien, a qu estamos esperando? Vamos a empezar ya.
de datos del que puede extraer los que sean necesarios. Es una conclusin Supongamos que usted es el director de compras. Uno de sus problemas
atrevida, pero no va contra la intuicin. principales es determinar el nivel de inventario de cada una de las materias
La potencia de un sistema de informacin se debera juzgar principalmente primas y piezas compradas. Usted sabe que es un trabajo ingrato. Si no mantiene
por la amplitud de las cuestiones a las que de verdad puede responder. Cuanta un inventario suficiente, los de operaciones se quedarn sin piezas y todo el
ms amplitud, ms potente ser el sistema. mundo le echar la culpa. Si intenta acumular grandes reservas, el director
A dnde nos lleva esto? Parece que el primer paso debe ser desarrollar un financiero pedir a su jefe que intente meterle algo de sentido comn. Cunto
proceso de decisin que sea adecuado para cada una de las preguntas que nos hay que tener? Y lo que no es menos importante, cmo puede usted demostrar
hacamos antes, y para muchas ms que no hemos mencionado. que est manteniendo el inventario en el punto adecuado?
Esto, como sin duda sospechan, nos asegura que nuestra pequea discusin Examinemos su problema usando algunos nmeros concretos. Supongamos
tendr que continuar algn tiempo ms, sin duda, ms all del alcance de este que el precio de compra de un elemento es de 100 dlares por unidad, y que el
libro. Hasta un pequeo caso supuesto nos ha hecho ver que no nos vamos a plazo de entrega del proveedor es de seis meses. Otro elemento cuesta 10.000
aburrir, pero, podemos permitimos dedicarle tanto tiempo? Si seguimos este dlares por unidad, y el plazo de entrega es de slo dos meses. Cuntas
camino, cundo vamos a hablar de la estructura de un sistema de informacin? semanas de inventario hay que tener para cada elemento?
La tentacin de construir los distintos procesos de decisin es muy grande, No se precipite con la respuesta. La percepcin del mundo del coste le
especialmente al darnos cuenta de que estos nuevos procedimientos ni son muy inducir a creer que la respuesta es obvia, que el nivel de inventario de la
complicados ni requieren una sofisticacin exorbitante. Por el contrario, da un primera pieza debera ser mayor que el de la segunda. En los cinco ltimos
poco de vergenza lo simples que son. No es de
90 EL SNDROME DEL PAJAR ESCRUTANDO LA ESTRUCTURA INHERENTE DE UN SISTEMA PE INFORMACIN 91
aos hemos aprendido que hay otros factores mucho ms dominantes que el el precio del elemento y el plazo de entrega del proveedor tienen mucha menos
precio y el plazo de entrega del proveedor. Vamos a considerar uno de estos importancia que la frecuencia de entrega. Slo impactan en el resultado a travs
factores adicionales. del nivel de interferencia que causan nuestras fluctuaciones internas. Cuanto
Si estamos debatiendo cul debe ser el nivel del inventario, quiere decir que ms estable sea nuestra empresa, menos importancia tienen.
estos elementos no se consumen de forma espordica, sino continuadamente. Si Ya que hablamos de niveles de interferencia, debemos reconocer que nuestra
fuera de otra forma, habramos comprado justo lo necesario para cumplir empresa no es la nica que est introduciendo incertidumbre en el juego. La falta
pedidos especficos y no estaramos hablando de mantener inventarios de de habilidad del proveedor tambin es importante. Vamos a usar el mismo caso,
materia prima. As que, vamos a suponer que el primer elemento se entrega con pero suponiendo que el primer proveedor, el que entrega cada dos semanas, es
una frecuencia bisemanal, mientras que la frecuencia del segundo es de slo una muy poco fiable. Poco fiable hasta el punto de que hay bastantes probabilidades
vez al mes. Cul sera ahora su respuesta? Qu elemento debe tener el nivel de que falle una o dos entregas, o de que un envo sea defectuoso en su totalidad.
ms alto de inventario? El otro proveedor es extremadamente fiable, tanto en las fechas de entrega como
Deberamos tener unas dos semanas de inventario del primer elemento, dos en la calidad del material. Qu contestamos ahora? Se acuerdan de la
semanas de consumo nuestro. Pero, para el segundo, dos semanas no es pregunta? Era: qu nivel de inventario debemos mantener para cada uno de
suficiente. Deberamos tener un mes, no? Dnde entran en el cuadro el precio estos dos elementos?
y el plazo de entrega del proveedor? Son en absoluto importantes? S, pero en Podemos ver que, para determinar los niveles de inventaro de materia prima,
mucha menor medida de lo que habamos supuesto. Veamos, cuando decimos un debemos considerar tres factores principales. El primero es la frecuencia de las
mes de consumo, qu es lo que de verdad queremos decir? Un mes de entregas, el segundo el nivel de interferencia de nuestra propia empresa (la falta
consumo medio? Con nuestra experiencia, no debemos caer en esa trampa. Ya de habilidad en los niveles de consumo). El tercer factor es la habilidad del
hemos aprendido, dolorosamente, que Murphy es la persona ms activa de proveedor (tanto en el cumplimiento de las fechas de entrega como en la calidad
nuestra empresa. Debemos mantener un mes de consume paranoico. Hasta qu de los productos). Esto ltimo suscita otra cuestin importante: si un proveedor
punto debemos ser paranoicos? Por supuesto, nuestra paranoia est en funcin de ofrece mejores precios, el segundo, mejor frecuencia y, el tercero, mayor
las fluctuaciones internas, que, a su vez, estn fuertemente influidas por la habilidad, qu proveedor elegiramos? Es evidente que nos hace falta una
fluctuacin en la demanda de nuestros clientes. Cmo podemos cuantificar la evaluacin numrica.
paranoia o, alternativamente, cuantificar a Murphy? Eso es otro asunto. A pesar Qu hemos hecho, aparte de demostrar una vez ms la diferencia entre
de ello, es obvio que nuestro grado de paranoia se ver influido por el precio pensar lgicamente en el mundo del valor o jugar con los nmeros en el mundo
unitario del elemento. Cuanto ms alto sea, menos nos podremos permitir el ser del coste? Podemos aprender de este ltimo ejemplo algo que nos ayude a
paranoicos. No es asombroso? Lo que en el mundo del coste considerbamos descubrir la estructura necesaria de un sistema de informacin?
como el parmetro ms importante resulta ser slo un factor de correccin en el
mundo del valor.
Qu ocurre con el plazo de entrega del proveedor? Tiene alguna
importancia? Una vez ms s, pero slo como factor de correccin secundario.
Cuando lanzamos un pedido al proveedor, algo que debemos hacer con una
antelacin, al menos igual que el tiempo de entrega del vendedor, no debemos
considerar nuestro consumo paranoico actual, sino nuestro consumo paranoico
futuro. El material que pedimos hoy slo ser inventario cuando llegue a nuestra
empresa, lo que esperamos que suceda en el plazo de entrega del proveedor a
partir del lanzamiento del pedido.
Por ejemplo, en el primer elemento tendremos que evaluar cul ser el
consumo dentro de seis meses. Por supuesto, cuanto ms largo sea el plazo de
entrega de proveedor, el momento futuro que se evale ser ms remoto y, por
tanto, la incertidumbre ser mayor. Pero, no olvidemos que
18
Introduccin de la necesidad
de cuantificar la proteccin
93
94 EL SNDROME DEL PAJAR
INTRODUCCIN DE LA NECESIDAD DE CUANTIFICAR LA PROTECCIN
95
Tiene sentido, y es normal que lo tenga. La necesidad de subordinar solo entra Ya nos hemos aprendido la leccin. El coste del producto slo es un fantasma
a travs de la necesidad de eliminar la tendencia a conseguir eficiencias altas? matemtico, sin ninguna relevancia en la vida real. La forma ms fcil de
No necesariamente. No olvidemos que lo que necesitamos predecir no es el justificar esta afirmacin es examinando la situacin descrita arriba con los
consumo, sino el consumo paranoico. Se puede conseguir? Por supuesto, pero siguientes datos adicionales. Supongamos que el precio de compra de la materia
para ello tenemos que desarrollar un mecanismo adicional. Para empezar, por prima necesaria para producir ese elemento es de 40 dlares, y que todo el
qu estamos paranoicos? Porque nos damos perfecta cuenta de que normalmente trabajo interno lo realizan recursos no limitados. Cul es ahora vuestra
las cosas no funcionan bien. Las perturbaciones son parte de la vida real. As respuesta? La compra del elemento impactar negativamente en el resultado
pues, necesitamos desarrollar un mecanismo que prediga numricamente los final en 80 dlares, mientras que el impacto negativo de producirlo en la
niveles de inventario que hacen falta en toda la fbrica, considerando la empresa ser de slo 40 dlares.
estructura de limitaciones y el nivel de ruido de nuestra fbrica. En efecto, Bien, la necesidad de identificar las limitaciones del sistema es cada vez ms
aqu el paso de subordinacin es muy importante. clara. Qu hay del segundo paso, el concepto de explotacin? Puede que la
Lo que vemos, al menos en este caso, es que para contestar a una pregunta de decisin de fabricar la pieza en la empresa sea, de hecho, la aplicacin de este
direccin, incluso cuando el proceso de decisin est plenamente desarrollado y concepto, aunque al revs de como lo habamos aplicado hasta ahora. Tiene
entendido (lo que sospecho que an no es el caso), necesitamos datos. No sentido. y el tercer paso, el concepto de subordinacin? Podramos decir que,
podemos obtener este tipo de datos en el mundo del coste. A un nivel ms bajo como la decisin ya se ha tomado en el segundo paso, el tercero no tiene
es informacin, informacin que los procedimientos tradicionales de decisin ninguna vigencia.
eran incapaces de deducir de los datos disponibles. Vemos que antes de que Podramos decirlo, pero no sera correcto. Deberamos entender el concepto
podamos responder fiablemente a las preguntas sobre compras, nuestro sistema de subordinacin con mucha ms profundidad. Recordemos que casi todo lo que
de informacin debe llevar a cabo dos pasos preliminares. hemos aprendido de la aplicacin de los cinco pasos de enfoque nos ha venido,
La primera fase, que tendr que incluir nuestro sistema de informacin, es el hasta ahora, del caso supuesto que hemos estudiado. Uno de los supuestos
procedimiento necesario para identificar y explotar las limitaciones, bsicos sobre los que est construido el caso es la ausencia de incertidumbre, de
subordinando a ellas todo lo dems, tanto ahora como en el futuro. Esta fase (o ruido. Podemos recordar que esto se hizo para desechar, de una vez por todas,
bloque cdigo, si consideramos un sistema de informacin por ordenador) tiene las excusas tpicas: la nocin de que la incertidumbre de los datos es lo que nos
que estar instalada. Adems de esto hay que instituir otra fase, basada en un impide conseguir una buena informacin. Aunque, por este motivo, la omisin
procedimiento que separe el ruido de las transacciones diarias, que ocurren, estaba justificada, por otra parte, nos ha impedido examinar en profundidad el
de hecho, en nuestra empresa. Este procedimiento debe ser capaz de convertir mecanismo de subordinacin.
estos datos en niveles adecuados de proteccin, que se colocarn en los sitios Al subordinar, la atencin se centra en los eslabones ms fuertes de
ms apropiados para reducir el impacto de Murphy. nuestra cadena. S, ya nos dimos cuenta de que en cualquier cadena slo puede
Vamos a examinar otra cuestin muy corriente para ver si se repite el mismo haber un eslabn ms dbil pero, por qu se da este fenmeno? Podemos
modelo. Si nuestros cinco pasos de enfoque son tan genricos como demostrar con todo rigor que ste ser el caso en cualquier sistema que contenga
sospechamos, as debe suceder. tanto variables dependientes como fluctuaciones estadsticas. Si en su viaje a
Supongamos que actualmente estamos comprando un cierto elemento para el travs de la empresa un material pasa por ms de una limitacin fsica alterna,
que tenemos la capacidad tcnica de producirlo en nuestra empresa. Debemos no se producir el resultado esperado, y el inventario crecer indefinidamente.
seguir comprndolo, o debemos empezar a producirlo? La respuesta del mundo (Vese Theory of Constraints Journal, volumen 1, nmero 5, artculo 1.)
del coste es, aparentemente, ridcula. Qu se supone que debemos hacer? En otras palabras, debemos huir de las limitaciones interactivas como de la
Calcular el coste de producir el elemento y compararlo con el precio de peste. Esta ltima conclusin nos lleva a darnos cuenta de que todos los dems
compra? Supongamos que el coste de producirlo en la empresa es de 100 eslabones deben tener ms capacidad de la que estrictamente se necesita para
dlares, de acuerdo con los clculos tradicionales, y el coste de compra es de 80 la carga prevista. Resulta muy lgico y muy bonito, pero, cul es la razn
dlares. Qu hacemos? sencilla, de sentido comn, para que esto sea as? Si las matemticas nos
demuestran que sta es la situacin real, debemos acep-
96 EL SNDROME DEL PAJAR INTR0DUCCI0N DE LA NECESIDAD DE CUANTIFICAR LA PROTECCIN
97
tarlo, pero la pregunta sigue ah. Por qu se da este fenmeno? Puede que la
respuesta resida simplemente en nuestro bien conocido e indeseable amigo, el
Sr. Murphy.
Vamos a mirarlo a fondo, teniendo presente lo que hemos aprendido hasta
ahora. Supongamos que hemos identificado la limitacin de un sistema y ahora
queremos explotarla. Cualquier despilfarro en la limitacin perjudicar
irremediablemente nuestro resultado. Pero, un momento, nos acabamos de
acordar de la existencia de Murphy. Si Murphy ataca directamente a la
limitacin, poco podemos hacer. Lo nico que podemos hacer es maldecir
nuestra mala suerte y continuar. Pero, y si Murphy ataca a uno de los recursos
que alimentan a la limitacin? Tampoco podemos remediarlo?
Seguimos queriendo explotar la limitacin. Y podemos hacerlo, siempre que
hayamos preparado, con antelacin, algo de inventario delante de nuestro
recurso limitado. Parece una buena idea, el inventario que necesitemos para
proteger nuestro resultado no se va a considerar como un pasivo. Mientras
Murphy siga existiendo, ms vale que lo tengamos.
Pero, es el inventario una proteccin suficiente? Si Murphy ataca, y
seguimos explotando la limitacin, consumiremos el inventario que habamos
acumulado delante de ella. Qu pasa entonces? Las visitas de Murphy a
nuestras empresas no son infrecuentes. Qu pasa si Murphy vuelve a atacar
los recursos no limitados? La limitacin se ve afectada.
Es obvio que debemos reconstruir rpidamente el inventario situado delante
de la limitacin, debemos reconstruirlo antes de que Murphy ataque otra vez.
Pero, para poder hacer esto, los recursos no limitados deben ser capaces de
procesar el material ms rpidamente de lo que sera estrictamente necesario
segn el ritmo de consumo de la limitacin. Tienen que seguir proporcionando
lo que necesita la limitacin y, adems, tienen que reconstruir el inventario.
Esto nos lleva a la inevitable conclusin de que mientras existan las
fluctuaciones estadsticas, si queremos explotar la limitacin, debemos tener en
los dems recursos ms capacidad de la que sera estrictamente necesaria segn
la demanda,
Para aclararlo ms, supongamos que uno de los recursos que alimenta a la
limitacin no tiene capacidad de sobra. Qu nivel de inventario necesitaremos
que haya delante de la limitacin para garantizar su explotacin? Supongamos
que Murphy ataca precisamente a este recurso, o a uno de los que le alimentan.
La limitacin empezar a comerse el inventario, y ahora no hay forma de
recuperarlo. El nivel de proteccin ha bajado irreversiblemente. Murphy ataca
otra vez. Vuelve a bajar el nivel de proteccin. Y, as, sucesivamente... Si
aceptamos que Murphy no va a desaparecer, cunto inventario debemos situar
inicialmente delante de la limitacin? En efecto, si tenemos otra limitacin en la
cadena un recurso sin capacidad sobran-
te necesitaremos un inventario infinito para poder explotar, al menos,
una limitacin.
Como la limitacin no tiene capacidad interna de proteccin, debemos
protegerla de Murphy con una combinacin de inventario situado delante de
ella y de capacidad de proteccin de los recursos que la alimentan. Estos dos
mecanismos de proteccin se compensan. Una menor capacidad de proteccin
en los recursos que la alimentan requerir un mayor nivel de inventario delante
de la limitacin. Si no es as, la Limitacin se quedar sin piezas de vez en
cuando y la empresa perder ventas. Si la capacidad de proteccin de uno de los
recursos que la alimentan es cero, el inventario requerido delante de la
limitacin debe ser infinito. As pues, si una cadena tiene ms de un eslabn
ms dbil, su fuerza ser considerablemente menor que la de estos eslabones.
Una cadena as se ver destrozada por la dura realidad; los sistemas que
contienen limitaciones interactivas desaparecen pronto en nuestro mundo
salvaje.
Solamos considerar que cualquier capacidad que no fuera la estrictamente
necesaria para producir era un desperdicio. Ahora nos damos cuenta de que
cuando examinamos la capacidad disponible no debemos dividirla en dos
segmentos, sino en tres. El primero es capacidad de produccin, el segmento
que necesitamos para cumplir con la demanda. El segundo es capacidad de
proteccin, que se necesita como escudo para defendernos de Murphy. El nico
que no tiene capacidad de proteccin es el recurso limitado (recordemos -
explotar). La capacidad que quede despus de considerar las capacidades de
produccin y de proteccin es, de hecho, exceso de capacidad.
Ahora, vemos que la produccin de un elemento que antes se compraba
puede tener efectos negativos, aunque la produccin slo se realice en recursos
no limitados. Por ejemplo, si el elemento consume tiempo de un recurso no
limitado que no tiene exceso de capacidad, la carga adicional reducir, por
definicin, la capacidad de proteccin de ese recurso. Esto requerir un
incremento de los niveles de inventario en proceso y de producto acabado para
proteger las limitaciones. Un aumento no slo en el inventario de ese elemento,
sino en el de todos los dems elementos que pasan por las mismas reas.
Esta consideracin es totalmente nueva, y hasta ahora no la hemos tenido en
cuenta. Lo que hicimos en nuestro caso supuesto fue concentrarnos en el
impacto sobre las ventas y sobre el gasto operativo. Lo que deberamos hacer
siempre es evaluar el impacto sobre las tres medidas, inventario incluido. El
paso de subordinacin es esencial para contestar con fiabilidad a las cuestiones
sobre comprar o fabricar.
Recordemos que la razn por la que pusimos al inventario en el segundo
lugar de la escala de importancia era por su impacto indirecto sobre las
98 EL SNDROME DEL PAJAR
99
100 EL SNDROME DEL PAJAR LOS DATOS REQUERIDOS A TRAVS DE LA PROGRAMACIN DE MURPHY 101
B de nuestro caso. Hay otras limitaciones que slo se pueden encontrar una vez La respuesta es, muy probablemente, que no. Consideremos el hecho de que
terminado el paso de explotacin sobre las limitaciones ya identificadas: el nadie tiene un sistema fiable de programacin; ciertamente no son datos que
caso del potencial de mercado para el producto P. Otras limitaciones slo se estn disponibles inmediatamente. Probablemente esto se debe a que los
revelarn una vez hecha la subordinacin. Normalmente ste es el caso de los intentos actuales se basan en un proceso de decisin errneo.
recursos que no tienen suficiente capacidad de proteccin. Es posible que no se disponga de informacin para programar, porque no
De lo anterior se deduce, claramente, que no se pueden encontrar de forma se ha hecho ningn intento serio de obtenerla? Este no es el caso. Basta con
simultnea todas las limitaciones, no hay un paso que lo abarque todo. Lo darse cuenta de cunto dinero, tiempo y esfuerzo se ha invertido, y se sigue
tendremos que hacer gradualmente, quiz, incluso, recorriendo los tres invirtiendo, en el intento de instalar y operar los sistemas de MRP (Material
primeros pasos en un proceso reiterativo, en el que se va identificando una Resource Planning).
nueva limitacin en cada bucle. Como el nmero de limitaciones es muy La intencin original de la implantacin de MRP era, y todava es,
pequeo, este hecho, en s mismo, no representa una carga significativa. programar. Que yo sepa, no hay ninguna empresa que haya implantado MRP
. Pero empezamos a darnos cuenta de otra cosa. Algunas limitaciones slo se slo para tener una base de datos. Hoy en da, una gran cantidad de empresas
pueden encontrar despus de haber realizado la fase de subordinacin, industriales han instalado (algunas, ms de una vez) un sistema as. Si tenemos
subordinacin que se refiere a la limitacin que ya se ha identificado y en cuenta no slo el precio del programa, del sistema de ordenadores y de la
explotado. Si ste es el caso, slo podemos evitar el proceso de iteracin en la carsima implantacin, sino, tambin, el espantoso gasto permanente que
realidad simulando sucesos hacia el futuro. supone mantener los datos medianamente actualizados, ser difcil que no
Esta es una conclusin muy importante y algo sorprendente. Lo que alcancemos una cifra de muchos miles de millones. Ciertamente, el que no haya
acabamos de decir es que, hasta para poder identificar limitaciones actuales un modo de programacin fiable y sistemtico no se debe a falta de esfuerzo.
necesitamos simular acciones futuras. Para identificar limitaciones, un sistema Ya hemos dicho bastante. Nos guste o no, si queremos obtener respuestas
de informacin debe tener la capacidad de simular acciones futuras. Esto quiere fiables a las preguntas de direccin, tendremos que resolver el problema de la
decir que la promocin debe ser una parte integral y fundamental de nuestro programacin fiable. Sin duda, la programacin es uno de los bloques bsicos
sistema de informacin. de un sistema de informacin, pero, desgraciadamente, no es el nico bloque
Parece que nos hemos encontrado con otra antigua necesidad: la capacidad adicional que necesitamos.
de generar sistemticamente un programa fiable. En efecto, sin duda es as. La Nuestras exploraciones nos han revelado la enorme importancia del papel
promocin debe ser uno de los bloques fundamentales de un sistema de que desempea Murphy en nuestras empresas. Si releemos el captulo anterior,
informacin, un prerrequisito del bloque de qu pasara si...? nos daremos cuenta de que Murphy es precisamente la razn por la que
En principio, parece que esta conclusin nos hace llevar una carga adicional. necesitamos inventarlo y capacidad de proteccin para cumplir con las ventas
Nos gustara llegar al punto en el que podamos contestar preguntas de previstas. Cmo podemos medir a Murphy?
direccin, y ahora nos encontramos con la enorme barrera que supone construir El intento de medir las perturbaciones locales de cada recurso individual no
un programa fiable para nuestros recursos. Aunque, pensndolo bien, no debera slo es una tarea gigantesca, es, tericamente, imposible. El tiempo necesario
sorprendernos tanto. Durante mucho tiempo, las preguntas de direccin ms para recopilar suficientes datos estadsticos en la realidad es mucho mayor que
preocupantes han sido: qu debemos lanzar al proceso?, "cundo debemos el tiempo medio entre los cambios que se producen. Parece que la nica salida
lanzarlo?, en qu cantidades debemos hacer las cosas? Resumiendo: es considerar el impacto agregado de todas las acciones de Murphy. Qu es
quin debe hacer qu, cundo y en qu cantidades? programacin. lo que necesitamos defender de Murphy? Las limitaciones del sistema. El
De hecho, la programacin es una lista de respuestas a preguntas de inventario adicional se acumula delante de la limitacin, de forma que sta
direccin y, por tanto, es informacin. Necesitamos un proceso de decisin pueda proseguir su trabajo sin interrupciones, aunque algo vaya mal en el
para poder generar esta informacin? Recordemos que sta era nuestra prueba proceso anterior. (Recordemos que el mercado, casi siempre, es una limitacin
crucial para distinguir entre lo que se debera incluir en un sistema de fsica en los sistemas que se supone que no tienen limitaciones polticas.) La
informacin y lo que se deba dejar para el sistema de datos. capacidad de proteccin de los recursos no limitados debe estar disponible para
Bien, podemos generar un programa fiable sin un proceso de decisin? que se puedan recuperar de los ataques de Murphy. El inventario de proteccin
debe
102 EL SNDROME DEL PAJAR
haberse recuperado a un nivel suficiente antes de que Murphy ataque otra vez.
Ya estn claramente localizados los pocos puntos en los que se agrega el
impacto de todas las acciones de Murphy; son las acumulaciones de inventario
20
que hay delante de las limitaciones, sta es la base lgica del procedimiento que
llamamos gestin de buffer.
Creo que aqu no debemos extendernos mucho en este procedimiento tan
Introduccin del concepto
interesante. De hecho, mi opinin es que debemos evitar meternos en
procedimientos particulares, aunque parezcan muy interesantes e importantes,
de buffer de tiempo
hasta que establezcamos, firmemente, el diseo conceptual del sistema de
informacin. Si no lo hacemos as corremos el riesgo de no alcanzar nuestro
objetivo principal. Cuando tengamos el marco global, y no antes, podremos
ampliar y describir detalladamente cada procedimiento a medida que nos
vayamos encontrando con la necesidad.
A pesar de esto, no podemos abandonar el tema de la gestin de buffer sin
aclarar, al menos, su terminologa ms bsica. Primero, porque no es justo
mencionar un procedimiento de pasada y dejar a todo el mundo cavilando. Vamos a volver al tema de los buffers. Dijimos que necesitbamos construir
Segundo, y ms importante, es que si no se define la terminologa fundamental, buffers de inventario delante de las limitaciones. Pero, un momento, puede que
sta tiene la mala costumbre de surgir en los sitios ms inesperados, nos hayamos precipitado. Lo que de verdad dijimos es que tenemos que proteger
convirtindolo todo en un lo indescifrable. Pero, para esto necesitamos otro nuestra capacidad de explotar la limitacin. No es lo mismo? No
captulo. necesariamente. Puede que la limitacin fsica no sea un recurso, puede que sea
el mercado o, siendo ms especficos, el pedido de un cliente. Y qu?
Si queremos garantizar la entrega a tiempo, a pesar de los problemas que
causa Murphy, parece que la nica solucin es acumular inventario de producto
acabado. No es as? No siempre. Supongamos que los acuerdos que tenemos
con nuestros clientes nos exigen entregar no ms tarde de una fecha especfica;
no podemos enviar despus de esa fecha, pero, si enviamos antes, nuestros
clientes estarn felices. S, ya s que ste no es siempre el caso, pero,
ciertamente, es una situacin muy comn. En los casos en que tenemos la
flexibilidad de enviar antes, es el inventario de producto acabado la nica
forma que tenemos de proteger la puntualidad de las entregas?
Si lo preguntamos de esta forma resulta evidente que podemos proteger la
fecha deseada de entrega a base de inventario o a base de tiempo. Podemos
empezar a cumplimentar un pedido antes de la fecha dada, por la duracin de
sus procesos. Empezar antes de lo necesario nos da el tiempo suficiente para
reaccionar ante las perturbaciones imprevistas y nos asegura la entrega a
tiempo. Si no hay perturbaciones, terminaremos el pedido antes de la fecha
prometida, pero el resultado no ser un incremento del producto acabado, sino
un envo ms temprano.
Si volvemos a examinar lo que acabamos de decir, nos queda un cierto mal
sabor de boca, parece que slo estamos haciendo juegos de palabras. S,
rodemos proteger con inventario o. como hemos visto en el ltimo
103
104 EL SNDROME DEL PAJAR INTRODUCCIN DEL CONCEPTO DE BUFFER DE TIEMPO
105
ejemplo, podemos proteger con tiempo, con un lanzamiento ms temprano. insuficiente. As pues, vamos a emplear un poco ms de
Tiempo e inventario no son sinnimos, y, aun as, nos parece que hemos
repetido lo mismo dos veces.
De dnde viene esta sensacin de incomodidad? Puede que debamos tratar
el caso en que el cliente no acepta que se le enven antes sus pedidos; en este
caso, es obvio que la nica forma de proteger es a base de inventario de
producto acabado. Cmo vamos a construir ese inventario? Empezando las
operaciones antes de lo estrictamente necesario. Esto significa que, en ambos
casos, las acciones que deben ejecutarse sern exactamente iguales:
conseguimos la proteccin empezando antes. Estamos tratando con dos
mecanismos de proteccin, o es slo uno?
Puede que la mejor forma de averiguarlo sea examinando otro caso donde la
limitacin sea un recurso fsico. Este es el caso en el que nuestra intuicin est
mejor desarrollada. Aqu est claro que tenemos que garantizar que el
inventario de proteccin est delante de la limitacin. Cmo nos aseguramos
de que el inventario se ir acumulando? Pensemos en una fbrica en la que
muchos productos distintos pasan por la misma limitacin. La forma de
construir el inventario es la misma de antes, empezando la produccin de cada
trabajo antes de lo que sera estrictamente necesario segn los tiempos de
proceso y de manipulacin de materiales.
Cmo es que dos entidades distintas, tiempo e inventario, parecen ser la
misma cuando se juzgan segn las acciones que implican? Creo que esta
uniformidad emana del hecho de que estos dos mecanismos de proteccin
deben existir simultneamente. En realidad no son dos mecanismos de
proteccin, sino uno solo. La dualidad emana de los distintos puntos de vista
con los que tendemos a ver las cosas. Podramos decir que estamos intentando
proteger dos cosas distintas. Una es la limitacin, la otra es el rendimiento, el
output, de la limitacin: los pedidos de los clientes.
Si usamos la terminologa de proteccin de la limitacin, nos centramos en
garantizar que la limitacin no estar ociosa. La terminologa que usamos de
forma natural es la de inventario; la composicin especfica de ese inventario
no tiene relevancia alguna. En realidad, a qu llamamos proteger la
limitacin, si no es a proteger su rendimiento? Si nos centramos en el
rendimiento de la limitacin, los pedidos especficos de los clientes, la
terminologa que usaramos es la de tiempo.
Como ya hemos dicho, proteger la limitacin y proteger su rendimiento es
bsicamente lo mismo, por lo que no es sorprendente que las acciones que se
derivan de ello sean iguales; lanzar antes el material. Qu terminologa
debemos usar de aqu en adelante, inventario o tiempo? Parece que nos
encontramos ante una eleccin, pero ya hemos aprendido, en muchas ocasiones,
que las elecciones arbitrarias son slo la consecuencia de un entendimiento
tiempo para aclarar este tema, en vez de elegir al azar, con un 50 por 100 de
probabilidades de arrepentimos de ello ms adelante.
Qu hemos dicho? Si usamos la terminologa de proteger la limitacin,
tendemos a usar el inventario como mecanismo de proteccin. La composicin
especfica de este inventario no tiene relevancia alguna. Interesante. Es posible
que la composicin del inventario no sea relevante? Parece sospechoso. Vamos a
estudiarlo con ms profundidad:
Proteger la limitacin. De dnde ha salido esta frase? En realidad, es una
versin abreviada del segundo paso de enfoque: decidir cmo explotar las
limitaciones del sistema. A que ahora est ms claro? Si explotar la limitacin
significa tenerla trabajando continuamente, la composicin del inventario no
tiene importancia alguna. Pero, no es ste el caso. Explotar la limitacin
significa sacarle el mximo (en trminos de la meta que se ha predeterminado).
Nuestro famoso caso nos ha enseado que la clave est en el contenido del
trabajo con el que queremos activar la limitacin. Slo cuando trabajamos con
un nico producto se deteriora el significado de explotar a hacerlo trabajar todo
el tiempo.
Ya que la composicin del trabajo de la limitacin es de la mxima
importancia, la proteccin se debe expresar como tiempo. Esta determinacin
(ya no es una eleccin) tambin est en lnea con nuestra intuicin cuando
consideramos aplicaciones ms amplias que la de produccin. Proyectos,
ingeniera de diseo, administracin, por no mencionar los sectores de servicio,
todos pertenecen al marco de nuestra discusin. Todos tratan de tareas que deben
cumplir los recursos para conseguir una meta predeterminada. Pero, en esos
entornos el inventario es con frecuencia invisible, mientras que el concepto
tiempo se entiende perfectamente.
Hemos decidido usar tiempo como nuestra unidad de proteccin, y, por lo
tanto, cuando nos refiramos al buffer nos estaremos refiriendo al buffer de
tiempo. Por lo tanto, el buffer es un intervalo de tiempo: el intervalo de tiempo
en el que lanzamos el trabajo antes de lo que sera necesario si asumiramos que
Murphy no existe. Los buffers se expresan en horas, das o meses. Qu
determina la longitud de un buffer? (Fig. 20.1).
El buffer de tiempo es nuestra proteccin contra perturbaciones desco-
nocidas. Lo que se desconoce de ellas no es que vayan o no a ocurrir; su
ocurrencia es algo casi garantizado. Lo que no sabemos es cundo ocurrirn,
dnde afectarn, ni cunto durar la perturbacin. Dada la naturaleza aleatoria de
las perturbaciones, es obvio que no estamos en situacin de estimar el buffer de
tiempo con precisin. Aunque tuviramos el tiempo y los recursos necesarios
para recopilar todos los datos estadsticos, slo conseguiramos una curva de
probabilidad. En la figura 20.2 se ensea una curva as, en la que en el 20 por
100 de los casos la perturbacin dura cinco minutos, y en el 1 por 100 de los
casos dura dos das.
106 EL SNDROME DEL PAJAR INTRODUCCIN DEL CONCEPTO DE BUFFER DE TIEMPO
107
Probabilidad
100 %
Tiempo
Fig. 20.2, Probabilidad de terminar un trabajo que pasa por muchas operaciones
en funcin del tiempo que transcurre desde el lanzamiento del trabajo.
21
Buffer y orgenes de buffer
remos una pieza media. Y no consideremos todo un lote, sino slo una pieza. Si un buffer es un intervalo de tiempo, ya no podemos hablar en trminos de
Recordemos que, excepto en procesos muy especiales, podemos pasar una pieza localizacin o contenido del buffer. El tiempo no tiene localizacin ni contenido.
a la siguiente fase del proceso antes de que el lote se haya terminado en la fase Debemos introducir otro trmino que nos permita referimos al sitio donde el
anterior. (Cuando estamos acelerando pedidos no llamamos divisin y solape inventario tender a acumularse, debido a lo adelantado de su lanzamiento.
de los lotes. En terminologa TQC es simplemente la diferencia que hay entre el Por qu? Por dos razones. La primera es que esta localizacin es muy
lote de proceso y el "lote de transferencia.) Si no somos fabricantes de piezas importante porque es el sirio donde podemos empezar el seguimiento del
muy sofisticadas de la industria aeroespacial, el tiempo medio de proceso por impacto agregado de todas las perturbaciones. Esta consideracin ha llevado a
pieza ser probablemente inferior a una hora, y en industrias de semielaborados Eli Shragenhaim a sugerir el nombre de punto de control del buffer,
ser de slo unos segundos. La segunda no se refiere al uso de los buffers, sino al proceso por el que los
Ahora, vamos a compararlo con el tiempo medio de permanencia del introducimos en nuestros planes. Como ya hemos dicho, el buffer es un
inventario en nuestra fbrica. Cmo vamos a calcular ese nmero? Es bastante intervalo de tiempo. Cmo situamos este intervalo flotante de tiempo sobre el
fcil. Probablemente tenemos, o podemos conseguir, un clculo bastante bueno eje de tiempo?
de las vueltas de inventario del material en proceso y del producto acabado. Si lo pensamos un poco nos daremos cuenta de que slo hay una opcin. Los
Doce vueltas de inventario al ao significa que la empresa mantiene en su poder buffer* existen para proteger el funcionamiento de la limitacin. As, cuando
cada pieza (desde el lanzamiento hasta su envo) durante un tiempo medio de un decidimos que una limitacin tiene que hacer un trabajo en un momento
mes. Comparen este nmero, que se expresa en semanas, con el nmero anterior, especfico, tenemos que lanzar el material requerido un buffer (intervalo de
que, probablemente, se expresa en minutos. Comparado con Murphy, el tiempo tiempo) antes que ese momento. (El material aparece entre comillas porque
real de proceso es insignificante. no es necesariamente un material fsico. Pueden ser planos, o, incluso, un
El tiempo total de proceso (lead-time) de los trabajos est dominado por permiso para empezar el diseo.)
Murphy. A efectos prcticos, el buffer de tiempo es el intervalo de tiempo en que Ya hemos dicho que para calcular la fecha de lanzamiento del material
adelantamos la fecha de lanzamiento de un trabajo con respecto a la fecha en la tenemos que retroceder en el tiempo durante un intervalo igual al buffer,
que est programado que lo consuma la limitacin. En la mayora de los casos partiendo del momento en el que la limitacin debe empezar a consumir el
no hace falta preocuparse de la insignificante correccin de tiempo necesaria material. As fijamos en nuestro plan de accin los intervalos de tiempo
para que se realice el trabajo en los distintos recursos. expresados por los buffers, o, dicho de otra manera: para calcular el programa
Qu sucede con los dos tipos de perturbacin, Murphy puro y de lanzamientos, tenemos que acoplar el extremo de los buffers de tiempo al
disponibilidad no instantnea? Cul de los dos es ms dominante en la programa de consumo futuro de la limitacin.
determinacin de la longitud del buffer? No lo s. Hasta hace muy poco, debido En el eje de tiempo, el programa de consumo de las limitaciones es el origen
a la falta de un sistema de informacin completo, no haba una forma prctica de de los buffers de tiempo. El buffer de tiempo retrocede en el tiempo a partir de
distinguirlos en la realidad. An, ahora, no hay suficiente experiencia prctica este punto. Recordemos que aqu slo estamos tratando con las limitaciones
para responder con rigor a esta pregunta. Mi estimacin personal es que deben fsicas. Las limitaciones polticas no deben protegerse, deben elevarse. Las
ser ms o menos iguales, pero el tiempo nos dir. limitaciones fsicas, ya sean un recurso o un pedido, tienen una ubicacin, y, por
La eleccin de tiempo como unidad bsica de proteccin, en vez de tanto, podemos llamar origen de buffer al sitio del que la limitacin saca el
inventario, les puede parecer tan natural que se estarn preguntando por qu material que consume. Esta terminologa nos permite conectar mentalmente
estamos perdiendo el tiempo con algo tan obvio. Un momento, algunas de sus los buffers que son intervalos de tiempo con la posicin fsica donde se
ramificaciones son casi contraintuitivas. Estamos acostumbrados a que los acumulan los inventarios de proteccin resultantes.
buffers sean algo fsico. Por ejemplo, nadie se sorprender cuando oiga Antes de abandonar este tema debemos aclarar un punto muy importante
preguntas como donde estn situado los buffers? o, "Cunto inventario cuntos tipos de buffer y, por tanto, de orgenes de buffer podemos tener
tenemos en el buffer? Pero, podemos seguir usando esa terminologa? ya no. en la empresa?
Por lo que hemos dicho hasta ahora parece obvio que tenemos ms de un
tipo de origen de buffer porque tenemos ms de un tipo de limitacin
112 EL SNDROME DEL PAJAR
ca; lo que hacen es advertirnos en contra de la repeticin continua de los sobre la que cae. Intentamos proteger todas nuestras alfombras? No. Muchas
mismos errores, No esperan que un prototipo funcione perfectamente la primera de ellas se pueden limpiar con facilidad; los recursos no limitados.
vez. Estn intentando cambiar la actitud mental actual. Si se hace el mismo tipo Dejando aparte las bromas, cul es la aproximacin fundamental inherente
de lote una y otra vez, por qu debemos aceptar tranquilamente que las a la terminologa del buffer y del origen de buffer? Por un lado, reconocemos,
primeras piezas de cada lote sean siempre defectuosas? sin lugar a dudas, la existencia de Murphy, si no, no hacen falta los buffers. Al
Aunque apoyamos totalmente este mensaje tan radical, la aproximacin que mismo tiempo, el trmino origen de buffer revela que somos muy tacaos a la
hemos elegido es mucho ms moderada. Nuestro punto de arranque es muy hora de permitir un buffer. En otras palabras, nos damos perfecta cuenta de que
distinto. Nos damos perfecta cuenta de que en la vida real no se puede eliminar a la proteccin tiene un precio; inflar el inventario tambin es perjudicial. Por
Murphy. S, la lucha contra Murphy es una tarea que merece la pena, pero no tanto, elegimos la proteccin slo cuando hay riesgo de perder algo ms
debemos dejarnos atrapar por nuestras propias palabras. Se puede, y se debe, importante: ventas.
luchar contra las perturbaciones, se puede reducir considerablemente a Murphy, Esta aproximacin nos lleva a intentar reducir, an ms, el precio que
pero, se puede llegar a eliminar? Por tanto, nuestra aproximacin debe consistir pagamos por la proteccin. Recordarn que la determinacin de la longitud de
en intentar desarrollar un modo de operar que tenga en cuenta, en cualquier los buffers de tiempo era una cuestin de juicio. Cmo verificamos si la
momento dado, que Murphy existe. Es ms, debemos tener en cuenta que la longitud elegida representa de verdad el equilibrio que tenamos in mente? Tiene
lucha para reducir las perturbaciones no es una batalla corta y nica, sino, que hacer algn mecanismo para comprobar si estamos demasiado expuestos
exactamente, lo contrario. Es una guerra continua. Por tanto, deberamos exigir por haber elegido un buffer corto, o si, en vez de estar algo paranoicos, como
que nuestro modo de operar nos guiar sabiamente en esta lucha interminable. debe ser, estamos histricos.
Como punto de arranque, nos debera proporcionar una lista constante de Pareto: Al explicar la naturaleza probabilstica del tiempo total de proceso (lead-
en qu problema nos debemos concentrar ahora, cul debemos resolver en time) hemos dado una indicacin clara de la tcnica que deberamos usar. Qu
segundo lugar?, y as sucesivamente. se demostr en la figura 22.2? Determinamos la longitud del buffer de tiempo
Reconozcmoslo, aunque limitramos el tema de Murphy a los problemas de esperando que un cierto porcentaje predeterminado de las tareas iba a estar en el
calidad, cuntos problemas de calidad tiene una planta? Cientos? Miles? origen de buffer en el momento necesario o antes. Por supuesto, suponamos que
Probablemente sean millones. Un esfuerzo hacia la calidad total slo puede se iba a lanzar un buffer de tiempo antes de la fecha de consumo. Lo que
ser efectivo si se gua por una lista de Pareto bien pensada y permanentemente deberamos hacer ahora es comprobar la situacin en la realidad.
actualizada. Si cumplimos las fechas de lanzamiento, y si nuestra estimacin del nivel de
Cmo vamos a inventarnos un modo de operar tan deseable? Precisamente perturbacin es ms o menos correcta, deberamos encontrarnos con lo que
la terminologa que hemos definido hasta ahora es casi suficiente para forzamos esperbamos. Pero si encontramos en el origen de buffer un porcentaje de tareas
hacia la direccin correcta. Tenemos que estar bien sintonizados con esta nueva ms alto del esperado, tenemos una clara indicacin de que sobreestimamos la
terminologa, y, adems, debemos tener cuidado de que nuestra inercia no nos longitud del buffer y, por tanto, debemos reducirla. Si ocurre lo contrario, un
retrase; una inercia que procede de antiguos hbitos y de nuevos (aunque no porcentaje mayor de lo esperado, no est llegando al origen de buffer ni siquiera
muy fundados) y entusiastas movimientos. en las fechas previstas de consumo, deberamos incrementar la longitud del
Buffers, la misma palabra que tantas veces hemos repetido en los dos ltimos buffer. S, no nos gusta tener que hacerlo, pero, mientras Murphy siga activo en
captulos, indica que nuestra aproximacin reconoce la existencia de nuestra organizacin, tal y como nos estn indicando los retrasos, se es el
perturbaciones. Pero, estamos intentando proteger todas y cada una de las precio que tenemos que pagar para proteger las ventas. Esto nos lleva
tareas? Por supuesto que no! El trmino origen de buffer muestra claramente directamente al siguiente tema.
que somos muy selectivos en lo que tratamos de proteger. De hecho, hemos Cmo podemos reducir el precio de la proteccin? Todo el que haya estado
elegido una aproximacin muy pragmtica. algn tiempo en una empresa sabe que el tiempo total de proceso (lead-time) de
Cul es una de las formas ms populares de describir a Murphy? Cual es la un trabajo es una entidad muy flexible. Aunque normalmente se tarde una
semana en hacer un trabajo, si es urgente y nos ocupamos personalmente de l,
probabilidad de que una rebanada de pan caiga con la mantequilla hacia abajo?
lo podemos hacer pasar por las operaciones en me-
Es directamente proporcional al precio de la alfombra
116 EL SNDROME DEL PAJAR PRIMER PASO EN LA CUANTIFlCACION DE MURPHY
117
Ya nos hemos dado cuenta de que si queremos reducir el precio que pagamos
por la proteccin, tenemos que concentrarnos en los trabajos que llegan ms
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 ms si atacamos las causas ms comunes de estos
retrasos.
Vamos a examinar esta idea tan interesante: utilizar el esfuerzo realizado
individualmente en los trabajos para determinar las causas ms generales de sus
retrasos. Cul 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
ms alta que, digamos, un 90 por 100. Despus, comprobamos si, de hecho,
estn en el origen de buffer. Si no encontramos all alguno de estos trabajos,
empezamos el proceso de aceleracin. La primera accin es encontrar dnde se
ha atascado el trabajo que est retrasado. Una vez encontrado, actuamos para
que siga adelante inmediatamente. Pero, ahora vamos a aadir otro pequeo
detalle; vamos a registrar dnde (delante de qu recurso) hemos encontrado el
trabajo atrasado. La repeticin de este proceso con cada trabajo que se retrase
resultar en una lista de recursos, y algunos de ellos aparecern en la lista
muchas veces. Cul 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 mayora, si no a todos, de los trabajos
que hace ese recurso. Es ms, si un problema de un recurso afecta a todos los
trabajos, y otro problema en otro recurso slo afecta a un trabajo, qu
problema es ms importante? Esta lnea de razonamiento, que reconoce que
muchos problemas finales tienen uno causa comn, nos
119
120 EL SINDROME DEL PAJAR GESTIN 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 estadstico.
Si un recurso aparece con frecuencia es porque contiene la causa de un
problema que es comn a muchos trabajos; puede ser un proceso defectuoso,
puede ser un ajuste poco fiable, puede ser una falta de capacidad de proteccin,
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 aceleracin. Si hacemos esto, si guiamos
nuestros esfuerzos de mejora de JIT y TQM por esta lista de recursos
problemticos, 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 reduccin del tiempo total de
proceso lead-time es muy probable) las ventas aumentarn. El aumento en
las ventas conducir a un aumento de las cargas de produccin que absorber
parte de la capacidad de proteccin 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 ms 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 problemticos resulte ms fiable. Recordemos que el tiempo que se
tarda en encontrar un problema de fondo suele ser ms corto que el tiempo
necesario para eliminarlo. As pues, no deberamos conformarnos con los datos
que reunimos durante nuestras actividades de aceleracin de trabajos,
deberamos ampliar nuestro seguimiento para cubrir tareas que an no
pretendemos acelerar, tareas que todava tienen tiempo de sobra, pero que an
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 todava) 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 aadir a la lista que
generamos cuando estbamos acelerando trabajos.
Probablemente, esta ampliacin del trabajo de seguimiento no slo
enriquecer la estadstica, sino que, adems, la mejorar. Vern, si empezamos
el seguimiento muy tarde, slo 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
problemtico, y, por tanto, ser raro que nuestra aceleracin de trabajos llegue a
detectar los recursos problemticos del principio del
proceso. En cualquier caso, el seguimiento de dnde quedan retenidos los
trabajos que se atrasan (no slo los urgentes) mejorar nuestra estadstica
considerablemente. No debemos llegar hasta el punto de seguir todos los
trabajos desde su lanzamiento; no siempre es mejor hacer ms. Si empezamos el
seguimiento inmediatamente despus del lanzamiento nos encontraremos con
ms del doble de trabajo, y, adems, la validez de la lista resultante se
difuminar.
Resumiendo, la gestacin 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,
sistemtica y metdicamente, para reducir el tiempo total de proceso (lead-
time). Despus, si localizamos los sitios donde se encuentran los trabajos
retrasados, y asignamos prioridades de acuerdo con el nmero de veces que
aparece en esa lista cada recurso (probablemente con un factor de ponderacin
que sea adecuado), tendremos una lista de Pareto que debe guiar nuestros
esfuerzos de mejora de la productividad. Pero, adems, hay otro beneficio que
probablemente es an ms importante.
Lo que debemos tener presente es que, cuando abordemos un recurso
problemtico, un recurso que aparezca en la lista con frecuencia, nos podemos
encontrar con que sus procesos estn en perfectas condiciones. Este recurso no
aparece en nuestra lista por tener problemas de proceso, sino porque no tiene
suficiente capacidad de proteccin. As pues, la gestin del buffer nos
proporciona el nico mecanismo conocido que permite calcular la capacidad de
proteccin que necesitan nuestros recursos.
Cuantificar Murphy es cuantificar la longitud del buffer y la cantidad de
capacidad de proteccin que se necesita,
En este punto es necesario hacer una advertencia. Todo lo que se ha dicho
hasta ahora se puede hacer fcilmente de forma manual, excepto, quiz, los
extensos trabajos de seguimiento, que probablemente deberan hacerse con un
informe de recursos ms 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 proteccin 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 proteccin, tenemos que acordamos de que una de las principales razones del
tiempo total de proceso de los trabajos es la disponibilidad no instantnea 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
proteccin, y, por tanto, un recurso puede aparecer frecuentemente en nuestra
lista de seguimiento debido a esas fluctuaciones. Lo que debemos
122 EL SNDROME DEL PAJAR GESTIN DE LOS ESFUERZOS DE MEJORA DE PROCESOS LOCALES
123
tener presente es que este problema no lo causa la proteccin de las limitaciones, las transacciones. Normalmente esta inexactitud reduce la utilidad de los datos
lo que pasa es que se revela gracias a nuestra forma sistemtica de trabajar. Pero, que hay en los informes de transacciones, pero quiz podamos matar unos
quiz ahora, debamos aclarar por qu decimos que es un problema. Es un cuantos pjaros de un solo tiro. Podemos mejorar significativamente la
problema porque la amplitud de la capacidad flexible de proteccin es bastante exactitud y puntualidad de los informes de transacciones y, al mismo tiempo,
limitada, ya que normalmente se reduce a las horas extras que haya disponibles. contestar otra pregunta de direccin que todava est pendiente?
Hoy en da abordamos esto aadiendo ms capacidad permanente, aunque esta Reconozcmoslo, la forma de mejorar sustancialmente la puntualidad y la
capacidad adicional slo es til, por definicin, durante una parte del tiempo. De exactitud de los informes de transacciones es convirtindolo, de alguna forma,
hecho, nos vemos obligados a aadir capacidad sobrante. A primera vista parece en el principal inters de las personas que tienen que informar. Cul es el
que estamos condenados a sufrir la naturaleza estocstica de nuestro entorno, y, principal inters de una persona sino sus propias medidas? Ya estamos a este
de hecho, ste es el caso, al menos en lo que se refiere a los clculos manuales. nivel, buscando datos sobre los pasos que avanza cada trabajo individual. Por
Pero hay una salida, siempre que contemos con la enorme paciencia de un qu no damos otro pequeo paso e intentamos averiguar cmo transformar este
ordenador para realizar clculos voluminosos sin morirnos de aburrimiento. esfuerzo en la respuesta al viejo problema de las medidas de rendimiento local?
La forma de vencer la necesidad de aadir capacidad permanente, para hacer No olvidemos que la cuestin de cmo medir, objetiva y constructivamente,
frente a los cambios frecuentes de la mezcla de producto, emana directamente de los rendimientos locales obtenidos es una de las cuestiones ms candentes de la
la relacin que existe entre la capacidad de proteccin y la longitud de los direccin. Si conseguimos contestar satisfactoriamente a esta pregunta,
buffers. Pero esto requerira programar de acuerdo con buffer dinmicos, y, por podremos llamar control justificadamente, a esta parte de nuestro sistema de
tanto, es mejor posponer todo este tema hasta el momento que tratemos del informacin.
bloque de PROGRAMACIN.
Si repasamos lo que hemos dicho en este captulo, parece que hemos
conseguido mucho ms de lo que pretendamos al empezar. Puede que debamos
continuar y seguir empujando un poco en la misma direccin. Nos disponamos
a cuantificar Murphy, y lo conseguimos con el mecanismo de control de la
longitud de los buffers. Pero, hemos conseguido ms, hemos encontrado un
mecanismo sistemtico para controlar la aceleracin de trabajos, no cuando ya
se ha hecho el dao, ni a base de apagar fuegos, sino de forma constructiva,
de forma que no apunta a un trabajo urgente especfico, sino que se dirige a
reducir el lead-time global de todos los trabajos. De hecho, hemos conseguido
algo que podramos empezar a llamar control.
El seguimiento de los puntos que estn 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 proteccin que se necesita en cada recurso. Como ahora estamos
hablando de hacer el seguimiento de un nmero considerable de tareas
atrasadas, podemos hacerlo de forma ms efectiva con un informe sobre
transacciones, en vez de con el mtodo, ms engorroso, de hacer el seguimiento
a lo largo de la explosin de los trabajos.
El informe de transacciones acerca an ms 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
24
Medidas del rendimiento
local
usamos el trmino control de inventario? A la capacidad de conocer dnde das slido y bien definido estas observaciones tan obvias? Puede que primero
est el inventario. Esto no es control en absoluto, slo es capacidad de reunir tengamos que aclararnos a nosotros mismos la unidad de medida con la que
datos. Para m, y probablemente para ustedes, control significa saber dnde estamos tratando aqu. Las desviaciones son, sin duda alguna, un tipo de pasivo,
estn las cosas con respecto a dnde deberan estar, y quin es el responsable de seguro que nadie dir que las desviaciones son un activo. Cul es la unidad de
las desviaciones que se produzcan. Y no de forma espordica, caso a caso, sino medida de un pasivo? Existe, de hecho, una unidad genrica? Intentemos
con un procedimiento que asigne continuamente un valor numrico a cada una averiguarlo. Tomemos un ejemplo claro de pasivo, un prstamo bancario. Esto,
de las reas responsables de la ejecucin. sin duda, es un pasivo. Cul es la unidad de medida de un crdito? Qu
Esta es la nica forma de dar a la gente la muy necesaria retroinformacin medida usamos para medir el perjuicio de ese pasivo?
sobre el resultado final de sus acciones. Esto es an ms importante en empresas Cuando recibimos un crdito de un banco el perjuicio en el que incurrimos
donde hay mucha gente implicada en todo el proceso, y donde el resultado final (el inters que tenemos que pagar) no es slo funcin de la cantidad de dlares
se suele obtener en algn departamento remoto, Pero esta forma de atacar el que nos prestan. Tambin nos preguntan por el tiempo que vamos a tener el
tema de las medidas del rendimiento local nos revela un aspecto muy crdito en nuestro poder. La cantidad absoluta de dinero que tenemos que pagar
interesante. Las medidas de rendimiento local no deberan enjuiciar el resultado como intereses es una funcin de la multiplicacin de los dlares que nos
final, ms bien deberan enjuiciar la influencia que tiene el rea que se mide prestan por el tiempo que tenemos el prstamo en nuestro poder. La unidad de
sobre el resultado final, Las medidas de rendimiento local deberan enjuiciar la medida de un prstamo es dlares multiplicando por das, abrevindolo,
calidad de ejecucin de un plan, y este juicio debera ser completamente dlares/da. Podra ser que cada vez que tratamos genricamente con pasivos,
independiente del juicio sobre el plan en s. y especialmente con las desviaciones, la unidad de medida adecuada fuera
Esto es especialmente importante en nuestras organizaciones, donde es dlares/da? Para examinar esta especulacin tan atrevida vamos a empezar por
frecuente que el nivel responsable de la ejecucin tenga muy poco que ver con el considerar toda la planta como la unidad local que queremos medir. A nivel de
desarrollo previo del plan. Si no tenemos la precaucin de juzgar por separado el planta, cules son los resultados finales de las desviaciones del primer tipo, no
plan y su ejecucin podramos recompensar a un departamento por un hacer lo que se debe? La respuesta es obvia: el resultado ser que no enviaremos
rendimiento magnfico cuando, en realidad, el rendimiento fue bajo, pero el plan a tiempo. Cul es la medida adecuada para los fallos en envos?
era lo suficientemente bueno como para cubrir el bajo rendimiento. O an peor, Como en una empresa normal los pedidos varan considerablemente en valor
podramos condenar a un departamento, cuyo rendimiento fue excelente, por monetario, y tambin varan los precios de venta de los productos individuales,
culpa de unos problemas que, en realidad, estaban en el plan original. no podemos usar como unidad de medida el nmero de pedidos o el nmero de
Estas advertencias nos llevan directamente a la conclusin de que cuando unidades que no se han enviado a tiempo (aunque, sorprendentemente, los
enjuiciamos adecuadamente el rendimiento local, de hecho, estamos enjuiciando porcentajes basados en esas unidades son bastante comunes). Es ms, parece
desviaciones, desviaciones en la ejecucin de un plan predeterminado. La razonable que tengamos en cuenta, de alguna forma, el nmero de das que se ha
calidad del plan en s debe juzgarse por las medidas que hemos estado usando: retrasado el pedido. Un retraso de un da en un pedido no se puede tratar de la
ingresos netos, inventario y gasto operativo. Pero, cules son las medidas misma forma que un retraso de un mes en ese mismo pedido.
adecuadas para las desviaciones? Una forma lgica de medir los retrasos en las fechas requeridas de entrega es
Lo primero que tenemos que reconocer es que las desviaciones del plan la siguiente: para cada pedido retrasado deberamos multiplicar el valor en
pueden adoptar dos formas distintas. El tipo de desviacin ms directa es no dlares de su precio de venta por el nmero de das que se est retrasando el
hacer lo que se debe hacer. Este tipo de desviacin, que es a la que, con razn, pedido. Si sumamos las multiplicaciones de todos los pedidos retrasados
se le presta ms atencin hoy en da, slo influye en una de las medidas. Si no tendremos una buena medida de la magnitud de la desviacin de la planta con
hacemos lo que se supone que debemos hacer, los ingresos netos disminuirn. respecto a su obligacin de enviar los pedidos a tiempo. No es de extraar que la
Pero hay un segundo tipo de desviacin. S, en efecto, es hacer lo que no se unidad de medida resulte ser dlares/da. donde los dlares reflejan los precios
debe hacer En cul de las medidas tendr un impacto adverso este tipo de de venta y los das reflejan los perodos de retraso de los pedidos.
desviacin? En el inventario, por supuesto.
Cmo podemos convertir sistemticamente en un conjunto de medi-
128 EL SNDROME DEL PAJAR MEDIDAS DEL RENDIMIENTO LOCAL
129
Podemos usar la misma tcnica del primer tipo en las secciones de una con una probabilidad bastante alta (digamos ms del 90 por 100), la llegada del
organizacin, tales como departamentos o, incluso, recursos individuales? No trabajo. Por lo tanto, podemos empezar a contar los das desde el momento en
veo ninguna razn por la que no se pueda hacer. A nivel de departamento, qu que el trabajo entra en la zona de aceleracin, en vez de usar la fecha de entrega
podemos usar como valor en dlares? No hay ninguna razn para no seguir del pedido. Esto nos dar algn tiempo para corregir la situacin antes de que el
usando el precio de venta final del pedido. Al final, es probable que no perjuicio para la empresa sea un fait accompli,
podamos enviar a tiempo el pedido debido a la desviacin de este Puede que esto no sea suficiente. Puede que tengamos que empezar a contar
departamento, S, este departamento slo tiene una pieza, pero, cules son las antes. Podemos decir que, en realidad, se ha provocado una accin de la
verdaderas ramificaciones? Cul es el dao potencial resultante para la organizacin (no una accin del departamento) mucho antes de que empezaran
empresa? No es el precio de esa sola pieza, es el retraso en recaudar el dinero las actividades de aceleracin. Empez cuando, debido a las desviaciones,
de todo el pedido. empezamos a hacer el seguimiento de la situacin de este trabajo. No
Qu pasa si resulta que dos departamentos estn retrasando el mismo deberamos contar los das desde ese punto? Puede ser.
pedido, porque cada uno se atrasa en un trabajo distinto? Por qu no usamos el As pues, vamos a multiplicar el precio de venta del pedido por el nmero
precio total de venta del pedido para cada uno de los departamentos? No de das que han pasado desde que empez una accin correctiva de la
tenemos que repartir las culpas, estamos intentando mostrar a cada organizacin. Qu vamos a hacer con el nmero resultante? A quin se lo
departamento el perjuicio que sufrir la empresa debido a las desviaciones del vamos a asignar? Al causante de que el trabajo se retrasara. Cmo vamos a
departamento. Recordemos que no vamos a poder enviar debido a las averiguar quin es el verdadero causante? Abriendo una agencia de
desviaciones de cada departamento por separado. Es suficiente con que slo investigacin? Tendr que ser mucho ms grande que el FBI, por no mencionar
uno de ellos no consiga recuperarse para que no podamos enviar a tiempo. el tipo de ambiente polmico que introduciramos en la organizacin si lo
Adems, no tenemos ninguna intencin de sumar todas las desviaciones de los hiciramos. Recordemos que el tema ms sensible de una organizacin es el de
departamentos para llegar a una medida global de la empresa. Por lo tanto, no las medidas de rendimiento individual.
se va a introducir ninguna distorsin por el hecho de usar el precio total de Qu piensan ustedes de la atrevida sugerencia de asignar la responsa-
venta del pedido en cada departamento que est retrasando ese pedido. bilidad, los dlares/da resultantes, al departamento donde est el trabajo ahora
Qu vamos a usar como punto de referencia de los das? Desde qu fecha mismo? Asignarlo basndonos en los hechos actuales, sin considerar en
vamos a considerar que un departamento est retrasando un trabajo? No parece absoluto qu departamento fue el que de verdad provoc la desviacin, parece
muy correcto esperar hasta la fecha de envo del pedido, sera incurrir en un injusto. Puede que el trabajo retrasado haya llegado ahora mismo, hace un
riesgo demasiado grande. Debemos recordar que ya que las medidas de minuto, a este departamento, y, ahora, vamos a poner toda la carga de los
rendimiento local se basan en las desviaciones, deberan avisar al rea que se dlares/da resultantes sobre los hombros de alguien que claramente no tiene
est midiendo de que algo est yendo mal. Si esperamos a esa fecha tan tarda nada que ver con el retraso.
para avisar, tendremos garantizado el dao. En ese momento lo nico que se Puede que a primera vista parezca injusta esta sugerencia tan directa, pero,
puede hacer es intentar minimizar los daos. Esto no parece casar bien con un momento, qu es lo que de verdad estamos intentando conseguir? No
nuestro ltimo descubrimiento de que debemos realizar el 100 por 100 de las olvidemos lo que nos disponamos a hacer. Estamos intentando medir el
entregas a tiempo. Qu deberamos escoger como punto de arranque para rendimiento local. Con qu propsito? Para motivar a las entidades locales a
sealar y, por lo tanto, cuantificar y empezar la acumulacin de las hacer lo que es bueno para la empresa como un todo. Examinndolo desde esta
desviaciones? Quiz, sera una eleccin razonable empezar a sealarlas cuando perspectiva, cul creen que ser la reaccin de un departamento al que se
la desviacin de un departamento ya haya provocado una accin correctiva de la acaba de cargar con un trabajo retrasado que arrastra consigo un nmero
organizacin. Ya hemos definido esos puntos en el tiempo. Recuerdan la zona considerable de dlares/da? Todos sabemos cul ser la reaccin, por supuesto,
de aceleracin? Vamos a repasar el significado de esa zona. A veces, una despus de maldecir al departamento que empez todo el lo.
desviacin en un departamento local provoca una accin de la organizacin. Este departamento que ahora tiene el trabajo retrasado llevar a cabo todas
Esto sucede siempre que un trabajo no llega a su origen de buffer, a pesar de que las acciones posibles para librarse de la multa, entregando ese trabajo
ha pasado el tiempo suficiente desde su lanzamiento, para que esperemos, retrasado al siguiente departamento lo ms rpidamente posible.
130 EL SNDROME DEL PAJAR MEDIDAS DEL HENDIMIENTO LOLAL 131
Al pasar el trabajo al siguiente departamento, pasar con l la penalizacin de trabajos retrasados es muy torpe; se quedan mucho tiempo en el departamento,
los dlares/da. Si por cualquier motivo no se acta, la penalizacin crecer aumentando la urgencia. Como resultado, vemos que, por supuesto, los
rpidamente, Recordemos que con cada da que pasa aumenta la penalizacin de dlares/da aumentan.
dlares/da. De hecho, conseguimos exactamente el tipo de actuacin que
desebamos; un trabajo retrasado pasar rpidamente de un departamento a otro,
como si fuera una patata caliente. La medida en s est provocando la
autoaceleracin.
Qu hay del hecho de que hacer esto sea simplemente injusto? Qu pasa
con las repercusiones sociales resultantes? Cuando examinamos las medidas a lo
largo del eje de tiempo, que es como debe hacerse, en vez de en un punto,
descubrimos que esta tcnica de fuerza bruta es, en realidad, una medida muy
justa. Veamos, por ejemplo, los siguientes tres grficos que representan la
medida de los dlares/da de ingresos netos, en funcin del tiempo, para tres
departamentos distintos.
Qu podemos deducir del departamento que muestra sus resultados en la
figura 24.1? Los picos nos cuentan toda la historia. Seguro que este
departamento no es la fuente de las desviaciones. Es un departamento que las
recibe y hace un trabajo excelente pasando rpidamente al siguiente
departamento los trabajos retrasados. El resultado final es un rendimiento muy
bueno, el promedio de dlares/da es muy bajo.
injusta la atribucin de los dlares/da al departamento donde est el trabajo? Qu pasa con el departamento de control de calidad? Por qu tienen que
Sin duda, se habrn dado cuenta de que esta medida es perfectamente aplicable sufrir mientras tanto? Dejemos de usar esta terminologa tan negativa: culpa,
a cualquier departamento de nuestra organizacin, sea ste ingeniera, envos o sufrir... Lo que estamos intentando hacer es enviar las seales adecuadas para
facturacin. La pregunta clave es siempre la misma: en este momento, quin que las personas sepan en qu se tienen que concentrar para ayudar a la
est retrasando el progreso del pedido? Por ejemplo, no es difcil imaginar que totalidad de la empresa. Vamos a coger el caso que acabamos de mencionar, el
bajo esta medida un departamento de ingeniera no se relajar mientras est departamento de control de calidad, cul es de verdad su funcin principal?
pendiente de entregar a produccin un solo plano entre los cientos necesarios Declarar que unas piezas son defectuosas? Eso es todo? O, an peor, retener
para fabricar algn sistema complejo. las piezas intentando averiguar si deberan ser desechadas o no, y mientras
Pero empieza a insinuarse otra ocurrencia perturbadora. Este tipo de medida nadie sabe si deberamos lanzar inmediatamente una reposicin, o si las piezas
puede fomentar el trabajo mal hecho. Bajo la presin creciente de los retenidas por control de calidad resultarn estar bien al final?
dlares/da, no puede elegir un departamento el camino ms fcil entregando a Su verdadero trabajo es localizar el origen del problema de calidad, para que
los siguientes departamentos un trabajo que no est bien hecho, entregando el los recursos correspondientes puedan actuar eliminando el problema de una vez
trabajo a medias para pasar la bola, para pasar la culpa a los hombros de por todas. Parece que la asignacin al departamento de control de calidad de
otro? Si ste es el caso, todo lo que hemos ganado fomentando la esos dlares/da que resultaron de los problemas de calidad no slo los lleva a
autoaceleracin se convertir en una situacin que no deseamos. hacer su trabajo verdaderamente importante, sino que, adems, les proporciona
Vamos a examinarlo tranquilamente. Supongamos que un departamento ha la necesaria lista de Pareto.
entregado un trabajo de baja calidad. Es inevitable que esta baja calidad se Miren hasta dnde hemos llegado. Es evidente que no hemos terminado de
revele algn da, ya sea por una de las siguientes operaciones o por un cliente explorar todas las repercusiones del uso de esta idea tan interesante, los
muy insatisfecho. Si ste es el caso, asignemos los dlares/da correspondientes dlares/da de ingresos netos. Todava tenemos que abordar el segundo tipo de
al departamento de control de calidad. S, al departamento de control de calidad. desviaciones, las que llevan a la inflacin del inventario, y, tambin,
Espero que a estas alturas ya estn usando extensivamente en sus empresas necesitamos abordar la medida local que se relaciona con el tercer elemento, el
el control estadstico de procesos (SPC). Aunque esta tcnica es muy til para gasto operativo. Estas desviaciones tambin se tienen que controlar. Qu
determinar cundo es mala la calidad de una pieza, su mayor fuerza reside en su vamos a hacer? Este capitulo ya es el ms largo de todo el libro!
capacidad de determinar la causa de fondo de la baja calidad, de sealar el Parece como si estuviramos cayendo en la trampa de la que hemos
proceso y, ciertamente, el departamento que produjo el defecto. En cuanto se intentado avisar: perder de vista lo que queremos conseguir. No olvidemos que
hace esto, los dlares/da se vuelven a asignar al departamento que caus el estamos intentando idear la composicin y estructura de un sistema de
problema de calidad. informacin. A este paso no vamos a llegar nunca, volvamos a nuestras
No es de esperar que este departamento se quede encantado con este directrices: limitamos a la estructura conceptual del sistema de informacin y,
fantasma del pasado. Recordemos que, a estas alturas, probablemente, estamos cuando sea necesario, abrir una nueva caja de Pandora, no dejarnos absorber
hablando de un pedido muy retrasado (especialmente en el caso de una totalmente en esos nuevos e interesantes temas. En nuestro contexto slo
devolucin del cliente); el nmero de das es considerable y tambin lo es la debemos proporcionar las directrices, no un anlisis completo.
penalizacin en dlares/da resultante. No hay duda de que cualquier As que, para el que quiera profundizar ms en el tema de las medidas del
departamento preferir comprobar la calidad muchas veces antes de que el rendimiento local, slo podemos decir que hay un poco ms escrito sobre el
trabajo traspase los lmites del departamento. Cualquier problema de calidad que tema en el Theory of Constraints Journal, volumen 1, nmero 3.
se detecte en las operaciones siguientes causar al departamento descuidado
unos dolores de cabeza mucho ms grandes, Asombroso. Nos temamos que esta
medida nos llevara a la mala calidad, y resulta que nos lleva, directamente, al
modo de trabajar tan querido por TQM: calidad en el origen.
25
Un sistema de informacin debe
estar compuesto por mdulos
de programacin, control
y simulacin
Como hemos estado tratando de tantas materias, puede que sea hora de ver
dnde estamos, Decidimos cortar por lo sano en la confusin existente entre
datos e informacin, definiendo lo que nosotros entendamos por esas palabras.
Para nosotros, un dato es cualquier conjunto de caracteres que describa algo
sobre la realidad. Decidimos que la informacin era la respuesta a lo que se ha
preguntado. Llamamos datos requeridos a la parte de los datos que es
necesaria para deducir la informacin requerida. A partir de estas definiciones,
nos encontramos con situaciones en las que la informacin no est
inmediatamente disponible, sino que tiene que deducirse de los datos requeridos.
Estas situaciones nos obligaron a darnos cuenta de que el proceso de deduccin
no es algo externo al sistema de informacin, y que, para muchos tipos de
informacin, el proceso de decisin en s debe ser parte integral del sistema de
informacin.
Debido a esto, y reconociendo los sistemas que hay disponibles actualmente,
decidimos llamar sistemas de datos a los sistemas que proporcionan
informacin inmediatamente disponible, reservando el nombre de sistemas de
informacin para aquellos que proporcionan informacin que no se puede
obtener sino es a travs de un proceso de decisin.
Al examinar diversas preguntas tpicas de direccin no pudimos dejar de
damos cuenta de que, a veces, la informacin tiene una estructura jerrquica,
donde lo que para un nivel es un dato requerido, puede ser informacin para
otro nivel. Es ms, nos encontramos con preguntas muy importantes para las
que no haba disponibilidad inmediata de los datos, se tenan que deducir
usando un proceso de decisin. Esos casos nos hicieron comprender que un
sistema de informacin que sea completo deber construirse sobre una
estructura jerrquica.
En los sistemas de informacin industriales est muy claro que, en la
135
136 EL SNDROME DEL PAJAR UN SISTEMA DE INFORMACIN DEBE ESTAR COMPUESTO POR MDULOS 137
cumbre de la pirmide informativa, sabemos contestar a preguntas de direccin ya que la informacin que proporcionan estos dos bloques son los datos que
que tratan principalmente de elevar limitaciones o de prevenir la creacin necesita el bloque de simulacin. Cul es la relacin entre los bloques de
innecesaria de nuevas limitaciones. A este nivel pertenecen las preguntas programacin y control? Son completamente independientes, o uno es
relacionadas con justificacin de inversiones, decisiones de comprar/fabricar, prerrequisito del otro?
cuestiones de compras y, por supuesto, dilemas entre el diseo del producto y Es suficiente un examen superficial para revelar que el bloque de control no
las ventas/marketing. Decidimos llamar a esta parte superior del sistema de se puede usar hasta que est implantado el bloque de programacin. Qu
informacin la fase de simulacin (qu pasara si...? dijimos que significaba control? Saber dnde estn las cosas con respecto a
Result que, para poder siquiera empezar a contestar a esas preguntas, dnde deberan estar. Debemos controlar las desviaciones con respecto a un
primero nos tenamos que dedicar a generar los datos requeridos, datos que, en plan predeterminado, por tanto, la programacin la planificacin debe
s mismos, no estn inmediatamente disponibles, y que son la respuesta de estar establecida antes de que podamos empezar con el control. Pero, vamos a
otros dos tipos de preguntas de la direccin. examinar conceptualmente, con ms detalle, lo que estamos intentando
El elemento ms fundamental resulta ser la identificacin de las limita- controlar, para que podamos exponer los requerimientos que deber cumplir el
ciones actuales del sistema. Nuestro anlisis nos mostr claramente que, para bloque de programacin.
identificar las limitaciones actuales del sistema (por no mencionar la necesidad Las desviaciones que influyen en los ingresos netos y las desviaciones que
de identificar las limitaciones resultantes que se derivan de la alternativa que se influyen en el inventario son desviaciones de planes realistas. Esto supone que
est evaluando), no tenamos ms remedio que resolver el viejo problema de nuestro plan programa debe tener en cuenta la existencia de Murphy, sino
cmo programar las operaciones de una empresa. As pues, la fase ms bsica no podr ser un plan realista. Es obligatorio que el bloque de programacin
de un sistema de informacin es la fase de programacin. proporcione un plan de acuerdo con algn clculo predeterminado del nivel de
Decidimos dejar para el final la discusin detallada de cmo programar Murphy que existe en la planta. Slo as podr proporcionar programas realistas
fiablemente las operaciones de una empresa, y nos sumergimos en la aclaracin el bloque de programacin, y el bloque de control tendr sentido en su esfuerzo
del otro tipo de dato requerido, el tipo de dato que gira alrededor de la por reducir el impacto de Murphy.
cuantificacin de las perturbaciones que se acumulan en la organizacin. Como Por tanto, debemos dar a la fase de programacin unos clculos aproxi-
este tema es un territorio relativamente virgen, tuvimos que emplear bastante mados de los buffers de tiempo y de los niveles requeridos de capacidad de
tiempo en aclarar la terminologa bsica adecuada. Durante este proceso nos proteccin, clculos que despus se afinarn en la fase de control. El intento de
fuimos convenciendo, cada vez ms, de que esta fase del sistema de usar la fase de simulacin antes de que se hayan determinado unos niveles
informacin, de hecho, est tratando con preguntas de la direccin que giran fiables de capacidad de proteccin con el uso de las otras dos fases es, desde mi
alrededor del tema de control. punto de vista, una prdida de tiempo.
La fase de control tiene la capacidad de cuantificar a Murphy, lo que es Ya tenemos el plan de accin. La primera fase que debemos construir del
esencial para entender la magnitud de la relacin que existe entre el inventario y plan de accin es la fase de programacin. El nico dato necesario, adems de
la capacidad de proteccin y, por tanto, para ser capaces de contestar los que hoy en da se usan normalmente, es un clculo aproximado del impacto
fiablemente a cualquier pregunta del tipo qu pasara si...? Es ms, este del Murphy existente. Una vez que esta fase sea operativa se puede poner en
mismo mecanismo es necesario para proporcionar otras dos clases de prctica la siguiente, la fase de control. Y solamente despus de haberlas usado
informacin necesaria. Una es la respuesta a la pregunta de dnde concentrar durante algn tiempo podremos alcanzar el objetivo ltimo del sistema de
nuestros esfuerzos para reducir Murphy: dnde enfocar nuestros esfuerzos de informacin: la capacidad de contestar a nuestras preguntas de simulacin.
mejora de procesos. La segunda es el tema, enormemente necesario, de las Ahora necesitamos empezar a tratar de la estructura de la primera fase la
medidas del rendimiento local. programacin, pero, no como antes. Acabamos de llegar a los cimientos y,
Hasta ahora hemos establecido que el sistema de informacin debe estar por tanto, ya no podemos dejar temas abiertos, quedndonos satisfechos con
compuesto por tres fases o bloques: los bloques de simulacin, de slo mostrar la direccin conceptual. De ahora en adelante cada detalle debe
programacin y de control. Tambin hemos establecido que el bloque de quedar muy bien establecido.
simulacin no se puede hacer antes de que los otros dos sean ya operativos,
TERCERA PARTE
Programacin
26
Acelerando el proceso
141
142 EL SNDROME DEL PAJAR ACELERANDO EL PROCESO 143
buena a base de refinar prematuramente una solucin que todava no se ha Cunto tardaremos si usamos el mtodo tradicional? Seguro que muchas
descrito? horas, quizs das. Si tienen que emplear tanto tiempo en evaluar siquiera una de
En otras palabras, el tiempo necesario para generar un programa, es un las muchas alternativas, de verdad creen que usaran el sistema de
factor decisivo que nos impedir totalmente el uso del sistema de informacin, o informacin? La conclusin inevitable es que debemos exigir que la fase de
slo es una molestia? A primera vista, parece que la situacin requiere que se programacin sea capaz de realizar una programacin detallada de un plazo
realice un programa nada ms. El que queramos tenerlo tan pronto como sea largo para toda la empresa en menos de una o dos horas, Es una exigencia
posible no importa mucho, siempre que, de verdad, lleguemos a tenerlo. Pero tremenda, pero, probablemente, es inevitable.
sta no puede ser la respuesta general. Para reducir drsticamente el tiempo necesario para programar, parece que
Es fcil demostrarlo. Imaginemos que el tiempo necesario para generar un no tenemos ms remedio que volver a examinar cada paso que consuma tiempo;
programa de una semana es ms de una semana. Si sta es la situacin, el incluso la forma en que actualmente tratan los datos los sistemas MRP
mtodo, ciertamente, no es prctico. El tiempo de generacin no es una convencionales. Tenemos que examinarlo crticamente, para encontrar dnde se
trivialidad, es un ingrediente esencial que se debe considerar mientras se consume la mayora del tiempo que tardan. Una vez ms, cuando nos
desarrolla la solucin. Tiene que haber un lmite mximo para el tiempo de encontramos con un problema que existe desde hace mucho, no tenemos ms
generacin del programa, un lmite que, si se supera, convierte al mtodo remedio que profundizar hasta las races escondidas del problema.
definitivamente en intil. Por qu tarda tanto una ejecucin de MRP? Los ordenadores tienen fama de
Bueno y, por qu estamos perdiendo el tiempo en cosas que son obvias? ser extremadamente rpidos. Como sabemos algo sobre ordenadores, sabemos
Porque puede que nuestra impaciencia provenga de la falsa premisa de que la que tienen dos velocidades diferentes: la velocidad de clculo y la velocidad de
mayora de las soluciones factibles para los problemas de programacin entrarn archivo y recuperacin de datos. Ambas velocidades son notables, pero son
dentro de los lmites tolerables sin ningn esfuerzo adicional. De verdad es ste drsticamente distintas.
el caso? Parece que lo es, sin duda. Nuestra experiencia en programacin ya nos La velocidad de clculo del ordenador, usando los que llamamos unidad
da un clculo aproximado de ese lmite superior. Sabemos que podemos tolerar central de proceso (CPU) y su memoria on-line, es extraordinaria. Hasta los
un tiempo de generacin del programa de muchas horas, incluso de un fin de ordenadores personales pueden multiplicar dos nmeros grandes en menos de
semana completo... Entonces, por qu tenemos que preocuparnos de limitar el una millonsima de segundo. Pero la velocidad del ordenador es muy distinta
tiempo de generacin? Un momento, no tan deprisa. Nuestra experiencia cuando recupera o escribe un bloque de datos en su soporte de almacenamiento
procede de una realidad en la que considerbamos la programacin como un fin de datos: los discos. Llamamos a este modo de operacin el modo de
en s misma, no como un paso necesario para otra cosa. Es posible que cuando entrada/salida (lnput/Output, I/O). Aun considerando los discos ms rpidos de
evaluemos la programacin como una fase de un proceso ms grande, el proceso uso ms comn que hay en el mercado, estamos hablando de tiempos mayores
de simulacin, nuestra intuicin nos pida que reduzcamos considerablemente el que una centsima de segundo. Una velocidad notable, pero es como el paso de
lmite superior? Reducirlo hasta el extremo de que no sean aceptables las un caracol si lo comparamos con la velocidad de clculo.
muchas horas necesarias para generar un programa detallado de varias semanas? De la forma en que se han escrito los paquetes de programacin disponibles
Para aclarar la situacin intenten imaginar que ustedes, como directores, actualmente destaca, sin duda, el hecho de que, la mayora del tiempo, el
estn intentando decidir entre varias alternativas. No olvidemos que la mayora ordenador est ocupado recuperando y escribiendo datos, desde y hacia los
de las cuestiones de direccin no slo tienen influencia en el futuro inmediato, discos. Cualquier profesional les dir, sin ninguna duda, que MRP es
sino, tambin, a medio plazo. Examinen, por ejemplo, la lista de preguntas que totalmente I/O. Que quiere decir, en palabras ms simples, que la gran
aparece al principio del captulo 17. Cul es el horizonte de tiempo que mayora del tiempo no se consume haciendo clculos, sino moviendo datos
implican? Vara desde algunos meses hasta varios aos. Como ya hemos dicho, internamente. Hasta el pequeo porcentaje de tiempo que el ordenador declara
si queremos evaluar fiablemente cada una de las alternativas, tendremos que como tiempo de la CPU resulta ser, si lo examinamos bien, el tiempo de la CPU
descubrir el impacto que tienen en las limitaciones del sistema y, por lo tanto, que tiene que invertir el ordenador para tratar los datos. Slo se dedica a los
debemos tener un programa que abarque todo el horizonte de tiempo clculos una fraccin de un porcentaje del
correspondiente, un programa detallado.
144 EL SNDROME DEL PAJAR ACELERANDO EL PROCESO 145
tiempo total que tenemos que esperar para que el ordenador genere el para recuperar datos que podran recalcularse internamente muchsimo ms
programa. deprisa. Por supuesto, este ltimo mtodo requiere mantener ms datos en la
Tiene que ser as, o podemos hacer algo para mejorar la situacin memoria on-line, pero, como ya hemos dicho, las limitaciones, en cuanto a
existente? Resulta que la mentalidad que usamos para codificar el ordenador memoria disponible, se han reducido drsticamente. Si prestamos atencin a
todava tiene una fuerte influencia de las limitaciones tcnicas que haba en el esta diferencia entre la velocidad de clculo y la velocidad de recuperacin,
pasado limitaciones que hoy en da estn totalmente superadas, incluso en el podemos reducir en ms de mil veces el tiempo total de ejecucin del
ms pequeo y corriente de los ordenadores personales (PCs). ordenador.
Vern, hace menos de quince aos, un programador no tena un ordenador Esto es bsicamente lo que tenemos que hacer aqu, pero, aunque
potente a sus rdenes, un ordenador con ms de un milln de bytes para el disponemos de mucha memoria, si la desperdiciamos puede llegar a convertirse
tratamiento de datos on-line (memoria on-line). Todos los programadores con en una autntica limitacin. Por lo tanto, deberamos examinar la forma en que
experiencia, y, ciertamente, todos los libros de texto sobre programacin, se vamos a almacenar y tratar los datos, que es lo que nos va a dictar los tiempos
basan en la experiencia conseguida en un entorno donde tenan que luchar globales de ejecucin, y, por lo tanto, la viabilidad de nuestro sistema de
contra la rigidez de no tener suficiente memoria disponible para sus programas. informacin.
Incluso cuando llegaron los grandes ordenadores centrales, trayendo con
ellos memorias on-line de millones de bytes, los programadores saban que si su
programa necesitaba una gran parte de esa memoria, tendra que esperar en la
cola durante muchas horas. Recordemos que esos ordenadores centrales los
utilizaban muchos usuarios, en contraste drstico con nuestro mundo de
ordenadores personales. Con esas restricciones de memoria, no quedaba ms
remedio que almacenar y despus recuperar los valores intermedios
(especialmente si recordamos que el tiempo promedio entre fallos era de unas
pocas horas).
La inercia que generaron las restricciones pasadas ha enmascarado la gran
diferencia que hay entre las preferencias de una persona y de un ordenador.
Supongamos que tienen ustedes dos listas de 50 elementos cada una. En una
lista estn los precios por unidad y, en la otra, las cantidades que se van a
comprar de cada elemento. Les gustara saber la cantidad total de dinero que
tendrn que pagar. Uno de los caminos posibles es multiplicar cada nmero de
la primera lista con su correspondiente de la segunda, y sumar los cincuenta
resultados. O, simplemente, podemos pasar la pgina y leer el resultado, est
escrito all. Qu preferiran hacer? Sin duda, pasar la pgina. Pero el ordenador
no.
Para el ordenador pasar la pgina supone acceder al disco y traer a la
memoria un conjunto de datos. En esta operacin tardar algunas centsimas de
segundo. Si hace las 50 multiplicaciones y, despus, suma los resultados,
tardar algunas millonsimas de segundo. El ordenador prefiere hacer el clculo
completo mil veces antes que tener que recuperar del disco el resultado.
En general, los paquetes que se encuentran en el mercado no utilizan esta
enorme capacidad de clculo. En vez de eso, van y vienen al disco
27
Reduciendo algo ms
la inercia: reordenacin
de la estructura de los datos
149
nar cantidades grandes de datos. En las cintas slo se pueden almacenar almacenamiento es a base de cintas. Lo ms aproximado es detallar el
cantidades grandes de datos. En las cintas slo se pueden almacenar y
recuperar los datos de forma secuencial; esta limitacin tcnica enfrent a los
diseadores de MRP con un enorme problema.
Examinemos la situacin a la que se enfrentaban cuando la estructura del
producto contena un subensamblaje complejo, necesario para distintos
productos finales. Veamos, por ejemplo, la figura 27.1.
Subensamblaje
A
Subensamblaje
A
Pero, qu habra pasado si hubieran elegido esa descripcin? Cada vez que
hiciera falta explosionar uno de los otros productos tendramos que rebobinar la
cinta para conseguir los detalles del ensamblaje. Saben cunto se tarda en
rebobinar una cinta? Ya no son fracciones de segundo, son minutos, aparte de
que haran falta tantos rebobinados que, probablemente, la cinta se rompera
antes de terminar la ejecucin.
150 REQRDENACION DE LA ESTRUCTURA DE LOS DATOS 151
EL SNDROME DEL PAJAR
La otra alternativa que tenan, tambin mala, era detallar los datos del
submensaje en todos y cada uno de los productos que lo necesitaran (como se Lista de materiales
muestra en la figura 27.3).
a a
Subensamblaje b c d b c d
Subensamblaje
A A
e f g h e f g h
Ruta
a d f h
___
b
e ___ g ___
___
153
rutas, representando cada entrada una fase del viaje. Bsicamente hemos
vuelto al cuadro ms fundamental, el que se muestra en la figura 27.1. Cada
paso del viaje del material es equivalente a un cdigo de pieza/cdigo de
operacin. Un cambio trivial.
A una persona que no haya pasado muchos aos en el entorno de MRP ni
siquiera le parecer un cambio, le parecer una eleccin natural. Pero el
impacto en el tiempo de ejecucin del ordenador es bastante profundo. Esta
fusin entre el BOM y las rutas convencionales reduce drsticamente el nmero
de veces que necesitamos acceder al disco, y, por lo tanto, acelera todo el
proceso en varios rdenes de magnitud. Qu precio tan alto hemos pagado por
culpa de nuestra inercia!
Pero no nos detengamos aqu, vamos a fundir ms ficheros de datos en
nuestra estructura del producto. Hoy en da la mayora de los sistemas
mantienen separados otros dos ficheros. Uno se suele llamar inventario de
almacn y el otro inventario de trabajo en proceso (work-in-process: WIP). El
inventario de almacn bsicamente detalla la cantidad disponible de piezas
terminadas, subensamblajes y materiales, mientras que el WIP contiene el
inventario de piezas parcialmente procesadas. Cul es el motivo de esta
separacin que, una vez ms, dilata el tiempo de la explosin?
Cuando consideramos desde el punto de vista de diseo del sistema algunas
piezas que estn procesadas parcialmente, nos encontramos con la necesidad de
codificarlas, de asignar un cdigo a estas unidades. De hecho, tenemos dos
alternativas para este caso. Podemos codificar el inventario segn el cdigo de
la ltima operacin por la que han pasado las unidades, o podemos codificarlo
segn el cdigo de la siguiente operacin que deben pasar. Ambas opciones son
equivalentes. No es de extraar que a principios de los sesenta los diseadores
del sistema decidieran elegir de acuerdo con la costumbre de las fbricas.
Dnde situamos los elementos que estn a medio procesar? En la cola que hay
delante de la siguiente mquina. En otras palabras, asignamos fsicamente el
inventario WIP de acuerdo con la siguiente operacin por la que debe pasar. Era
una eleccin natural.
Esta eleccin, tan natural para piezas semiprocesadas, es totalmente
inadecuada cuando estamos tratando con piezas acabadas. Aqu no tenemos la
opcin de codificar el inventario de acuerdo con la siguiente operacin, la
siguiente operacin es el ensamblaje. Si le asignamos el cdigo del ensamblaje
damos la falsa impresin de que tambin estn disponibles los dems
componentes que hacen falta para ese ensamblaje.
Para las piezas acabadas, la nica alternativa posible es codificarlas de
acuerdo con la ltima operacin que se les ha hecho. Esta diferencia hace
necesaria la separacin de los dos ficheros de inventario, una separacin que no
molest demasiado a los diseadores, ya que reflejaba la separa-
cin que ya exista entre los ficheros BOM y de rutas. Nosotros tendremos que
ser ms coherentes, ya que hemos fundido los dos ficheros de la estructura del
producto. Siempre nos referiremos al inventario segn la ltima operacin por
la que haya pasado. Esto no slo nos permitir fundir en uno los dos ficheros de
inventario, sino que, adems, permitir la convergencia de los datos de
inventario en un solo campo, que residir en el fichero de la estructura del
producto,
Esta reduccin del nmero de ficheros abre la posibilidad de mantener en la
memoria todos los datos necesarios. Esto slo se podr conseguir si no inflamos
los datos necesarios para programar con otros detalles que no tienen nada que
ver, como la direccin de un proveedor o el ngulo al que se debe cortar el
material. Igualmente, debemos tener la precaucin de no almacenar demasiados
resultados de clculo intermedios. Si lo hacemos, se comer rpidamente la
memoria disponible, y nos veremos obligados a recurrir a los discos.
Recordemos que repetir un clculo largo es mucho ms rpido que ir a buscarlo
al disco.
La capacidad de mantener en la memoria todos los datos necesarios
permitir que el ordenador slo tenga que acceder al disco al principio de la
ejecucin de la programacin para copiar los datos en la memoria y, al
final para escribir la programacin. La disponibilidad de memoria que existe
hoy en da, que alcanza los megabytes incluso en un PC, nos permite operar de
esta forma tan deseable. No es de extraar que el resultado sea un recorte
drstico del tiempo de ejecucin. La programacin detallada de una fbrica
grande, para un horizonte de muchos meses o, incluso, de aos, puede
conseguirse ahora, en los potentes PC actuales, en bastante menos de una hora.
Por supuesto que el problema de la conversin empieza a levantar su fea
cabeza. Cmo vamos a pasar de la estructura multiarchivo actual a la red de
estructura-tarea uniforme que se sugiere? Este problema parece an ms
complicado cuando recordamos que en nuestros ficheros actuales hay metidos
muchos ms datos, muchos ms de los estrictamente necesarios para la
simulacin de las acciones futuras de la empresa. Esos datos adicionales no
van a convertir el plan que hemos sugerido en otra pesadilla distinta, pero no
menos complicada?
Puede que s, puede que no. Pero la pregunta que de verdad nos debemos
hacer es si tenemos o no que convertir toda nuestra base de datos. De verdad
que nos tenemos que preocupar de esto? Aqu estamos tratando de construir un
sistema de informacin, no estamos intentando mejorar nuestros sistemas
actuales de datos. En cualquier caso, ya hemos llegado a la conclusin de que un
sistema de informacin no sustituye a un sistema de datos; es mejor que nuestro
sistema de informacin absorba los datos que necesite de un sistema de datos.
154 EL SINDROME DEL PAJAR REORDEMACION DE LA ESTRUCTURA DE LOS DATOS
155
Programad las tareas que debe realizar una organizacin! Es fcil de hacer,
pero por dnde empezamos? Debemos empezar con los pedidos de los
clientes y explosionarlos hasta el nivel de las tareas? Si lo hacemos as, qu
pedido debemos coger primero? El de mayor facturacin? El que representa
una carga mayor? El que ya estamos sospechando que vamos a entregar tarde?
O puede que debamos intentar un ataque completamente distinto, como podra
ser empezar con los trabajos que estn atascados ahora mismo: limpiar el
sistema no parece mala idea. Pero hay una vocecita que nos susurra desde el
fondo que, ya que hemos discutido tanto el problema de la capacidad limitada,
lo mejor sera empezar por secuenciar las tareas de uno de los recursos ms
cargados, y continuar a partir de ah. Hay tantas posibilidades... Ninguna de
ellas parece muy prometedora, especialmente cuando descubrimos que cada
una de ellas se ha intentado ya ms de una vez, y que han llevado a programas
que ciertamente no eran nada extraordinarios.
Bueno, en algn sitio tendremos que empezar. Pero, antes de luchar con la
pregunta de dnde empezar, es mejor que aclaremos lo que de verdad
queremos conseguir. Un programa! No est claro? No necesariamente. Qu
tipo de programa queremos construir? Qu programa nos resultar
satisfactorio?
Empezamos a darnos cuenta de que el primer paso para desarrollar un
programa es definir los criterios que debe cumplir un buen programa. El
primer criterio es muy obvio: el programa debe ser realista. Pero, un momento...
Qu queremos decir con la palabra realista? No nos conformemos con usar
palabras de significado demasiado amplio, palabras que no nos facilitan un
entendimiento seguro de lo que en realidad debemos, o no debemos, hacer.
Qu puede hacer que un programa se considere como no realista?
157
158 EL SNDROME DEL PAJAR
ESTABLECIMIENTO DE LOS CRITERIOS PARA UN PROGRAMA ACEPTABLE 159
tenemos que tomar mucho ms en serio el requerimiento de que los productos cumplir con los requerimientos del cliente. Para vencer este obstculo los
sean realistas. tiempos disponibles individuales (ya fuera el nmero de tarjetas Kanban o
Antes de hacer una pausa para seguir avanzando, debemos recordar que los tiempos de colas y esperas) tuvieron que reducirse tanto que, una vez ms,
tenamos dos requerimientos para que un programa fuera realista. Uno era la nos encontramos con programas inestables:
resolucin de conflictos entre limitaciones. Cul era el segundo? Ah, s! El Lo que se necesita es inmunidad en el programa hasta el punto de que las
segundo requerimiento que debe cumplir un programa es que sea inmune a las predicciones del programa sean realistas: la prediccin sobre el funcionamiento
que se espera de la organizacin, y la prediccin sobre las limitaciones de la
perturbaciones. Para nosotros este requerimiento no es una novedad, ya que lo
organizacin.
hemos tratado bastante extensamente en los captulos anteriores, pero no como
Es eso todo? Ya hemos terminado de definir los criterios por los que
parte del programa en s. Hemos tratado de este tema como parte del control.
deberamos juzgar un programa? Todava no hemos mencionado el ms
El concepto de inmunidad tiene que ver con la programacin? No podemos
importante. Para qu necesitamos un programa? No nos olvidemos de lo que
dejar de darnos cuenta de que, sin duda, es as.
estamos tratando. Cuando originamos un programa nuestro objetivo es, como
Un programa, por definicin, se refiere a un intervalo de tiempo. Si el
siempre, intentar alcanzar la meta. As pues, el programa, una vez que sea
propsito del programa es la identificacin de limitaciones futuras, el programa realista, debe juzgarse con las mismas medidas que usamos para juzgar los
deber ser absolutamente realista para ese futuro intervalo de tiempo. Si resultados: valor generado, inventario y gasto operativo. Debemos tener
cualquier perturbacin, cualquier accin de Murphy, provoca una presente la escala de importancia de estas medidas. Cuando nos encontremos en
reprogramacin, es la mejor indicacin de que el programa que se ha generado una situacin en la que se pueda perjudicar el valor generado, una situacin que
no es, en absoluto, realista para el futuro intervalo de tiempo requerido. Parece podramos corregir aumentando el inventario o el gasto operativo, debemos
que la inmunidad es un requerimiento obligatorio para un programa. tomar las medidas de correccin adecuadas sin titubear. Pero aqu es necesaria
Los mtodos antiguos han tenido en cuenta la inmunidad? No del todo. La una advertencia. Siempre que aumentemos el inventario o el gasto operativo
programacin lineal no dudaba en presentar soluciones que se basaban en debemos tener mucho cuidado de no chocar contra las condiciones necesarias.
limitaciones interactivas. Esto se haca a pesar del hecho de que todos los Por ejemplo, si para proteger el valor generado debemos aumentar el
anlisis de sensibilidad (que son parte integral de la programacin lineal) inventario de material (lanzando el material antes de lo que es normalmente
indicaban, claramente, en los numerosos casos de soluciones a limitaciones necesario), esto debe hacerse a travs del sistema de informacin. Pero si
interactivas, que los programas resultantes eran inestables, y que cualquier necesitamos aumentar capacidad para proteger el valor generado, ya sea
perturbacin invalidara totalmente los programas que no sugeran. No, a pesar comprando una nueva mquina o autorizando algunas horas extras, el sistema
de que tenamos todas las indicaciones, preferimos ignorar la inmunidad como de informacin deber ser mucho ms cuidadoso, la compra de una nueva
requerimiento vlido. mquina podra violar la condicin necesaria de disponibilidad de caja. Es ms,
Y qu hay de JIT y del MRP? Estos mtodos eran mucho ms prcticos, faltan muchos de los datos necesarios para tomar una decisin as, como el
pero no lo suficiente. Ambos mtodos se daban cuenta de que la inmunidad tiempo de entrega de la mquina nueva o las nuevas capacidades que se ofrecen
contra las perturbaciones era esencial para un programa, tanto que han llegado hoy en da para esa tecnologa. De la misma manera, cuando se necesitan ms
al extremo de asignar ms tiempo a la inmunizacin que a la realizacin de las horas extras de las que ya se han autorizado, el sistema de informacin no debe
tareas en s. A pesar de ello, los programas que resultan de ambos mtodos estn autorizar las horas extras adicionales. No debemos ignorar el hecho de que
lejos de ser inmunes, lo que resulta evidente cuando vemos que la muchos de los datos necesarios para tomar una decisin as (como la voluntad
responsabilidad de resolver las sorpresas recae sobre los hombros del de hacer ms horas por parte de los implicados, o su efectividad cuando las
personal de planta. El problema principal lo provoca el hecho de que ambos horas extras se usan en demasa) no estn disponibles para el sistema. Ni
mtodos han intentado inmunizar el programa en s, en vez de inmunizar el siquiera debemos pretender que el sistema disponga de estos datos. En la
resultado del programa. Este enfoque los ha obligado a intentar proteger cada mayora de los casos es un volumen enorme, y normalmente existen slo a nivel
instruccin individual, un mtodo que se destruye a s mismo. El resultado intuitivo. No, en estos casos nuestro sistema de informacin debe destacar la
inevitable de querer proteger cada operacin es una sobreextensin del lead- situacin, dejando que la decisin especfica la tome el usuario.
time necesario para
162 EL SNDROME DEL PAJAR
tendremos que recorrer los pasos de identificar, explotar y subordinar una y examen de si podemos o no suponer con seguridad que los pedidos de los
otra vez, aadiendo, cada vez, una nueva limitacin, hasta que lleguemos al clientes siempre son una limitacin de nuestra organizacin. (Por cierto, esto
punto en el que al final de la subordinacin no se encuentren violaciones de la subrayar el hecho de que debemos cambiar de actitud hacia las limitaciones; si
realidad. Slo entonces habremos terminado. los pedidos de los clientes son limitaciones, entonces, las limitaciones no son
Esto implica que siempre que tengamos dudas sobre si algo es o no una necesariamente algo malo.)
limitacin es mucho ms seguro suponer que no lo es. Si no es una limitacin, y Si no hay limitaciones internas en nuestra organizacin, entonces, la
nosotros declaramos que lo es, vamos a tener que cargar con ella. Pero, si la limitacin est en la demanda del mercado (ignoremos por el momento la
verdad es una limitacin, y en esta fase decidimos ignorarla, no habremos posibilidad de la limitacin en los proveedores), Si internamente tenemos
hecho ningn dao, porque llegaremos a cogerla en una de las vueltas exceso de todo, lo nico que nos limita para ganar ms dinero es la demanda
siguientes. As que la cuestin es: qu podemos declarar como limitacin del mercado. Qu pasa con los casos en los que s tenemos limitaciones
desde el principio y con un alto grado de probabilidad? internas de capacidad? No es arriesgado suponer que en estos casos el
Aparentemente, empezar eligiendo un proveedor o, incluso, un material mercado sigue siendo la limitacin? Recordemos que hemos supuesto que no
especfico, es demasiado arriesgado. Slo podemos identificar a un material hay limitaciones polticas en lo que respecta a nuestro sistema de informacin.
como limitacin cuando comparemos su disponibilidad actual y futura con los Vamos a distinguir entre dos casos, cuando de hecho tenemos cuellos de
plazos y cantidades del consumo requerido. Esto implica que disponemos, botella, y cuando slo tenemos limitaciones de capacidad debidas a una
desde el principio, de un conocimiento detallado de lo que, de hecho, estamos insuficiente capacidad de proteccin. Este ltimo caso es ms fcil de tratar, as
intentando generar con este proceso: el programa. No, la decisin de empezar que empezaremos por l.
con la limitacin en el proveedor no es una buena eleccin, sobre todo cuando La cantidad de capacidad necesaria de proteccin que tiene que tener un
recordamos muchos casos en los que no haba limitacin en los proveedores. recurso est en funcin de la longitud del buffer de tiempo. Si no se especifica
Podemos empezar con una limitacin en los recursos? Podra ser, pero un plazo de entrega (implcita o explcitamente), la longitud del buffer de
recordemos que la mayora de las limitaciones de recursos con las que nos tiempo no tiene lmite y, por lo tanto, no hace falta ninguna capacidad de
encontramos en la realidad no son cuellos de botella, sino recursos que no proteccin. As pues, siempre que tratemos con un caso en el que exista un
tienen suficiente capacidad de proteccin. La marca de un recurso con recurso limitado debido a una falta de capacidad de proteccin, estaremos, por
capacidad de proteccin insuficiente es que ese recurso, aunque tiene suficiente definicin, tratando un caso en el que la limitacin principal ser la demanda
capacidad media, no es capaz de absorber sus picos de carga. As pues, slo lo del mercado.
podremos identificar analizando con detalle los requerimientos en funcin del Lo que nos queda por examinar es el caso del cuello de botella, un recurso
tiempo. Volvemos a encontrarnos con una situacin en la que para identificar la que no tiene suficiente capacidad disponible como para satisfacer estrictamente
limitacin necesitamos tener el programa. No, no podemos construir un la demanda (como el siguiente anlisis del caso del cuello de botella es idntico
procedimiento general basado en la poco realista suposicin de que en toda al anlisis requerido para el caso de una limitacin en el proveedor o en un
situacin hay, al menos, un recurso que no tiene capacidad suficiente para material especfico, ste no se detallar separadamente). Nuestro pequeo caso
satisfacer la demanda del mercado. de Q y P nos ense que, cuando un cuello de botella participa en la
Bueno, las vueltas que hemos dado nos han llevado a algo: la nica opcin realizacin de ms de un producto, la demanda del mercado sigue siendo la
que nos queda es empezar desde las Limitaciones del mercado: los pedidos de limitacin del sistema para todos los productos, excepto uno. Es ms, a
los clientes. Pero antes de lanzamos es mejor que comprobemos si es correcto diferencia del caso, normalmente tenemos fechas de entrega; tenemos que
suponer, con una probabilidad alta, que los pedidos de los clientes siempre se entregar a nuestro cliente no ms tarde de una fecha determinada. En un caso
pueden tomar como limitaciones. El mero hecho de decir que no queda otra as, el pedido especfico ser una limitacin.
alternativa equivale a suponer que hemos incluido en nuestro anlisis todas las Resulta que el nico caso en el que no podemos considerar al mercado
posibilidades. Esta suposicin, adems de ser arrogante, es muy peligrosa. como limitacin es cuando no tenemos que comprometernos con fechas de
As que vamos a ignorar el hecho de que ya hemos descalificado todas las entrega a clientes. Tenemos un recurso limitado fabricando un solo producto, y
otras posibilidades que conocemos, y nos vamos a concentrar en el cada unidad que ofrecemos la absorbe el mercado inmediatamente.
Reconozcamos que es un caso muy raro, as que, si tenemos pedidos
166 EL SNDROME DEL PAJAR IDENTIFICACIN DE LAS PRIMERAS LIMITACIONES
167
con sus correspondientes fechas de entrega, no es arriesgado suponer que las nuestros conocimientos sobre el futuro se degradan a medida que miramos ms
limitaciones son los pedidos de los clientes. y ms lejos, la cantidad de pedidos que tenemos en
Por fin sabemos, sin ninguna duda, dnde debemos empezar con nuestros
esfuerzos de programacin Y ahora qu? Deberamos examinar cmo explotar
las limitaciones. Muy complicado. Si las limitaciones son los pedidos de los
clientes, explotar la limitacin significa, simplemente, cumplir las fechas de
entrega requeridas; el paso de explotacin se consigue por defecto. Ahora
podemos continuar con el siguiente paso de subordinar todo lo dems a los
pedidos de los clientes, lo que no resultar tan fcil. Tendremos que emplear un
tiempo y un esfuerzo mental considerables para determinar precisamente cmo
hacerlo.
M problema es que al final de la subordinacin cualquier conflicto en los
datos indicar la existencia de una limitacin adicional. Tendremos que
localizarla, en cuyo caso tenemos garantizado que el paso de subordinacin lo
ser todo menos trivial. El seguir este camino representa un riesgo pedaggico;
dedicar primero mucho tiempo a la subordinacin, y despus a la explotacin,
puede grabar en nuestra memoria una secuencia distorsionada. As pues, y slo
para que yo me quede tranquilo, vamos a seguir buscando limitaciones reales
antes de pasar al siguiente paso de explotar lo que ya hemos encontrado. Esto
nos obligar a dedicarnos, primero, al paso de explotacin, para pasar, despus,
a la subordinacin.
Podemos encontrar en esta fase inicial, aunque slo sea a nivel terico,
alguna otra limitacin? S, a veces nos podemos encontrar con una situacin en
la que, de hecho, existe un cuello de botella. Recordemos que podramos
simplemente continuar, ya que, sin duda, lo encontraremos al final de la primera
vuelta cuando la subordinacin nos indique que hay conflictos en los datos. Pero
vamos a intentar tratarlo ahora mismo. El resultado final va a ser el mismo, pero
esto ayudar a clarificar el proceso.
Cmo podemos identificar un cuello de botella en esta fase inicial? Para eso
tendremos que proporcionar al sistema otro parmetro. Un cuello de botella es
un recurso que no tiene suficiente capacidad productiva. En qu plazo de
tiempo? Si no se especifica el plazo de tiempo, un plazo ilimitado con una
demanda de mercado finita implica que todos los recursos tienen suficiente
capacidad. Asi pues, cuando la demanda del mercado se concrete en un conjunto
de pedidos dados, slo tendr sentido hablar de cuellos de botella cuando
tambin se especifique el plazo de tiempo.
Debemos elegir como plazo de tiempo el intervalo que va desde hoy hasta
la fecha de entrega ms remota de los pedidos que tenemos? Esto casi nos
garantiza que, en la vida real, acabaremos con las manos vacas en nuestro
intento de encontrar un cuello de botella. No olvidemos que, normalmente,
firme no engloba todos los pedidos que recibiremos en el futuro. Normalmente,
cuando examinamos los pedidos en firme, tenderemos a ver una gran
concentracin de pedidos para el futuro inmediato, una concentracin que se va
diluyendo cuando cambiamos nuestro enfoque hacia horizontes de tiempo ms
remotos. Por supuesto que lo que se considera futuro inmediato y horizonte de
tiempo ms remoto depende, en gran medida, del tipo de industria con el que
estemos tratando: en la industria de armamento un ao se considera como un
futuro muy prximo, mientras que, en un taller pequeo, incluso un mes puede
llegar a verse como demasiado remoto. As pues, s insistimos en encontrar un
recurso limitado antes de intentar explotar y subordinarnos a las limitaciones del
mercado, el nico camino practicable que nos queda es pedir al usuario que
especifique una fecha de corte, una fecha a la que vamos a denominar horizonte
de programacin.
Para comprobar si tenemos o no un cuello de botella, primero tenemos que
calcular la carga total que se ha puesto sobre cada uno de los tipos de recursos,
la carga que han generado los pedidos en los que se debe trabajar durante el
horizonte de programacin. Cules son esos pedidos? Desde luego, aquellos
cuya fecha de entrega sea anterior a la fecha del horizonte de programacin.
Pero esto no es suficiente. Consideremos, por ejemplo, un pedido que se debe
entregar un da despus de la fecha del horizonte de programacin: de verdad
queremos decir que todo el trabajo necesario para satisfacer ese pedido se debe
hacer slo el ltimo da? Vemos que incluso un pedido que se tiene que entregar
despus del horizonte de programacin puede colocar cargas dentro del
horizonte. Cunto nos tendremos que adentrar en el futuro? Cules son los
criterios? Desgraciadamente, parece que el nuevo parmetro horizonte de
programacin no nos ha ayudado, despus de todo.
Para qu necesitamos este quebradero de cabeza? Sabemos que si tenemos
recursos limitados, acabaremos encontrndolos antes o despus gracias a nuestro
proceso de reiteracin. Por qu no nos quedamos con la limitacin de mercado
ya identificada y continuamos a partir de ah? Es ms, estamos empezando a
tener la muy errnea impresin de que slo se deben tener en cuenta los pedidos
en firme. No olvidemos que la mayora de las preguntas de la direccin qu
pasara si...? deben tener un horizonte mas largo y, por lo tanto, nuestro anlisis
tambin se debe basar en las previsiones de ventas. As que, cuando hablemos
de pedidos, siempre queremos decir pedidos en firme ms previsiones. Si
repasamos esta ltima pgina, no sera mucho mejor descartar todo este ftil
ejercicio pedaggico? Parece que slo nos lleva a callejones sin salida. Un
momento! Un pequeo obstculo no debera causar tanta agitacin. Puede que
un minuto ms de reflexin sea suficiente para ensearnos claramente el
camino.
168 EL SNDROME DEL PAJAR IDENTIFICACIN DE LAS PRIMERAS LIMITACIONES
169
Supongamos que cuando comparamos las dos listas, la que recoge la carga
por tipo de recurso con la que nos muestra la disponibilidad de recursos, nos
encontramos con que todos tienen suficiente capacidad. No importa. No
podremos llegar a ninguna conclusin con respecto a la existencia de recursos
limitados, pero tampoco se habr hecho ningn dao. Recordemos que como
todos los datos requeridos estn en la memoria, este trabajo de explosin de
necesidades {que bsicamente equivale a ejecutar los requerimientos de toda la
red) se habr hecho en un tiempo insignificante. Sin embargo, qu hacemos si,
no slo uno, sino varios recursos resultan tener menos capacidad disponible de
la que es necesaria para cumplir los pedidos?
En un caso as, ciertamente, tenemos algn recurso limitado, pero, cuntos
tenemos? Debemos considerar como limitacin a cada uno de esos recursos
problemticos? Desde luego que no! En esa lista podemos encontrar que
tenemos una limitacin, pero solamente una. Recordemos lo peligroso que es
considerar como limitacin un recurso que no lo es! Debemos tener mucho
cuidado. Primero vamos a aclarar cmo es posible que un recurso pueda no ser
una limitacin, aunque el clculo nos indique claramente que no tiene suficiente
capacidad para cumplir con toda la demanda.
Supongamos que tenemos un caso elemental en el que slo tenemos que
entregar un producto. Los pedidos nos exigen entregar 100 unidades diarias
durante los prximos diez das. El proceso de produccin de este producto es
muy simple, cada unidad pasa por diez operaciones distintas que se hacen en
serie (una tras otra), y cada operacin requiere un tipo distinto de recurso. En
nuestra empresa slo hay una unidad de cada tipo de recurso, y estn
disponibles veinticuatro horas al da. Supongamos que cada operacin tarda en
realizarse, al menos, una hora, y la ms larga
171
172 EL SNDROME DEL PAJAR COMO TRABAJAR CON DATOS MUY INEXACTOS 173
tarda dos. Ahora vamos a calcular la carga que suponen esos pedidos para cada Normalmente, el calendario es comn
recurso, comparndola con su disponibilidad. En nuestro caso, la comparacin
nos indica claramente que todos y cada uno de los recursos no tiene suficiente
capacidad.
Significa esto que todos son limitaciones, que todos los recursos estn
limitando la capacidad de nuestra empresa para ganar ms dinero? En absoluto.
Si no hay forma de que consigamos capacidad adicional, el recurso que dictar
el resultado final ser el recurso que necesita emplear dos horas en cada unidad.
El resto de los recursos no tendr influencia alguna sobre el resultado final. Si
no podemos conseguir ms capacidad para este recurso especfico, podemos
llegar a doblar la capacidad de los dems sin que cambie el resultado final. As
pues, podemos ver que puede que slo haya una limitacin, aunque tengamos
ms de un recurso sin capacidad suficiente para atender a la demanda del
mercado.
Por tanto, de todos los recursos que no tienen suficiente capacidad, en este
punto slo podemos declarar como presunto recurso limitado al que tenga
menos capacidad de todos. Hemos dicho presunto. Por qu no lo podemos
considerar definitivamente como limitacin? Porque este anlisis se basa en los
datos disponibles, y sabemos que este tipo de datos puede ser enormemente
inexacto.
En qu situacin nos encontramos ahora? Hemos identificado una
limitacin en los pedidos, y tenemos razones para creer que, adems de eso,
tenemos un recurso limitado. Si resulta que estamos en lo cierto, que tenemos
un recurso limitado y somos incapaces de satisfacer la limitacin del mercado
por falta de capacidad, quiere decir que nos encontramos ante un conflicto entre
las limitaciones de la empresa. Cualquier solucin a este conflicto dar como
resultado una degradacin de los resultados de la empresa. Antes de
comprometer estos resultados, no deberamos, al menos, comprobar si la
situacin est basada en datos errneos? Pero tenemos que reconocer que,
despus de intentar mantener unos registros exactos durante ms de dos
dcadas, casi desesperadamente, hemos aprendido que es virtualmente
imposible mantener todos los tiempos de proceso con exactitud. Entonces, qu
hacemos?
Recordemos que, aunque no es posible garantizar la exactitud de todos los
tiempos de proceso, es bastante fcil verificar la validez de unos pocos.
Qu datos nos han llevado a sospechar la existencia de un recurso limitado
en particular? Vamos a examinarlos, teniendo presente que distintos tipos de
datos pueden tener distintas probabilidades de ser inexactos. Nuestra estimacin
se ha basado en el clculo de la disponibilidad de cada tipo de recurso y en las
cargas que se les asignan. A su vez, el clculo de disponibilidad se basaba en el
calendario y en el nmero de unidades disponibles de este tipo de recurso.
a toda la organizacin, o, al menos, a gran parte de ella, y, por tanto, suele estar
ms que comprobado. La probabilidad de encontrar un error aqu es muy
pequea.
Pero no es ste el caso cuando consideramos la exactitud del nmero de
unidades del recurso. Por extrao que parezca, este tipo de dato suele estar
sujeto a grandes errores. No es demasiado sorprendente cuando consideramos
que el nmero de unidades del recurso no sirve para calcular los requerimientos
netos ni para hacer clculos de costes, as que hoy en da nadie se molesta en
actualizar estos nmeros. Es ms, es bastante comn encontrar en nuestra lista
recursos que simplemente no existen. Son slo fantasmas que se han
introducido para que el personal de sistemas pueda burlar la rigidez de sus
propios sistemas.
Por supuesto, si nos encontramos con errores as de grandes los corregimos y
volvemos a examinar nuestra lista. Supongamos que ya hemos comprobado los
datos de disponibilidad del presunto recurso limitado y hemos encontrado que
son exactos. Qu debemos comprobar ahora? Los datos que hemos usado para
calcular las cargas. Qu parte de esos datos nos preocupa ms? Los tiempos de
proceso, por supuesto. Todos ellos? Ciertamente no, slo los tiempos de
proceso de ese recurso en particular. Lo podemos reducir todava ms? S, el
tiempo de proceso de los trabajos que hace este recurso en particular, para los
que haya, al menos, un pedido dentro del plazo de tiempo que el usuario est
considerando, Son todos igual de importantes? No, algunos trabajos absorben
una gran cantidad de tiempo, mientras que otros slo requieren algunas horas.
De qu depende? Del tiempo necesario para procesar una unidad y de las
cantidades requeridas por los pedidos.
Esta lnea de razonamiento parece muy obvia, casi infantil, por qu nos
molestamos en desarrollarla tanto? Porque, desgraciadamente, la situacin
actual es que, siempre que sospechamos que nuestros datos no estn en buena
forma y nos estn llevando a conclusiones errneas, lo normal es declarar que
hay que limpiar la base de datos, normalmente con la recomendacin
adicional: por lo menos hasta un nivel del 95 por 100 y dejar el problema al
usuario. Cualquier sistema que aborde de esta forma el problema de la exactitud
de los datos est ignorando una de sus funciones ms importantes: destacar, de
forma clara y precisa, qu datos de toda la maraa son los que hay que
comprobar, reducindolo hasta el punto de que resulte factible el trabajo de
verificacin de la exactitud de esos datos. Lo que estamos haciendo ahora es
demostrar que esto lo puede hacer un sistema, siempre que los diseadores de
ese sistema den a este tema la importancia que merece.
As que dnde estamos ahora? Est bastante claro que el sistema debe
mostrar al usuario un grfico que detalle el porcentaje de disponibilidad
174 COMO TRABAJAR CON DATOS MUY INEXACTOS 175
EL SNDROME DEL PAJAR
de nuestra presunta limitacin que absorbe cada trabajo. Aqu estamos tratando por este recurso en particular) hacia el nivel de los pedidos. Este paso
con variables interconectadas dbilmente, y, por tanto, es razonable esperar que establecer las conexiones del producto entre nuestro recurso limitado y las
muy pocos trabajas estn creando la mayora de la carga. Los tiempos de correspondientes limitaciones de mercado. Para hacerlo ms simple, llamaremos
proceso de sos trabajos, y solamente esos, deben ser verificados por el usuario. lneas rojas a esas conexiones del producto, como si pintramos con una
Normalmente tendremos que comprobar unos cinco tiempos de proceso. pintura roja imaginaria esas secciones de la estructura del producto.
Recordemos que siempre es preferible comprobarlo con la gente que est Ahora, podemos bajar por las estructuras de producto desde las rdenes
realizando el trabajo, no con los que lo disearon. Los consultores expertos en correspondientes, pero slo por las lneas rojas, almacenando las cargas (no los
MRP tienen la siguiente regla: comprueba siempre con el encargado, no con el datos de los pedidos) que necesitamos para el grfico de cargas que hemos
ingeniero. Es probable que el encargado te engae, quiz en un 30 por 100. Pero mencionado antes. Esto supone una cantidad de datos relativamente pequea,
sabrs exactamente en qu direccin te est engaando. El ingeniero te puede que no representar una carga significativa para la memoria on-line disponible.
despistar, incluso hasta en un 200 por 100, y no tendrs la menor idea de en qu Slo cuando el usuario desee ver los detalles de los pedidos correspondientes al
direccin. trabajo especfico en el que est interesado, subiremos por las estructuras de
Una vez comprobados los tiempos de proceso relevantes (y suponiendo que producto, slo para ese trabajo, para encontrar y mostrar el contenido de los
no se hayan encontrado errores) es el momento de verificar, slo para esos pedidos. Pueden parecer muchas subidas y bajadas repetitivas, pero recordemos
trabajos de carga alta, los pedidos correspondientes. No es raro encontrar en que esta actividad slo tarda unos segundos, o, incluso, menos. Es cierto que
la cantidad del pedido algn error, un cero errante mal tecleado por algn requerir un mayor esfuerzo de programacin, pero, qu es ms importante, el
administrativo aburrido. trabajo inicial del programador, o el consumo continuado de la paciencia y el
Cul es la forma recomendada para que el sistema de informacin destile tiempo del usuario?
esos datos? La tendencia normal es a almacenar todos estos datos a medida que As que, una vez que hemos pasado la fase de verificacin de los pocos datos
el sistema lleva a cabo las explosiones necesarias para calcular las cargas. Es que nos hicieron sospechar la existencia de un recurso limitado, slo entonces
cierto que en esta fase se visitan todos los datos y se pueden registrar estaremos en la poca envidiable situacin de tener que resolver un conflicto
fcilmente. Pero esto es lo que no se debe hacer. Preguntmonos lo siguiente: si aparente entre las limitaciones de la empresa. Cmo se supone que debe tratar
capturamos los datos en la fase de explosin, cuntos datos habr que esto un sistema de informacin? Dejndolo en manos del usuario? Qu hara
almacenar, y qu mnima parte de ellos har falta mostrar eventualmente? ste entonces? No, aqu llega una verdadera prueba para nuestro sistema de
He aqu un ejemplo muy bueno de cmo conseguir que el sistema responda a informacin, reducir el conflicto a sus races ms bsicas, para que nosotros, los
paso de caracol. Recordemos la enorme diferencia que hay entre la velocidad de usuarios, nos encontremos ante alternativas muy claras. Tan claras que no
archivo/recuperacin y la velocidad de clculo. Si almacenamos con cada tengamos ninguna dificultad para elegir entre ellas usando solamente nuestra
recurso todos los trabajos relevantes, junto con sus tiempos de proceso, y, intuicin.
adems, almacenamos, para cada uno de esos trabajos, todos los cdigos de los
pedidos correspondientes, entonces, no hay duda de que, incluso en una empresa
relativamente pequea, no tendremos suficiente memoria on-line. Diecisis
megabytes de memoria on-line (el mximo actual disponible para un PC) no
sern suficientes. Si intentamos almacenarlo todo en los discos, el tiempo
consumido ser demasiado largo.
La respuesta est en la direccin que ya hemos apuntado. Como todos los
datos. relevantes ya estn en la memoria, no tiene sentido almacenar resultados
intermedios. Simplemente se vuelven a calcular. En lo que respecta al presunto
recurso limitado, vamos a subir por las estructuras de productos desde todos sus
trabajos (cdigo de pieza/operacin que pasa
31
Localizacin de los conflictos
entre las limitaciones
identificadas
177
178 LOCALIZACION DE LOS CONFLICTOS ENTRE LAS LIMITACIONES IDENTIFICADAS 179
EL SNDROME DEL PAJAR
uno de los recursos. As que, en vez de intentar subordinar toda la empresa a la nada de inventario si sta es suficiente para cubrir algunos de los pedidos pero
decisin de explotacin, slo vamos a intentar subordinar las acciones de ese no todos? Este es un ejemplo excelente de cmo coger un gatito domstico y
recurso especfico. Vamos a buscar los detalles del conflicto resultante. presentarlo como un tigre salvaje, dando una enorme importancia a una serie de
Qu significa subordinar un recurso? Significa ignorar sus propias procedimientos tcnicos triviales y bien establecidos. Qu estamos intentando
limitaciones y concentrarse en conocer exactamente lo que nos gustara que conseguir? Impresionar a todo el mundo con nuestra competencia en asuntos
hiciera ese recurso para satisfacer la limitacin. Muy bonito. As que, dado un tcnicos? Ya estbamos de acuerdo en que nuestra discusin pretenda descubrir
pedido especfico, qu nos gustara que hiciera nuestro recurso para cmo se puede construir un sistema de informacin. Se nos ha olvidado nuestro
satisfacerlo? Realizar el trabajo necesario, producir el nmero de unidades objetivo original?
necesarias para cumplir con el pedido. Bien, cuntas unidades? Depende. Lo de arriba tambin es un buen ejemplo de lo fcil que es ahogarse en los
Vaya hombre! Si yo SOY vuestro obediente recurso, estoy deseando hacer lo detalles, ahogarse hasta el punto de que no slo queda borrado el cuadro global,
que me digis, as que, por favor, decdmelo. No a base de pistas e indicios, sino que, adems, se abren las puertas para la supersofisticacin; una
decdmelo directamente, usando nmeros concretos siempre que sea posible. sofisticacin que puede arruinar la facilidad de uso del paquete. Cmo
Vale, nos hemos enterado. De repente, estamos hablando con un ordenador, asignamos el inventario? De acuerdo con las fechas de entrega requeridas en los
un tonto completamente obediente. Probablemente eso es lo que debemos pedidos. El que tenga una fecha de entrega ms temprana gana al que la tenga
suponer cuando estamos intentando desarrollar un procedimiento muy riguroso. ms tarda. No tiene sentido usar reglas ms sofisticadas. No intentemos decidir
Cuntas unidades tiene que producir el recurso? Eso es bastante fcil de qu pedido es ms importante. En cualquier caso, este tipo de datos nunca est
calcular. Empezamos con la cantidad requerida por el pedido, hacemos la rpidamente disponible para un sistema mecanizado. No intentis considerar el
explosin de necesidades a travs de la estructura del producto, y traducimos lead-time desde el inventario hasta el pedido; en todo caso, esos lead-time
este nmero a unidades que se piden al recurso. No olvidemos que, en la estarn en funcin de nuestro querido y viejo Murphy. No intentemos pasarnos
estructura del producto, la cantidad por, escrita en las flechas de conexin, de listos, el resultado final nos demostrar que nos equivocbamos. Nosotros,
puede ser distinta de uno. Por ejemplo, si el pedido es de coches y nuestro por lo menos, vamos a seguir con la sencillez. Al que llega primero se le sirve
recurso tiene que producir las ruedas, un pedido de 100 coches se traducir en un primero. Es una regla simple y buena.
requerimiento para producir 400 ruedas. O, si un pedido es por veinte tornillos, Qu tomadura de pelo! Por favor, un poco de calma. Slo quera encontrar
puede traducirse en la necesidad de preparar un documento de facturacin, honradamente cmo subordinar el recurso limitado a la decisin de explotar la
Eso no es suficiente en s mismo. Puede que tengamos en la estructura del limitacin del mercado. Puede que para ustedes resulte fcil, pero no debemos
producto algunos datos relativos a la expectativa de piezas defectuosas. As, nos ignorar el hecho de que es la primera vez que yo hago estas cosas. Ya resulta
podemos encontrar con que, para entregar al cliente 100 unidades, tendremos bastante difcil de entender lo que de verdad se quiere decir con subir y bajar
que pedir al recurso que haga 110, y no slo 100. Ya estamos contentos con la por las estructuras de producto. No hace falta que lo hagan ms difcil an
respuesta? mostrando su impaciencia.
No del todo. No podemos suponer que empezamos con la pizarra en blanco, Hemos calculado la cantidad que tiene que hacer nuestro recurso para
con las lneas vacas. Qu pasa con las tareas que ya estn entre nuestro recurso satisfacer un pedido especfico. Desde ah, usando el tiempo necesario para
y los pedidos en el momento de hacer la programacin? Necesitaremos deducir fabricar una unidad y el tiempo de cambio, podemos deducir fcilmente la
estos inventarios, que es exactamente lo que hicimos cuando calculamos las cantidad de carga que se est asignando al recurso. Ahora lo que nos falta es
cargas de los recursos. encontrar dnde situar esta carga en el eje de tiempo, determinar cundo tiene
S, pero, ahora, nos encontramos con otro problema. Cmo vamos a asignar que trabajar el recurso para satisfacer ese pedido, suponiendo que el recurso en
esos inventarios? Esto no tena importancia cuando considerbamos la carga s no tiene limitaciones.
total, pero, ahora estamos intentando determinar las instrucciones detalladas. A Es bastante fcil contestar a esta pregunta. Tenemos la fecha requerida del
qu pedido debemos asignar una cantidad determi- pedido, el usuario nos ha dado la longitud del buffer de envo, la cantidad de
tiempo que tenemos que asignar para que el trabajo llegue a su destino con
segundad. As que debemos soltar el trabajo desde el recurso limitado con
una antelacin sobre la fecha de entrega igual a la duracin del
180 EL SNDROME DEL PAJAR LOCALIZACION DE LOS CONFLICTOS ENTRE LAS LIMITACIONES IDENTIFICADAS 181
buffer de envo. En otras palabras, idealmente, el recurso limitado debe los bloques superiores hacia la izquierda, situndolos antes de lo que sera
terminar su trabajo un buffer de envo antes de la fecha de entrega. estrictamente necesario segn las fechas de entrega de sus pedidos. En realidad,
Lo que tenemos que hacer ahora es repetir el mismo clculo para todos los esto significa un aumento de inventario, pero eso es mejor que perder valor
pedidos que requieran trabajo de nuestro recurso limitado, colocando los generado.
bloques de trabajo resultantes sobre el eje de tiempo del recurso. Como As que vamos a imaginamos una gran mquina niveladora a la derecha de
tenemos que realizar la asignacin de inventarios intermedios y generar los nuestro cuadro de ruinas. Ajustemos su cuchilla a una altura igual al nmero de
bloques para cada uno de los pedidos, podemos combinar estas dos tareas y unidades disponibles del recurso. Ahora, decimos a la niveladora que se mueva
hacerlas en un solo paso. Como decidimos asignar segn la fecha de entrega de hacia la izquierda, nivelando el suelo. Nuestra niveladora es un instrumento
los pedidos, la forma ms fcil de hacerlo es empezar con el pedido ms muy especial. Mantiene el orden (la secuencia) de los bloques; un bloque cuyo
cercano en el tiempo y, movindonos hacia delante, continuar con cada uno de lado derecho aparece detrs (ms tarde) del lado derecho de otro bloque,
los dems. Tendremos que generar el bloque de trabajo que se requiere del mantendr su posicin relativa, incluso despus de que la niveladora haya
recurso limitado para cada pedido que no tenga suficiente inventario en la lnea. nivelado el suelo. Es muy fcil convertir este cuadro figurado en un cdigo de
Por supuesto que estos bloques pueden quedar apilados uno encima del otro, ordenador, as que, no hace falta que nos extendamos ms en detalles tcnicos.
ya que los estamos colocando sin considerar las limitaciones propias del Un brote de impaciencia ha sido suficiente.
recurso. Probablemente, obtengamos un cuadro como el de la figura 31.1, Pero, un momento, no hemos terminado. No hemos eliminado el conflicto,
semejante a unas ruinas. Un escenario totalmente impracticable. No es slo lo hemos cambiado de sitio. Como estamos tratando con un recurso que no
realista pretender que un recurso trabaje simultneamente en ms de un bloque, tiene bastante capacidad, es inevitable que el resultado final del trabajo de
as que, si tenemos, por ejemplo, una sola unidad de ese recurso, no podemos nuestra mquina niveladora sea que algunos bloques quedan en el lado
trabajar con una pila de bloques. incorrecto de nuestro eje de tiempo. Inevitablemente, algunos bloques de
trabajo se desplazarn hacia el pasado. Es evidente que no podemos pedir a un
recurso que haga un trabajo ayer. Es ms, nuestra tcnica de nivelacin
empeorar las cosas. Dependiendo de la distribucin de las fechas de entrega de
los pedidos, puede que deje huecos hacia la derecha, empeorando las cosas
donde de verdad importa: a la izquierda del cuadro.
Presente Tiempo
Presente Tiempo
Fig. 31.1. Las ruinas.
Fig. 31.2. Nivelacin de las ruinas de acuerdo con la disponibilidad de dos
Nos encontramos ante un conflicto. No nos sorprende, lo estbamos unidades del recurso.
esperando, y ahora es el momento de intentar resolverlo. Debemos nivelar las
ruinas. Debemos asegurarnos de que la cantidad de bloques que se necesita Peor? No exactamente, es slo una representacin ms precisa del
hacer en el mismo momento nunca exceder del nmero de unidades conflicto. Llegados a este punto parece inevitable que nos enfrentemos a la
disponibles del recurso limitado. Esto quiere decir que cada vez que realidad: no podemos hacer cosas en el pasado. Algunas de las fechas de
encontremos una acumulacin, tendremos que desplazar los bloques superiores. entrega tendrn que ceder. Vamos a coger nuestra niveladora. Ahora mismo est
Hacia qu lado de las ruinas debemos desplazarlos? Debemos posponer la aparcada a la izquierda de nuestro cuadro, le damos la vuelta y bajamos la
ejecucin? Obviamente no, si desplazamos un bloque hacia adelante en el cuchilla para que acte como una pared de acero. Ahora le
tiempo, ponemos en peligro la fecha de entrega del pedido correspondiente. As
que vamos a nivelar las ruinas desplazando
182 EL SNDROME DEL PAJAR LOCALIZACION DE LOS CONFLICTOS ENTRE LAS LIMITACIONES IDENTIFICADAS l83
ordenamos que se mueva, que empuje los bloques hacia la derecha, hasta el ensea el resultado final hasta su momento. Pueden imaginarse cul sera el
punto en el que no quede ningn trabajo en el pasado. Con este ltimo resultado si, en vez de tratar con un cuello de botella, estuviramos tratando con
movimiento hemos evitado la posibilidad de chocar con la realidad, pero qu un recurso que tiene suficiente capacidad media, pero que se queda corto en
pasa con las fechas de entrega de los pedidos? intervalos especficos de tiempo? Parece que ya tenemos un mtodo genrico
Por supuesto que la manipulacin de los bloques con la niveladora, para tratar con cualquier tipo de recurso limitado. Por supuesto, todava tenemos
movindolos primero hacia el pasado y despus hacia el futuro, los deja en que explorar el procedimiento general de corri subordinar no slo el recurso
posiciones distintas de las originales. Como hemos empezado con un recurso limitado, sino, tambin, todos los dems, pero nos estamos acercando.
limitado, es inevitable que algunos bloques queden ms tarde (hacia la derecha)
de lo que estaban originalmente. Esto quiere decir que los pedidos que les
corresponden estn en peligro. Si el desplazamiento resultante es de ms de
medio buffer; no es ya que la empresa tenga una probabilidad alta de no cumplir
la fecha de entrega, es que podemos estar seguros de que Murphy lo convertir
en una certeza. Por tanto, en vez de llenar de datos la pantalla, vamos a
limitarnos a destacar en color rojo los bloques peligrosos. Un sistema que haga
todo lo antedicho proporcionar al usuario un cuadro muy preciso y muy
concentrado del conflicto que hay entre las limitaciones de la empresa.
Presente Tiempo
Fig. 31.3. Nivelacin de las cargas en los recursos limitados, teniendo en cuenta
que no podemos hacer cosas en el pasado.
185
186 EL SNDROME DEL FAJAR COMIENZO DE LA RESOLUCIN DE CONFLICTOS 187
bloques, lo haramos rutinariamente. Todos conocemos muchos casos en los menores. Por otra parte, para ahorrar tiempo de
que el tiempo de cambio es bastante largo y hay muchos pedidos enanos que
requieren tiempos de proceso ridiculamente cortos. Si no pegamos los bloques
en estos casos, nos encontramos con una situacin en la que la mayora del
tiempo del recurso limitado no estar dedicado a producir, sino a hacer
cambios. Entonces, por qu decimos que estos ahorros de tiempo de cambio
son una mejora pequea? La respuesta reside en el hecho de que no estamos en
contra de pegar bloques, estamos en contra de permitir que el sistema de
informacin lo haga sin un control cuidadoso por parte del usuario. En la
mayora de los casos el ahorro de tiempo de cambio lleva una penalizacin
mayor que el simple aumento del inventario. Vamos a investigarlo con ms
profundidad.
Cundo pegamos dos bloques, todos los bloques que se iban a hacer despus
del segundo bloque saldrn beneficiados; se va a trabajar en ellos antes de lo
que se hara si no hubiramos pegado los bloques. Se van a adelantar un tiempo
igual a la cantidad de tiempo ahorrada en el cambio. Pero, qu sucede con los
bloques que estaban entre los dos que hemos pegado? Todos ellos se harn ms
tarde. Su ejecucin se pospondr un tiempo igual al necesario para producir el
segundo bloque, el que se salt la fila. Si estamos tratando con un caso en el
que hay, al menos, un bloque rojo entre los dos bloques idnticos, pegar los dos
bloques idnticos supone que sabemos qu pedido es el ms importante para
entregarlo a tiempo. Este tipo de decisin no debe tomarla el sistema de
informacin.
A pesar de ello, hay bastantes situaciones en las que el usuario tendr que
tomar decisiones de este tipo. Va a permitir el sistema que el pegado slo se
pueda hacer manualmente? En algunas situaciones bastante comunes, la
manipulacin manual tratando cada bloque por separado volver loco al
usuario. Debemos proporcionar una ayuda automatizada. Es ms, recordemos
que cada vez que ahorramos un cambio, no slo estamos cambiando la situacin
de un bloque, estamos afectando a muchos bloques. Y como ya hemos dicho,
algunos se pondrn rojos y es de esperar que otros dejen de estarlo. Es evidente
que debemos proporcionar algn mtodo que permita al usuario no slo dar
instrucciones bloque a bloque sino, tambin, dar una instruccin mucho ms
amplia, permitindole ver el efecto de su instruccin en todos los puntos
conflictivos.
Qu tipo de instruccin general sera apropiada? El pegado de bloques es
ms importante cuando los tiempos de cambio son relativamente grandes. No
olvidemos que el tiempo de cambio no es slo funcin del recurso, tambin es
funcin del trabajo especifico que vaya a realizar. Por lo tanto, aunque aqu
estamos tratando con un solo tipo de recurso, los distintos bloques representarn
oportunidades de ahorro del tiempo de cambio que pueden ser mayores o
cambio, tenemos que ir hacia el futuro y traemos de all un bloque. Cuanto ms
lejos vayamos, habr ms bloques que sufrirn debido a esta maniobra (todos
los que estn entre el bloque original y el que estamos adelantando).
As pues, es razonable pedir al usuario una instruccin general expresada
como un nmero que represente una relacin, la relacin entre el tiempo que se
va a ahorrar y el tiempo que se permite que el sistema vaya hacia el futuro. Por
ejemplo, un nmero 100 se interpretar de la siguiente forma: por cada hora de
cambio ahorrada, se permite que el sistema traiga un bloque que est separado
de su bloque idntico por un mximo de 100 horas hacia el futuro.
Como la mayora de los usuarios nunca han tenido la oportunidad de ver el
impacto de esto en sus operaciones, este nmero no debe ser un parmetro de
entrada: el usuario debe tener la capacidad de probar, sobre la marcha, varios
nmeros distintos hasta que quede satisfecho con los colores de los bloques que
le muestra el cuadro. Como la ejecucin de una instruccin as (intentando ver la
influencia de un nmero sobre los colores de los bloques) no debe tardar ms de
unos segundos, aqu estamos hablando de un autntico sistema de soporte de
decisiones un sistema que se ha diseado de forma que no ignore el hecho de
que la intuicin humana no siempre se puede expresar en nmeros y que, al
mismo tiempo, no "ayuda presentando datos conocidos, sino presentando los
resultados de la decisin alternativa del usuario.
Hemos resuelto ya todos los conflictos? Ya hemos eliminado el rojo de la
pantalla? Probablemente hemos reducido el nmero de bloques rojos, pero,
todava, nos quedan algunos: recuerden, sabemos que estamos tratando con un
cuello de botella. En realidad, en las situaciones en las que el recurso limitado
no tiene un tiempo de cambio significativo, todava no hemos hecho nada para
eliminar los conflictos.
As que ha llegado el momento de usar un can ms grande. Las horas
extras.
33
Resolucin de los
restantes conflictos
Como ya hemos mencionado antes, el sistema debe facilitar que entre los
datos de entrada se puedan dar unas directrices amplias sobre las horas extras
permitidas en cada recurso. Estas directrices se dan con l entendimiento claro
de que las horas extras se usarn slo en el caso de que los ingresos netos se
puedan perjudicar si no se hacen, y no se usarn para ningn otro propsito
artificial.
Las instrucciones para las horas extras se dan en forma de lmite: cul es el
mximo de horas que se permite por da, por fin de semana, y cul es el total
mximo que se permite por semana. La necesidad de especificar las horas
semanales se debe a que, algunas veces, el total de horas que se permite por
semana es inferior a la suma de las horas diarias ms las del fin de semana. El
cansancio de la gente debe ser una consideracin prioritaria.
Como podremos ver ms tarde, las instrucciones sobre horas extras, en lo
que respecta a recursos no limitados, se van a obedecer sin que el usuario tenga
que dar ningn permiso adicional. Este no es el caso cuando tratamos con un
recurso que se ha identificado como limitacin; aqu es donde estuvimos
ocupados intentando ahorrar tiempos de cambio. Slo despus de que el usuario
haya agotado esa va tendr sentido la inyeccin de horas extras y, por lo tanto,
se requiere la iniciativa del usuario.
Lo que tenemos que tener presente es que, siempre que autoricemos horas
extras para una fecha determinada, el beneficio no va a ser slo para los bloques
que haba que terminar al final de ese da; tambin se van a beneficiar todos los
dems bloques posteriores a esa fecha, ya que se podrn hacer antes de lo que se
haba planificado. Por lo tanto, nos podemos encontrar con una situacin en la
que cuando permitimos algunas horas extras para ayudar a un determinado
bloque rojo, puede que ste siga siendo rojo, pero muchos otros bloques de los
que se van a hacer
191
192 EL SNDROME DEL PAJAR RESOLUCIN DE LOS RESTANTES CONFLICTOS 193
No nos gusta fallar en las fechas de entrega, pero hay algo a lo que debemos
temer an ms: fallar en una fecha de entrega sin avisar al cliente. Cul es la
situacin aqu? No tenemos suficiente capacidad, ya hemos intentado todo lo
que se nos ha podido ocurrir, y nos sigue faltando. A no ser que suceda un
milagro, seguro que vamos a fallar en algunas fechas de entrega. Es mucho
mejor llamar ahora, para dar al cliente la mala noticia con algunas semanas de
antelacin. Es muchsimo mejor que disculparse despus del hecho.
Una vez terminada esta fase, ya hemos terminado nuestro primer intento de
los que se suele llamar programa maestro. Debemos destacar que este
programa maestro se diferencia en un punto importante del concepto
generalmente aceptado. No slo se crea con los datos de los pedidos, sino,
tambin, con los datos que se refieren al programa detallado del recurso
limitado.
Por qu tenemos la precaucin de referirnos a l como a un primer
intento? Porque todava no hemos terminado, Puede haber ms recursos
limitados. As que, ahora, tenemos que realizar el siguiente paso: subordinar
todo lo dems a la decisin anterior. Tenemos que derivar las acciones de todos
los dems recursos, para que apoyen, con toda seguridad, lo que ya hemos
decidido.
En cierto modo, lo que hemos hecho es fijar firmemente algunas actividades
en el eje de tiempo, asegurndonos de que no haba conflictos internos. Ahora,
las dems actividades tienen que marchar de acuerdo con esto. Por eso llamamos
autorizar el tambor a la fase que acabamos de terminar. Hemos determinado
el ritmo de tambor al que deber marchar toda la empresa.
Antes de profundizar y empezar a idear el procedimiento adecuado para
subordinar todos los dems recursos, puede que debamos introducir en este
punto un nuevo concepto, el concepto de barras, De hecho, en la mayora de los
sistemas no tiene aplicacin en esta fase, pero hay algunos en que s la tiene, y
en unos pocos es dominante. Es ms, en todos los entornos el concepto de barra
es vital si se ha identificado un segundo recurso limitado, as que vamos a
tratarlo ahora.
Podemos encontrarnos con situaciones en las que el recurso limitado tiene
que realizar trabajo en ms de una fase del mismo pedido. En este caso, el
mismo pedido generar ms de un bloque en nuestro programa. Esto no es
especialmente problemtico, siempre que un bloque no alimente al otro pasando
por operaciones hechas por otros recursos. El dilema es, por supuesto, cuanto
deberamos proteger la segunda (ms tarda operacin de la limitacin? No
podemos dejarla sin proteccin Murphy podra atacar en las operaciones
intermedias pero, por otra parte, tampoco es deseable retrasar el trabajo que
ya ha hecho la limitacin. Es evidente que
tenemos que proteger la segunda operacin de la limitacin, pero, tambin, es
evidente que no podemos ser excesivamente precavidos, as que no debemos
protegerla con un buffer de la limitacin entero. Parecera razonable protegerla
con la mitad de la longitud del buffer de la limitacin.
ra hazlo en esa fecha, La interpretacin correcta es: hgalo tan pronto como Si lo examinamos un poco ms, resulta aparente que la
pueda, preferiblemente en el momento en que le llegue el material, pero, si el
material llega antes de la fecha especificada, espere, no trabaje en l Alguien ha
cometido un error. Desde el punto de vista global del sistema, y teniendo en
cuenta las perturbaciones, no hay necesidad de trabajar ahora mismo en esas
piezas. Por favor, retngalo hasta la fecha especificada.
Lo que nos lleva a la conclusin de que, a menos que haya mucho exceso de
inventario en planta, no tiene mucho sentido dar un programa a los diversos
centros de trabajo. Es suficiente con controlar firmemente el lanzamiento de
materiales, y decir a todos los dems que trabajen, en la secuencia que sea, sobre
el material que les llegue.
A todos, menos, por supuesto, a los recursos limitados. Los recursos
limitados deben seguir rigurosamente la secuencia que con tanto trabajo hemos
pulido. Deben intentar seguirla de la mejor forma que puedan y, por lo tanto, se
les debe proporcionar una lista del drum.
Un momento, hay otra excepcin, las operaciones que usan piezas comunes,
piezas que se usan en ms de una referencia/operacin.
En estos centros de trabajo, una orden del tipo si tienes material, trabaja en
l puede producir una divergencia del material hacia un canal incorrecto,
causando, por un lado, falta de piezas y, por otro, exceso de inventario.
Tendremos que dar el programa a esos recursos (no limitados) para evitar que
usen demasiado pronto el material disponible. El programa para los recursos no
limitados tiene ahora un significado completamente nuevo. No dice a los
recursos cundo deben hacer las cosas, sino lo contrario. El programa dice a los
recursos cundo no deben hacer algo; es una lista de no hacerlo antes de...". No
ha sido demasiado difcil determinar las fechas de las actividades que alimentan
directamente a los recursos limitados. Qu hay de las actividades que alimentan
pedidos libres, pedidos que no requieren ninguna actividad de los recursos
limitados? Lo que hemos dicho antes parece totalmente aplicable; lo nico
distinto que tenemos que hacer es usar el buffer de envo donde antes usbamos
el buffer del recurso. La lgica, aun en este caso, parece impecable.
Hemos terminado? Todava no. Qu pasa con las actividades de las rutas
rojas, las actividades que hay que hacer una vez que el recurso limitado ha
hecho su parte? Usamos como drum la fecha de cumplimiento del ltimo
bloque, intentando sacar esos trabajos tan rpido como podamos, o usamos,
como en otros casos, la fecha de la limitacin a la que alimentan: la fecha de
entrega del pedido?
A primera vista puede parecer una pregunta con truco. S ya nos hemos
ocupado de resolver los conflictos entre las fechas del recurso limitado y las de
entrega de los pedidos, entonces qu importancia tiene que sigamos una u otra?
eliminacin de los conflictos no quiere decir, necesariamente, que la pregunta no
tenga significado.
Hemos construido el drum desplazando los bloques en el tiempo hacia atrs y
hacia delante. Esto implica que algunos bloques se pueden haber programado
antes de lo que sera estrictamente necesario para cumplir con su pedido. Se han
programado antes porque, despus, la limitacin debe dedicar su tiempo a otros
pedidos. Recordemos que los pedidos de los clientes no estn llegando
maravillosamente ordenados de acuerdo con la disponibilidad de nuestro recurso
limitado, por no mencionar tendencias estacionales y otras cosas de ese tipo. Es
bastante probable que encontremos bloques programados para hacerse antes de
la fecha de entrega de su pedido menos el buffer de envo.
Por lo tanto, una vez ms, en lo que respecta a todas las operaciones
intermedias, la pregunta es: debemos ordenar a los recursos no limitados que
agilicen el paso del material tanto como puedan, lo que quiere decir que
estaremos siguiendo la fecha de cumplimiento del ltimo bloque? O debemos
restringirlos para que empiecen a trabajar en las unidades disponibles despus de
la limitacin guindose slo por las instrucciones que se derivan de la fecha de
entrega del pedido? No es una pregunta con truco, es una cuestin muy real.
De verdad? Si hacemos caso a los consejos tan peculiares que hemos
desarrollado, no programar los recursos no limitados, entonces, no importa que
nos guiemos por una u otra fecha de cumplimiento, no? Cualquier material
activar el trabajo en el recurso adecuado en el momento en que est disponible
despus de la limitacin, por qu tenemos que preocuparnos?
En efecto, suceder as, siempre que nos ocupemos de dos tipos de situacin.
La primera es bastante obvia: dijimos que debamos dar un programa a los
recursos no limitados que usen piezas comunes. Qu debemos hacer aqu? En
esta situacin est clara la fecha que tenemos que seguir. Para qu tenemos que
dar un programa a esos recursos? Porque tememos que se roben piezas, tememos
que usen material comn para un pedido cuando la intencin era usarlo para
otro. Por lo tanto, en el caso de los recursos que consumen directamente piezas
comunes, tendremos que generar un programa basado en las fechas de entrega
de los pedidos. No hay otra alternativa.
Esta era una de las situaciones. Cul era la otra? Esperemos que nos lleve a
la misma conclusin porque, si no lo hace, estaremos atascados. El otro tipo de
situacin que tenemos que tratar es cuando el pedido es para un producto que
supone el ensamblaje de muchas piezas, de las que slo una requiere la
participacin de un recurso limitado. Supongamos que el recurso limitado se ha
programado para que haga esa pieza antes de lo
200 EL SNDROME DEL PAJAR
SUBORDINACIN MANUAL: EL MTODO DBR 201
203
204 LOS RECURSOS NO LIMITADOS. SUBORDINACIN Y CAPACIDAD
EL SNDROME DEL PAJAR
205
Primero vamos a refrescarnos la memoria. No sera justo pretender que nos Vamos a considerar uno de estos picos de carga en un recurso. Es evidente
acordramos con exactitud de algo que se llama disponibilidad no instantnea que no lo podemos dejar ah; no podemos hacer que un recurso trabaje por
de los recursos. Cul era el problema? Ah s, comentbamos el hecho de que encima del 100 por 100 de su capacidad. No estamos tratando con un retorcido
el tiempo real de proceso contribua muy poco al lead-time global. Ahora, sistema de primas, donde todos trabajan regularmente al 130 por 100; estamos
empezamos a recordarlo. Dijimos que, aunque tengamos suficiente capacidad trabajando con nuestra mejor estimacin. Entonces, qu vamos a hacer con
media, puede que el trabajo tenga que esperar en la cola cuando llegue el este pico de carga? Por favor, no se atrevan ni a pensar en las horas extras. No
recurso, porque ste puede estar ocupado con algn otro trabajo necesario. olvidemos que estamos tratando con recursos no limitados. Debemos utilizar
Qu podemos hacer al respecto? Probablemente mucho. Tenemos todos los horas extras para aumentar la capacidad de unos recursos que ya tienen ms que
datos necesarios. Quizs podamos conseguir una buena estimacin de cundo suficiente? Qu idea tan ridcula!
van a ocurrir estas sobrecargas temporales. Si podemos conseguir esto y tenerlo Es obvio que tenemos que intentar trasladar el pico a algn valle cercano. Si
en cuenta, quizs podamos tener en cuenta la capacidad durante el proceso de estamos tratando con un recurso no limitado, tiene que haber valles suficientes.
subordinacin. Vamos a intentar ver cmo lo podemos hacer en la prctica. No No, no debemos buscar valles hacia adelante en el tiempo; qu bamos a hacer
tenemos nada que perder, de todas las maneras, estamos metidos en un buen lo. con un valle as? Si trasladamos el pico en esa direccin estaremos posponiendo
No hay nada que nos impida calcular las cargas diarias de cada recurso no pedidos, estaremos perjudicando el valor generado. Debemos mover el pico
limitado. Es un clculo bastante directo, tal y como lo ha estado haciendo MRP hacia el pasado, hacia atrs en el tiempo.
durante aos. Tenemos la disponibilidad diaria del recurso, ya que tenemos las Un momento, si tocamos el pico, en cualquier direccin que lo movamos,
fechas. Si dividimos una lista por la otra obtendremos una indicacin clara de no necesitaremos mover tambin las cargas de los otros recursos que lo
cundo y dnde van a ocurrir las sobrecargas. Es verdad que ser slo una alimentan?
aproximacin; sabemos que el trabajo tender a llegar ms tarde, debido, S, pero, cul es el problema? De lo que hemos dicho ahora se puede
principalmente, a estas mismas sobrecargas, pero, ciertamente, ser una concluir, lgicamente, lo siguiente: debemos trasladar los picos hacia el pasado,
aproximacin muy til y muy vlida. y debemos hacerlo de forma que garanticemos que las cargas resultantes se
til? Cmo? Qu vamos a hacer con el cuadro resultante, que, proba- podrn hacer en todos los recursos. Por lo tanto, est clarsimo que no debemos
blemente, se parecer al horizonte de Manhattan? Y, por favor, no me digan que mirar los perfiles de carga despus de haber terminado todo el programa. Es
nos va a proporcionar una mejor introspeccin. Cuando estamos trabajando con demasiado tarde.
un ordenador, mejor introspeccin equivale a no sabemos qu hacer con esto. En vez de eso, al construir el programa debemos tener cuidado de movemos
Qu va a hacer un ordenador con una mejor introspeccin? hacia atrs en el tiempo de forma constante. No se debe programar ninguna
Vaya, ahora queremos devolverle la pelota al usuario. No pretenderemos operacin en una fecha especfica hasta que se haya terminado con todas las
que sea el usuario el que traslade los picos a los valles? Cmo iba a hacer el dems operaciones que tienen que programarse en fechas posteriores. Esta es la
usuario un milagro as? MRP intent hacerlo bajo el sofisticado nombre del nica forma de garantizar que si movemos un pico hacia una fecha ms
bucle cerrado. Me gustara ver, siquiera, una implantacin que haya tenido temprana, las operaciones que lo alimentan caern en un valle en vez de caer en
xito saliendo de ese bucle. No nos damos cuenta de que si retrasamos un pico un pico an ms alto. Tambin implica que tenemos que recoger los datos de
de carga en un recurso, necesitaremos hacer los cambios correspondientes en carga de cada recurso, y hacer los traslados necesarios, no despus de, sino
los dems? Se alimentan uno a otro. Puede que solucionemos un pico, pero, durante la construccin del programa para los recursos no limitados.
probablemente, crearemos otros, quizs mayores, en los dems recursos. Todos Segn lo que se ha dicho, parece muy sencillo. No es que entienda del todo
sabemos que este bucle cerrado es un bucle sin fin; este proceso de lo que me estn diciendo, pero, no ha programado MRP siempre hacia atrs en
iteracin, simplemente, no converge, el tiempo? Si estamos en los cierto, cul es el problema para que MRP calcule
Bien, nos hemos desahogado un poco, pero est claro que hay una buena las cargas mientras programa, en vez de terminar primero con el programa y
solucin escondida en alguna parte de esta rea, as que, vamos a buscarla... hacer despus los clculos de carga? Por qu no han hecho ellos lo mismo?
pero despacio, sin duda est profundamente escondida en un campo de minas. Probablemente no es tan fcil. Probablemente es
206 EL SNDROME DEL PAJAR LOS RECURSOS NO LIMITADOS. SUBORDINACIN Y CAPACIDAD
207
mucho ms complicado de lo que se est diciendo... y, por lo tanto, sospecho as sucesivamente. A esto le llamamos hacia atrs en el tiempo? A m me
que estamos equivocados. parece un zigzag en el tiempo, con una fuerte tendencia a moverse conti-
Bien, vamos a examinarlo detalladamente. De todas formas, todava lo nuamente hacia delante.
tenemos que convertir en un procedimiento prctico, hasta ahora slo hemos MRP programa hacia atrs? Seamos serios. Cmo podemos disear un
hecho una descripcin somera. Pero, antes de hacerlo, contsteme: por qu se procedimiento que se mueva hacia atrs en el tiempo constantemente, al mismo
ha dicho que MRP programe hacia atrs? S, ya s que todo el mundo piensa as, tiempo que nivela las sobrecargas?
pero eso no quiere decir que sea verdad. Tal y como yo entiendo lo que hace
MRP, y djenme que elija uno de los procedimientos ms simples (de todas
formas, todos llevan exactamente a la misma respuesta), la forma en que MRP
se mueve por el eje del tiempo es... Ser mejor que ponga un ejemplo.
Imaginemos que, en la estructura, slo tenemos un producto que consiste en
el ensamblaje de dos piezas. Para este producto, tenemos muchos pedidos con
distintas fechas de entrega. Cmo se mover MRP sobre el eje de tiempo
cuando programe esta empresa? Debe empezar con el pedido ms temprano, si
no MRP tendr problemas para asignar los inventarios existentes. No est
claro? Bien. Supongamos que MRP ha empezado con el pedido ms tardo,
recordemos que MRP asigna los inventarios en proceso mientras hace la
programacin. Intenten imaginar la reaccin del usuario cuando se d cuenta de
que los inventarios que ha fabricado para un pedido urgente se han asignado, de
repente, a un pedido que tiene que entregarse dentro de un mes. Adems, el
estpido ordenador le est pidiendo que se d prisa con la produccin de ese
mismo inventario.
As que MRP empieza con el pedido ms temprano. Por favor, pongan su
dedo sobre el punto apropiado del eje de tiempo, sobre la fecha de entrega de
este pedido. Ahora MRP empieza a hacer la explosin de necesidades por la
estructura del producto, al hacerlo se mueve hacia atrs en el tiempo. Por favor,
muevan el dedo de acuerdo con esto. Debe elegir una de las dos rutas, una de las
dos piezas que hay que fabricar. Elige una y contina movindose por ella, y su
dedo continua movindose hacia la izquierda. Hasta ahora nos estamos
moviendo hacia atrs en el tiempo, no hay problema. MRP llega a la materia
prima y se ocupa de ella: qu ms? Todava tenemos que programar otra pieza,
as que va al ensamblaje y empieza a meterse en la segunda ruta. Un momento,
no tan deprisa! Qu debe hacer ahora su dedo? Volver al ensamblaje significa
moverse hacia adelante en el tiempo, y meterse despus en la segunda ruta
significa moverse hacia atrs. El dedo ha hecho un zigzag maravilloso sobre el
eje de tiempo. Ya hemos terminado con este pedido. Ahora qu?
Por qu no bailamos un tango? Si vamos al siguiente pedido, el dedo se
mueve ms hacia la derecha. Nos metemos en una pieza, ahora hacia la
izquierda, por favor. Ahora hacia ensamblaje, otra vez a la derecha; a la segunda
pieza, a la izquierda; al siguiente pedido, ms hacia la derecha... y
36
Buffers de tiempo dinmicos
y capacidad de proteccin
211
Ciertamente hay algo de eso. Cul es, de verdad, el significado de pasar la que representa una media, slo nos puede conducir a unos resultados muy
carga de un pico a un valle anterior? En palabras menos coloristas, significa insatisfactorios.
simplemente que, por consideraciones de capacidad, tendremos que programar No hay duda de que mejoramos considerablemente cuando usamos buffers,
antes un trabajo que nos habra gustado programar en una fecha ms tarda. Es de tiempo en vez de tiempos de cola individuales. El concepto habitual de
esta la nica actividad cuya fecha se ve afectada? No, todas las actividades que tiempo de cola intenta realizar el promedio al nivel del recurso: cunto tiempo,
la alimentan tienen que moverse de acuerdo con sta, incluyendo la fecha de de promedio, tiene que esperar un trabajo delante de ese recurso. Esto no nos
lanzamiento del material correspondiente. El resultado final del tratamiento de sirve, la capacidad excedente de maana no me sirve para hoy, ni tampoco el
los picos de carga es que lanzamos los materiales antes de la fecha definida por exceso de capacidad de ayer, cuando el trabajo todava no haba llegado. Pero,
la longitud del buffer. Esto equivale a incrementar la longitud original del buffer, sin duda, s que nos sirve hacer el promedio al nivel del trabajo, usando el
pero slo para estas actividades. concepto de buffers de tiempo y de la aceleracin de trabajos.
Pues s, este mecanismo va a considerar, con bastante exactitud, el impacto Lo que estamos proponiendo aqu parece ser la prxima fase de mejora.
que tiene la disponibilidad no instantnea en el tiempo total de proceso (lead- Podemos predecir, con bastante fiabilidad, las fluctuaciones de cargas que
time) del trabajo. Intentemos digerir esta sorpresa tan agradable. Uno de los esperamos tener. Estn definidas por los cambios dados en las limitaciones del
problemas ms difciles con los que hemos estado luchando era la estimacin de mercado, modificados por las limitaciones internas. Lo que sugerimos es
los tiempos de cola individuales. Todo el que haya intentado implantar MRP programar el lanzamiento de materiales de acuerdo con las fluctuaciones de
sabe que la estimacin de los tiempos de cola es una lucha constante entre el cargas que esperamos tener. Esto reducir, sin duda, el tiempo que tiene que
personal de produccin y el de gestin de materiales. esperar el trabajo delante del recurso y, por tanto, reducir significativamente el
Las emergencias constantes y los cambios de prioridades hacen sospechar tiempo total de proceso.
que se han subestimado los tiempos de cola. La presin que existe para reducir Lo nico que queramos era un mecanismo para identificar las limitaciones
el tiempo total de proceso (lead-time global) nos est obligando a reconocer que, de la empresa. Hemos conseguido, como beneficio aadido, otra disminucin
cuando se agregan, se han sobreestimado. En algunas industrias de armamento significativa del inventario. Sin duda, esto es seal de que vamos por buen
nos encontramos con que los tiempos de cola se han fijado en una semana por camino.
operacin, y no tienen relacin alguna con la duracin de la actividad. A pesar
S, tendremos que reducir considerablemente los clculos originales de los
de ello, las faltas de material en ensamblaje se toman casi como un fait
buffers de tiempo. Lo que tenemos que dar a nuestro sistema de informacin no
accompli. A pesar de las continuas discusiones, todos los afectados saben muy
es el clculo del tiempo total de proceso, sino algo ms pequeo. Slo tenemos
bien que las estimaciones de tiempos de cola en un determinado centro de
que calcular el impacto que tiene en el tiempo total de proceso el Murphy
trabajo slo son conjeturas sin base. En la ingeniera de diseo la situacin es
puro; podemos ignorar el impacto de la disponibilidad no instantnea. Esta
an peor. Aqu los tiempos de cola se mezclan con los tiempos de ejecucin, lo
que lleva a una desconfianza total sobre cualquier clculo de tiempo. ltima parte la va a hacer el propio sistema, caso a caso. Lo que en realidad
No es de extraar. Los tiempos de cola no estn en funcin de los trabajos tenemos que dar al sistema es la parte fija del buffer de tiempo. El sistema
individuales que se van a realizar, estn principalmente, en funcin de la carga tendr que calcular la parte variable. Lo que vamos a hacer es usar un buffer
que se asigna al recurso. El flujo de los pedidos no es uniforme, y la mezcla de dinmico.
productos puede cambiar constantemente. En consecuencia, la carga que afecta Una nota al margen. En realidad, tendramos que retroceder y volver a
a cada tipo de recurso puede fluctuar considerablemente: durante dos das un escribir toda la explicacin del proceso de subordinacin, usando los trminos
recurso determinado trabaja desesperadamente y, al da siguiente, casi no tiene parte fija y parte variable. Por suerte, resulta que podemos continuar
nada que hacer. El intento de asignar un nmero al tiempo de cola es un intento tranquilamente sin crear confusin alguna. Donde hacamos referencia al buffer
de representar esta entidad dinmica con un tiempo promedio de cola de tiempo, se debe entender que nos referamos solamente a la parte fija del
imaginario. El intento de representar una entidad que flucta acusadamente con mismo.
un nmero Es cierto que la gestin del buffer va a modificar continuamente los
clculos originales de la longitud del buffer de tiempo, pero, cmo podemos
llegar a una estimacin inicial? Tenemos que empezar en algn sitio, y todava
no hay nadie que tenga la experiencia necesaria para evaluar
212 BUFFERS DE TIEMPO DINMICOS Y CAPACIDAD DE PROTECCIN
EL SNDROME DEL PAJAR
213
slo una parte del tiempo total de proceso: la parte que proviene del Murphy zona de seguimiento y entra en la zona de aceleracin. Si sigue faltando, la
puro, En este punto mi consejo depende del nivel de experiencia real que tenga limitacin tendr que desviarse de su plan. Su rendimiento se ver daado.
el usuario en la implantacin de los buffers de tiempo. Si ya tiene una Volvamos al tema de la capacidad de proteccin teniendo en cuenta este
implantacin manual de DBR, puede dejar la longitud del buffer en la mitad. Si cuadro. Examinemos un recurso no limitado trabajando al 100 por 100 en un
no es as, puede calcular el promedio del tiempo total de proceso de los da determinado. Ese da este recurso no tiene capacidad de proteccin, lo que
trabajos, y dividirlo por cinco. Esto nos proporcionar un punto de arranque supone que los trabajos se atrasarn (como promedio) en su llegada al origen
satisfactorio. del buffer debido a las perturbaciones. Los agujeros penetran en el origen del
Vern, esta nivelacin de los picos de trabajo va a provocar que un recurso buffer. Cunto? Bueno, depende. De qu? Debe depender del nivel de
est a plena carga durante unos perodos de tiempo bastante largos. capacidad de proteccin que necesitaba el recurso y de la longitud del buffer.
Bsicamente, puede que se programe a un recurso para que trabaje al 100 por Cmo podemos entender mejor este tema? Puede que debamos intentarlo
100 de su capacidad disponible durante muchos das. Es obvio que durante este con algunos nmeros. Supongamos que un recurso necesita un 5 por 100 de
intervalo de tiempo este recurso no tendr capacidad de proteccin; toda su capacidad de proteccin. Esto significa que debe tener libre el 5 por 100 de su
capacidad disponible se dedica a la produccin. Durante cunto tiempo, tiempo para ayudar a que la empresa se recupere del impacto de las
durante cuntos das vamos a permitir que un recurso no limitado se quede sin perturbaciones. En otras palabras, quiere decir que se necesita el 5 por 100 de
capacidad de proteccin, antes de admitir que tenemos un problema? capacidad de proteccin para que el recurso no "contribuya a la progresin de
Vaya pregunta... Pero, es cierto, tenemos que abordar este tema. Veamos... los agujeros en el origen del buffer al que alimenta. Si el recurso no tiene
Un recurso necesita tener capacidad de proteccin para restaurar el dao capacidad de proteccin durante un da, la penetracin adicional del agujero en
causado por las perturbaciones, no slo en ese recurso, sino, tambin, en todas el origen del buffer ser del 5 por 100 de un da. Esto es un promedio, por
las actividades que lo alimentan. De qu tipo de dao estamos hablando en supuesto. No estamos tratando con sucesos determinsticos, sino estadsticos,
este caso? Bsicamente, del que resulta de dejar sin proteccin a las las perturbaciones. Ahora, la respuesta es obvia. Cada da consecutivo que est
limitaciones. a plena carga el recurso, el agujero progresar una fraccin de da equivalente al
En cualquier momento dado la limitacin slo est protegida por el porcentaje de la capacidad de proteccin necesaria. Cuntos das consecutivos
contenido del material que se encuentra en el origen del buffer. Recordemos podemos permitir que trabaje a plena carga un recurso no limitado? Tenemos
que este inventario no tiene que ser fsico; en el caso de una limitacin de que decidir cunto vamos a permitir que penetren los agujeros sin que lo
mercado puede tomar la forma de envos adelantados; en el caso de ingeniera consideremos como un problema. Vamos a decidir que sea medio buffer; ms
puede ser un plano o unos datos necesarios. Hemos subrayado que la proteccin de eso sera como jugar a la ruleta rusa con cinco balas.
no la proporciona cualquier inventario; tiene que ser el inventario adecuado, los Esto supone que, cuando subordinemos, tendremos que tener la precaucin
materiales que estn programados para que los consuma la limitacin. de no dejar que un recurso trabaje demasiado tiempo antes de darle algn
Ahora intentemos crearnos el siguiente cuadro mental. Olvidemos el tema de tiempo no programado. Bsicamente tenemos que hacer un seguimiento
las sobrecargas temporales, de sas ya nos encargamos por otro lado, aqu constante de lo que va a hacer la carga de cada recurso con nuestros agujeros
estamos tratando de las perturbaciones normales. Consideremos un trabajo que imaginarios. Pero, como entendemos la relacin que hay entre la capacidad de
se ha programado para que lo haga la limitacin en algn punto entre el proteccin y la longitud del buffer, esto se convierte en un trabajo de
momento actual y el momento ms tardo de un buffer de tiempo. Si este trabajo programacin relativamente simple.
no est ahora en el origen del buffer, lo vamos a llamar un agujero en el origen Queda algo ms?
del buffer.
Intentemos seguir el viaje tpico de un agujero de este tipo. Supongamos que
ahora hay un buffer de tiempo antes de la fecha programada para el trabajo,
empieza a penetrar en el origen del buffer un agujero. A medida que pasa el
tiempo, si no llega nuestro trabajo, el agujero contina penetrando ms y ms
profundamente en el origen del buffer. Pronto cruza la
37
Algunos temas residuales
215
216 ALGUNOS TEMAS RESIDUALES 217
EL SNDROME DEL PAJAR
que elegir entre autorizar horas extras adicionales (el sistema tendr que decir las distintas operaciones. Como en el caso de una lnea de montaje, aunque se
cuntas ms hacen falta), desviar el trabajo a otro recurso (el sistema tendr que tarde un da en terminar el pedido en un centro de trabajo, eso no impide que el
decir cul es la cantidad mnima que hay que desviar), o retrasar el pedido (el siguiente centro de trabajo empiece a trabajar en cuanto est terminada la
sistema tendr que decir hasta qu fecha). Hay ms posibilidades? Puede que primera unidad. Como pueden ver, si nos preguntamos cul es la contribucin
el usuario sepa que el problema ha ocurrido porque los datos son errneos, y directa de los tiempos de proceso, resulta que es an ms pequea de lo que
puede que decida indicar al sistema que ignore el pico y que contine. pensbamos. Si, como en el caso de una lnea de montaje, no hay problemas de
Pero, qu sucede si es un problema real? Qu puede hacer el usuario si disponibilidad de recursos, y Murphy no existe, entonces el tiempo que se tarda
ninguna de las posibilidades que se han mencionado son factibles? Entonces, en terminar el pedido es casi igual al tiempo requerido para procesar el pedido
parece que tenemos una limitacin adicional, no es s? El recurso que tiene el en un solo centro de trabajo: el que tenga el tiempo de proceso ms largo. Si
pico se debe considerar como limitacin, y el sistema debe abandonar todo queremos ser an ms precisos, el tiempo que se tarda en hacer el pedido es
intento de continuar en esta fase. Hemos conseguido un objetivo intermedio: igual al tiempo que se tarda en hacerlo entero en la operacin ms larga, ms la
hemos identificado otra limitacin. El sistema debe pasar a la siguiente fase, suma del tiempo que se tarda en hacer una unidad en cada una de las dems
resolver los conflictos entre las limitaciones identificadas. operaciones. Esto siempre resulta ser ridiculamente pequeo comparado con la
Parece que esto suena bien. Pasemos a otro punto pendiente. Me gustara disponibilidad no instantnea y con Murphy. Por qu nos tenemos que
preguntar cmo tenemos en cuenta el tiempo que hace falta para realizar la molestar en calcularlo slo porque los datos estn disponibles?
operacin en s. Entiendo que estamos teniendo en cuenta el impacto que tienen Lo que se ha dicho no suena mal, pero se est presumiendo la capacidad de
los tiempos de proceso sobre el tiempo total de proceso (lead-time), a travs de solapar actividades a lo largo de todas las operaciones necesarias para realizar
las cargas que suponen para los recursos. Tambin entiendo, y estoy de acuerdo, el trabajo. Esto no siempre es posible. No me estoy refiriendo a entornos en los
que la contribucin directa del tiempo de proceso es bastante pequea, pero aun que, sin duda, es posible, pero en los que est prohibido por alguna poltica
as, los tiempos de proceso contribuyen en alguna medida. Si tenemos los datos ridicula que se escuda en la falsa pretensin de un mejor control. No, en esos
necesarios, por qu no tenemos en cuenta esta contribucin directa? entornos deberan elevarse las limitaciones polticas. Me refiero a situaciones
Veamos. Lo que se sugiere es calcular el tiempo que se tarda en hacer un en las que el solape no es prctico por limitaciones tcnicas. Por ejemplo, un
lote en cada operacin, multiplicando el tiempo de proceso unitario por el horno que funcione por lotes enteros, en el que una vez que entra el lote y se
nmero de unidades requeridas, aadir el tiempo de cambio y, despus, sumar cierra la puerta, todas las unidades del lote tienen que esperar hasta que se
los resultados a lo largo de la secuencia de operaciones necesarias para hacer el termine el proceso y se abra la puerta. El transporte es otro caso en el que de
trabajo. Observen lo que suceder si seguimos esta sugerencia. ninguna manera podemos dedicar una camioneta a cada unidad. En los casos en
Supongamos que estamos tratando con una lnea industrial. Supongamos que los que se procesa junto todo el lote, tcnicamente no existe la posibilidad de
la lnea tiene diez centros de trabajo distintos, y que el tiempo de proceso de una solapar.
unidad vara de menos de un minuto a ms de dos minutos entre los distintos As pues, la contribucin del tiempo real de proceso al tiempo total de
centros de trabajo. Ahora tomemos un caso en el que el pedido es de varios proceso (lead-time) es el tiempo necesario para procesar el lote en la operacin
cientos de unidades. Qu conseguiremos si seguimos esa sugerencia? Como el ms larga, ms el tiempo necesario para procesar el lote en las operaciones que
tiempo de proceso de todo el pedido en cada centro de trabajo es, no se pueden solapar, ms el tiempo de proceso de una unidad en el resto de las
operaciones. Tenemos todos los datos necesarios, por qu no los usamos?
aproximadamente, de un da, obtendremos la impresin de que, aunque no haya
perturbaciones, tardaremos en terminar el pedido, aproximadamente, una Bien, si insisten. Podemos empezar ya con el mecanismo de subordi-
nacin, o hay algo ms?
semana. Es ridculo, sabemos que slo se tarda un da, ms o menos.
Si tenemos en cuenta el tiempo necesario para hacer todo un lote en cada Una ltima pregunta, si an le queda paciencia. Debemos intentar ahorrar
tiempos de cambio durante la fase de subordinacin?
operacin, estamos ignorando la posibilidad de solapar los lotes entre
Por qu bamos a tener que hacerlo? Cul es el propsito de ahorrar
tiempos de cambio? Qu es lo que en realidad estamos ahorrando? No es
218 EL SNDROME DEL PAJAR ALGUNOS TEMAS RESIDUALES 219
dinero, sino tiempo. Podemos hacer algo con este tiempo? Nos ayudar a como si fueran un solo bloque es relativamente pequea, y la posibilidad de
incrementar los ingresos netos? Los ingresos netos vienen determinados por las ayudar es relativamente grande.
limitaciones de la organizacin, y aqu slo estamos tratando con los recursos no Podemos ahorrar tiempos de cambio para reducir su impacto en los gastos
limitados. Si un recurso no tiene suficiente capacidad por culpa de los tiempos operativos? esto sera ir demasiado lejos, la nica forma efectiva de influir en
de cambio, lo consideramos como limitacin y tratamos los tiempos de cambio los gastos operativos es reduciendo la necesidad de horas extras. Dnde
consecuentemente. As que, por qu nos tenemos que preocupar de los tiempos permitimos las horas extras? En el tambor (programa de la limitacin), donde,
de cambio durante el proceso de subordinacin? de todas formas, ya estamos intentando ahorrar cambios; en los picos de carga
Los ingresos netos no son lo nico que afecta a nuestro resultado. Tambin del primer da, donde, de nuevo, ya hemos decidido ahorrar cambios; y en los
tenemos que considerar, aunque en menor medida, el inventario y los gastos picos de lneas rojas. En este ltimo caso, de todas formas, no podemos
operativos. Veamos si esto nos obliga a considerar el ahorro de tiempos de desplazar el lote hacia el pasado. As que, de qu estamos hablando en
cambio, incluso en la fase de subordinacin. realidad?
Siempre que intentamos ahorrar tiempo de cambios tenemos que saltan un Bien, ya es suficiente. Vamos a construir un procedimiento que permita que
lote que de no ser as, se hara en un futuro ms remoto. Al ahorrar cambios la subordinacin tenga en cuenta, adecuadamente, la capacidad de los recursos
aumentamos el inventario, y las consideraciones sobre inventario nos aconsejan
no limitados.
alejamos de los intentos de ahorrar tiempo de cambios.
A menos que la contribucin del tiempo de cambio sea tan grande que cree
una limitacin, por supuesto. Si este es el caso, tenemos que pagar con
inventario para proteger de las perturbaciones a la limitacin. Decidamos hacer
dos cosas. La primera es intentar ahorrar cambios antes de considerar una
segunda limitacin en los recursos. Recordemos que al identificar el primer
recurso limitado utilizamos el mnimo tiempo de cambios (un cambio por cada
cdigo de pieza/operacin, no por cada pedido), que es equivalente al mximo
ahorro posible de tiempos de cambio.
En qu momento intentamos identificar una limitacin adicional en los
recursos? Cuando hemos terminado la fase de subordinacin 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 desvos
que haran falta para resolver el pico sin tener que considerarlo como recurso
limitado.
Adems, 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 subordinacin, 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 limitacin. En este caso ya habremos pagado la
mayora de la penalizacin por inventario, ya que el programa de la limitacin
tuvo que desplazar los bloques. La penalizacin adicional que supone tratar los
bloques pegados
38
Los detalles del procedimiento
de subordinacin
223
Por tanto, tenemos que decidirnos por un intervalo de tiempo que represente sustraer el buffer de envo. Esto nos obligar a
la mxima sensibilidad del sistema. Todo lo que sea menor que este intervalo no
debe aceptarse como razn para cambiar la fecha actual. Como las fechas de
entrega de los pedidos se suelen dar sin especificar una hora determinada,
parece razonable que, en lo que se refiere a movimientos hacia atrs en el
tiempo, escojamos el da como unidad de sensibilidad mxima.
Esto nos deja con tres categoras distintas que nos obligarn a movernos en
el tiempo, La primera es el tambor (programa de la limitacin). Siempre que
lleguemos a una actividad del tambor tendremos que tener en cuenta su fecha,
que podra ser distinta de la fecha actual,
La segunda categora la componen los buffers. Siempre que profundizamos
desde un pedido, o desde una operacin hecha por un recurso limitado, o desde
una operacin de lnea roja hasta una operacin normal, debemos proporcionar
el buffer de tiempo correspondiente.
La tercera categora son los picos de sobrecarga. La nivelacin de un pico
puede suponer que se asignen a una fecha anterior las operaciones
correspondientes. Para tratar esta categora tendremos que elegir una unidad
mnima de tiempo, ya que la carga no se define en un punto, sino en su
intervalo. Una vez ms, necesitamos una unidad de tiempo que consideremos
significativa. Por qu no continuamos con la eleccin que habamos hecho: un
da?
A medida que bajemos por la estructura del producto, cada vez que nos
encontremos con una de estas tres categoras tendremos que marcar dnde
estamos, para poder volver a ese punto, pero no debemos continuar bajando. A
medida que contina el proceso de subordinacin, probablemente tendremos
que ir guardando ms recordatorios de este tipo, as que ser conveniente que
los dispongamos en una lista ordenada de recordatorios. El primero en la lista
ser el ms cercano a la fecha actual y, el ltimo, el ms cercano al momento
presente. Recordemos que nos estamos moviendo hacia atrs en el tiempo, todo
est invertido,
Cuando empezamos nuestra lista de recordatorios no est vaca. Debe
contener todo el tambor: las fechas de entrega de los pedidos y las fechas de
terminacin de los bloques del recurso limitado. Tambin sabemos que, a lo
largo del proceso de subordinacin, debido a la segunda y a la tercera
categoras, vamos a aadir muchos ms recordatorios a nuestra lista.
Ahora vamos a empezar el proceso de subordinacin. Vamos a coger el
primer elemento de la lista para empezar a bajar desde l. Lo ms probable es
que el primer elemento sea un pedido, y debemos bajar desde l hacia las
operaciones que lo alimentan (podemos encontrarnos con ms de una, ya que el
pedido puede ser para una diversidad de productos). Pero, primero, tenemos que
retroceder. No podemos hacerlo inmediatamente porque puede que haya otros
pedidos con la misma fecha actual. Por tanto, slo vamos a identificar las
operaciones que alimentan directamente al pedido y vamos a poner las notas
correspondientes en nuestra lista de recordatorios.
Siempre que aadimos un nuevo miembro a la lista de recordatorios, la
posicin que toma se basa en la fecha que se le haya asignado. Recuerden que
cualquier fecha anterior al presente debe igualarse a la fecha del presente, no
tiene sentido dar instrucciones para el pasado. As pues, en este caso, la fecha
que se asigna es la fecha del pedido menos el buffer de envo, o la fecha
presente, la que sea ms grande de las dos. Ahora que ya hemos terminado con
este pedido, podemos borrarlo de la lista de recordatorios y pasar al siguiente
candidato.
Si continuamos siguiendo esos pasos acabaremos cogiendo de la lista no un
pedido, sino una operacin. Entonces, tendremos que ocupamos de la operacin
en s. Tendremos que calcular la carga que representa, ajustando, tambin, de
acuerdo con esta carga, la capacidad actual disponible del recurso que tiene que
hacer esa operacin.
Si la carga adicional es mayor que la capacidad disponible, tendremos que
poner el exceso en el campo carga restante de ese recurso. Como hemos
agotado la capacidad actual disponible, no se podrn programar para la fecha
actual otras operaciones que necesiten este recurso. La nica excepcin se da
cuando la fecha actual llega a la fecha del momento presente, en este caso todas
las cargas se aaden al primer da, porque no hay posibilidad de dejar restos de
cargas.
Nada de eso afecta a la fecha actual y, por tanto, podemos continuar bajando,
registrando cada ensamblaje por el que pasemos, hasta que nos encontremos con
una de las tres situaciones siguientes.
La primera es, probablemente, la ms comn: hemos llegado hasta el
material. En este caso tendremos que volver al ensamblaje ms cercano
recordemos que an no ha ocurrido ningn movimiento en el tiempo para
bajar por las ramas adicionales que haya. Si no hay ningn ensamblaje marcado,
podemos volver a nuestra lista de recordatorios.
La segunda situacin se da cuando, al bajar, llegamos a una operacin del
tambor. No nos ocupamos de esta operacin, porque ya ha sido considerada.
Solamente tenemos que volver al punto de ensamblaje ms alto (si lo hay) o a la
lista de recordatorios.
La tercera situacin ocurre cuando intentamos ajustar la disponibilidad del
recurso correspondiente, encontrndonos con que su disponibilidad actual ha
llegado a cero. En este caso tenemos que volver a la lista de recordatorios, ya
que abordar esta operacin supone ir hacia atrs en el tiempo. El sitio adecuado
de la lista lo determinar la cantidad de carga pendiente del recurso
correspondiente.
224 EL SNDROME DEL PAJAR
229
que los beneficios para los directores de produccin estn casi al mismo nivel.
la fase de control, que, a su vez, son casi triviales si se los compara con el
Todo el que haya pasado algn tiempo en una planta es perfectamente
propsito principal de todo el sistema: la fase de simulacin. Pero esto,
consciente de la lucha constante para determinar el tamao de las tiradas de
ciertamente, es tema de otra discusin.
cualquier mquina que est bastante cargada y tenga tiempos de cambio
Puede que la mejor forma de acabar esta discusin sea recordndonos que
largos. Por fin, tenemos un instrumento que puede ayudar a encontrar una
hemos desarrollado este sistema basndonos en el reconocimiento del mundo
respuesta global dinmica para todas las tiradas. Esta nueva capacidad,
del valor. Hoy en da la cultura de nuestras empresas todava est demasiado
combinada con lo que casi es una bola de cristal para predecir la necesidad de
inmersa en el mundo del coste. No nos engaemos pensando en que es posible
horas extras, parece demasiado buena para ser cierta. Por no mencionar el cambiar la cultura de nuestras empresas usando un ordenador.
hecho de que al poner en manos de los directores de materiales un
instrumento mucho ms fiable, seguro que la vida del personal de produccin
va a resultar ms fcil.
Pero no son stos los nicos que van a disfrutar de los beneficios. Si no me
equivoco, es la primera vez que ventas va a tener unos preavisos fiables. El
sistema les va a dar la capacidad de comunicarse con los directores de
produccin, no a base de echarse las culpas, sino a base de una terminologa
comn: de hechos y consideraciones de la vida real.
Los que probablemente van a disfrutar ms de los beneficios son los
ingenieros de proceso y los directores de calidad. Aunque la tcnica de buffers
dinmicos reduce drsticamente el tiempo total de fabricacin y el inventario,
en realidad, su principal beneficio reside en otra rea. Por primera vez, el
seguimiento de los agujeros en los orgenes de buffer apuntar hacia los
procesos que se deben mejorar, en vez de hacia centros de trabajo que no
tienen suficiente capacidad de proteccin. Se puede proporcionar a los
crculos de calidad la informacin vital de qu problemas son los que deben
concentrarse en resolver, con la seguridad de que cada vez que resuelvan uno
toda la empresa va a cosechar las ganancias. Esto evitar que los crculos de
calidad se deterioren convirtindose en reuniones sociales sin sentido.
Pero, probablemente, para quien es ms importante el sistema, aunque slo
tenga la primera fase de programacin, es para la alta direccin. Esto se debe,
por una parte, a que hemos insistido en construir el sistema de forma que no
considere ninguna limitacin poltica, y, por otra parte, a que nos hemos
asegurado de que se identificarn todas las limitaciones fsicas y de que se
resolvern todos los conflictos que haya entre ellas. El programa resultante es
inmune y duradero y, por tanto, cada vez que digamos que no se puede
seguir el programa, sabremos que la nica razn para decirlo es que existe
una limitacin poltica. Lo que ha convertido a nuestro sistema en un
instrumento eficaz para identificar limitaciones polticas internas es
precisamente la terquedad en no reconocer esas limitaciones polticas.
Es bastante asombroso darse cuenta de que todos estos beneficios pali-
decen cuando se los compara con los beneficios que se pueden esperar de
A. Goldratt Institute ibrica
Nombre______________
Empresa_____________
Puesto______________
Direccin____________
Ciudad______________ ___
D.P
Telfono ( )_________
Actividad de la empresa
Nc de empleados______
_____Otras publicaciones
_____Actividades del Instituto Goldratt