The Animations:
Queueing
An animation of a single server queue, e.g., the scanner at airport security. Individual, average, and predicted waiting time are graphed.
Little's Law
An animation of a room where people enter and leave. Average inventory, the product of average system time and average throughput, and predicted inventory are graphed.
News-vendor
An animation of the clasic news-vendor problem. Each period the total overage or the total underage cost is graphed. The average over time of the sum of overage and underage costs is also graphed.
Inventory
An animation of customers coming to a store and buying a good. Two rules for reordering goods can be applied: a reorder point level with a fixed reorder quantity, or a periodic reorder with the quantity based on order-up-to rule. On hand inventory, inventory position, and predicted average on hand inventory are graphed.
The Face Game:
An animation based on a simple 3 stage process that can be done in class with 4 people, drawing a simple face on a 3x5 index card. It involves the concepts of flowtime, throughput, inventory, quality, and Little's Law. I've found the physical demonstation quite useful in an early class. Students then make suggestions for improvments. The animation is useful to allow the class to see whether a suggested improvement affects the intended performance measure.
Economies of Scale in Queueing:
This animation allows one to compare two queueing systems, each with k servers. The first system has a separate queue for each server. The second system has a joint queue that handles all the servers. One can compare the two systems on measures of flow time and throughput.
Plans for further animations:
Batching Animations:
There are three distinct ones that involve producing batches of product on a series of machines that require both setup and unit processing times. The goal is to understand how batching affects throughput and flowtime. There is one where the machines are bottlenecks, one where the machines are not bottlenecks, and a third where the machines operate in parallel to do the same step.
The Funnel Game:
An animation that allows you to simulate a combination of Deming's red bead experiment and funnel experiment so everyone in the class can participate on their laptops
Other Ideas?
Do you have other ideas? Contact me and make your pitch. :)
Information for Instructors
1. What is TioX?
TioX (/taɪ ɑːks/) is a set of animations for demonstrating some of the main ideas in Operations Management. These include queueing, bottlenecks, Little's Law, the newsvendor problem, inventory management, economies of scale in queueing, and batching (the impact of batching decisions on flow time and throughput).
Each animation shows people and/or packages moving through a system and is designed as an aid to students' first exposure to these concepts. Let's take queueing as an example to start. Although one can observe people coming to a store or a bank and see that sometimes people wait to be served, one has no knowledge of or control over the rates of arrivals or the rates of service. The animation provides the student with the opportunity to observe a system knowing the arrival rate of customers and the service rate of the server and see how the system performs. Crucially, it is then possible to adjust these rates and the variability in these rates and observe how the system performance (waiting time for customers in this case) changes.
Many basic concepts in Operations Management involve understanding how sequences of events, such as a customers arriving at store, being served, and being checked out, will interact. Although many ideas are straightforward, such as the rate a system can handle customers is driven by the slowest stage of a process, it is helpful to actually see this a few times first.
These animations are designed to act as a bridge for the students, to allow them to see the phenomenon of a bottleneck of a system limiting throughput, variability causing a queue to form, or inventory in a store allowing customers to be served immediately.
These animations are not designed to replace the mathematics Operations Managers use to understand systems. They are not designed to be used to model real systems. There are plenty of sophisticated commercial simulation systems for modeling real systems. These animations are meant simply to be a bridge for the first time student. To understand inventory systems, traditionally one draws a graph of on-hand inventory over time to show customers buying product and delivery of orders from a supplier. One might say "Inventory is on the y-axis and time is on the x-axis." Yet, to some first time Operations' students the notion of customers arriving over time and drawing a graph of inventory going down to represent this may be a challenge. It was that idea, "Time Is On the X-axis" that led to the acronym for these simulations (TioX). We hope that watching the inventory animation will help students expeditiously understand the connection between the events of customers and orders arriving and the inventory curves we all draw.
2. Short teaching notes for each animation
Below is a set of short teaching notes you may use as a starting point for planning how to incorporate the animations into your teaching plan. Each is designed to take just a few minutes of class time and be used early on in the introduction of each of the topics.
Each of the plans below runs the animation for perhaps a minute or so in each of a set of scenarios. In each of the animations, you will see the scenarios on the right hand side of the screen typically labeled A, B, C.
Queueing
Students new to Operations Management are not at ease with rates (of arrival or of service) or with variability in rates. The most common misconception is that if "people are coming to a server at a rate that is less than the service rate then no queue should form." Thus, I start with Scenario A: no variability, where customers are arriving at a rate of 5/minute and being served at a rate of 6/minute with no variability in either the interarrival times or the service times. They see that no one waits and the graph shows zero wait for all customers as then enter service.
Next I switch to Scenario B: arrival variability, in which the CV of arrivals is raised to 1. The key point here is that the average arrival rate has not changed and is still less than the service rate, yet people are arriving in a more clumped fashion and so some of them wait for service.
Next I switch to Scenario C: arrival and service variability, so now the CV of service times is 1 as well. Explain what that means and then run it long enough to observe that waiting times are longer than in the previous scenario.
At this point the students should have a sense of what is going on in the animation and what the graph means. The number of people the server has processed is small so it seems reasonable to speed up time, so I run Scenario D: speed it up, for another minute.
I then weave into the story that our TSA agent has been working hard and needs a coffee break. As I start Scenario E: coffee break, I draw their attention to the statistic showing the number of people in queue, because the number of people waiting soon fills the screen and the rest are off screen to the left.
After probably less than a minute of real time, and the simulation operating at speed 5, roughly 100 people have queued, so when I switch to Scenario F: return to work, it takes some time for the queue to return to zero. I ask them, "Why does is it taking so long? Didn't we just say that the server is operating at a rate faster than the arrivals? Didn't we see some people waiting no time before in this situation?" I wait for the class to explain that it is the large queue that built up that must be worked down. Next I ask them to estimate how long it will take to deplete that queue.
Perhaps you end this segment suggesting that highly utilized systems can't afford much downtime without causing significant delays.
As described in more detail below, you can switch the scenarios using a "presentation remote" allowing you to roam the class as you discuss the different scenarios.
Little's Law
In the deterministic case in which the arrival rate and the service time (or time in system) has no variability then Little's Law is fairly clear. So, I start with this situation with Scenario A: no variability, and arrival rate of 1, service time is 6, so there are 1 * 6 = 6 people in the system at any one time on average. Mention to the students that the number on each person is the time they have spent in the room.
To make the example a bit more interesting I increase the arrival rate to 2 and the service time to 10. So, now average inventory I is 20 = 2 * 10. Here people will spend some of their time waiting at a particular spot in the room.
Next I add variability with Scenario C. This adds variability in the arrival rate as well as the service time. Even though some people will zip through the system and others wait much longer in the system, and the arrival pattern is variable the average inventory over time and the average throughput times the average stay in the room are both converging to 20. Next, I switch to Senario D: speed it up, to run the simulation faster so the students can see that there is convergence of these two average performance measures. The actual numbers tend to be below the predicted value because the system always starts empty.
News Vendor Problem
This animation shows a number of "days" in which the newsvendor orders a given number of parcels which are seen in the "store". A random number of customers come, one by one, to pick up the parcels. If there are parcels left over at the end of the day the parcels turn dark before disappearing, to visually indicate these units are waste, incurring a cost of overage. If there are too many customers then the unsatisfied customers turn "pale" as they leave the store emptyhanded, to visually indicate the underage costs being incurred. For each day both the underage and the overage costs are plotted. The blue line represents the average across the days of the two costs.
Although to us as instructors it is obvious that each day there is either an overage cost or an underage cost, I feel it is worthwhile pointing this out. Each day there is either a red dot or a green dot above the x-axis and the other dot is on the x-axis.
To someone not comfortable with variability the most common misconception is that setting the order quantity to the averge daily demand is the best choice. Thus I start with Scenario A: At the Start, which has the order quantity equal to the average daily demand.
After a few "days" of animation, students are getting bored watching the it so I move to Scenario B: Speed it up, so we can get more data on to the graph. I typically run it long enough so we feel we have a reasonable estimate of the average cost. The average cost is about 40. I then continue to let it run and ask them to suggest what we might do to improve (reduce) the average cost. Usually several students immediately suggest ordering more but none is quite sure how much more to order.
Scenario C: Increase Order Quantity, moves the order quantity from 20 to 30. It also Resets the animation so the graph starts empty and will not be contaminated by the early data points. So, make sure the class knows the average cost in Scenario B was about 40. With a higher order quantity, you should see an average cost of about 20. Now the question is how do we determine the optimal quantity.
The actual percentage of days that demand was met from inventory is shown above the graph. The expected percentage and the desired percentage of days is also shown. Thus, if you derive the optimal fractile for the newsvendor problem, you could return here as an empirical observation that setting the expected percentage to the desired percentage seems to minimize costs. If you are curious, for this animation the demand random variable with mean r and variability v is a uniform random variable with range [r(1-v),r(1+v)].
Inventory
The inventory simulation is really two simulations for the two ordering systems: ROP and Order-up-to. This animation is the source of the name I picked for these apps, TioX, time is on the x-axis. Although a plot of saw-tooth curve of inventory going up and down over time is familiar to all of us, I feel operations students have an easier time connecting the reality of customer purchases and store replenishments to the the sawtooth graph by watching the customers come and take away their parcels, and watching the truck coming with replenishment orders. The ROP simulation has a horizontal line showing that as inventory crosses this line an order is placed. The Order-up-to simulation has vertical lines showing which days inventory is reviewed and an order is placed.
Scenarios 1A,1B, 2A, 2B, and 2C are for the ROP model. The students should probably have a bit of understanding about the two costs of holding and setup/ordering before running 1A and 1B. Scenario 1A: small truck load, has less inventory and more frequent orders. Scenario 1B: large truck load, has more inventory on average and less frequent orders. The objective is merely to introduce the EOQ trade-off. Demand is deterministic for these two cases. The "predicted on-hand inventory" curve, should you decide to click this on, is for the determinisitic demand case.
Scenarios 2A and 2B show that one may have two trucks coming at the same time, thus introducing the notion of ordering based on inventory position rather than just on-hand inventory. Scenario 2C: Add variability, is for showing that once there is some demand variability some customers will be disappointed. I usually ask them what we should adjust to deal with this. Someone is usually quickly able to articulate that adjusting the order quantity, Q will not help, whereas adjusting the reorder point, ROP will. Then you can adjust this and the class can see that fewer customers are "lost."
I have used Scenarios 3A and 3B to introduce the Order-up-to Model, usually after I have introduced the safety stock decision for ROP. I have found the graphs, even in the essentially deterministic case, a useful prop for explaining that in the order-up-to model the period of "uncertainty" on which you should decide the order-up-to quantity is based on the period between orders, P, plus the lead time, L. Pausing the simulation at one ordering time, (note, space-bar on your keyboard is a play-pause toggle) and then talking about having to wait P+L for more inventory, and finally running the simulation for P+L time, helps make this period of "uncertainty" more clear.
The Face Game
If you ask a novice operations management student what it means if a process is 'fast' my experience suggests that half will say something about an item or job getting through the system quickly, i.e., low flow time. The other half will say that the process can produce a lot quickly, i.e., high throughput. The basics in operations management deals with the trade-offs between these two. For service systems we want systems that to allow jobs to be processed in a timely fashion, i.e., low flow time, but do not waste money on excess capacity. For inventory systems we want to keep inventory low, which is related to flow time by Little's Law, yet maintain throughput, i.e., few unsatisfied customers. So, it is useful early on to help students distinguish these two ideas: flow time and throughput, understand that low flow time and high throughput are both desireable, yet understand what parameters of a system affect which system measure.
I typically run the physical game in class. The initial scenario in the animation is typically how the game runs. The first person is pumping many cards into the system. The second person is the bottleneck and struggles to work the queue of work for him/her. The third person is idle. Part way through a special order for a pink card is requested and takes a great deal of time to get through the system because of all the inventory between person 1 and person 2. After the pink card enters the system, the first person process becomes faulty, yet by the time those faulty cards make it through the system, and are observed by quality control after step 3, there is a large amount of now wasted inventory.
After I run the physical game and we understand what the words flow time and throughput mean for this system, I ask the students to generate improvments. I am not explicit about which measure they should improve. I ask them for their change, put it into the animation, and then ask them which measure(s) they hope to improve. Then we run it and see how well it works.
The animation provides the ability to input the processing time for drawing each feature so you can use either what you think your students did or have them measure the steps in the physical run of the game. In taking the student suggestions you can assign any feature to any stage (1, 2, or 3) including eliminating a stage. You can assign two or three people to each stage. You can limit the inventory that can collect between stages. Finally you can flag (i.e. mark cards as pink) as they come onto the stage so that the flow time for these cards is more evident.
Economies of Scale in Queueing
The animation allows one to compare two queueing systems. The system on the left is the 'Separate' system in which each server has its own queue and customers pick a server at random and join its queue. The second system is the 'Joint' system in which all demand joins a single queue and customers go to the first available server. The animation allows you to compare the two systems on the measures of flow time and throughput. As is well known, if the servers are identical and both serve the same arrival process, the joint system does better on flow time. The throughput will be the same on average.
The first scenario (A) has a relatively low utilization (0.7), 2 servers, and no variability in the arrival or service process. First observe that the arrival process to both systems is identical. The customers are even color coded the same to make this point more obvious. Because the choice of queue to join for the separate system is random, this randomness is enough to see that the separate system has a higher average flow time. Because Scenario A is operating fairly slowly Scenario B just speeds up time. Scenario C increases the utilzation (to 0.95). This increases the arrival rate. You will probably see a further increase in the flow time for the separate system. Scenarios D add servers (from 2 to 4). This doubles the arrival rate because the utilzation and the service rate per server are set. You should see an increase in the average flow time for the separate system. Finally, Scenario E adds variability so the flow time for both systems increases but the separate system is still worse.
Why does the separate system perform worse. Well, I usually find after running a simple scenario for a few minutes a more astute student will point out that in the separate system a server can be idle and yet there is a queue at another server. You can then direct the class to see if they can also see this phenomenon. This phenomenon cannot happen in the joint system. Whenever a server in the joint system is idle the queue is empty. I have found that to observe this without wasting a great deal of class time requires running the animation "fast" but then the situation you want to observe (an idle server and another server with a queue in the separate system) disappears quickly. To aid the presentation, a extra button,notification_important, has been added. It is a toggle and once it is on the animation will pause in two situations: 1) whenever a separate server finishes a customer and becomes idle and another separate server has a queue, or 2) whenever a person joins a queue for a separate server (and does not immediatly start service) and another separate server is idle. Hitting play will cause the animation to continue to the next such event. Of course you can turn this toggle off at any time.
Note
These scenario collections are just suggestions and you are welcome to customize the scenarios in all the animations, to collections you find useful for your presentation. See below how to customize, save, and share scenarios.
3. Background and History:
In a 2006 article entitled "Web-based Simulations for Teaching Queueing, Little's Law, and Inventory Management," published in INFORMS Transactions on Education, Robert Shumsky and I introduced earlier versions of three of these simulations. The Flash and Shock-Wave versions of these at some point became unavailable and the link at the publisher no longer worked. Robert Shumsky and Chris Huston produced an updated Flash version of the animation for Queueing, and I and my sons produced a Java version for all three and several others.
Adobe announced that December 2020 is the End-of-Life for Flash. Java became problematic for use via a web browser much earlier. The Java version is still available and still runs fine on a laptop if you are willing to install the Jave Runtime System. Yet, the Java version was designed around a fixed screen size. It can appear small on a modern laptop, and thus small on the projector for class, and adjusting system settings to workaround this difficulty is awkward.
For these reasons among others, I am in the process of rewriting the animations in Javascript. About half are completed and on this site. The rest are in progress. They run in most modern browsers (Chrome, Safari, FireFox, Opera, and Edge, although Chrome is suggested).
The animations that have been reproduced are Queueing, Little's Law, News Vendor, Inventory (handling both the standard Reorder Point/Reorder Quantity model and the Periodic Ordering and Order-up-to model, the "Face Game," (an easy to run game for an early class to demonstrate the notions of flow time and throughput), and Economies of Scale (to demonstrate queueing economies of scale). Others will follow including, several that deal with batching issues (showing the implications of batching to flow time and throughput), and finally "The Funnel Game" which demonstrates W. Edward Deming's red bead and funnel experiment.
4. What if you have ideas for additions or extensions:
If you have other ideas for an animation that would introduce a basic Operations Management concept feel free to contact me. Perhaps we can design one together. Again my goal is to provide a bridge for first time students from what they see in the real world to the models we use in Operations Management. The animations that I have used here have been intentially simple, for example, people and trucks. Stick figures are not intended to look like real people and the trucks here don't move and act like real trucks but provide the bridge to aid a student's first understanding of these concepts. A (mathematical) model represents only a few salient aspects, ignoring much of the detail of the real situation. Likewise these animations crudely represent some salient features and ignore much of the detail. Thus, people queueing up in a straight line for a TSA agent is not realistic but may allow the student to imagine another situation such as requesting an appointment at a doctor's office and being placed in the scheduling system for the day of the appointment, as a queueing system.
5. Scenarios:
If you have used these animations/simulations for a bit you may recognise that to demonstrate some system behaviors in class it is useful to show the animation running for a first set of parameter settings and then switch to a second or third and compare the performance across the various scenarios. To facilitate this use in a class, a faculty member can predefine a set of scenarios for each animation.
Once a collection of scenarios is setup, say for a demonstration in class, then the instructor can switch between the scenarios. This switching can of course be done by clicking on the different ones in the list. Alternatively, the web page will move to the next scenario by pushing the downarrow or pagedown key. These were picked because presentation remotes often use these keyboard codes to move to the next slide in a presentation.
More details: Of course the uparrow and pageup keys work as well. Further, each scenario can be set to 1) pause the animation if it is playing, play the animation if it is paused, or "none" meaning leave it in the mode it was currently in: paused or playing. When a new scenario is picked it can force the animation to reset (as if the reset button were pushed). A reset causes the animation to begin again from an empty system, and clears the chart of any old data. Play/Pause (by spacebar) and Reset (by letter b) can be controlled from the keyboard or a presentation remote as well.
How to create your own sequence of scenarios:
The sequence of scenarios can be customized by each instructor. Hopefully the interface is largely self-explanitory. Click edit to edit. The animation will pause. Pick an existing scenario and then changing any of the parameters in the sliders will change that scenario. All changes are saved immediately. Double-clicking the name (or typing Return when one is selected) will allow you to change the name of the scenario. Scenarios are kept in alpha-numeric order, so use a numbering system to put your scenarios in the order you want for your presentation. Adding and deleting scenarios should be a familiar interface with add and remove icons at the bottom of the list. Although only a few will display, you are not limited to the number of scenarios you can create.
So where are they stored and how do I retrieve them?
The mechanism for storing the scenarios is called "Local Storage" for your browser. It is stored on your machine and for the browser (say Chrome) with which you created them. If you return to that machine and that browser then leading an animation will load the scenarios you saved previously. This mechanism is simple, and requires no passwords or cloud storage. Admittedly it does not make sharing them easy.
OK, so how do I share them with my colleague or my students?
If you need to share a collection of scenarios that you have created for one animation, you can create a URL that references the animation and contains all the scenarios encoded in the URL. Once you are ready, click the link icon. The URL will be copied to the clipboard so you can pass it to a colleague or post the URL in your learning managment system in an assignment for example. If your colleague wants to keep these scenarios as his/her own in his/her "Local Storage" then he/she needs only to load the URL you sent and then hit the edit icon and they will be saved (although they will replace any scenarios she/he currently has saved for that animation).
6. Speeds:
Each of the animations will run at 5 standard speeds: 1x, 2x, 5x, 10x, and 25x. At the slowest speed the people should look like they are walking. Yet, this is probably too slow to observe the animation because so little happens at this speed. So the apps provide four faster speeds. These speeds are simply labeled from 'slow' to 'fast'. At the fastest speed the movement of the people is largely a blur and even the movement of the trucks is perhaps too fast to watch but the results in the graph accumulate much faster. At the faster speeds a longer duration is plotted along the x-axis so more events can be observed.
Yet, even so this may seem too slow and too little data so a final speed labeled '∞' is provided. At '∞' speed the animation is no longer shown, a curtain is pulled over this area of the screen, and the x-axis is expanded further so one can observe more events. In the queuing animation the x-axis shows 200 units of time. If you hit 'play' now or you were playing when you hit '∞' speed the graph will fill with 200 units of time and the simulation will pause. If you hit 'play' again you will get another 200 units of time, from 200 to 400. You can continue this as long as you like. When you switch back to a slower speed, say 'slow', the graph will show only 10 units time, the curtain will raise so you can see the animation, and the animation will run again when you hit 'play.'
7. Accessibility
The colors I have used in the graphs may not seem the most obvious yet I have chosen them to make them more readable to people who have one of the three types of colorblindness.
The first page is a set of links now (it was originally a stack of buttons). A set of links is more useable by those who have difficulty using a mouse (or trackpad) or who prefer a keyboard. It also has the advantage that a Command-Click on a link will open a new tab (or window) making it easier to open several copies of a particular animation in several tabs. Of course if you have used the tab key and have focus on a particular link, say Queueing, then Command-Return will open copy of this animation in a new tab (or window).
8. You need something more?
Let me know what you think you need and if demand is there (there are others like you with a similar request) I will try to generate something to meet your needs. Of course if you find bugs please let me know. You can submit an issue to me directly or to GitHub
-Greg