MoDELADO DE OPERACIONES DETALLADAS “Name Nombre) Process Product Type 1 (Proceso. del tipo de producto 1) Tech Call (tlamada técnica) ‘Action (Accién) Seize Delay Release (Tomar Demorar Liberar) “Resources (Recursos) ‘Type (Tipo) Resource (Recurso) Resource Name (Nombre del recurso) Tech 1 Delay Type (Tipo de demora) Expression (Expresiéa) Units (Unidades) Minutes (Minutos) Expression (Expresin) Tech Time (Tiempo técnico) Pantalla 5-18, Mlédulo proceso de llamada de soporte téenieo para el tipo de producto 1 Figura 6-5. E1 médulo de datos Expression (Expresién) Lacxpresin Tech Time se define usando el médulo de datos Expression (Expresién) que se encuentra en el panel de Advanced Process (Procesos Avanzados). Haga clic en el médulo, doble clic para afiadir una nueva fila e introduzca el Name (Nombre) de la expresién, Tech, ‘Time. Después haga clic en la celda Expression Values (Valores de la expresidn), que abrira una hoja de céleulo, ¢ introduzca la expresion TRIA (3, 6, 18) como se muestra en la figura 5-5. Los dos médulos Process (Proceso) restantes de esta seccién consiguen la misma tarea para Jos productos de Tipo 2 y 3 que necesiten tomar un recurso Tech 2y Tech 3, respectivamen- te. Las capacidades para ambos recursos también tienen que colocarse en 3 en el médulo de datos Resource (Recurso). A continuacién desarrollaremos la parte de Hamiadas de ventas de nuestro modelo. 54.4 Llamadas de ventas Las lamadas de ventas de nuestro médulo Decide (Decidir), de a seccién 5.4.1, se envian a esta seocién de nuestro modelo. La logica para las lamadas de ventas es muy similar a la descrita para las llamadas de soporte técnico. Sin embargo, se requieren mucho menos médulos (de he cho s6lo dos) ya que no tenemos las complejidades de tipos de productos miiltiples y diferentes recursos, Los pasos l6gicos que se necesitan para las llamadas de ventas se muestran aqui y los. meédulos de diagrama de flujo en la figura 5-6, Assign entity type and picture (Asignar tipo e imagen de 1a entidad) Seize sales call resource (Tomar el recurso de llamada de ventas) Delay for service (Denora por servicio) Release sales call resource (Liberar el recurso de Lamada de ventas)214 Cartruvo 5 Figura 6-6. Logica de lamada de ventas sna liamada de ventas que lega se envia aun médulo Assign (Asignar), donde asignamos {1 Entity Type (Tipo de entidad) a Sales call (Lianada de ventas) y ala Imegene laentidad Picture.Green Ball, como en la pantalla 5-19, Entonces esto procede a un médulo Process [Proceso] (pantalla 5-20) donde se toma una Had del recurso Sales (Ventas), se demora para el servicio TRIA (4, 15, 45) minutos libera su unidad del recurso Sales. 5.4.5 Llamadas de estado del pedido as llamadas de estado del pedido se manejan de forma automatica, pot lo menos al Principio, Foeeeisren otro recurso que una unidad de Trunk Line (Linea Troneal). Los pasos logicos para las Hamadas de estado del pedido son: ‘Name (Nombre) Assign Sales Call Entity dype and Picture (Asignar tipo e imagen de entidad a la _ Hanada de ventas) __ ‘Assignments (Asignaciones) Type (Tipo) Entity Type (Tipo de entidad) Entity Type (Tipo deentidad) Sales Call (tlamada de ventas) Type (Tipo) Entity Picture (Imagen de 1a entidad) ity Picture (Imagen deentidad) | Picture.Green Ball (Imagen.Bola verde) Pantalla 5-19, Asignar tipo e Imagen de entided ala llamada de ventas ‘Name (Nombre) Process Sales Call (Proceso llamada de ventas) Action (Accién) Seize Delay Release: (Tomar Denorar Liberar) Resources (Recursos) ‘Type (Tipo) Resource (Recurso) Resource Name (Nombre del Sales (Ventas) Delay Type (Tipo de demora) Triangular Units (Unidades) Minutes (minutos) Minimum (Minimo) 4 ‘Mos likely (Més parecido) as Maximum (Maximo) 45 Pentalla 5-20. E1 médulo Process (proceso) lamada de ventasMODELADO DE OPERACIONES DETALLADAS 215 nopign entity type and ploture (Aeignar tipo e imagen de entidad) Delay for automated call (Denora para llamada automética) TE customer wants to epeak to a real person (Si el cliente quiere hablar con un operador telef6nico) Set customer priority (Configurar prioridad del cliente) Seize sales pereon (Tomar empleado de ventas) Delay for call (Demora para llamada) Release sales person (Liberar empleado de ventas) La ligica de Arena se muestra en la figura 5-7. La llamada entrante de estado del pedido se envia a un médulo Assign (Asignar) (pantalla 5:21) donde le asignamos el Type (Tipo) deentidad a Order Status Call (Llamada de estado del pedido), y la Entity Picture (Imagen de entidad) a Picture. Blue Ball (Imagen.Bola azul) Las llamadas de estado del pedido se manejan de forma automética pore sistema de teléfono, to que significa que iniialmente incurren en una demora como las llamadas que llegan y las de soporte téenico. Como con las primeras dos demoras, queremos mostrar la llamada en la anima- cidn asi que podrfamos usar una combinacién de médulos Store-Delay-Unstore (Almacenar-De- morar-Desalmacenar) como hicimos para las primeras dos demoras, Pero esta vez tomemos un enfoque diferente y usemos un médulo Delay (Demorar) del panel Blocks (Bloques) Al usar este rmédilo, podemos capturar la misma fancionalidad que con la combinacin de médulos previa ya TRE SA Figura 5-7. La légica de! proceso de llamada de estado del pedido Name (Nombre) Resign order Status Entity Type and Picture (Asignar tipo © imagen de 1a entidad al estado del pedido ‘Assignments (Tareas) Type (Tipo) Entity Type (Tipo de entidad) order Status Call (Llamada de estado del pedido) ‘Type (Tipo) Entity Picture (Imagen de entidad) Entity Picture (Imagendeentidad) Picture.Blue Ball (Imagen.Bola azul) Entity Type (Tipo de entidad) Pantalla 5-21. Asignar tipo e imagen de entidad a la llamada de estado de! pedido216 Cavtruro 5 ‘Label (Etiqueta) "Order Status Delay (Denora de estado del pedido) Duration (Duracién) TRIA(2, 3, 4) Storage ID (Identificacién Order Status Delay Storage (Aimacenamiento de'la deAlmacenamiento) __denora del estado del pedido) Pantalla 5:22. | médulo Delay (Demorar) del panel Blocks (bloques) ta Ia ldgica Store/Unstore (Almacenas/Desalmacenar). La entidad se coloc i en Almacenamiento definido, incurriré en una demora y luego se retirara del Almacenamienta Hicimos entradas para Label [Etiqueta] (igual que para Name [Nombre], Duration (Duracién, y Storage ID (Identificacién de Almacenamiento), como se presenta en la pantalla 5-22. Note que cuando hace clic en el médulo Delay (Demorar) no se asocia con la vista de hej de célculo; éste sera el caso para cualquier médulo de los paneles Blocks (Bloques) o Elemeats (Elementos). Cuando use médulos del panel Blocks (Bloques), también debe estar consciente de qué unidades de tiempo base (Base Time Units) especifieé en el diilogo Run > Setup > Re plication Parameters (Ejecutar > Configurar > Pardmetros de réplica), y asegurarse dle que ls: unidades de cualquier valor de tiempo (por ejemplo, la Duration [Duracién] en nuestro module Delay [Demorar}) sean las mismas. En nuestro modelo, hemos especificado minutos, asi qu: somos consistentes. Si ha elegido usar el médulo Delay (Demorar) del panel Advanced Proces: (Proceso avanzado), deberin haber incluido una entrada para las unidades de tiempo. Cuand empleamos ef médulo Store (Almacenar) para colocar una entidad en un Almacenamient, Arena de forma automitica introdujo el nombre del Almacenamiento en el médulo de date: ‘Storage (Almacenamiento) (panel Advanced Process [Proceso avanzado]). Ese no es el caso é un médulo Delay (Demorar) del panel Blocks (Bloques). Asi que ahora tendra que hacer ci en el médulo de datos Storage (Almacenamiento) e introducir su nombre, Order Status Delay Storage (Almacenamiento de demora de estado del pedido), No Sales Person Required? (gNo se requiere un empleado de ventas?) Type (Tipo) 2-way by Chance (2 vias por probabilidad!_ 35 Name (Nombre) Pantala 5-28. Determinaci6n de si se requiere un empleado de ventas para ‘una llamada do estado del pedidoMoDéLADO DE OPERACIONES DETALLADAS 217 Habiendo completado la demora, la entidad entra a un médulo Decide (Decidir), en la pantalla 5-23, donde se decide sies necesario conectar a un operador telefénico de ventas. Sino hhace falta, la entidad se envia a la salida del sistema; de otro modo, hay que tomar a un emplea- do de ventas para completar la llamada. Nosotros de forma arbitraria decidimos que “Verdade- ro" significa que en verdad es el caso en que no se requiere un empleado de ventas (por lo tanto el médulo Name [Nombre] y la entrada 85 para Percent True [Porcentaje verdadero)). En la descripcién de nuestro problema inicial, indicamos que las llamadas de estado del pedido se enrutan al personal de llamadas donde esperarin con una prioridad mas baja que las llamadas de ventas. Esto significa que si una llamada de estado del pedido se encuentra en una cola esperando a un empleado de ventas y entra una llamada nueva de ventas, a ésta se le dara prioridad sobre la llamada de estado del pedido y sera contestada primero (aunque la nue- va llamada de ventas no se haya adelantado a una llamada de estado del pedido que ya pueda estar en progreso). En este punto, para encontrar una Solucién a nuestro problema, necesitamos desviarnos del tema y explicar de qué manera Arena asigna recursos a entidades en espera, Esperamos que por ahora este proceso de asignacién sea bastante claro cuando todas las en- tidades que quieran un recurso estan ubicadas en una misma cola y tienen la misma prioridad, Sin embargo, si hay varios lugares dentro de un modelo (combinaciones diferentes de Cola- ‘Tomar) donde puede asignarse el mismo recurso, se aplican algunas reglas especiales. Primero consideremos varias circunstancias bajo las cuales puede asignarse un recurso a una entidad: = una entidad pide un recurso y el recurso esta disponible, = un recurso queda disponible y hay entidades que lo piden en s6lo una de las colas, 0 = un recurso queda disponible y hay entidades que piden el recurso en més de una cola. Esto puede ser més obvio que lo que ocurre bajo los primeros dos eseenarios, pero atin asi lo trataremos. Situna entidad pide un recurso y éste se encuentra disponible, espera a ver sil recurso se asig- na a la entidad. En nuestro segundo caso, cuando un recurso queda disponible y hay entidades en slo una de Tas colas, entonces el recurso es asignado a una entidad de esa cola. Aqui el factor determinante para qué entidad en la cola obtiene el recurso es la regla de clasificacién de cola que se usa para ordenar las entidades, Arena proporciona cuatro opciones de elasificacién: Primeras legadas Primeras salidas (FIFO, por sus siglas en’ inglés), Ultimas legadas Primeras salidas (LIFO, por sus siglas en inglés), Primero el valor mAs bajo (Low Value First), y Primero el valor mas alto (High Value First). Bl determinado, FIFO, clasifica las entidades en el orden en que entran ala cola, asi la entidad que leva en la cola mas tiempo obtendria el recurso. LIFO coloca la legada mas reciente al frente de la cola (como un montén empujar/meter [push/popp, asi la éentidad que se unié més recientemente a la cola obtendria el recurso. Las ttimas dos reglas cla- sifican la cola con base en el valor de un atributo de las entidades que hay en ella; le corresponde ‘cada quien definir una expresion para tal atributo. Por ejemplo, conforme cada entidad llega al sistema, se debe asignar un dato apropiado a un atributo de esa entidad. Si seleccioné “Primero 1 valor ms bajo”, con base en este atributo de datos apropiados, tendria el equivalente de una regla de clasficacién de colas de primeros datos apropiados. Conforme llega cada entidad a la cola, ésta se coloca en posicién con base en incrementar los datos adecuados. EI diltimo caso, donde las entidades en més de una cola piden el recurso, ¢s un poco mas complicado, Arena revisa primero las prioridades de tomar: si una de estas prioridades es un rndimero més pequerio (mayor prioridad) que el resto, el recurso se asigna a la primera enti- dad en la cola precediendo a esa toma. Podriamos utilizar este método y regresar al médulo218 Captroro 5 Process (Proceso) que usamos en nuestra légica de Hamada de ventas y cambiar la selecidn Priority (Prioridad) a High [Alta] (1), Entonces usariamos otro médiulo Process (Proceso) pare tomar el recurso de ventas de nuestras llamadas de estado del pedido y configurar la seleceion de Prioridad a Medium [Media] (2) 0 Low [Baja] (3) Esto podria resolver nuestro problema de asignacién del recurso, Pero continuemos nuestro andlisis de asignacién de recursos y veamos si hay otro camino, Si todas las prioridades son iguales, Arena aplica una regla predeterminada para romper éempate, ye recurso se asigna con base en It entidad que estuvo esperando mas sin fener en cuenta Ja cola en la que esté. Por lo tanto, es eseicialmente una regla romper el empate FIFO entre uns fusién de las colas involucradas. Esto significa que si sus cola estaban clasificadas de acuerdo con los primeros datos apropiados, entonces la entidad que satisfaga ese criterio puede no siempre at asignada al recurso, Por ejemplo, un trabajo tardio puede haber apenas entrado a una cola, mien tras que un trabajo temprano puede estar al frente de otra cola y haber esperado més. Arena proporciona una solucién a este problema potencial en la forma de una cola compart da. Una cola compartida es justo fo que su nombre indica (una sola cola que puede compartins para dos 0 més actividades de tomat). Esto permite definir una sola cola donde todas las ents ddades que pidan el recurso se colocaran sin importar dénde estén sus actividades de tomar en st ‘modelo. Arena desempefia la contabilidad para asegurar que una entidad en uné cola compart a continie en el Ingar adecuado en la Iégica del modelo cuando se le asigna un recurso En nuestro modelo, cada llamada de ventas y un pequedio porcentaje (15%) de las lamada de estado del pedido requeririn una unidad del recurso Sales (Ventas). Puesto que estas a. tividades se modelaron por separado, usaremos una cola compartida cuando intentemos tomar tuna unidad del recurso Sales (Ventas). A ambos tipos de llamadas se les asigna una unida del recurso Sales (Ventas) con base en una regia FIFO, o el tiempo de espera mis largo asi que no se requiere una cola compartida en nuestro modelo para asegurar que la llamas correcta se asigna al recurso. Sin embargo, una cola compartida también nos permite recon {ar estadisticas compuestas ficilmente del niimero total de llamadas que esperan a ui recuno Sales (Ventas) y proporciona la habilidad de mostrar todas estas llamadas de espera en raisma cola (por si decidimos animar esa cola). Pesto que no asignamos una prioridad alas lamadas de ventas, sacaremos ventaja del hecht sde que para una entidad con un valor sin asignar de un atributo, ese valor seré cero de forma predetetminada. Ahora usaremos un médulo Assign (Asignar) para definir un atributo nue, Sales Call Priority (Prioridad de llamada de ventas), para aquellas llamada de estado del pedido que requieren una Unidad del recurso Sales (Ventas) y configurar su yal en 1, como en la pantalla 5-24 Erresultado es quelas llamadas de ventas tendrin una Sales Call Priority (Prio- Tidad de Iamada:ide. ventas) con un valor de 0, mientras las Lanadas dee abel (tiqueta) Set Order Status Call Priority (Configurer Prioridad de llamada de estado del pedido) ‘Type (Tipo) Attribute (atribute) Attribute Name (Nombre del Sales Cat Priority (Pricridad de Mamada de atributo) ventas) ‘New Value (Nuevo valor). Pantalla 5-24. Asignacién dela priordad de llamadaMopéLADO DE OPERACIONES DETALLADAS Name (Nombre) Order Status Call Seizes Sales Person (Llamada de estado del pedido toma persona de ventas) _ Resources (Recursos) ‘Type (Tipo) Resource (Recurso) Resource Name (Nombre del recurso) Sales (ventas) Quantity (Cantidad) a 1 Quene Name (Nombre dela cola) Process Sales Call gusue Pantalla 5-25. MOdulo Seize (Tomar) del estado del pedido tado del pedido con un valor de 1. A continuacién enviaremos la entidad a un médulo Seize (Tomar). Se podra preguntar por qué estamos usando un médulo Seize (Tomar) en lugar dde un Process (Proceso). Esto provoca que si usamos un médulo Process (Proceso), el nom- bre de la cola predeterminado ser “nombre de médulo” con una extension “.cola”, que no se puede cambiar, Puesto que queremos usar la misma cola que se definié para la toma de las llamadas de ventas, en su lugar necesitamos usar un médulo Seize (Tomar), que nos permite cambiar el nombre predeterminado de la cola, Nosotros hacemos de esta cola una compartida, primero al colocar y Ilenar el médulo Seize (Tomar) y luego al seleccionar el nombre de la cola, Process Sales Call.Queue, de la lista de sugerencias, como se presenta en la pantalla 5-25, ‘Una vez.que se complete, iri al panel Basic Process (Proceso basico) y abrir el médulo de datos Queue (Cola). Su cola ya estard en la vista de la hoja de calculo, y ahora tendré que revisar la caja Shared (Compartido) para dejarla disponible como una cola compartida. Después, haga clic en la celda Type (Tipo) para nuestra cola y seleccione Ia opcién Lowest Attribute Value (Atributo del menor valor). Esto le permite seleccionar un atributo de la Hista de sugerencias en la celda Attribute Name (Nombre de atributo). Puede seleecionar el Attribute Name (Nombre de atributo) Sales Call Priority (Priori- dad de llamada de ventas) ‘Ahora, tanto las entidades de llamada de ventas como de llamada de estado del pedido se ubicardn en la misma cola, Puesto que las entidades de llamada de ventas tienen una prioridad 0, acllas siempre se les asignaré primero un recurso de ventas disponible, A la entidad de a llamada de orden del pedido s6lo se le asignara un recurso disponible si no hay entidades de llamada de ‘yentas actualmente en la cola. Esto resuelve nuestro problema de asignacién del recurso. ‘Después de tomar un recurso Sales (Ventas), la entidad entra a un médulo Delay (Demo- rar), como se presenta en la pantalla 5-26, con una demora de TRIA(3, 5, 10) minutos, Delay for Order Status Conversation With Sales Person (Demora de la conversacién del estado del pedido con la persona de ventas) Delay Time (Tiempo de TRIA(2, 3, 4) demora) Units (Unidades) Minutes (Minutos) ‘Name (Nombre) Pantalla 5-26, La demora de las ventas de estado del pedo“Name (Nombre) ~~ Order Statue Call Releases Sales Person (llamada de estado del pedido Libera 2 empleado de ventas) Resources (Recursos) ‘Type (Tipo) Resource (Recurso) Resource Name (Nombre Sales (Ventas) TectTso) Pantalia 5-27. Liberacién del recurso ventas del estado del pedide A continuacién se envia a un médulo Release (Liberar) (Advanced Process panel [panel de Proceso avanzado}) donde liberamos el recurso de ventas, presentado en la pantalla 5-27, Después de liberar el recurso de ventas, la entidad se envia a la salida del sistema. 5.4.6 Salida del sistema y contiguracién de ejecucién Al haber completado su misién de vida, todas las amadas de las secciones de soporte técnica, ventas y estado del pedido se envian a esta parte de nuestro modelo, Aqui se muestran los pasos logicos y los médulos de diagramas de flujo aparecen en la figura 5-8 Release Trunk Line (Ldberar linea troncal) Decrement active call counter (Diaminuir contador de 1lanada activa) Record ccapleted calle (Grabar 1lamadas completes) Dispose of entitiy (Dieponer de 1a entidad) Las entidades que Hlegan entran a un médulo Release (Liberar) en donde liberamos el recur so Trunk Line (1{nea troncal), en la pantalla 5-28. Al salir del médulo Release (Liberar), ellas entran a un médulo Assign (Asignar) donce disminuimos el contador de llamadas activas, la variable Total WIP (WIP Total), presentads en la pantalla 5-29, Figura 5-8. Laldgica de salida del sistemaMobELADO DE OFERACIONES DETALLADAS Name (Nombre) "Release Trunk Line (biberar linea _ principal) Resources (Recursos) ‘Type (Tipo) Resource (Recurso) Resource Name (Nombre delrecurso) _‘Trunk Tine (Lifnea troncal) Pantalla 5-28. Liberaci6n del recurso linea principal Entonces usamos un médulo Record (Grabar) para grabar la llamada completa en el conta dor Completed Calls (Llamadas completas), pantalla 5-30, Por fin la entidad se envia a un médulo Dispose (Disponet) en donde se destruye. Antes de que podamos probar nuestro modelo, necesitamos abrir el didlogo Run Setup (Configurar ejecucién) y hacer entradas para el Project Title (Titulo del proyecto), Analyst Name (Nombre del analista) y Project Description (Descripcién del proyecto) que se encuen- tran bajo el tabulador Project Parameters (Pardmetros del proyecto). También aceptamos los predeterminados bajo la seccién Statistics Collection (Coleccién de estadisticas), que significa “Name (Nombre) Decrement Active Gall Counter (bieninuir contador de llanada activa) Resources (Recursos) ‘Type (Tipo) Variable Variable (Variable) ‘Total WIP ‘New Value (Valor nuevo) Total WIP - 1 Panta 5-29. Disminuci6n del contador de llamada activa ‘Name (Nombre) Record Completed Calis (Grabar llanadas ‘completas) Counter Name delcontador) Completed Calls (Liamadas completas) Pantalla 5-30. Grabar las lamadas completas.22 Cavtruro 5 ue obtendremos de forma automatica estadisticas de Jas entidades, recursos y colas. Ahora vaya al tabulador Replication Parameters (Parémetros de réplica) en donde pedimos una sola replica sin periodo de calentamiento, una duracién de réplica infinita y donde especificamos las unidades de tiempo base como minutos, En este punto, debe recordar (creemos que ahora ya lo olvidé) que antes, al principio de Ja primera parte de la seccién 5.4.1, le comentamos que fbamos a usar la variable Total W1P para determinar cuando detener la simulacién. El centro de llamadas acepta llamadas entrat- tes s6lo de 8 a.m. a 6 p.m, (600 minutos), pero cualquier llamada que esté en el sistema a las 6 pm, se debe completar. Podriamos haber configurado slo un tiempo de réplica largo de forma arbitraria, pero esto podria dar resultados no precisos, en especial en utilizaciones del recurso y otras estadisticas de tiempo persistente, Hay dos condiciones que deben ser ciertas ‘antes de que podamos apagar el sistema y terminar Ia ejecucién de la simulacién. La primera Que el tiempo de la simulacion debe ser por lo menos de 600 minutos. La segunda condicién es que debemos completar todas las Hamadas, Puesto que la variable Total WIP se usa para ‘mantener el rastro de cudntas llamadas se encuentran actualmente en el sistema, solo necesita. ‘mos revisar si aquélla es cero, lo que implica que todas las lamadas se han completado. Asi que introduciremos la expresién TWOW >= 600.0 && Total WIP ==0 En el campo Terminating Condition (Condicién de término); && significa “y”, De hecho, uusamos el Expression Builder (Constructor de expresién) para desarrollar la expresién, Definimos esta variable especialmente para nuestros propésitos, aunque también podis mos usar la variable de Arena NR (Trunk Line). Esta variable nos dice qué tantas lineas principales se hallan ocupadas en el momento, asi cuando este valor es cero, no hay llamadas activas en el sistema, Por ahora tiene que entender muy bien como usar los médulos del panel Advanced Process (Proceso avanzado), y lograr una mejor comprensién de qué proporcionan los médulos prin- ipales en el panel Basic Process (Proceso basico). Habré notado que la logica de las dltimas dos secciones, llamadas de ventas y estado del pedido, tienen varios componentes en comin, Al definir y asignar un tipo de llamada y las expresiones para las demoras de tiempo, podria: ‘mos haber desarrollado una seccién general de Igica que manejara ambos tipos de llamadas (Consideramos hacerlo.) Sin embargo, a veces este enfoque se complica bastante, y este tipo de logica pocas veces es obvia para otro modelador (o cliente) si alguien més tiene que usar 0 modificar su modelo. A menos que pueda combinar cantidades significativas de la logica del modelo y hacerlas relativamente transpacentes, le recomendamos que presente cada seccidn de 6gica por separado, aunque hacer esto puede ser a veces un poco redundante. Basicamente, es una cuestién de gusto, Eso completa nuestro desarrollo del modelo, pero antes intentemos ejecutarlo: desarrolle- ‘mos nuestra animacién, 5.47 Animacién No vamos a ser extravagantes con la animacién de nuestro modelo, pero si queremos represen tar sus actividades. Animaremos nuestras demoras de grabacién (Storages [Almacenamientos), recursos, colas de recurso, niimero de lamadas activas en cada seccién del modelo y niime: total de lineas troncales en uso. Nuestra animacion final aparece en la figura 5-9. Esto muestta elestado en aproximadamente 281.6 minutos de la ejecucién de simulacién,