Self Teaching Guide
The self teaching guide is designed to walk you through a series of interesting lessons and exercises to help you become proficient with ProcessModel.
Install the Software
A model is made up of multiple files including additional temporary files which are created during simulation. Creating a model “package” is the method ProcessModel uses to bundle the essential files together in a compressed (.spg) format. This facilitates moving models to a new location (either on your computer or on another computer), or creating multiple versions of a model as you build your application. To open or install a model package, open ProcessModel and click the Open option from the File menu. Then browse for the package file. Don’t use WinZip (or other zipping program) to create or install package files.
When opening a model file you will be opening a .SPG file. To open a model you must start the ProcessModel application and click the Open option from the File menu, then browse for your model file. Do not simply double click on a model file from My Computer or Windows Explorer. Doing so may not open the application properly.
To aid in your learning process, each lesson will have questions to check your comprehension of the concepts being covered. Your answers can be verified by checking the Appendix at the end of this guide.
Self Teaching Guide Conventions
The following icons will be used throughout this manual to indicate sections to take note of.
|Action to take|
|Important information to be aware of|
|Tip or something to think about|
|Questions to answer in order to confirm comprehension of information covered|
|Watch tutorial video|
|Bold||Menu items to click, text to be typed, or other actions to take|
Continue with Lesson 1: Your First Model
Lesson 1: Your First Model
See Overview of Modeling with ProcessModel video tutorial.
See Learn How to Use the Interface video tutorial.
Operating Parameters and Requirements
In our first lesson we will model a small call center. The objective of this lesson is to find the appropriate staffing level for a given call volume. We will be modifying the model itself, as well as changing some parameters in order to reach the objective.
Help desk staff (Level 1 resource) make $8/hr while support staff (Level 2 resource) make $12/hr.
75% of the calls taken can be resolved over the phone within the first 2 minutes. Once the question is answered, the call exits the system. But the remaining 75% of calls are more difficult and require additional research. The research function takes 20 minutes to complete. Following the research, the call must be returned to the customer. This call back takes 3 minutes.
New calls come into the call center every 5 minutes. Management has determined that the average customers with a difficult issue should not to wait more than 60 minutes to receive a call back.
Open the Model
Start ProcessModel and open the Lesson 1 – Call Center model package by selecting the Open option from the File menu.
This will install the model files from the package but keep the package intact. That way you can change the model as much as needed. Then, if you ever need to go back to the original version of the model, you can just install the package again. Just make sure you use File / Save As to change the name of your model before installing the package again. Otherwise you will overwrite your current model of the same name.
You should now see the model shown below.
Answer the following questions without simulating the model. Supposing 200 calls arrived:
1. How many calls exit without requiring research?
2. How long does each simple call take to complete?
3. How many calls require research?
4. How long does it take to service the difficult calls?
Simulating the Model
To simulate the model, click the Simulation menu and then select the Save & Simulate option.
The upper left region of the simulation window is called the Scoreboard. It shows some key statistics for entities which have completed the process and left the model. The upper right section of the window shows the simulation clock. 30 hours and 23 minutes into the simulation, the 63 completed difficult calls have taken an average of 681.24 minutes to make it through the process. That may be a surprise since the total activity time for the model is only 25 minutes. One of the benefits of simulation is to demonstrate what will actually happen, rather than what is supposed to happen, or what you think will happen.
You can speed up the simulation or slow it down by dragging the scroll bar at the top of the window to the right or left.
The indicator lights above the resources show their activity. Red means the resource is on break or off shift. Blue means the resource is on shift but waiting for work. Green means the resource is currently working on an entity.
The number above and to the left of an activity represents the contents of its input queue. In this case there are 14 calls waiting to be returned because the activity is currently busy. The number below an activity shows the current contents of a multi-capacity location. The Perform Research activity has a capacity of 10, but since there is only 1 Level 2 resource, only 1 entity can be processed at a time at that location.
View the Output Report
Following the simulation you will be asked if you want to see the results. Click No, after returning to ProcessModel click the output report button .
Scroll down to the Resources section. You’ll notice that the Level 2 resource was busy 96.7% of the time while the Level 1 resource was only busy 40% of the time.
Scroll down to the Entity Summary section. There you see that 70 Difficult calls left the model and took an average of 669.69 minutes to do it.
Scroll to the top to view the Activities section. Notice the input queue for the Return Call activity had an Average Contents of 21.76 and an average wait time of 497.37 minutes. That’s over 8 hours in that activity alone before the call was returned. Our manager is not happy!
Solution 1 – Hire More Staff
Close the output report by clicking File and selecting Exit. Then double click on the Level 2 resource and change the Quantity field to 2.
Save this as a new file by clicking the Save As option on the File menu. Save the file as using the name Lesson 1 – Solution 1. Now simulate your model and find the average cycle time for the Difficult calls.
5. How much improvement was there in the cycle time?
6. How did the resource utilization change?
7. Is that utilization change good or bad?
Solution 2 – Change Entity Handling
While there was a dramatic improvement in cycle time, solution 1 will increase cost. Let’s try another where the Level 2 resource stays with the entity from the time they begin research until after they return the call.
Open the original call center model by clicking File and then Open. Select the Lesson 1 – Call Center model. Change the Get and Free connector from Perform Research to Level 2 to a GET.
Also change the Get and Free connector from Level 2 to Return Call to a Free.
Now, instead of the Level 2 resource being freed immediately after the Perform Research work is complete, the resource will travel with the Difficult call through the Return Call activity until the call is complete and has been returned.
Save this new model as Lesson 1 – Solution 2. Simulate the model.
The average cycle time is now 212.27 minutes which is not as good as in Solution 1. However, there is no increase in cost. The Perform Research input queue has an average contents of 8.28 and an average time of 179.23 minutes.
8. Where is the queue buildup now?
9. What happened to the input queue buildup at Return Call?
Solution 3 – Change Responsibilities
Since the Level 1 resource has some free time, let’s see what happens if we have them return calls instead of the Level 2 resource.
Close any models you have open. Open the Lesson 1 – Call Center model. Click the dashed line connecting the Level 2 resource to the Return Call activity. Press the Delete key on your keyboard. Hover your mouse over the Level 1 resource. Then click and drag your mouse to Return Call.
Rename your model to Lesson 1 – Solution 3 by clicking the Save As option on the File menu.
After simulating this new model, you’ll notice the cycle time for Difficult calls has dropped to 105.35 minutes.
10. What was the Average Contents value for the Perform Research input queue?
11. How long did the average Difficult call wait in the input queue of the Perform Research activity?
12. What was the utilization for each resource?
Solution 4 – Alternate Resource
Another alternative is to cross train Level 1 workers so they can help doing research when they aren’t busy taking calls. Remember though, taking calls is their first priority. So if they are doing research and a call comes in, they need to stop doing their research in order to take the call.
Open the Lesson 1 – Call Center model. Hover the mouse over the Level 1 resource. Click and drag your mouse to the line connecting Level 2 to Perform Research.
To place priority on taking calls, click the connector between Level 1 and Take Call. Then click the Respond Immediately check box.
Save this file as Lesson 1 – Solution 4. Then simulate the model.
The average cycle time for Difficult calls is no 53.95 minutes. Remember management wanted that time to be under 60 minutes.
13. Several alternatives were tried in this lesson. Given your knowledge of business, which solution do you think makes the most sense?
14. What other solutions would you suggest? Do you see how ProcessModel can help you determine the best alternative?
15. Go back to the original call center model. Review the operating parameters and requirements outlined at the beginning of this lesson. Double click each object in the model to locate each of those parameters
Continue with Lesson 2: Replications and Distributions
Lesson 2: Replications and Distributions
Distributions (which we will discuss later in this lesson) are a method used in ProcessModel to introduce randomness or variability. For example, you may have an activity where the processing time is not always constant due to the type of entity being processed, or a variety of other reasons. In order to understand the importance of running replications in a simulation, let’s suppose you have 3 consecutive activities, each having a distribution in their time fields. Because the values for those times are chosen randomly each time an entity enters the processes, it is possible that the majority of the times chosen will be on the low range of possible values. That of course would give a lower than expected overall cycle time for your process. Now let’s say you delete one of the processes. You would expect the average cycle time to drop because there is one less activity. However, because of the randomness of the distributions, the two remaining activities could return many time values in the high range of the scale. In that case, the average cycle time would actually go up instead of down. Even though this is an extreme example, it demonstrates the nature of randomness. Replications allow you to run a simulation multiple times, generating different random values for each replication. Then by taking an average of those replications, your results are much more realistic and repeatable.
When using replications, you can view the minimum and maximum results for each section in the output detail report. Run your replications, then on the output report’s filter tab, click Statics and select the check the Min – Max checkbox. Min – Max should now be selected.
The min and max values will be displayed in each of the report sections similar to that shown below.
Open the last model used in Lesson 1, Lesson 1 – Solution 4. Click on the Simulation menu and select Options.
You’ll remember that the simulations in Lesson 1 ran for 40 hours. The Options menu is where the simulation run length is determined. Warmup length is the amount of time you want to run your model before collecting statistics (use to preload a production line). Replications determines the number of times a simulation is repeated before displaying the results.
Turning off the animation in the Options window will make the simulation run much faster.
Let’s see what happens when you set the Replications to 30, turn off the animation and the scoreboard. Click Close, simulate the model, click No to close Output Detail Report, Click from the toolbar to view the output report.
Goto the Entity Summary tab on the General Report.
The results of each replication are shown in the first 30 rows. The last two rows show the Average and Standard Deviation for all replications. Note the Average Cycle Time average of the replications is 68.95 which is above the required 60 minute maximum specified by management.
A distribution could be defined as a set of values which specify the relative frequency with which an event has occurred or is likely to occur. In the real world, events tend to occur randomly, according to certain statistical patterns or distributions. Distributions allow you add randomness or variability to your model in order to make it more accurately reflect reality.
Distributions are of two major types: discrete and continuous. Discrete distributions contain a finite number of possible outcomes. Two examples would be an entity randomly routing to one of several locations, or a randomly generated quantity of arriving entities. Continuous distributions contain an infinite number of possible outcomes. Examples include generating service times or the time between arrivals.
The following represent only 4 of the commonly used distributions in ProcessModel. For a complete list of available distributions you can open the Stat::Fit program from ProcessModel’s Tools menu.
|Triangular||T(a, b, c, s)||a = mimum
b = mode
c = maximum
Example: T(2, 10, 15)
|Uniform||U(a, b, s)||a = mean
b = half range
|User-defined (or discrete)||D n (% 1 , X 1 , . . . % n , X n )||% = percentage of time the value is returned
x = value to be returned
n = number of return values (between 2 and 5)
Example: D3(20, 35, 30, 45, 50, 37.5)
The following diagrams show what the Triangular and Uniform distributions explained above would look like.
Triangular – Unload time for trucks could be as little as 7 minutes, is typically 18, but could be as long as 45 minutes. To model this example, you would enter T(7, 18, 45) in the Time field at the Loading Dock activity.
Uniform – Everyday you have anywhere between 50 and 150 customers come to your store. To model this example, you would enter U(50, 150) in the Quantity field of your daily pattern arrival.
User-defined – One of two types of prep need to occur on each part entering your process. 34% of the time the prep takes 8 minutes. 66% of the time it takes 14 minutes. To model this example, you would enter D2(34, 8, 66, 14) in the Time field of the Prep activity.
Close any currently open model and open the Lesson 1 – Call Center model. Double click the Perform Research activity and enter T(10,20,30) in the Time field.
Adding the time distribution will cause the time to vary between 10 and 30 minutes, with most times being around 20 minutes, for each entity that enters this activity.
Double click the arrival route (line between the Call entity and the Take Call activity). Enter D2(90,1,10,2) in the Quantity field. Then enter T(2,5,12) in the Repeat Every field.
90% of the time, a quantity of 1 call will arrive. 10% of the time, 2 calls will arrive together. Calls will arrive between 2 and 12 minutes apart, with the majority of arrivals occurring around 5 minutes apart.
Set this model to run 10 replications by clicking Simulation and selecting Options. Save this model as Lesson 2, then simulate it.
1. What is the average and standard deviation for the Level 2 resource?
2. What is the average and standard deviation for the Difficult calls?
3. Though you don’t see a typed distribution, where do you find randomness or variability in the Lesson 1 – Call Center model?
4. Think of a real world situation where you would use a triangular distribution. What questions would you ask to obtain the parameter values you need?
Though you can use estimates of what your randomized data values will be at any given time, it is always best to use real data to generate reliable results based on quantitative data. That is where Stat::Fit comes in (available on the Tools menu). Stat::Fit is a statistical tool which allows you to create statistical distributions based on actual measured data.
Let’s look at one example of why it is important to use Stat::Fit. One distribution which is fairly easy to understand is the Triangular distribution. It has 3 parameters: a minimum value, a mean value, and a maximum value. For example, suppose we have an activity that takes a minimum of .25 minutes, usually takes 2 minutes, but could take as long as 100 minutes. That is easily written as T(.25,2,100). However, if the data should actually be represented by a Lognormal distribution, the graph below shows where much of the time you could be getting wrong values if you used a Triangular distribution instead.
So taking the easy route (or using the easy distribution) may cost you in reliable results. Using collected data and Stat::Fit gives you confidence that you can depend on your output accuracy when introducing variability into your model.
For the next portion of our lesson, suppose you have collected data for the Perform Research activity, but you don’t know what distribution to use or how to get that data it into your model.
Close your current model and open Lesson 1 – Call Center. Click the Tools menu and select Stat::Fit. In the Document1: Data Table window, click in the column to the right of the number 1.
Enter the following numbers in the Data Table (you can select, copy and paste this data): 25 18 19 12 25 26 20 15 21 20 22 23 15 14 25 26 19 23 15 17 19 22 18 24 20
If you already have your data in another application like Excel, you can copy and paste your data points rather than typing them manually.
After entering your data, click the Auto::Fit button, select the unbounded option, and click OK.
To view the graph of any of the distributions simply click the distribution name on the left.
Load the Weibull distribution into the Perform Research activity by clicking Stat::Fit’s Export button, then click OK.
Exit Stat::Fit and double click the Perform Research activity. Highlight the 20 in the Time field. Right click your mouse and select Paste. This will paste the Weibull distribution you created in Stat::Fit into your model.
Continue with Lesson 3: Entity Arrivals
Lesson 3: Entity Arrivals
Entities are the things that move through your process. They include things like phone calls, patient’s, customer orders, raw materials, service requests, parts, etc. Entities come into your model through Arrival routes (with double headed arrows).
Close any open models and open Lesson 1 – Call Center. Double click on the arrival route connecting the Call entity to the Take Call activity.
A single Call arrives every 5 minutes. Using a Periodic arrival with a First time value of 0, the first call arrives immediately as the simulation begins.
Continuous – Entities will enter the model as soon as there is capacity to accept them at the first location (activity or storage) connected to the arrival. If the first activity has an input queue, it is ignored.
Daily Pattern – Entities arrive in a weekly (168 hours) repeating pattern, at times and quantities you specify on a given day of the week. If the start time and end time is different, the entities will arrive in a randomly distributed fashion during that block of time. The Quantity field may be a constant, distribution, or scenario parameter.
Ordered – Entities arrive according to the parameters established in the Order Signal route connected to it. This means a request must be made by an event downstream from the ordered arrival rather than from the arrival itself.
Periodic – Entities arrive at the interval indicated in the Repeat every field, in the quantity specified. Since all simulations start at midnight on Monday morning, that is when the first arrival occurs, unless you specify a value in the First time field in which case the arrival will be delayed by that amount of time. Each field may be a constant, distribution, or scenario parameter.
Scheduled – Entities arrive according to schedule you define using a numbered day (e.g. 1 st Monday, 3 rd Thursday). Each arrival is a one-time occurrence which the system does not repeat. The Quantity field may be a constant, distribution, or scenario parameter.
Daily Pattern Example
Let’s create a daily pattern arrival in which a quantity of 48 entities arrives between 8am and noon, then another 48 arrive between noon and 4pm.
Double click on the arrival route connecting the Call entity to the Take Call activity. Change the arrival Type to Daily Pattern and click Define Pattern. Then click New. In the Start time field enter 8:00 am. In the End time field enter 12:00 pm. In the Quantity field enter 48.
Click New and repeat the process for 12:00 pm to 4:00 pm.
Now copy the Monday pattern to Tuesday through Friday by clicking the Copy day button. Click Tuesday and then click Paste Monday. Repeat for Wednesday through Friday. Then click Close.
Each day, Monday through Friday, is divided into two blocks of 8am to noon, and noon to 4pm. In each of those 10 blocks a quantity of 48 calls will arrive, randomly distributed through each block.
Daily pattern arrivals (as well as scheduled arrivals and shifts) use a 24 hour clock. Up to now we have only been concerned with simulating straight working hours. As you will see shortly, this will impact how you setup your models.
Save this model as Lesson 3 and then simulate it.
1. What is the average cycle time for Difficult calls?
2. What is the utilization of the Level 2 resource?
3. Why has the utilization decreased?
4. Why did the animation stop during the simulation?
5. How many days were simulated?
6. How do you make the simulation run for an entire week?
7. If you change the arrival so all 96 entities arrive between 8:00am and 8:01 am, Monday through Friday, how does this change the results and why?
Continue to Lesson 4: Routings
Lesson 4: Routings
Routings are lines that connect the locations (activities, storages, etc.) in the model. Ten different kinds of routings allow for great flexibility in how entities move through a model. These routing types include
See The Logic of the Flow video tutorial on routing.
In the Lesson 1 – Call Center model there is only 1 routing type, the 3 percentage routes.
Note: The numbers 25% and 75% shown on the routes above are simply text labels used for clarity and have no affect on the actual percentages used.
These routes cause a specified percentage of the entities leaving a location to select that route when moving to the next location. With the exception of Create routes, no other routing type may be combined with percentage routes leaving a location. The sum of all percentage routes at a given location must equal 100%.
This is the time it takes the entity to move across the route to the new location. Any expression is valid.
The percentage of entities that should use this route. Only constants are allowed in this field.
This optional field allows you to rename an entity. If you have placed an icon in your model for this new entity, its name will appear in the drop down list and the name should be selected from that list rather than typed in. If no new icon exits, you may type a new name and the previous entity’s icon will continue to be used.
Unique statistics are kept for each entity named in the model. Thus, in the call center example, ProcessModel shows different statistics for Call and Difficult. When renaming an entity, all attributes and statistics are inherited from the previously named entity.
Since cycle time, the time an entity spends in the model, can only be accurately reported if the entity has left the model, stats are not collected until that time.
This route is used when you want to create additional entities to be processed. Often this route is used for parallel processing such as a customer placing an order which generates additional tasks such as data entry, credit approval, etc. In the example below the Truck entity would be considered the parent entity and the Pallet entity would be the child.
Create “after activity” or “before activity”
The new entity can be created before processing the activity from which originates, or after activity processing is complete.
This is the time it takes the entity to move across the route to the new location. Any expression is valid.
This is the number of entities to be created (0 – 9999). Any expression is valid.
Created Entity Name
The new entity must have a name given to it. If you have placed an icon in your model for this new entity, its name will appear in the drop down list and the name should be selected from that list rather than typed in. If no new icon exits, you may type a new name and the previous entity’s icon will continue to be used.
Attach routes are typically used in conjunction with Create routes. This route will attach one or more entities, known as child entities, to another single entity, known as a parent entity, which is waiting at the attach location. Once attached, the combined group of entities continues through the model as a single unit, with the parent entity’s graphic and attributes. Attributes of the child entity are masked by the parent and not accessible unless the entities are later detached.
It is best to either hold the attaching child entities in a storage, or make sure the child activity has an output queue of sufficient size to hold all waiting entities. That way if the parent and children somehow get out of sequence, the attach route won’t keep other waiting child entities from getting passed the entities first in line waiting for their parent.
This is the time it takes the entity to move across the route to the new location. Any expression is valid.
This indicates the number of child entities to attach to the parent entity. Any expression is valid.
The word All can be a useful attach quantity. Let’s talk about two examples.
1. You have created a variable number of child entities using a Create route. You then want to attach all the children which that parent created.
2. You have a varying number of test samples waiting to be picked up by a technician who does a collection run every 2 hours.
The child entity may be attached to any entity or to the entity that created it.
Install the model package Lesson 4 – Create and Attach model. Double click on the create route between Lab and Document Results.
A patient comes into the hospital for a lab test. After taking the test he (the parent entity) takes the 100% route to wait for his results at Release Patient. The test results are created and move to Document Results across the Create route, getting their new name of Results. The results then attach back to the entity that created it (Patient). After all, we don’t want the patient getting the wrong test results. Through the attach route, the patient receives his results and he is released.
As soon as the results have been documented, another create occurs, creating the Notification entity which goes to the doctor.
Double click the attach route between Document Results and Release Patient and review the settings for that route.
Conditional routes determine which route is selected based on a Boolean expression in the route’s Condition field.
Conditions can contain any Boolean expression and typically include at least one entity attribute. User defined variables may also be used. In the example above, the value of the attribute a_Priority is checked. If the value is 1, then the route is selected.
Conditional routes are tested in the order in which they were drawn. When the first true condition is found, that route is selected. The condition may be blank if you wish. But always make sure the route with a blank condition is the last one drawn since a blank condition is always true and no other routes will be tested.
This route is used to select an alternate location when the primary location doesn’t have capacity to accept the incoming entity. The route is drawn by clicking on the Connector Line Tool (from the Toolbox on the left edge of the modeling window), then drawing a line from the primary route to the alternate location.
A detach route caused entities that have been previously attached to the current entity to be detached and routed to the connected activity.
The Else route is used in conjunction with an Attach or Pickup route and is selected if the attach or pickup cannot be executed because the associated parent or child entity cannot be found.
The Ordered route causes entities to wait until and Order Signal is received. The order signal contains two pieces of information: the size of the order to be released, and the reorder level. When the contents of the activity or storage from where the signal originates falls below the reorder level specified, the order is placed, releasing the designated quantity of entities. An order signal is displayed as a dashed line and is connected on the arrow end to the ordered route.
The Pickup route functions in a similar way to the Attach route. However, the Pickup route causes the parent entity to wait for the child entity to arrive at the attaching location. Whereas the Attach route causes the child entities to wait. Also, the Pickup route only allows attaching a single child entity to the parent since no Quantity field is included.
The Renege route causes entities which have been waiting in an activity’s in put queue longer than an allotted time to leave the input queue without being processes at that activity and follow the renege route. The renege route will not pull an entity out of the activity itself. It only works from the input queue.
All Routes Sample
Install the model package Lesson 4 – All Routes model. Simulate it and view each of the routing types and how they work. The red routes are all 100% routes.
The Document entity is created by the Create route leaving the Process1 activity. Entities following the Renege route on the upper right side of the model are renamed to Item2. The attribute Att1, used in the Conditional routes, is assigned its value using action logic found on the Action tab of the Process11 activity.
Continue to Lesson 5: Attributes, Variables and Action Logic
Lesson 5: Attributes, Variables and Action Logic
Attributes are placeholders associated with an individual entity. Its value cannot be seen or changed by any other entity. An attribute describes an entity such as name, size, color, type, condition, etc. They can be either numeric values or character descriptors (single word descriptions). Attributes follow an entity as it moves through a model and can’t be changed globally by events that occur elsewhere in the model. All entities have 5 system defined attributes including Name, Cost, ID, VATime, and CycleStart. You may also create user-defined attributes. Attributes are often used to control action logic or to make routing decisions in the model. User-defined attributes are not displayed in the output reports. It is recommended that you begin all attribute names with “a_”. For example, a_Type, a_Color, a_Weight. That way they are easily recognized when reading your action logic.
Variables are placeholders for either numeric values or character descriptors (single word descriptions). They may be used to describe or track activities and states in the system such as the number of entities that have completed a particular activity, day of the week, hour of the day, etc. Variables are global in nature. That means any entity can view them or assigned a value in the Action tab of the properties dialog at any location. Variables are shown in the output reports and may be used to export modeling results to Excel. It is recommended that you begin all user-defined variable names with “v_”. For example, v_Count, v_Completed, v_BatchSize. That way they are easily recognized when reading your action logic.
ProcessModel allows you to design custom behavior in your model by writing simple but powerful logic statements. Action logic allows you to go beyond the normal property fields to determine how an entity is processed. Examples would include assigning values to attributes or variables, or performing a test using an If…Then statement.
Creating Attributes and Variables
You create an attribute by clicking the Insert menu and selecting Attributes & Variables. Then click New and enter the attribute name.
To create a variable click the Insert menu and selecting Attributes & Variables. Click the Global Variables tab, click New and enter the variable name.
Customizing with Action Logic
Let’s begin customizing our model behavior by adding a variable which will track the number of entities in our model at any given time.
Open the Lesson 1 – Call Center model. Create a variable by clicking the Insert menu and select Attributes & Variables. Click the Global Variables tab. Click New and enter the name v_Count in the Name field.
Next we need to write some action logic to use the v_Count variable.
Double click the arrival route (between the Call entity and the Take Call activity). Click the Action tab. In the window on the left, type Inc. That is a system statement which mean increment. Then click the Filter drop down list on the right and select the Variable option. This will display the name of all variables you have created using the Insert / Attributes & Variables option. With v_Count highlighted, click the Paste button.
Even though you can just type v_Count rather than selecting it from the filter list, selecting from the list eliminates typing errors, and can save time when you have defined many variables and attributes but have trouble remembering exactly how you spelled each one.
Inc v_Count is equivalent to writing v_Count = v_Count + 1, just shorter.
Now that we are increasing v_Count each time an entity enters the model, we need to decrease or decrement v_Count when each entity leaves.
Double click the 75% route leaving Take Call, then click the Action tab. Repeat the steps to create the action logic on the arrival route, except use Dec (for decrement) instead of Inc.
Since entities also leave the model after the Return Call activity is complete, we need to add an exit route and add the needed action logic.
To save a little typing time, click and drag your mouse over the Dec v_Count action logic. Then hold down the Ctrl key on your keyboard and press C to copy the text. Now add an exit route to the Return Call activity by hovering your mouse over the Return Call activity. Then drag your mouse to the right. Click the Action tab. Click your mouse in the Action window. Hold down the Ctrl key on your keyboard and press V to paste the action logic from the Windows clipboard.
To get a longer look at the process lets increase the simulation run length to 100 hours.
Click the Simulation menu and select Options. Change the Run Length to 100 hours.
Click Close. Now save your model as Lesson 5 – In-Process Count. Simulate the model and view the results. In order to create a Time Series plot of the counter variable, press the icon (Generate a time series plot) in the report toolbar.
In the Value window, double click the v_Count Value History item to add it to the Selected Values window on the right. Then click OK.
We created a variable to track the number of entities in the system at any given time. We then added action logic to increment that variable each time an entity entered the model, and used similar action logic to decrement the variable at each location where entities left the model. By using the Time Series Plot option in the output report, we now can see the trend of in-process entities. The increasing slope of the plot shows us that more entities are arriving in the system than it is able to process.
To learn about all the functions and statements allowed in ProcessModel, see Section 3.11 of the ProcessModel User’s Guide.
Let’s try adding a second Level 2 resource to see what happens to the plot.
Double click the Level 2 resource. In the Quantity field, enter 2. Save the model as Lesson 5 – In-Process Count 2. Then simulate the model and generate the time series plot as you did before.
Output Summary Report
A business decision is seldom made on a single factor such as in-process inventory. Consider some of the other things you need to evaluate before making a decision about the success of your change. Let’s look at another output report, the Output Summary.
Return to the modeling window by closing the Output Detail report. Then click in the ProcessModel toolbar, or click the View menu and select Output Summary. Click the Total Cost option on the left. Review each of the reports to see how the summary of
The Output Detail report (standard report shown following a simulation) uses an ABC costing method which only shows direct value added costs. To see the total cost of the simulation you must view the Output Summary report which includes all overhead costs such as unused resource costs. That total cost is then distributed across all entities leaving the process. Therefore, the average entity cost shown in the Output Detail report may be different than the cost shown in the Output Summary report.
1. Is it better from an in-process inventory perspective to have a 2 nd Level 2 resource?
2. What are the factors involved in deciding if it was cost effective to add a 2 nd resource?
3. Do you feel it is cost effective to add a 2 nd resource?
4. Are there better alternatives?
There are many functions and statements that can be used in ProcessModel to achieve a high degree of customization. Let’s just look at a couple of other examples.
Install the model package Lesson 5 – Route Distribution.
The Process2 activity utilizes 2 entity attributes in action logic to distinguish between the two entity types and route them accordingly. NAME is a system defined attribute given to all entities. In this model, a_Route is a user-defined attribute used on conjunction with the Conditional routes exiting Process2. All Item2 entities are to be routed to Process3 and are assigned an a_Route value of 1. The condition of the route leading to Process3 requires that a_Route must equal 1, therefore all Item2 entities will select that route. If the entity name is not Item2, a user-defined distribution is used to assign the a_Route value. 40% of all Item2’s are to be routed to Process4, and 60% to Process5.
Remember that a Percentage route must use a numeric constant in the Percent field. Distributions, attributes, and variables may not be used. However, if your routes are selected based on a percentage which may vary, Conditional routes can be used instead. The model above is only one example of using randomness in a percentage route selection.
Rework is a common part of just about every industry. This next example demonstrates the concept that each time an entity goes through rework, the odds of it needing additional rework diminishes.
Install the model package Lesson 5 – Rework Loop.
When a Card arrives, the a_LoopCount attribute is initialized to a value of 0. At Inspect, that attribute is incremented in order to track how many times the entity has been inspected. The 1 st time, there is a 50% chance it will require rework and the a_OK attribute will be set to 0. If the Card is ready to ship, a_OK is set to 1. The 2 nd time through the loop, 80% of the time it is ready for shipping. The 3 rd time, 90% of the time it is ok. Cards are always ok the 4 th time through.
If you need to execute multiple lines of action logic based on the result of an IF…THEN statement, you must enclose those statements within a BEGIN…END block. For example
If a_PatientType = Critical Then
Get Nurse And Doctor
5. In the Route Distribution model, if you changed the condition on the route leading to Process3 to “Name = Item2”, how would you change the action logic in Process2 to make the model give the same results as it does now?
6. Since user-defined attributes are not shown in the output report, how can you report on the number of times cards were reworked?
Continue to Lesson 6: Shifts
Lesson 6: Shifts
How They Work
By assigning a shift to a resource or activity, you create a fixed block of time when that resource or activity is available to work on entities. Shift files are created using a shift editor which can be called from the Shift tab of the Properties Dialog box for resources and activities. You can also create a default shift file by clicking the Simulation menu, selecting Options, then clicking the Files tab. Individual shift files assigned to a resource or activity will override a default shift file. Though you can assign a shift to either a resource or an activity or both, scheduling of activities is typically controlled by the shift of the resource working at that activity.
Once you assign a shift file in your model (or use Daily Pattern arrivals), you need to remember your simulation run length is now simulating a 24 hour clock. For example, a 40 hour run length no longer represents a week’s worth of working hours. 40 hours into a simulation now represents Tuesday at 4pm since all simulations start Monday morning at midnight.
By default, a resource on a shift file will work overtime if an entity is currently being worked on when the shift ends. If you want the resource to stop working and go off shift, you must check the option on the resource’s Shift tab to Interrupt current activity to go off shift or on break.
Let’s load our first model and begin working with shifts. Remember that the simulation run length is currently 40 hours. That represents five 8 hour days in straight work time. When we add shifts to the model we will need to adjust the simulation time to a 24 hour day.
Creating a Shift File
Open Lesson 1 – Call Center. Double click the Level 2 resource, then click the Shift tab. Open the shift editor by clicking the Create shift file button.
Create an 8 to 5 shift by clicking and dragging your mouse on the Mon line from 8am to 5pm. Don’t worry if you didn’t get it exactly right. Just click on the bar you drew, then adjust the starting and end times using the Begin Time and End Time adjustments at the top of the window.
Make sure the Monday shift is not selected by clicking the gray area around the time grid. Now define a lunch break from noon to 1pm. Click the Define Break icon in the tool bar. Then click and drag your mouse from noon to 1pm on the Monday shift you just created.
Click the 9 to 5 button next to the coffee cup icon to switch back to Define Shift mode. Click the Monday shift to select it. Click the Duplicate Day button to copy the Monday shift. Hold down the Shift key on your keyboard and click anywhere in the Tue timeline to paste the Monday shift. Repeat for Wed, Thu, and Fri.
Save your shift file as 8 to 5 and close the shift editor. Then click the Browse button and select the shift file.
Save your model as Lesson 6 – Shifts. Adjust the simulate run length to at least 120 hours (5pm on Friday). Assign a shift file to the Level 1 resource (either the same 8 to 5 shift or create a new one). Create a Daily Pattern arrival. Simulate your model.
1. Does your model have capacity to handle the calls they way have set them up?
2. Think of ways you could adjust your model to handle the load put on it.
Now is a good time to discuss model packages since you have now specified a path to your shift files. As we have mentioned already, your model is made up of several files, now including your shift file. Moving your model to a new location, either on your hard drive or sending it to someone else is easy because of the package creation function.
Click File and select Save.
Note the files listed. These are the files required to run your model. You could send your model by e-mail to another ProcessModel user. However, when they open the model, the shift file will be pointing to your hard drive location and they will get an error saying it can’t find the shift file.
By creating a package of your model and send the package file rather than the individual files, the other user would install the package rather than just opening the .igx file. By clicking File and selecting Install Package, the system will automatically remap the location of the shift file to the location selected by the package installer. This applies to simply moving your model to a new location on your own hard drive. When installing the package, a new shift file is copied and its location is remapped for you.
A model package is also a good way to backup your model for future retrieval. Just make sure you save the package with an appropriate name, uniquely identifying it. Helpful things to include in the name are the date, model builder, function of the model, etc.
Important! Be aware of one important issue when naming your files. With version 5.x and earlier, you cannot use periods in a model filename (e.g. My Model 1.5.3). You can use spaces, hyphens, or other delimiting characters, but not periods.
3. Model package are in a .zip format. Is it ok to use WinZip to extract model files rather than installing them from the File menu?
Continue to Lesson 7: A More Complex Call Center
Lesson 7: A More Complex Call Center
Our call center is quite simple. Though our next example is still fairly simple, let’s consider some additional issues such as the number of phones lines available, how long a customer is willing to wait on hold, alternate routings and additional action logic.
Another Call Center
Install the Lesson 7 – Call Center package.
Let’s look at what attributes and variables are being used in this model.
Click the Insert menu and select Attributes & Variables.
Complexity – A descriptive attribute describing how difficult the call is
Tolerance – How long a customer is willing to wait on hold before hanging up (reneging)
Start_Hold_Time – The simulation clock time when the customer was first put on hold
In_Process – The number of calls pending a resolution
On_Hold – The number of callers currently on hold
Abandons – The number of callers who hung up before being helped
Hold_Time – The hold time of each call
Research_Cycle_Time – The total amount of cycle time a Research call was in the system
1. How many trunk lines are there?
2. What is the purpose of the route coming out of the bottom of the Return Call activity?
3. How many TSR1 operators are there?
4. How many TSR2 operators are there?
5. Is TSR1 helping TSR2, or is TSR2 helping TSR1?
6. Where do the Renege calls go?
Action Logic Window
The action logic window is big and provides sufficient screen space to read and review the logic. Click on the action tab in the properties dialog, after selecting the arrival route to open the action logic window.
Double click the arrival route. Click the Action tab.
The number of in-process calls is incremented each time a new entity arrives. The call complexity is set using a user-defined distribution to one of three settings: easy, moderate, or difficult. The caller’s tolerance to stay on hold is set using a triangular distribution.
Double click the route between Take Call and Research Problem. Click the Action tab.
The Trunc_Line resource is freed since the caller has hung up and research will be starting in order to resolve the issue.
At any given location in your model, you can GET and/or FREE resources using connector lines or using action logic, but not both. For example, you may use connector lines at one activity and action logic at another activity. But you can’t use both methods at the same activity.
Double click the Research Problem activity. Click the Action tab.
All moderate calls will take a time determined by the Uniform distribution U(20,10). All other calls (difficult) will use a time assigned using the T(1.0,1.5,3.0) distribution. Remember the time on the General tab is 0 since the time is specified in the action logic.
7. With so many distributions in this model, how can you ensure that you have a good statistical representation of realistic results?
Continue to Lesson 8: Model Building Techniques
Lesson 8: Model Building Techniques
There is never only one right way to build a model. Most problems can be approached from many different angles and use different solutions. One of the benefits to simulation is that you can try several approaches to see which gives the best results before actually implementing the changes in your actual process. However, there are some basic steps you should take in order to have the greatest success with the least amount of rework and troubleshooting.
Some people try to build their entire model with all the detail they can right from the start. Even if you have a good understanding of how your process works, this approach can cause lots of headaches and rework. Even if your real process uses multiple entities, build your initial model with just one entity. It’s much easier to “watch” your simulation run and see trouble spots when there is only one entity to track. Don’t even add resources until you are confident that you flow is correct and entities routing to the proper locations. Don’t worry about times, capacities or quantities at first. Just get the flow working. Then start adding details.
Test as you go
You can save yourself a lot of grief by building a small section of your model, then testing it to make sure you are getting the expected results. If you build large sections, add functionality like resources and action logic, and then test when you’re finished building, you may find yourself with a troubleshooting nightmare. By testing small changes, you will always have a good idea where to look for problems.
Start adding times, capacities, arrival information, etc. If you need multiple entities in your model, start adding them before adding resources and action logic. Then add resources and action logic, testing as you go.
Remember, ProcessModel is an estimating tool that allows you to see trends and the impact of changes to a process. It isn’t intended to be a scheduling, order management, or MRP system. It’s important to make your model reflect reality as much as possible. But if your costs don’t match the real process penny for penny, that doesn’t mean the model is broken or can’t have significant impact on business decisions which can save millions of dollars.
Quick Model Building
To place a shape in the layout window simply left click on the shape you would like to use. You don’t need to drag the shape. Just move your mouse to the location in the layout window where you would like to place the shape and left click your mouse again.
Close any model you may have open. Click the green ball. Then click on the left side of your layout window to place the ball in your model.
By default, the green ball is an entity. But you may change it to another object type by clicking the Object type field drop down list.
If you would like to change the name of the object, just click it and start typing the new name. Whatever you type will replace the default name. When you’re done, either press the Esc key on your keyboard or click your mouse away from the graphic.
Notice there is a Name field on every Properties Dialog box. The text you type on the graphic will automatically be written to the Name field. The text displayed in the Name field will be name displayed in the output reports. If you would like to have different text on the layout than what shows in the output report, you can edit the Name field in the Properties Dialog box. In general though, it is best to edit object names by clicking on the graphic itself and typing a new name. You may also edit the text on the graphic by right clicking on it and selecting Edit Text or by pressing the F2 key on your keyboard.
Every object name field (also including attributes and variables) must be unique and must start with an alpha character.
You may customize the appearance of the graphics in your model by right clicking on them and selecting from the available options such as Format, Font, and Text Layout.
You can place shapes on your layout and then manually connect them by drawing each route. However, it is much faster if you use the automatic connection method.
With the green ball already on your layout, click the rectangle process shape in the shape palette. Then hover your mouse over the green ball in your layout. Note how the cursor changes to indicate you will be connecting shapes. Left click your mouse and drag to the right of the green ball.
The system knows that since you were connecting to an entity, the route should be a double headed arrival rather than a single headed routing line.
Left click your mouse away from the Process graphic just placed so the mouse cursor changes back to a pencil pointing to a box. Hover your mouse over Process, click and drag to the right again to place another Process step, automatically connected to the first.
Note how the shape names are automatically given unique names by adding a number to the end of the default name.
You may also draw exit routes, or routing lines from one object to another by simply hovering your mouse of the first object, then clicking and dragging to the desired location.
You may also place automatically connected resources in the same way.
Click the resource icon in the shape palette. Hover your mouse over the object where the resource is to work. Then click and drag away from the object.
You may also draw your own connector lines by hovering your mouse over the resource, then clicking and dragging to the desired location.
Continue to Case Study 1: Analysis
Case Study 1: Analysis
Finding the Problem
Although the model used in the case study wouldn’t be recommended for starting your own business, it is valuable for the purposes of demonstrating several things. We will look at activity and resource utilization, cycle time, and overall resource usage.
Install the model package called Case Study 1 – Analysis. Then double click the dashed resource connector between Gather Customer Information and the Tech 1 resource.
When you draw a resource connector, it defaults to a Get and Free connector. However, in this model, note that the connector between Tech 1 and the first activity is a Get connector. That means the resource is gotten at the first activity, but not released until later in the process. So he travels with the entity until a Free occurs after each oil change is complete.
Your 1st Assignment
The first thing we need to do is watch the simulation run to see what problems we can find before even looking at the output results. Then we will look at details of the output report in order to make a comparison of some simple changes we will be making to the model.
Simulate the model by clicking Simulation then select the Save and Simulate option.
The first thing you will notice is the second oil change activity is never used. Why is that when there are plenty of cars backing up waiting to be serviced? The reason is because of how the first resource (Tech 1) is being used. He takes the customer information for the first car, then goes with the car all the way through the process until the first oil change is complete. Then he is released and goes back to get the next customer’s information. By then, of course, there are no cars in the oil change bay. So when the 2 nd car comes in, it just goes to the first bay again because it’s empty. That means completely unutilized equipment and work space.
The second problem you will see is that the average cycle time (shown in the scoreboard) is 57.90 minutes for a 12 minute oil change. That means unhappy customers.
The third problem is that even though our last car arrived no later than 7pm, it doesn’t exit the model until close to 8pm. That means employees have to work overtime.
Now let’s look at the output report.
When asked if you want to see the results after the simulation, click No, on the ProcessModel main window click to launch the Output Report. Click on the Activities tab.
Note the Average Minutes Per Entry column. We see that customers waited (in the first input queue) to have their information taken for an average of 42.65 minutes.
Click on the Resources tab.
Our resource utilization is 45.52% for Tech 1, and 38.33% for Tech 2. So even though we have people waiting for an oil change, the resources are actually working less than half the day.
Click the Hot Spot Evaluator, with the Hot Spot Evaluator option selected, click the Chart tab.
This chart shows that approximately 80% of the cycle time for customers is spent waiting in the Gather Customer Information activity.
Your 2nd Assignment
That was a pretty dismal performance. Let’s see if we can make a simple change to the model to get some better results.
Close the output report and double click on the first resource connector again. Change the type to Get and Free. Then also change the two connectors going from Tech 1 to each of the Oil Change activities to Get and Free and simulate the model again.
As the simulation runs, note that both change bays are now being used, and the last car exits the process before 7:20pm.
View the output report and compare the results to the first simulation.
The average wait time in the first input queue has dropped from 42.65 minutes to just over 8.29. Plus the utilization has dropped on Tech 1.
Again, display the Hot Spot Evaluator’s Chart view.
The non-value added wait time in the first activity has dropped from 90% of the overall cycle time to less than 30%.
Wait time typically increases processing costs, increases production inventories, and lowers customer satisfaction. So reducing that non-value added time is typically a significant concern in process improvement projects. Low resource utilization in and of itself isn’t necessarily a good thing. But what this result is telling us is that the process is much more efficient than the first one was.
Continue to Case Study 2: Replications
Case Study 2: Replications
If a picture is worth a thousand words, how much is a dynamic, moving picture worth? Let’s find out. Rather than just talk about the theory behind the statistical reasons for replications, let’s watch some results in real time.
Install the model package called Case Study 2 – Replications.
This model uses a non-repeating periodic arrival with a quantity of 100 entities, 102 minutes of run length, a 50% route leading to Process2, 30% route leading to Process3, and a 20% route leading to Process4. Just for visual effect we rename the Item entity on the percentage routes.
This is a very simple model but it has a couple of new tools to make our “proof” a little easier to visualize.
We could just view the output report and do a simple calculation to determine if the number of entities entering each of the end processes matches the percentage on the routes leading to those activities. But with just a little extra work, the system can do all the work for us using variables and labels.
Double click the exit route leaving Process2. Click the Action tab, view the Action Logic window.
These action logic statements increment the variable v_TotalCount by value of 1 each time an entity uses this route in order to count the total number of entities leaving the model. The variable v_Count2 is also incremented, increasing the count of entities going through Process2. A calculation is then done for each of the 3 entities using the latest total count variable in order to accurately calculate the percentages of each entity type. The same action logic is repeated on each exit route, replacing Inc v_Count2 with the appropriate variable name.
Double click the red label titled Item2 Percentage.
The function of a label is to display the value of a variable on the screen during simulation. In this case, the variable selected from the Name drop down list is v_Pct2, which was calculated on the 50% route and shows the actual percentage of total entities entering the Process2 activity.
As the model simulates you will see that the percentage of entities crossing each percentage route varies because the system uses random functions to determine which of the percentage routes to select. For example, when the first entity arrives, it must choose which of the three routes to take. Regardless of which one it takes, the percentage break down will not be correct because one entity can’t be divided 50/30/20. As the second entity arrives, the same thing happens. But statistically it is impossible for the 50/30/20 breakdown to occur. A large enough sampling of entities must enter the model for those percentages to start to occur. The larger the sample of entities, the greater the chances for the breakdown to match the 50/30/20 percentages. But even with a large sample, randomness is still in effect. So the numbers will not be exact.
How can we minimize the effect of variation in the percentages? Replications. As you complete the simulation of this model you see the percentages are 52%, 25%, and 23%. That’s close to the expected results. But we should be able to do better.
Click the Simulation menu and select Options. Then change the Run Length to 1 day and Replications value to 30. Uncheck the Show Animation option and click Close.
When you run multiple replications, it can take quite a bit longer to run the simulation. Since we are just wanting to get the results and don’t need to watch the animation, let’s speed things up a bit.
Simulate the model, click No at the end of the simulation. Click the icon in the ProcessModel toolbar to view the output report. Click General Report to view the Averaged results.
Goto the Variables tab and to view the average variable values for v_Pct2, v_Pct3, and v_Pct4.
Note the percentages are now closer to the expected values, but still not quite there. Let’s get it closer.
Close the report. We will need a larger sample of entities. Increase the number of arrivals to 1000. Click Simulation and select Options. Then increase the Run length value to 1020 minutes and run the simulation again.
You will see the following in the Variables section of the output report.
Close the report. Click Simulation and select Options. Increase the arrival quantity to 10000. Then increase the Run length value to 10200 minutes and the Replications to 50. Run the simulation again and view the Variables section.
As you can see, the more replications and the larger the entity sample size, the closer the results get to the expected values. This is the statistical nature of variation you build into your models whether through percentage routes, distributions, arrival rates, etc.
The reason replications yield different results from each other is because of the starting random seed value. Each time you start a model with a single replication, the random functions start at the same point (starting seed). When you use replications, the starting seed for the next replication begins where the previous seed value left off. Therefore all subsequent random calculations have a new sequence.
Continue to Case Study 3: Froedtert Hospital Improves ICU Care
Case Study 3: Froedtert Hospital Improves ICU Care
Turning away Emergency Patients?
Froedtert Hospital, located in Milwaukee, Wisconsin, is the only ACS verified level 1 trauma center in southeastern Wisconsin. The hospital has almost 50,000 visits to the Emergency Department per year. Even though they have a capacity of nearly 450 beds, a staggering 12% of the time they were forced to reject patients requiring emergency care. Of course, this presented a critical problem for patients. But it also represented a significant loss of revenue as well as a black eye on the hospital’s reputation.
What the Model Told Them
A hospital staff member was given the assignment to analyze hospital processes in order to reduce the number of ambulance diversions away from Froedtert. A project was created which included the ICU, surgical capability and scheduling from both emergency arrivals (ambulances) and from elective surgeries. Using ProcessModel, it was determined that doctors had complete control over elective surgery scheduling without the insight of how the rest of the hospital was being affected by their decisions. It also showed that current patterns for elective surgery would stack up randomly on certain days, causing the ICU to fill in order to meet demand. On other days the ICU would be unaffected by elective surgeries. Because of the random loading of the ICU, they were sometimes unable to handle the demands of emergency patients needing ICU services. As a result, ambulances were turned away.
Through simulation, the hospital administrators and doctors were able to see the cause of the diversions. Experiments were conducted to identify an acceptable level of elective surgeries per day while still
accommodating the needs of emergency care. Rather than rely on best guess solutions, ProcessModel enabled Froedtert to use quantitative methods to discover the problem and suggest solutions. They arrived at a definitive number of elective surgeries that would still allow them to meet the emergency requirements of the ICU. Perhaps the most amazing thing learned through modeling their processes was that they could still perform the same number of elective surgeries by altering their scheduling, while being able to handle all the emergency cases needing help.
Benefits of Simulation
Doctors and administrators have implemented the solutions, resulting in millions of dollars of increased revenue for the hospital. The most important benefit though is that the hospital can now provide the level of health care needed by their patients, which in turn enhances public relations and the hospital’s reputation. These successes have lead to other projects being implemented in other areas such a reduction of length of stay for patients, optimizing staffing levels, reducing clinic patient wait times, optimizing lab procedures, etc.
Though building a comprehensive model of the complete process was required to gain a full understanding of the end to end impact of process factors, the key issue as far as scheduling was a relatively simple procedure. Load leveling was the key. Let’s look at the model representing the “before” arrival conditions.
Install the model package called Case Study 3 – Froedtert Before. Double click the red arrival route. Then click the Define Schedule button.
This scheduled arrival covers a period of 4 months. The action logic can be ignored since it will not be used in this case study. But it is used to define attributes of each patient.
Close the scheduled arrival and double click on the Surgical Intensive Care activity. Then select the Action tab.
The purpose of this action logic is to assign the variable v_SIC_Count the number of patients in the activity. A Time Series Plot of this variable will be shown when the output report is displayed.
The animation is turned of in order to display the output as quickly as possible. Begin the simulation by clicking the Simulation menu and selecting Save and Simulate. Then click Yes to see the results.
As shown above, the contents of the activity is at its maximum of 21 over 25% of the time. That means that “potentially” 25% of the time emergency patients would have to be turned away. Fortunately there were not always emergencies during those peak times. As noted earlier, the actual rejection rate was 12% which is still an alarming number.
Of course, you can’t control the number of emergency cases. But you can control the number and timing of elective surgeries. The following chart shows the number of elective surgeries scheduled on Mondays over a 4 month period.
The load leveling goal was to never have more than 4 scheduled procedures per day. The next chart shows the result of load leveling. On days where more that 4 surgeries were scheduled, those extra procedures were simply moved to other days.
The result of the load leveling was that they were able to maintain the same number of surgeries (elective and emergency) while reducing the number of turned away emergency cases.
Let’s see the results of the new schedule of arrivals found in the next model package.
Install the package file Case Study 3 – Froedtert After and simulate the model. Then view the results.