CHAPTER 5
Demonstration and Reference Models

This chapter describes the demonstration and reference models that are included with the SIMPROCESS installation under the Demos subdirectory in the models directory. Running these models and studying the techniques used in building them will give a better appreciation for the activity modeling and advanced modeling constructs of SIMPROCESS. Included in the Demos directory, but not described here, are As-Is.spm (Chapter 3 and Tutorial model) and To-Be.spm (Chapter 4 and Tutorial model).

The ExpressionDemos subdirectory contains models that demonstrate various aspects of the SIMPROCESS Expression Language. Located in ExpressionDemos is SIMPROCESS Expression Models.pdf, which discusses each model.

Call Center Model

(model name: CallCenter.spm)

Staffing of Call Centers has become a important issue for many companies today. Balancing staffing levels with the need to maintain the high level of service that consumers demand, requires complex analysis.

In this model, three types of calls are generated: Type A, Type B, and Type C. Each call type has its own cyclical schedule, at a generate activity inside the Generate Phone Calls process.

The center is staffed by 3 levels of Technicians: X, Y, and Z.

· Question Type A can be answered by any of the three technicians

· Question Type B can be answered by a Y or Z Technician

· Question Type C can be answered only by a Z Technician

The numbers of each type of Technician available in the model are model parameters. Each time the simulation is started, a dialog will open. The user change any of the model parameters from that dialog.

By default, the incoming call buffer can contain no more than 10 calls on hold. If 10 callers are already on hold, the next incoming call will get a busy signal and be dropped. The maximum number of calls the buffer can hold is also a model parameter, the user will be prompted to change the queue's capacity each time the model is run.

If a call is on hold for too long (in the buffer) it will hang up (renege). This is done by setting the Entity system attribute MaxWait. MaxWait determines the amount of time an entity will wait to obtain a resource. If the resource is not obtained within the specified time, the entity exits the activity without processing. When this occurs the Entity system attribute EndWait is set to TRUE. This is demonstrated in the Accept Entity expressions of the branch activities Check Queue and Response. Note: If further processing is required, be sure to reset MaxWait to 0 and EndWait to FALSE.

This model demonstrates the use of dynamic labels. The labels for Number of calls on hold and the labels in the column # of Calls are updated by setting a value for the label to monitor. The labels under the columns Answered, Balked, and Reneged are updated by using the SIMPROCESS expression statement UpdateDynamicLabel. These statements can be found the Accept Entity expressions of the dispose activities Balked Calls, Reneged Calls, and Completed Calls.

The sample Dashboard Call Status.spd is included in the Demos subdirectory. This Dashboard is assigned to the Call Center model. To view the Dashboard while the Call Center model is running, select Tools/Remote/Start Local Dashboard Server. Once the Dashboard Server has been started, start the model. Make sure the animation is turned on. Once the model has been started, the Dashboard will appear. See Chapter 16 of the SIMPROCESS User's Manual for a full discussion of SIMPROCESS Dashboards.

Cashier Process Model

(model name: Cashier.spm)

This model also addresses staffing issues. Many organizations want to study how experience and training programs for employees will affect the quality of service given to their customers. In this model, we are using how long the customer will wait for a cashier as the measure of customer service.

This simple model uses the Get and Free Resource activities. Two different resources are available to service the incoming customers, Cashiers and Trainees. The incoming customer will go to the first available, regardless of which of the two it is. The service time of the customer is dependent on which resource is servicing the customer. The Trainee will take slightly longer than the more experienced Cashier.

Both resources have an expression which passes a value to a global entity instance attribute called "cashier". The value passed to the attribute on the Cashier is 1.0 and on the Trainee is 1.2. This value is passed to the customer when the cashier resource becomes available. The service time is calculated by an Evaluate Function on the delay activity, "Cashier Services Customer". The function takes the value of the global entity instance attribute "Cashier" on the customer, that the customer got from the cashier resource, and multiplies it by the standard time. The time standard for servicing the customer is represented by the an exponential distribution with a mean of 12 (minutes).

Configuration Management Model

(model name: CnfgMgmt.spm)

Responding quickly to changes in the market and to customer demands requires that Product Change Requests be processed as efficiently as possible. Long delays in handling and transportation mean changes to make the product more competitive and produced more cost effectively may not implemented on a timely basis. One strategy to decrease the time it takes to process a Product Change Request is to use electronic means to transfer them between the various parties involved. Workflow tools are one example of an implementation of electronic transfer.

The Product Change Request Process contains two alternative sub-processes, "As-Is" and "To-Be". The As-Is alternative models this process using standard mail to transport the Requests to the various parties whose input and/or approval are necessary for implementation. The To-Be alternative has essentially the same process map, with the exception that the Requests are electronically transmitted through the process.

To view the two alternatives, ascend to the highest level of the model. Select the Change Request Process, and click on the Properties button on the System Toolbar. From the list of Alternative Sub-processes, select "As-Is" and the OK button. Descend into the Change Request Process. To change to the To-Be alternative, ascend to the top level of the model, open the Properties dialog of the Change Request Process and select "To-Be" from the list of Alternative Sub-processes. When the simulation is run, the output reports will reflect the currently selected sub-process.

Credit Issuance Process Model

(model name: Credit.spm)

This demonstration is a model of the IBM Credit Corporation's reengineering example that is used in Hammer and Champ's book Reengineering the Corporation (Harper Collins, 1993). The As-Is process, according to Hammer and Champy, took an average of six days, and sometimes as long as two weeks. Because of this delay, customers occasionally canceled deals. When two IBM managers decided to walk through the process and determine exactly how much time was required to process a loan request, they discovered that the process took only 90 minutes! They determined (apparently) that the delays were caused by "hand-offs," or transfers between departments.

At the top level, the Credit model contains 3 processes. The first process is a GENERATE activity that generates finance requests based on an interval that uses an exponential distribution with a mean value of 30 minutes. The second major process is a hierarchical representation of the business processes. The third process is a DISPOSE activity that marks the end of the process.

As-Is Alternative

The As-Is process for processing a finance request consists of 5 major sub-processes:

1) Log Request - Field sales personnel call in request for financing to group of 14 people. The person taking the call (Call Logger) logs the information on a piece of paper. The paper is taken upstairs to the Credit Department by a Courier.

2) Check Credit - A Credit Specialist enters the information into a computer and does a credit check. The result of the credit check is written on a piece of paper. The Courier takes the paperwork to the Business Practices Department.

3) Add Special Terms - Standard loan contracts are modified by a Business Administrator to meet customers requirements. The request is then taken to a Pricer by the courier.

4) Price Financial Request - The pricer determines the interest rate. The interest rate is written on a piece of paper and taken to a clerical group by the courier.

5) Send Quote Letter - A quote is developed by an Administrator and sent to Field Sales via Federal Express.

To-Be Alternative

IBM management decided to reengineer the process by replacing the specialists with "deal structurers," or generalists. In the reengineered process, the generalists handle the process from beginning to end. To facilitate processing, the generalists would receive assistance from a sophisticated computer system and, when there was a problem, would seek help from one of the remaining specialists. IBM decided to eliminate all hand-off delays and prioritize credit application processing by assigning personnel to handle the process from beginning to end.

The To-Be process for processing the finance request starts out with a BRANCH activity where the nature of the finance request is determined. Ninety percent of the time a request is sent to a Generalist while ten percent of the time a request is sent to a team of resources consisting of a Generalist, an Administrator, a Credit Specialist, a Business Practitioner and a Pricer.

New Accounts Model

(model name: NewAccount.spm)

An insurance company is striving for higher customer satisfaction by attempting to process new requests the same day. The New Accounts Department handles new customer's requests for life insurance. This department is made up of: a credit check expert, risk rating expert, medical doctor, quotation expert and typing pool.

When a new account arrives, a Credit Check is performed. Then copies are sent to Risk Rating and Medical Check to be processed in parallel. The new account may be rejected at any of the three steps. If it passes all three, it is sent to a quotation expert, the typing pool, and then sent to the customer.

This model can be used to test how sensitive the system is to changes in staffing levels by changing the number of resources available in the model. Resources are used to model the personnel performing the work in the system, such as Doctors, Credit Check Experts, Typing Clerks, etc.

It can also be used to test how the system will handle an increase in the number of proposals requested. If, for instance, a marketing campaign was planned that was expected to increase the number of requests by 10%, the number of incoming requests to the model could be increased by the same amount. Running the simulation again, we can see how the system's performance will be affected by the increase.

Supply Chain Model

(model name: Supply.spm)

For an industrial enterprise, one of key business processes is the supply chain process. The primary goals of supply chain management are to maintain high service levels while minimizing costs. The key problem in supply chain management is how to balance inventory. Variability in demand and process times, complexity of the supply chain objects, and system dynamics create uncertainty that can only be modeled and analyzed with a tool like SIMPROCESS.

This demonstration model represents a typical supply chain for an industrial enterprise with 4 factories (Reno, Denver, Fargo, and Richmond), 3 suppliers (Phoenix, Omaha, and St Louis), and 4 customers, or distributors (San Francisco, Dallas, Detroit, and Boston), in the United States. This high level model of the supply chain demonstrates how SIMPROCESS can help define the major processes, resources, and entities involved in providing products to customers. The model also demonstrates the power of the hierarchical simulation capability of SIMPROCESS. To view the power of hierarchical modeling, drill down into the Reno factory (Factory 1).

Since travel time is important, the Connectors between factories, suppliers, and customers represent the distance between each of the locations. Each Connector at the top level determines the appropriate travel time between locations by dividing the distance in miles by the average miles per hour. The average miles per hour is a model parameter that can be changed before each run. Shipments from factories to customers require a Factory Driver Resource. The Factory Driver can only drive from 8am to 10pm. Shipments from suppliers to factories require 2 Supply Driver Resources. Thus, travel is not interrupted for shipments traveling from a supplier to a factory.

Because Orders are transmitted electronically, Transfer Activities are used to send Orders from customers to factories. This reduces the number of Connectors required on the top level.

Below is a brief description of the model elements.

Customers

Customers demand products from the factories. The customer process defines the frequency and quantity of demand from the factories.

Suppliers

Suppliers supply raw materials (supplies or components) to the factories. Each supplier produces different types of raw materials and ships to each factory.

Factories

Factories assemble the components, package the goods (inventory) and ship them to customers. A factory typically ships to customers in its geographic region. For example, the Reno factory receives 60 percent of its orders from the San Francisco customer and 40 percent of its orders from the Dallas customer.

Such a model of a supply chain can be enhanced to answer questions such as:

· What if the demand for certain products from the east coast supplier doubles?

· What if the Phoenix supplier is having manufacturing problems with a product line?

· What if we use alternative transportation carriers to deliver products to customers?

· What if we outsource the assembly process?

Purchasing Process Model

(model name: Purchasing.spm)

The high degree of change in the business environment has created a new challenge for industrial and service enterprises. That challenge is to determine an organizational structure that minimizes administrative costs while maximizing service to its customers.

Traditionally, managers have used organization charts to describe hierarchical structures and evaluate business decisions regarding changes to the organization. Unfortunately, these tools are no longer adequate because they do not take into account the process view and dynamics associated with administrative processes. Documenting the processes, understanding the dynamics of the business processes and activity costs in a changing administrative process can only be achieved with a tool like SIMPROCESS.

This hierarchical model of a purchasing process consists of 5 major processes. They are:

· Select Supplier

· Negotiate Terms and Pricing

· Prepare Purchase Order

· Place Purchase Order

· Audit Invoice

The demonstration model highlights one of the powerful features of SIMPROCESS - the ability to create alternative representations of a hierarchical business process. In this model, the purchasing process object consists of 3 alternative organizational representations.

Alternative 1 - Functional, Centralized Purchasing

The purchasing process is performed by centralized, functional organization where the five functions are performed by staff dedicated to each function.

Alternative 2 - Product based, Decentralized
Purchasing

The purchasing process is performed by three decentralized, product organizations where the each product organization performs all 5 functions for its product line.

Alternative 3 - Hybrid Purchasing

The purchasing process is performed by a hybrid organization where the supplier selection and terms and pricing functions are performed by a centralized organization; and the other 3 functions are performed by decentralized, product organizations.

This model is a simple demonstration model for OptQuest. OptQuest automatically searches for optimal values. To examine the optimization setup choose OptQuest from the Tools menu. OptQuest for SIMPROCESS is licensed separately from SIMPROCESS. Therefore, if OptQuest is not enabled on the Tools menu, contact the SIMPROCESS Sales Manager for information on licensing. How this model was setup for optimization is described in Chapter 15 of the SIMPROCESS User's Manual.

Help Desk Model

(model name: HelpDesk.spm)

Today, customers are much more demanding and cost-conscious than they are 5 or 10 years ago. Increasing competitive pressures make it a tough challenge for service enterprises to maximize service quality while minimizing costs. Such performance metrics as waiting time and activity costs are critical to providing quality service and strategically pricing services.

Typically, staffing and communication technology decisions for a customer service process have been made by analytical tools which fail to take into account the randomness and system dynamics that result in queuing. SIMPROCESS provides a complete set of statistical tools such as probability distributions, Data Analysis, and Design of Experiments; and advanced modeling features such as cyclical generation of entities, and resource downtimes.

This demonstration model shows how SIMPROCESS can be used for modeling the random nature of a Help Desk. The Help Desk utilizes three types of Customer Service Representatives (CSR's) to handle incoming customer calls. These CSR's are modeled as resources. The three type of CSR's are:

CSRhelp

Customer Service Representative trained to handle calls regarding transfer of ownership, power outage and billing inquiries.

CSRpage

Customer Service Representative trained to handle calls regarding paging inquiries.

CSR

Customer Service Representative cross-trained to handle calls regarding transfer of ownership, power outage, billing and paging inquiries.

The hierarchical business process "Help Desk" contains two alternative ways of utilizing the same total number of resources. The business objective of this exercise is to best utilize the CSR's to minimize the time customers spend on hold waiting for an available Representative.

Alternative 1

This is the "As-Is" process. When a call arrives, it is answered by the first available CSRhelp. The Representative determines what the inquiry is regarding. The CSRhelp then either passes the call to "Desk 2" if it is a paging inquiry, or else handles the call. If the call is passed to Desk 2, the customer is put on hold until a CSRpage is available.

Alternative 2

This is the "To Be" version of the process. When a call arrives, it is answered by the first available CSR. The Representative determines what the inquiry is regarding and services the customer regardless of the category.

Assemble Reference Model

(model name: Assemble.spm)

This model is a simple example of how the Assemble activity is used. A list of component entities and their quantities is specified on the Assemble Activity. When all of the required component entities are present at the activity, a new entity is created. The component entities are either deleted when the new entity is created, or they are batched and carried with the new component. This is controlled by a check box on the Assemble Activity Properties dialog.

There are two Generate activities, one Assemble activity, and one Dispose activity. Request Info Pack is the original entity in this model, and is created using a periodic schedule at the Request Info Package activity. The Requests follow the connector to the Assemble process. At the Assemble activity, the Requests will be combined with a Folder, Brochure and a Demo CD. The Folder, Brochure and Demo CD are re-supplied weekly or monthly based on calendar type schedules for each entity type. Once all four of the required entities are at the activity, a new entity is created, an Information Package. The component entities are now deleted, all of the statistics gathered on them are complete. The Information Package follows the connector out of the Assemble Process to Mail.

Run the model to gather the statistics and display the reports. Typically, the statistic of most interest when using the Assemble activity, is the Hold For Condition time of the entities. This will record the amount of time the component entities are held at the Assemble activity until the specified component entities have arrived. In this example, a Request Info Pack, Folder, Brochure and a Demo CD, are needed to build an Information Package. The Hold For Condition statistic will show the average or peak amount of time each component was held at the Assemble activity until all required component entities are available. For this example, we are most interested in how long the Requests for Information Packages had to wait before the pieces of the Information Package were all available. Essentially, we are seeing if our re-order strategies for the pieces of the Information Package is causing too long of a turn-around time for getting Information Packages out to prospective customers. The average Hold For Condition time for the Request Info Pack is .212 hours and the peak Hold For Condition time is 24 hours. This shows, that with this re-order strategy, Requests for Information Packages wait on average almost 13 minutes for all of the components for the Information package to be available. We also see that the longest wait is just under one day. This is probably acceptable. In this simple example, no resources are required for any steps in the model, so the Wait For Resource time is zero. The Duration At Activity refers to the time the entities spent in a Delay activity, or time during a delay specified on any other type of activity.

Batch/Unbatch Reference Model

(model name: Batch.spm)

This model is a simple example of how the Batch and Unbatch activities are used. The Batch activity will hold entities until the specified quantity of entities has accumulated, then a batch of those entities is formed. The Unbatch activity breaks the batch back down to its component entities.

The Generate and Dispose activities are placed at the highest level of the model, with the Batch/Unbatch process. Descend into the Batch/Unbatch process. Here there are three activities, a batch activity, delay activity and an unbatch activity. Mail is the entity in this model, and is created using a periodic schedule at the generate activity. The pieces of Mail follow the connector to the Batch/Unbatch process. The first step in the process, the Batch activity, holds the Mail until ten pieces have accumulated. The "batch" of ten pieces of Mail moves to Delivery where it takes one hour to move the batch from the district office to a local office. Once the batch of Mail arrives at the local office, the Mail is unbatched. The ten component pieces of Mail are released and follow the connector out of the Batch/Unbatch process.

Run the model to gather the statistics and display the reports. Typically, the statistic of most interest when using the batch activity, is the Hold For Condition time. This will record the amount of time the entities are held at the batch activity until the number of entities specified have arrived. In this example, ten pieces of Mail are needed for a batch. The Hold For Condition statistic will show the average or peak amount of time a piece of Mail was held at the batch activity until the specified number of pieces of Mail reached the activity and a batch was formed. In this example, the average Hold For Condition time is 2.25 hours and the peak Hold For Condition time is 4.5 hours. In this simple example, no resources are required for any steps in the model, so the Wait For Resource time is zero. Duration At Activity refers to the time the entities spent in a Delay activity, or time during a delay specified on any other type of activity. In this model, Duration At Activity measures the amount of time spent in the Delivery, which is one hour.

One important last note, when the entities are unbatched, they regain the individual identity they had before being batched. For example, if a unique attribute was attached to each of the entities before they were batched, when they are unbatched, the individual entities will still contain their own unique value of that attribute.

Split/Join Reference Model

(model name: SplitJoin.spm)

This model is a simple example of how the Split and Join activities are used and how to use Expression Plots. When an entity reaches the Split activity, a clone or clones of the entity are created. The original entity will exit the Split activity from the pad labeled "Original". The clone entities will exit the Split activity from the pad labeled "Clones". The number of clones made corresponds to the number of connectors that originate from the clones pad. The original entity and its clone(s) are referred to as a "family". The Join activity will hold the original entity and its clone entities until the entire family has reached that activity. The original entity will then continue through the model, the clone entities are deleted by default, or can be batched with the original entity.

The Generate and Dispose activities are placed at the highest level of the model, with the Split/Join process. Double-click on the icon representing this process to descend one level. Here there are four activities, a Split activity, two Delay activities, and a Join activity. Orders are the entity in this model, and are created using a periodic agenda at the Incoming Orders activity. The Orders follow the connector to the Split/Join process. The first step in the process, the Split activity, creates a clone of the Order, called "Invoice". The Order then moves to Shipping where the Order is filled from stock on hand, when the Order moves to the Join activity. The Invoice moves to billing, when work is completed there, it moves to the Join activity. When both the Order and its matching Invoice arrive at the Join activity, they are batched and follow the connector out of the Split/Join process.

Run the model to gather the statistics and display the reports. The model is preset to run 10 replications so either run the model for one replication or run all 10 replications and look at the report for Replication 1. Typically, the statistic of most interest when using the Join activity, is the Hold For Condition time. This will record the amount of time the entities are held at the Join activity until the original entity and all of its clones have arrived. In this example, an Order and its Invoice are needed. The Hold For Condition statistic will show the average or peak amount of time an Order or Invoice was held at the Join activity until the rest of its family reached the activity. In this example, the average Hold For Condition time for the Invoices is .925 hours and the peak Hold For Condition time is 3.526 hours. The average Hold For Condition time for the Orders is .687 hours and the peak Hold For Condition time is 10.206 hours. In this example, no resources are required for any steps in the model, so the Wait For Resource time is zero. Duration At Activity refers to the time the entities spent in a Delay activity, or time during a delay specified on any other type of activity. In this model, Duration At Activity measures the amount of time spent in the Shipping and Billing activities as they are the only Delays or duration's in this model.

This model also demonstrates creating plots with the SIMPROCESS Expression Language. Two plots are created, a Trace plot and a Histogram plot. These plots graph values from each replication, so the model must be run for multiple replications for the plots to be populated. (Turning off Animation will cause the replications to complete quickly.) The commands to create and populate the plots are in the Model Expressions (Define/Model Expressions). See the section Expression Plots in Chapter 8 of the SIMPROCESS User's Manual and the section Creating and Controlling Plots With Expressions in Chapter 10 of the SIMPROCESS User's Manual for a full description.

Advanced Resource Downtime Reference Model

(model name: Sample Downtime.spm)

This model has four examples of how to use some of the more advanced features of resource downtime: Interrupt Activities, Release All Resources, and Release Entities In Process at Start of Downtime. These features are described in Chapter 11 of the SIMPROCESS User's Manual. Briefly, Interrupt Activities and Release All Resources are options of resource downtime schedules. Interrupt Activities causes the resource to interrupt any entities that are processing with the resource that is going down. Release All Resources is only active if Interrupt Activities has been selected. If selected, Release All Resources causes other resources obtained at the same activity to be released when the resource in question goes down. Release Entities In Process at Start of Downtime is an option on the resource usage dialog of activities. If selected, this option causes an entity interrupted by downtime to be released. If this option is not selected, the entity remains at the activity until all processing time is complete.

There are four processes at the top level of the model: Construction Process, Business Process, Manufacturing Process 1, and Manufacturing Process 2. Each process has a flow that is independent of each of the other processes. Note that these examples are do not necessarily reflect the operation of any real process. The intent is to demonstrate the downtime options. The Construction Process simulates the welding of parts. Each part requires two Welder resources to do the welding (click on Resources tab of the "Weld Parts with 2 Welders" activity to see resource requirements). One unit of the Welder resource goes down every 3.5 hours. Interrupt Activities is selected for the Welder resource, and Release Entities In Process at Start of Downtime is selected for the resource usage for the "Weld Parts with 2 Welders" activity. When one unit goes down, the entity is released from the activity. In the Release Entity expression, calculations are done to see if the entity completed its processing. If it did not, then the entity is branched to the "Finish with 1 Welder" activity. This activity completes the welding with the one welder that is still available, and the remaining processing time is increased by 50% to represent the fact that it takes longer for one welder to complete the job.

The Business Process models a portion of approving policies for an insurance company. There are four Underwriter resources that review policies. Thus, up to four policies can be processing in the "Review Policy" activity. Every three hours, one unit of the Underwriter resource goes down. The Interrupt Activities option is selected for the downtime, and the Release Entities In Process at Start of Downtime option is selected at the "Review Policy" activity. When the unit of resource goes down, an entity processing at "Review Policy" is interrupted. If necessary, that entity is routed to the "Finish Review" activity (see Release Entity expression of "Review Policy"). In the Accept Entity expression of "Finish Review" the priority of the entity is increased. The next available Underwriter resource completes the review. The remaining time is not increased since only one unit was needed for review to start with.

Manufacturing Process 1 simulates the assembly of a widget. The widget is on a conveyor and two workers (Worker 1 and Worker 2) are required to assemble the widget. The workers are modeled as separate resources since each have different downtime schedules. The Widget 1 entity acquires the Conveyor 1 resource, then moves to the "Assemble Widget" activity where the two workers are assigned in the resource usage dialog. Both Worker 1 and Worker 2 are needed to process the entity. The Conveyor 1 resource goes down every half hour. The Interrupt Activities option is selected. Release Entities In Process at Start of Downtime is not selected at "Assemble Widget." The Worker 1 and Worker 2 resources each have a downtime schedule with Interrupt Activities and Release All Resources selected. Thus, Conveyor 1, Worker 1, and Worker 2 can all cause the entity to stop processing. Worker 1 and Worker 2 have Release All Resources selected. If Worker 1 goes down, Worker 2 is released, and if Worker 2 goes down, Worker 1 is released. Conveyor 1 is not released when Worker 1 or Worker 2 go down since Conveyor 1 was acquired at a Get Resource activity. Likewise, Worker 1 and Worker 2 are not released when Conveyor 1 goes down. Since Release Entities In Process at Start of Downtime is not selected, entities remain at the activity until all processing has been completed.

Manufacturing Process 2 also models the assembly of a widget. The resources (Conveyor 2, Worker 3, and Worker 4) have the downtime schedules and options as Conveyor 1, Worker 1, and Worker 2 except Worker 3 and Worker 4 do not have Release All Resources selected. The main difference is the "Assemble Widget" activity has Release Entities In Process at Start of Downtime selected. When this option is selected the resources obtained at the activity are released when the entity is released. So, it doesn't matter whether or not Release All Resources is selected. In this case it is more difficult to determine if the entity has finished processing when Worker 3 or Worker 4 goes down. This is because Conveyor 2 has been going down every half hour, which extends the amount of time required to finish processing. Notice the Release Entity expression of "Assemble Widget." This is the same logic that was used in Construction Process and Business Process. In this case, though, we have to account for the amount of time the entity is at the activity while not processing (due to the Conveyor 2 downtime). This is done by using the Interrupt Processing and Resume Processing entity instance expressions of the Widget 2 entity. To view the expressions, select Define/Entities on the menu. From the list of entities select Widget 2 and click the Edit button. This brings up the properties dialog for Widget 2. Click the Entity Expressions tab. In the Interrupt Processing expression an attribute (StartInterruptTime) is assigned the current SimTime. Note that this is only done if the Interrupted attribute is FALSE. This is checked since another interruption can occur before the first downtime is complete. In the Resume Processing expression, the total time not processing is accumulated (InterruptTime). In the Release Entity expression of "Assemble Widget", the InterruptTime is added to the delay time of the entity (DelayTime) to determine the total time the entity should have been in the activity.

Entity Preemption Reference Model

(model name: Preempt.spm)

This model is an example of how higher priority entities can preempt the processing of lower priority entities. Two types of entities are generated, Routine Message and Urgent Message. The transmission of the messages is modeled by a Delay activity which uses the Transmitter resource.

The Urgent Message entity has a higher Priority (priority 2) than the Routine Message entity (priority 1). Also the Preempt Lower Priority Entities option is selected.

If an Urgent Message arrives while a Routine Message is processing, the processing of the Routine message stops. This causes the Transmitter resource to be released for the Urgent Message. Once the Urgent Message has completed processing, the Routine Message that was preempted obtains the Transmitter resource and completes processing. Note that the preempted entity does not start the processing over. The entity processes the amount of time that was remaining when preempted.

Preemption can be further refined by using Expressions. Entities have a System Attribute called Interrupt. Individual entities can be set to preempt lower priority entities by setting this attribute to TRUE.

Run the model and look at the Standard Report. Note that the Wait For Resources time is zero for the Urgent Message entity type.

Custom Plot Reference Model

(model name: Customer Service.spm)

This model is an example of how to use custom plots. Four different types of entities are generated: Hardware Sales Call, Software Sales Call, Hardware Service Call, and Software Service Call. The calls are process based on call type (in Process Calls), then the sales calls create an order and ship the product (in Complete Calls).

Three custom plots have been defined for this model.

· Call Time In System - plots the time in system for each of the call types.

· Sales Calls In System - plots the number of Hardware Sales Call and Software Sales Call entities in the system. Creates a trace plot and a histogram plot.

· Service Calls In System - plots the number of Hardware Service Call and Software Service Call entities in system. Creates a trace plot and a histogram plot.

These custom plots are hidden. That is, they do not display when the simulation starts. Run the simulation. Click the plots button on the tool bar to see a listing of the plots that are hidden. This can be done while the simulation is running or after the simulation is complete. Select the plots to display and click OK. This causes the plots to appear. If more than one plot was selected, the plots will be stacked on top of each other.

Remote Plot Reference Model

(model name: Remote Plot.spm)

This model is an example of how to display plots on a remote server. This demonstration model will only work if the license for the remote plug-in has been purchased. The model is the same model as Customer Service.spm, except one of the custom plots has been modified to plot remotely and two remote entity plots have been added. See "Custom Plot Reference Model" on page 92 for a description of the model. The two entity plots added are

· Entities In System Trace for Hardware Sales Calls

· Entities In System Histogram for Hardware Sales Calls

These plots, plus the Call Time In System custom plot are setup to plot remotely. This option and the URL of the remote server are set in the plot properties. See Chapter 8 of the SIMPROCESS User's Manual for more information on setting plot properties.

To run this example first start the Java RMI Registry. Start the RMI Registry from the SIMPROCESS menu by selecting Tools/Remote/Start RMI Registry.

After the Java RMI Registry has been started, start SPPlotServer. The Java RMI Registry and SPPlotServer must be started on the server where the remote plots are to appear. This example model assumes the plots will plot on the same machine, but use a different instance of the Java Virtual Machine (the Remote Server URL on the plot properties is rmi://localhost/). For this example start SPPlotServer from the SIMPROCESS directory using the command java -classpath SPSYSTEM\SPRemote.jar;SPSYSTEM\plot.jar com.caci.remote.SPPlotServer (for non-Windows systems use forward slashes and colons in the classpath). Once the Java RMI Registry and SPPlotServer have been started, load and run the model.

To have the remote plots display on a different machine, the server must have a JVM, and SPRemote.jar and plot.jar from the SPSYSTEM directory must be copied to that server. The Java RMI Registry must be started on the remote server. Then, from the directory where SPRemote.jar and plot.jar reside, execute java -classpath SPRemote.jar;plot.jar com.caci.remote.SPPlotServer (use a colon in the classpath for non-Windows systems). In the model, the URL for the server, must be entered in the Remote Server URL field of the plot properties.

Inventory Model

(model name: Inventory.spm)

This sample model demonstrates an Inventory Pull and Manufacturing system. The process is characterized by the Reorder Points and Reorder Quantities defined for each resource in the supply chain. There are four steps in the supply chain: Warehouse, Assembly, Component1 Vendor and Component2 Vendor, and the Raw Material Vendor. Inventory is pulled only when it is needed (there is insufficient stock to fill the order or the Reorder Point has been reached).

The process begins with a customer order of random size. The Warehouse first attempts to fill the order from its inventory. If the customer order can't be filled, more Finished product is pulled from Assembly (based on the Reorder Quantity), and the customer order is placed on backorder. If the customer order can be filled from Warehouse inventory, the model will fill the order and check to see if the Reorder Point has been reached as a result of that order. If the Reorder Point has been reached, more inventory will be pulled from Assembly.

The Assembly and Component Vendor steps work in a similar fashion. After each order is received the model checks to see if any Reorder Points have been reached and pulls more inventory if necessary. In the manufacturing sub-processes each item in the customer order is manufactured one at a time.

The Raw Material Vendor is not being modeled in detail, because it is not a focus of this study. A Delay is simply used to model the effect on the Component Vendors.

Using the model parameters dialog that appears when the model is run, experiment with different Reorder Points and Quantities to evaluate their effect on the system (inventory levels, and the delay to the customer). The goal is to minimize the amount of Inventory held without impacting the customer negatively (increase order cycle time). This can be done by finding the optimal Reorder Point and Quantities for each node in the supply chain. Real time plots can be used to view inventory levels and the effect of a change in a Reorder point or quantity.

Note that there are Connector travel delays for the raw materials to reach the Component Vendors, Connector travel delays for the components to reach Assembly, and a Connector travel delay for the finished product to reach the Warehouse.

This model is setup to be used with OptQuest. OptQuest will automatically search for the optimal reorder points and quantities. To examine the optimization setup choose OptQuest from the Tools menu. OptQuest for SIMPROCESS is licensed separately from SIMPROCESS. Therefore, if OptQuest is not enabled on the Tools menu, contact the SIMPROCESS Sales Manager for information on licensing. How this model was setup for optimization is described in Chapter 15 of the SIMPROCESS User's Manual.

Network Model

(model name: Network.spm)

This sample model simulates the communication between two servers. Note the Simulation Time Unit in Simulate/Run Settings is set to Seconds instead of Hours (which is the default). This is done to preclude rounding errors since this model uses some of the smaller time units. The transmission delay from server to server is modeled on the Connectors between the servers.

This model also demonstrates the use of icons and background images imported for a specific model. The graphic on each side of the main layout title and the icon for the servers were imported just for the Network model. Model specific imported graphics are stored in ModelImages.jar in the model's directory. Storing images in the model's directory facilitates sharing of models. See Chapter 6 of the SIMPROCESS User's Manual for information on importing icons and background graphics, including the difference between importing images for SIMPROCESS versus importing images for a model.

Human Resources Model

(model name: Human Resources.spm)

This model simulates an As-Is and To-Be scenario at the same time. The top flow is the As-Is, and the bottom flow is the To-Be. The two scenarios are kept independent by using two different flow paths along with different entity types and resources for each flow. Dynamic labels and color changes are used to track simulation progress and compare the two scenarios.

Justice System Model

(model name: Justice System.spm)

This model simulates the workload of a city court system. Inputs come from the police department, city attorney's office, and various other locations. Note that in this model there are several processes that are empty. This is because several parts of the actual business process modeled needed to be shown in the model, but did not need to be simulated.

This model demonstrates the use of local Transfer Activities. Local Transfer Activities route entities from one part of a model to another without the use of connectors.

Remote Application Call Model

(model name: RemoteCall.spm)

This model is very simple, but it demonstrates a powerful capability: communication with a remote application. This demonstration model will only work if the license for the remote plug-in has been purchased. The model communicates with an example server program developed by CACI. The System Methods Example section of Appendix F of the SIMPROCESS User's Manual discusses the RemoteCall feature of the expression language and the example programs developed by CACI.

The model plots data from the simulation on a remote plot. For simplicity, the plot is on the same machine but running in a separate Java Virtual Machine (JVM). However, the plot could be populated on another machine. The Start Simulation expression of the Generate activity and the Accept Entity expression of the Delay activity call methods of the remote server. The remote server (SPServerDemoServer) creates an instance of SPServerDemoImpl. SPServerDemoImpl creates the plot (SPPlotDemo).

Note in the expressions that the first parameter is a String that gives the URL of the server. The second parameter is the name by which the server is registered in RMI (in this case, serverdemo). The third parameter is the name of the remote method to execute. Any further parameters are parameters of the remote method.

Since the remote server is registered with RMI, the Java RMI Registry must first be started. Start the RMI Registry from the SIMPROCESS menu by selecting Tools/Remote/Start RMI Registry.

Once the RMI Registry has been started, start the demo server. From a command line in the SIMPROCESS directory execute java -classpath SPSYSTEM\plot.jar;SPSYSTEM\SPRemote.jar com.caci.demo.SPServerDemoServer (use forward slashes instead of backslashes and colons instead of semicolons on non Windows systems). This will cause a plot window to appear. Once the plot window has appeared, start the simulation. The picture below shows how the plot should appear.

External Schedule Model

(model name: Remote.spm)

This model is very simple, but it demonstrates a powerful capability: generation of entities from a remote application. This demonstration model will only work if the license for the remote plug-in has been purchased. See Chapter 11 of the SIMPROCESS User's Manual for a detailed discussion of the External schedule and its affect on simulation execution. Basically, the simulation waits for input for an external source.

The Generate activity has two external schedules: External1 and StopSim. The StopSim schedule generates a StopSim entity which is branched to the StopSim Dispose activity. This activity has a Maximum Entity Count of 1. So an entity entering this activity will cause the simulation to stop. Simulations with external schedules will continue until a Maximum Entity Count is reached in a Dispose activity, the external application executes the stopSimulation method (see Chapter 11 of the SIMPROCESS User's Manual), or the simulation is stopped manually. The simulation end date and time in the Run Settings will not stop the simulation.

In package com.caci.demo (contained in SPRemote.jar within the SPSYSTEM directory) there is a program called ExternalApp and a program called ExternalApp2. These programs will generate entities for this model. The only difference is ExternalApp ends the simulation using the Maximum Entity Count of the Stop Sim Dispose activity, and ExternalApp2 uses the stopSimulation method. (Again, see Chapter 11 of the SIMPROCESS User's Manual for a discussion of these programs.) To run this example the Java RMI Registry must first be started. Start the RMI Registry from the SIMPROCESS menu by selecting Tools/Remote/Start RMI Registry.

Then SPServer must be started. Start SPServer from the SIMPROCESS menu by selecting Tools/Remote/Start SPServer. To start SPServer, from a command line of the SIMPROCESS directory execute java -classpath SPSYSTEM\simprocess.jar;SPSYSTEM\SPRemote.jar com.caci.remote.SPServer (use forward slashes instead of backslashes and colons instead of semicolons on non Windows systems). SPServer starts SPServerFactory. SPServerFactory has three methods that an external application can execute: getSimTime, generateEntity and stopSimulation. The method getSimTime returns the current simulation time, the method generateEntity causes the generation of entities in the simulation, and the method stopSimulation ends the simulation. Once SPServer has been started, start the simulation. Notice that the status panel says Simulating, but nothing is happening. This is because the simulation is waiting for a signal to generate. Starting ExternalApp will cause the generate of entities. ExternalApp must be started after the simulation has been started. To start ExternalApp, from a command line of the SIMPROCESS directory execute java -classpath SPSYSTEM\SPRemote.jar com.caci.demo.ExternalApp (use forward slashes instead of backslashes and colons instead of semicolons on non Windows systems). Entities will be generated every two seconds (real-time) until the StopSim entity is generated.

Emergency Room Model

(model name: EmergencyRoom.spm)

The administrators at a hospital wanted to find the optimal staffing levels for their Emergency Room. The Emergency Room must be able to treat its patients in a timely manner, yet not be overstaffed (which costs the hospital a lot of money). This model finds the optimal Emergency Room staffing levels.

The simulation model diagrams an Emergency Room process. Patients arrive to the Emergency Room either through the entrance door or via ambulance. The hospital groups these patients into 3 categories: level 1, level 2, and level 3. Level 1 patients, such as heart attack victims, are considered the most critical and need to be treated immediately. Level 2 and 3 patients go through a triage process where the hospital makes an initial assessment of their injuries. All patients are then transferred to an available room for treatment. They also go through a registration process either before or after treatment, depending on the severity of their injury. After initial medical treatment, the hospital can release the patient, or assign them to a room in the hospital for a longer stay.

The SIMPROCESS optimization tool, OptQuest, can be applied to the model to find the optimal staffing. A sample optimization is defined. The objective is to "maximize the rooms in use", which would, in effect, reduce the number of unneeded resources and rooms. The Treatment process has two alternatives. The "As Is" alternative is used in the sample optimization.

Get Resource Reference Model

(model name: H2O.spm)

H2O is a local water supply and delivery company. It owns a fleet of 30 tanker trucks for delivering water to customer. There are 3 sizes of the truck tanks: size A is 12 cubic meters, size B is 18 cubic meters, and size C is 28 cubic meters. There are 9 trucks with tanks of size C, 12 trucks with tanks of size B, and 9 trucks of size A.

To place an order, a customer must come in person to the H2O office to pay for the size of tank desired. The customer receives a copy of the receipt, then proceeds to the water station operator and hands the operator the receipt copy. The customer then waits in the waiting area until a tanker truck of the required size is filled with water at any of the available pumps. There are 7 pumps installed at H2O. When the truck is ready, the customer leaves with the truck. After the truck empties its water tank at the customer's location, it returns immediately to the station and becomes ready for new orders. If a truck of the desired size is not available, the customer must wait until a truck of the proper size returns. These waits can be very long. If a customer must wait too long or closing time comes before a truck arrives, the customer will get a refund and leave.

In the CallCenter model (see page 67), the Entity System Attribute MaxWait is used to set the amount of time an Entity will wait for a resource. In this model, that time is set on the Resources tab of each Get Resource activity.

The Get Truck process has two alternatives. The "3 Get Resource" alternative has the Entity branch to the Get Resource activity that requests the appropriate size truck. The branching is done based on probability. Thirty percent of the customers want Truck A, 40% want Truck B, and 30% want Truck C. In the Release Entity expression of each of the Get Resource activities, the type of truck needed by the customer is set in the Entity attribute TruckType. This attribute is used in the FillTruckTime function (Define/Functions) to determine the amount of time to delay for filling the truck. The "1 Get Resource" alternative uses only one Get Resource activity in conjunction with the GetResource System Method. In this alternative, the Entity attribute TruckType is set in the Accept Entity expression of the Get Resource activity Get Truck. Then the truck desired is requested by using the GetResource System Method. This allows the Entity to tell the activity which resource is required and thus eliminates the need for three Get Resource activities.

Airport Staffing Model

(model name: Airport.spm)

This model examines passenger & carry-on screening workflow at an airport. The objectives of the model are

· To monitor the time a passenger spends in line pre-screening

· Ensure the wait time is less than or equal to 15 minutes for 80% of passengers per day

· To assess the impact on security operations during security breaches

The number of workers for each shift are set by model parameters, thus allowing an optimal workforce to be determined. The model includes a sample OptQuest optimization. The optimization minimizes the maximum passenger wait time. The number of workers for each shift are varied from 1 to 3, and the maximum wait time cannot exceed 40 minutes.

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com