CAPITULO 5 Modelado de operaciones detalladas Ea el capftulo 4 se mostraron Jos tipos de modelado que se podian hacer con médulos prove- nientes en su mayoria del panel Basic Process (panel de procesos basicos). Son médulos de rela tivamente alto nivel, ficiles de usar que por lo general permiten avanzas hacia la construccién ® de un modelo con un suficiente nivel de detalle A veces sera todo lo,que necesite, | Pero a veoes.no lo es. Conforme.adquiera experiencia en el modelado y sus modelos se hhagan mis grandes, complejos y detallados, puede descubrir que le gustaria poder controlar co modelar cosas a un menor nivel, con més detalle.o s6lo.de forma diferente a lo que ofrecen Jos médulos del panel de procesos basicos, Arena no Jo deja varado.en este nivel ni lo obliga a sceptar un nimero limitado de construcciones de modelado “enlatadas’, ni tampoco le impone | aprender un lenguaje de programacién o alguna sintaxis de seudoprogramacién para captar qspectos complicados del sistema, Mas bien, ofrece una jerarquia rica,y profunda de varios hiveles diferentes de modelado para obtener la flexibilidad que puede necesitar para modelar alguna logica especifica de forma apropiada. Probablemente sea una buena idea comenzar con Jos médulos de alto nivel, levarlos tan lejos como vayan (quizé sea todo el camino) y cuando necesite mayor flexibilidad de la que ellos proporcionan ir a un nivel mas bajo y detallado, Esta estructura le permite aprovecharse de las construcefones de modelado féciles y de alto nivel, hasta donde sea posible, y profundizar cuando lo necesite. Y-debido a que'los médulos de ‘Arena estandar proporcionan todo este poder de modelado, se acostumbrara a utilizarlos. Para | ponerlos a funcionar, simplemente necesitara familiarizarse con fo que hacen. "Este capitulo explora algunas de las construcciones (ciertamente no todas) de modelado detalladas y de menor nivel que estn disponibles en los paneles Advanced Process (Proceso ‘aanzado) y Blocks (de Bloque); este iltimo proporciona la Logica del modelo del nivel mas bajo, en donde los médulos corresponden a los bloques en el Jenguaje de simulacién SIMAN _ que subyace en Arena. 2 El ejemplo que usaremos para esto es un centro de llamadas telefonicas,incluyendo sopor- te teenivo, ventas y revision del estado de los pedidos. En la secciOn 5.1 se describe el sistema inicial y en la seocién 5.2 se habla acerca de cmo modelatlo, al usar algunos nuevos Conceptos de modelado de Arena. En la seoci6n 5.3 se describe nuestra estrategia bisica de modelado. La Jbsica del modelo y animacién se desarrollan en la seecién 5,4. En la 5.5 embellecemos nuestro modelo y presentamos varios conceptos nuevos de modelado de Arena, Luego le mostraremos tomo modificar el modelo original para crear el modelo embellecido. También mencionaremos Jos temas importantes de los procesos de legada no estacionarios (dependientes del tiempo) y ‘un mayor nivel de personalizacién en la animacién. En la seocién 5.6 afiadimos més medidas de resultado a nuestro modelo mejorado. Cerramos el capitulo en la seccién 5.7 con un tipo de ‘modelo completamente diferente, un sistema de inventario, y.aprovecharemos esta oportuni dad para ilustrar el uso de uno de los niveles de modelado mis bajos y detallados de Arena, el Blocks panel (panel de bloques) que compone el Ienguaje de simulacién SIMAN subyacente. Después de leer este capitulo, el lector deberd ser capaz de construir modelos muy detallados ¥y complejos y de explotar Ia jerarquia rica y profunda de niveles de modelado de Arena196 Cartru.o 5 5.1 Modelo 5-1: un sistema de centro de atencién telefénica sencillo [Nuestro sistema de centro de atencién telefnica genérico proporciona un niimero central en ‘una organizacién al que los clientes llaman para encontrar soporte técnico, informacion de ventas y estado de los pedidos, Las llamadas entrantes llegan con tiempos entre llegadas distr- buidas exponencialmente con una media de 0.857 minutos. Este nimero central alimenta 26 li- neas troncales. $i las 26 lineas estin en uso, la persona que llama obtiene una sefial de ocupado; con un poco de suerte, quien llame lo intentara de nuevo mas tarde, pero para nuestro modelo, s6lo se va. Alguien que llame y le contesten escucha una grabacién que describe tres opciones: transferencia al soporte técnico, informacién de ventas o peticidn de informacion del estado de tun pedido (76, 16 y 8% respectivamente). El tiempo estimado para esta actividad es UNIF(0.1, 0,6); todos los tiempos estan en minutos. Si quien llama elige el soporte técnico, una segunda grabacién pregunta cual de los tres, tipos de producto usa el cliente, lo que requiere UNIF(0.1, 0.5) minutos. El porcentaje de pe- ticiones para los tipos de producto I, 2 y 3 son 25, 34 y 41%, respectivamente. $i una persona calificada de soporte técnico esta disponible para el tipo de producto seleccionado, la llamada se enruta de forma automatica a esa persona, Si no hay nadie disponible en ese momento, se coloca al cliente en una cola electrénica en donde esta sujeto a misica rock molesta hasta que la persona de soporte esté disponible, Se estima que el tiempo para todas las llamadas de soporte técnico sea TRIA(3, 6, 18) minutos sin importar el tipo de producto. Una vez com- pletada la llamada, el cliente sale del sistema, ‘Las llamadas de ventas se enrutan de forma automética al personal de ventas. Si no hay vendedores disponibles, la persona que llama recibe musica espacial new-age tranquilizante (después de todo, esperamos una venta). Se estima que las llamadas de venta sean TRIA(4, 15, 45): jel personal de ventas tiende a hablar mucho més que el de soporte técnico! Una vez com- pletada la llamada, el feliz cliente sale del sistema, Quienes llaman y solicitan informacién sobre el estado de un pedido son manejados de forma automitica por el sistema telefSnico y no hay un limite en el nimero que maneja el siste- ‘ma (excepto que existen s6lo 26 lineas principales, lo que en si mismo es un limite, puesto que una llamada del estado de un pedido en curso ocupa una de esas tineas). El tiempo estimado para estas transacciones es TRIA(2, 3, 4) minutos, con 15% de esos clientes que optan por ha- blar con un operador telefénico después de haber recibido el estado de su orden. Estas llamadas se enrutan al personal de ventas en donde esperan con una prioridad menor que las llamadas de ventas. Ello significa que si una llamada del estado de una orden esti en la cola, en espera de un vendedor, y entra una nueva llamada que llega a ventas, se le dara prioridad a estat ma sobre la anterior y se atendera primero. Se estima que estas llamadas de seguimiento del estado de una orden duren TRIAG, 5, 10) minutos. Estas personas que llaman después dejan el sistema, EI horario del centro de atencién es de 8 a.m. a 6 pm., con una pequefia proporcién del personal en servicio hasta las 7 p.m, Aunque el sistema se cierra a nueva llamadas a las 6 p.m, todas las llamadas que entran al sistema a esa hora se contestan y atienden. En el curso de un dia hay ocho empleados de soporte técnico para responder llamadas de este tipo. Dos se dedican a llamadas para el tipo de producto 1; tres, a lamadas para el tipo de pro- ducto 2 y otros tres a lamadas para el tipo de producto 3. Hay cuatro empleados de ventas pare responder tales lamadas y aquéllas sobre el estado de una orden realizadas por quienes opten por hhablar con un operador telefénico. ‘Como punto de interés, contaremos el niimero de lamadas de clientes que no pueden llegar a una linea principal y que por lo tanto son rechazados para entrar al sistema (algo similar al‘MopELADo DE OPERACIONES DETALLADAS 197 bualking [renuncia] en Jos sistemas de colas, aunque esto por lo general significa una decision por parte del consumidor de no entrar, mas que ser rechazado como en nuestro modelo). Sin embargo, no consideraremos el abandono (reneging), es decir, os clientes que legan a una li- © nea principal al inicio pero que después cuelgan el teléfono antes de que se les atienda (véase la seecidn 9,3 para un anilisis de como modelar el reneging {abandono)). ‘Algunas estadisticas de interés para estos tipos de sistemas son el nimero de rechazos al cliente (sefiales de ocupado), tiempo total en la linea por tipo de cliente, tiempo de espera para fublar con un operador telefénico por tipo de cliente, ntimero de llamadas que esperan servicio por tipo de cliente y utilizacién del personal. Disc el punto de vista de fa simulacién, este problema es bastante diferente de los que cu- timos en los eapitulos 3 y 4. La diferencia mas obvia es que los sistemas anteriores estaban crientados a la fabricacién y éste es de una naturaleza de servicio. Aunque la versin original deSIMAN (€l lenguaje de simulacién en el que esti basado Arena) se desarroll6 para aplica- tiones de fabricacién, las eapacidades actuales de Arena también permiten el modelado ade- ado de sistemas de servicio. Las aplicaciones en esta area incluyen restaurantes de comida ‘pid, bancos, empresas de seguros, centros de servicio y muchos mas. Aunque tales sistemas tienen algunas caracteristicas especiales, los requisitos basicos de modelado son en gram parte Jos mismos que en los sistemas de fabricacién ‘Ahora echemos un vistazo a nuestro centro de Ilamadas y explorers os nuevos requisitos. | 521 Rechazos (Rejections) y cuando el cliente renuncia (Balking) Una llamada generada por nuestro proceso de llegada es en realidad un cliente que intenta ‘ener acceso'a una de nuestras 26 lineas principales, Si las 26 lineas se encuentran en uso en ese ‘momento, se recibe una sefal de ocupado y se rechaza (reject) al cliente, quien deja el sistema, Eltérmino para esto es balking (renuncia), ies que el cliente lo hace de forma voluntaria, aun- {jie en nuestro centro de atencjén es involuntario, asf que lo llamaremos rejection (rechaz0); el ‘modelado y el manejo del balking y del rejection es, no obstante, similar entre ellos. ‘Considere un mostrador de auioservicio en un restaurante de comida rapida que tiene una {ola ventanilla con espacio para que s6lo cinco autos esperen por el servicio. Las entidades que “ egan serian los autos que entran a una cola para esperar a tomar el recurso que se llama “ser- sivio de ventanilla”. Necesitariamos configurar la capacidad de la cola en 5. Esto permitiria a iin auto estar en servicio a un méximo dé cinco autos a esperar, Si un sexto auto intenta entrar ‘al cola, renuinciarfa (balk) o seria rechazado (rejected). Decida el lector entonces, como parte ° de sus supuestos de modelado, qué sucede con estos autos 0 entidades balkedirejected (que renunciaron /fueron rechazadas). Deberian ser dispuestas (Disposed) 0 podriamos suponer que ‘manejarian alrededor de la cuadra e intentarian volver a entrar a la cola un poco después. TExisten dos métodos para modelar el (balking/tejection) en Arena, Fl primer método semplear un médulo Queue (Cola) del Block pane! (panel de bloques) y definir la capaci- dad de la cola como 0. Una entidad que llega (una llamada que ingresa en nuestro modelo) entra ‘en lacola con capacidad ceto y de inmediato intenta tomar una unidad del recurso que se ama ““inea principal”, Si alguna unidad esta disponible, se le asigna a una llamada y ésta entra al sis- © ema. Sino hay ninguna unidad del recurso disponible, la entidad intenta quedarse en la cola. © Pero puesto que la cola tiene una capacidad de 0, la llamada tendria que renunciar (balked) de entrar en la cola y se desharia della, EI segundo método dejaria que laentidad que lega usara198 Cariruto 5 ‘un médulo Decide (Decidit) para verificar si alguna unidad del recurso “linea principal” esti disponible, Si hay una disponible, se permite que la entidad proceda y tome el recurso. Sino hay ‘ninguna disponible, se envia la entidad a la seccién de quienes renuncian (balking) de entrar en el modelo. Usaremos este segundo método en nuestro modelo. Balking (renunciat) y rejection (rechazar) claramente representan una clase de falla del sste- ‘ma a la hora de satisfacer las necesidades de los clientes, asi que contaremos el niimero de veces que esto sucede ei la simulacién; cuanto més pequeiio, mejor. 5.2.2. Decisionos de tres caminos Una vez que a una llamada se le asigna una linea principal y entra al sistema, entonces debemos determinac el tipo de llamada de manera que la podamos digi ala parte correcta del sistema para servicio, Para hacerlo, necesitamos la habilidad de enviar entidades o llamadas a tres di ferentes partes del sistema segtin Ins probabilidades dadas. F1 mismo requisito aplica para las llamadas técnicas, puesto que hay tres diferentes tipos de productos. Podriamos sacar muestra calculadora y quitarle el polvo a nuestros conceptos de probabi- lidad para calcular la probabilidad de cada tipo de llamada (hay un total de cinco). Entonces, ppodriamos defini las Sequences [secuencias] (véase la seccibn 7.1) para cada uno de estos tipos de llamadas y enrutarlas a través del sistema. Aunque esto pudiera funcionar, tendria que volver a calcular las probabilidades cada vez que cambie la distribucién de los tipos de llamada, lo que habra que hacer para probar la flexiilidad o fortaleza del sistema, Puede no haber considerado esto, pero la capacidad se proporciona para bifurcarse en tres 0 mas direcciones en el mismo médulo Decide (Decidr) que usatnos en los modelos del capitulo 5.2.3 Variables y expresiones En muchos modelos es posible que queramos usar de nuevo 1os datos en varios lugares diferer tes. Por ejemplo, en nuestro centro de llamadas, habra varios lugares en donde necesitaremes introducit tas distribuciones del tiempo para manejar las llamadas de soporte téenico. Si dec Value (Valor) 0.057 Units (Unidades) Minutes (minutos) ‘Max Arrivals (Llegadas méximas) MaxCalls (Néximo de Lanadae) call (Mamada entrance) Randon (Expo) (Aleatorio (&xpo)] Pantalla 5-1. Creacién de las legadas de las lamadas