Carusos Pizza1

Caruso Pizza es una empresa mixta de restaurantes y reparto de pizzas a domicilio. Caruso se especializa en pizzas de muy alta calidad, especialmente pizzas gruesas. Este tipo de pizzas, al tener una masa de mayor grosor, son ms propensas a acumular humedad, que si no se libera adecuadamente moja la pizza y la convierte en una masa blanda de mal aspecto y peor ingestin. Por ello, Caruso ha estado siempre muy preocupado por encontrar una tecnologa capaz de situar la pizza en casa del cliente, en las condiciones ideales para ser degustada a satisfaccin. El cliente domestico de Caruso, el que pide pizza para que se la lleven a casa, es tpicamente una madre de familia que tiene necesidad urgente de alimentar a hijos hambrientos. Por ello, cuando el cliente llama a Caruso pidiendo una pizza, espera que la entrega se produzca en unos 30 minutos. Si se tarda ms, es probable que ya no quiera la pizza. Por otro l do, 30 minutos es tiempo suficiente para que la pizza se a enfre, si no se toman precauciones especiales. Y todo el mundo sabe que una pizza fra es prcticamente incomible. En el pasado, esto hacia necesario que la produccin de pizzas se hiciera siempre bajo pedido. Esto llevaba a poner el mximo empeo en disear un proceso con un plazo de produccin inferior a los 10 minutos. La mayora de otros proveedores de pizza a domicilio tenan sistemas logsticos capaces de entregar pizzas en menos de 20 minutos, normalmente apelando al transporte en motocicletas ligeras cuya velocidad media en medios urbanos era ms elevada que la de otros tipos de transporte. En una convencin de fabricantes, Caruso atendi una presentacin de una empresa que deca haber puesto a punto una tecnologa capaz de mantener pizzas en stock, sin que se degradaran en calidad o temperatura. Se trataba de unos hornos de gas, que mantenan la pizza en atmsfera controlada y garantizaban una calidad, como de recin salida del horno, por un tiempo de almacenamiento de alrededor de dos horas. Adicionalmente, la tecnologa se haba implantado en unidades mviles, camionetas de reparto. Con estas camionetas, una empresa poda producir pizzas y mantenerlas en stock durante dos horas, al mismo tiempo que realizaba el reparto con la propia camioneta. En un horno caban unas 40 pizzas. La velocidad media de las camionetas en trfico urbano no superaba los 20 Km/hora, por lo que (al aadirle los tiempos de parada) una camioneta poda cubrir un rea d 2 x 2 Km, centrada alrededor del e punto de fabricacin. Caruso compr cuatro camionetas y empez el reparto de pizzas gruesas usando esta tecnologa. Las camionetas cargaban sus hornos en el centro de produccin, con hasta 5 variedades de pizza. A continuacin salan hacia las zonas de reparto. Cuando un cliente llamaba al centro de toma de pedidos, el encargado se pona en contacto con las camionetas, para determinar cul era la ms cercana al domicilio del cliente que tenia pizza del tipo deseado. A continuacin daba la orden a la camioneta de entregar el pedido . Si ninguna camioneta tenia pizza del tipo adecuado, el operador trataba de convencer al cliente de que cambiara su pedido. Esto, que se lograba solo en un 30% de los casos, permita servir el pedido con una pizza ya existente en una camioneta. Si el cliente no cambiaba el tipo de pizza, la camioneta deba volver al centro de produccin para recoger pizza del tipo deseado. Esta circunstancia se aprovechaba para recargar los hornos con todos los t ipos de pizza. Si en algn momento una

Hart C.W.L. Carusos Pizza: reparto Expres (A). Caso P-672. Division de Investigacion del IESE. Barcelona 1988

camioneta tenia pizzas que llevaban dos horas en la misma, la camioneta se diriga al centro de produccin para cargar pizzas nuevas. Tras unos meses de operar el nuevo sistema, Caruso empez a notar un aumento notable en el volumen de desperdicios. Al mismo tiempo, no pareca que los clientes estuvieran muy contentos con el servicio de la empresa. A Caruso le preocupaban varios aspectos 1. Cul era el origen del aumento de los desperdicios? Cuntos tipos de pizza poda distribuir con los camiones? Cunto le costaba mover las pizzas por toda la ciudad, con respecto a la tcnica tradicional de la motocicleta? Qu rea poda cubrirse de una forma razonable? Vala la pena usar el sistema de las camionetas?

Un modelo para Caruso

Para contestar las preguntas planteadas, Caruso preparo una simulacin usando PSPS, que presentaremos en esta seccin. Empezaremos por la seccin System de una primera versin simplificada, indicando las funciones necesarias para la implantacin.
Cuadro 1. Modelo Caruso. Seccin System. System {--Inicio y lectura de datos--} GENERATE 0,1; COMPUTE Leedatos; TERMINATE 0; {--Generar demanda y buscar camion--} GENERATE Exponential(tDemanda),on; {--Determinar el punto de demanda y la disponibilidad de tipo de pizza fresca en el camion. Si no hay camion con pizza adecuada ir a reponer--} COMPUTE CargaAtributosDemandayCamion, IraCasoSegunDisponibilidad; {--si no se puede hallar un camion disponible en maxespera dejarlo--} ENTER at[camion],1,fifo,maxEspera,OutOfStock; ADVANCE Erlang(at[distancia],2); entrega: COMPUTE zz = RealizaEntrega(at[camion],at[tipo]); DEBUG step do stop; TABULATE 1,cl-at[hora]; LEAVE at[camion],1; COMPUTE zz = CalculaEstadisticas; TERMINATE 1; {--cada camion se representa por una facility. Las demandas son transacciones--} reponer: ENTER at[camion],1,fifo,maxespera,outofstock; {--ir a casa, cargar y volver--} ADVANCE Erlang(at[distancia],2); DEBUG Mapa do COMPUTE Fdrawcont(6,GCLRALL); COMPUTE camiones[at[camion],horasalida] = cargapizzas(at[camion]), entrega; {--perdidas por impaciencia--} outofstock:TERMINATE 1; perdido: TERMINATE 1; {--Informar de resultados en una tabla--} DEBUG Tablas do GENERATE Tiempo,1; DEBUG Tablas do COMPUTE zz = resultados; DEBUG Tablas do TERMINATE 0; Endsystem;

El modelo genera pedidos con una distribucin entre pedidos exponencial, de parmetro tDemanda (un dato). A continuacin, la funcin CargaAtributosDemanda carga en los atributos de la transaccin las caractersticas del pedido, las coordenadas (x, y) del punto en que se origina la demanda, la hora a la que se produce y el tipo de pizza pedido. La funcin FindCamion trata de encontrar un camin que cumpla con los requisitos establecidos en el caso. Si lo encuentra, devuelve su nmero, que se guarda en un atributo de la transaccin, para usarlo luego. Si no lo logra, puede ser por dos razones. Primero, puede haber un camin que incluso yendo al deposito a cargar, llegue a tiempo de servir al cliente en el tiempo deseado. Si lo hay, se devuelve el nmero del camin en negativo, para indicar que tiene que ir primero a casa a repostar pizzas. O puede ser que no haya camin a una distancia factible, en cuyo caso se da por perdido el pedido. Si hay que ir al centro, el camin se pone en movimiento (el bloque ENTER bloquea el camin elegido), espera el tiempo de transito, y una vez pasado este, recarga el camin mediante la funcin Cargapizzas. Si en el proceso de recarga de un tipo de pizza, se encuentra que la edad de alguno de los tipos en el camin supera un tiempo dado, antigedad, tambin se sustituye este tipo de pizza, eliminando todas las unidades del mismo. El camin sale, para dirigirse a la ubicacin del pedido, presumiblemente la casa del cliente. La impaciencia en el ENTER hace que si el camin que se ha hallado, pero no queda disponible en un tiempo maxespera, el proceso se abandone y el pedido se pierda. Cuando se ha encontrado un camin con la pizza adecuada, el pedido bloquea al camin mediante un bloque ENTER. De esta forma el camin puede dirigirse a casa del cliente (bloque WAITFOR) y entregar el pedido. Los tiempos de transito se muestrean de una distribucin Erlang(x,2) para que tengan algo menos de variabilidad que en el caso exponencial. Una vez completada la lgica fundamental podemos pasar a escribir las funciones que implantan el detalle. El lector observar que la implantacin que hemos hecho no reproduce totalmente la realidad. Esto es parte del espritu de la metodologa, llegar a un primer modelo lo ms rpidamente posible. Ahora deber empezar el proceso de refinamiento, que dejamos al lector como ejercicio. Aun con sus limitaciones el modelo tiene un poder explicativo importante, que explotaremos en las seccin siguiente. Aqu tiene el lector las funciones que implementan los detalles.
Cuadro 2. Modelo Caruso. Seccin Macros. Macros {--usamos la distancia l1(manhattan distance)--} distance :function(x0,y0,x1,y1) return abs(x0-x1)+abs(y0-y1); {--halla un camion disponible, que tiene pizza del tipo deseado y ms cerca de la demanda. Incluye la posibilidad de ir a repostar para los que no tienen la pizza adecuada Si ninguno la tiene manda a repostar al ms cercano. Devuelve el numero de camion (positivo) si hay un camion que tiene la pizza, y el mismo numero pero negativo si hay que ir a repostar --} findcamion : function (tipopizza,timedist) Locals xx,i,hay,k,zz,acasa; begin xx = 9999999, k = 0, acasa = False, for i = 1 to numfurgo do if fc[i] == 0 then begin punto = &camiones[i,1], stockpizza = &camiones[i,stocks],

tiempoPizza = &camiones[i,tiempos], hay = (stockPizza[tipopizza] > 0) and ((cl-tiempoPizza[tipopizza]) <= duracion), if hay then zz = distance(at[posx],at[posy],punto[posx],punto[posy])/velocidad else zz = (distance(at[posx],at[posy],0,0)+ distance(0,0,punto[posx],punto[posy]))/velocidad + tcarga, if (zz < xx) then begin xx = zz, k = i, acasa = (not hay) end end, ^(timedist)= xx, if acasa then k = -k, return k end; CargaAtributosDemandayCamion: function() begin at[hora] = at[1], at[tipo] = Random(1,numpizzas+1), at[posx] = Uniform(-xmax,xmax), at[posy] = Uniform(-ymax,ymax), at[camion] = findcamion(at[tipo],&at[distancia]), return True end; IraCasoSegunDisponibilidad:function() begin if at[camion]>0 then return cb+1 else if at[camion] == 0 then return perdido else begin at[camion] = - at[camion], return reponer end end; cargapizzas :function(num) Locals j,zz; begin {--preparacion de las variables--} stockpizza = &camiones[num,stocks], tiempoPizza = &camiones[num,tiempos], {--mirar todos los tipos de pizza. Si su antigedad es superior a antigedad reponerlos. Lo mismo si su nivel ha bajado por debajo de smin --} for j = 1 to numpizzas do begin if (cl-tiempoPizza[j]) > antiguedad then begin desperdicio = desperdicio + stockpizza[j], stockpizza[j] = 0 end, if stockpizza[j] <= smin[j] then begin totalCargado = totalCargado + smax[j]-stockpizza[j], stockpizza[j] = smax[j] end, tiempopizza[j] = cl end, numcargas = numcargas + 1, DEBUG mapa do zz = FDrawXY(6,num,0,0), DEBUG dibuja do if (totalCargado > 0) then zz = Fdrawxy(1,1,cl,desperdicio/totalCargado), DEBUG dibuja do zz = FdrawXY(2,1,cl,cl/numcargas), return cl end; realizaEntrega:function(cami,tip) Locals z; begin punto = &camiones[cami,1], stockpizza = &camiones[cami,stocks], punto[posx] = at[posx], punto[posy] = at[posy], DEBUG mapa do z = FDrawXY(6,cami,punto[posx],punto[posy]),

distTotal = at[distancia], stockpizza[tip] = stockPizza[tip]-1, entregas = entregas + 1, return True end; CalculaEstadisticas:function () Locals zz; begin DEBUG dibuja do zz = FdrawXY(5,1,cl, statvar(&distTotal,SAVERAGE)*velocidad), if (cl-at[hora]) > tservicio then begin numretrasos = 1, retraso = cl-at[hora]-tservicio, DEBUG dibuja do zz = FdrawXY(3,1,cl, statvar(&retraso,SAVERAGE)), DEBUG dibuja do zz = FdrawXY(4,1,cl, statvar(&numretrasos,SAVERAGE)) end else numretrasos = 0, Return True end;

Resultados Veamos los resultados de este modelo y que nos dicen con respecto a los problemas de Caruso. Iniciamos el anlisis bsico considerando un solo tipo de pizza, y un stock de 10 pizzas en el horno del camin.

Figura 2. Resultados de la simulacin

En esta simulacin la demanda es de un pedido cada tres minutos. Suponemos que cada pedido es por una sola pizza.

Figura 3. Tabla de Procesadores.

El porcentaje de pedidos retrasados es de un 6%. Si suponemos que son aceptados por el cliente, esto no perjudica la productividad, la rentabilidad del negocio. Pero si lo hace, y gravemente, con la competitividad, la percepcin que tiene el cliente del servicio de la empresa. La demanda total de pizza por hora es en promedio 60/3 = 20 unidades y por tanto de 20/4 = 5 pizzas por camin. Si se cargan en promedio 10 pizzas, y una pizza dura en promedio dos horas, habr que vender 5 pizzas por hora en promedio para no tener que tirar pizzas Y este valor coincide exactamente con la demanda. Por tanto el sistema esta perfectamente equilibrado en cuanto a capacidad d produccin. Si se e opera perfectamente, no debera haber desperdicio alguno. Pero esto supone que toda la demanda se atiende, es decir que no se pierden pedidos por problemas de plazo de entrega. Contar los pedidos que se pierden no es fcil sin la simulacin. Por tanto acudamos a los resultados. Segn la cuenta de los bloques TERMINATE, durante los 5000 minutos de tiempo de simulacin se han entregado 1116 pizzas. Se han cargado 1370 (segn la variable TotalCargado) Por tanto se han tenido que tirar 1370-1272= 98 pizzas, o un desperdicio de 98/1370 = 7% Pero veamos que sucede si se cargan dos tipos de pizza. Supongamos que la demanda se reparte igualmente entre ambos tipos. Dividamos tambin la carga en dos partes iguales, 5 pizzas de cada tipo.

Figura 4. Resultados de la simulacin

Aunque el tiempo entre visitas al centro de produccin parece ser aproximadamente el mismo, el porcentaje de desperdicio ha crecido, y ahora es del 15%. Y si aadimos un nuevo tipo de pizza, con un total de 3 tipos, el porcentaje de desperdicios se eleva a un 23%. Este fenmeno se origina en la divisin de la demanda lo que, al obligar a repartir el stock de seguridad, hace que no se alcancen los mismos niveles de proteccin que consigue el stock total con la demanda consolidada. Al crecer el nmero de productos, crece el nmero de roturas de stock, y por tanto crecera el

nmero de veces que el camin debera ir a repostar. Sin embargo, como el porcentaje de roturas que encuentran al camin a ms de una distancia, depende poco del nmero de tipos de pizza, ahora se rechazaran ms pedidos, por no poder servirse en el tiempo deseado. La operacin del sistema ser de parecida eficiencia, o incluso mejor. Con tres productos, los camiones tienen un tiempo entre recargas de unos 35 minutos, dando un intervalo entre visitas al centro de un camin de 140 minutos. El porcentaje de entregas retrasadas disminuye desde el 4.2% al 3%. La direccin podra pensar que todo va mejor. Y esto es as, en apariencia, porque el filtro del tiempo de servicio hace desaparecer ms pedidos en origen, y por tanto el sistema esta menos cargado. La venta disminuye pero la direccin puede concluir que esto es achacable al mercado, especialmente si no queda constancia de los pedidos que no se pueden atender por un mal tiempo de respuesta. Tambin disminuye la ocupacin del camin desde el 56% con un tipo, al 54% con tres tipos. Qu se puede hacer?. Aumentar la velocidad de los camiones? Arreglara esto algo?. Y cmo se puede hacer ?. El lector puede explorar el sistema analizando posibilidades. Aunque los refinamientos le darn una mejor perspectiva, ver que el diagnostico general ya esta perfectamente establecido. El sistema esta mal planteado. Obliga a tener stocks de seguridad perecederos en un almacn mvil, la camioneta. El fenmeno de la divisin de demanda, al que nos hemos referido ms arriba, se agrava por estas dos circunstancias. Caruso cayo en la trampa tecnolgica, usando una tecnologa poco adaptada a su proceso productivo y de servicio. Posiblemente debe replantearse el problema desde el principio: Cmo atender a los clientes en flexibilidad (la pizza que quieran) y en rapidez?. Producir a medida, Just In Time, parece ser la nica alternativa viable. El potencial de desastre de la situacin de Caruso es grande, pero difcil de ver sin un anlisis del tipo que hemos hecho. Esta es otra ventaja de las simulacin en la empresa: Ayudar en el diagnostico de los motivos, en casos complicados. En Caruso, la direccin solo se ha alarmado por el aumento de los desperdicios y la disminucin de los beneficios, sin entender el problema. Con la simulacin hemos logrado entenderlo. Lo de menos son los nmeros concretos, y hasta la precisin del modelo. En estas condiciones, vale la pena refinar el modelo?. Creemos que no. Que la diferencia sern unos puntos en los porcentajes, pero probablemente no un mejor entendimiento de la naturaleza del problema. Y refinarlo toma tiempo de diseo, de programacin y de anlisis. En nuestra experiencia el balance se inclina siempre hacia modelos sencillos y rpidos de preparar y entender2 .

Una vez vimos un modelo de una factora tan detallado, que simulaba a velocidad menor que el sistema real. Se tardaba una hora en simular media hora de proceso de la factora. Costaba tanto entenderlo que se termin abandonando, ante la imposibilidad de saber lo que hacia. Sus propios creadores renunciaron a comprenderlo