ORMSwareTM is a proprietary quantitative modeling and programming system developed by Reginald Joules at Ushar Enterprises Inc, Littleton, Colorado, USA
An Aerospace and Information Systems company was responding to a Request for Proposal from the Internal Revenue Service for an estimated $1 billion modernization plan. A key part of preparing the RFP involved ensuring that the tax returns processing capacity of five IRS regional centers were sufficient at each center to process each tax return within a 17-day time window mandated by Congress. However, overestimating the capacity could contribute to rendering the company's bid less competitive.
Since this daily processing capacity figure (number) was to drive the sizing of the entire architecture for meeting all of the information systems performance specifications, the company wanted to use a systematic approach to determine processing capacity required at each center. A rough-and-ready estimate was acceptable, but the company wanted something more than mere "educated guesses" people were making (and there were many guesses by "eyeballing" various plots of the tax returns arrival data).
Several assumptions were made to make it possible to develop a quick-and-dirty (yet high confidence) model for determining required processing capacity. They were:
Formulation of this problem is more easily understood through its ORMSware network diagram and supplemental data files. Click the links further below as desired to open these files in separate windows for reference while reading this document. The mathematical model expressed in the ORMSware diagram below can be viewed by clicking here.
This model can be implemented in a spreadsheet in a matter of minutes. However, the purpose here is strictly to show how to use the Goalseeking procedure in NMOD's Optimization Module to find minimum cost solution. It will be obvious to the reader that if the bidding company wanted to expand this model to consider variations in arrival patterns and service rates, consequences of expanding work week, introducing overtime, etc., spreadsheet would be a cumbersome environment to continue the modeling.
Following section describes the model:
If the Remaining Window capacity on a given day is greater than the arrivals on that day, it may be because the daily service capacity is too large. If the Remaining Window capacity on a given day is less than the arrivals on that day, it is because the daily service capacity is too small. If we calculate the quantity [Daily Violations = Daily Arrivals - Remaining window capacity] for every day, and track the maximum value of Daily Violations over the 26-week horizon, it will tell us whether a daily service capacity is too large or too small.
When this Maximum Daily Violations quantity is negative, it implies that the daily processing capacity is too large. When it is positive, it means that the daily capacity is too small. Therefore, our goal is to find that daily processing capacity which makes the Maximum Daily Violations as close to zero as possible. We can use our descriptive/what-if model to find the minimum capacity solution by using Goalseek from NMOD's Optimization Module to probe the what-if model in a systematic manner.
Execution of this model begins at the green Start node of the network (nInitializations). nInitializations sets up initial values of several variables, performs certain non-repetitive tasks, and launches the following two cycles in the network:
nInitializations: This node is used to do the typical things done in a Start node as you have already seen in previous examples. However, this node also has logic in its SignalTarget property. It sends a signal to aEnding inventory-->>|ReturnsInQueue. This signal is one of the AND triggers that serve to start the tax returns processing cycle described earlier. Whenever a node or arc has content in its SignalTarget property a ^ appears at the end of the top line of that network object's display.
nDayAndLoadWatcher: This node is self-explanatory, but a couple of clarifications may be helpful. strfNxtDayOfWeek is a string function provided by NMOD, which retrieves the next day of the week given current day of the week. It also increments current week number if the next day is a Sunday. WorkDay is a flag used for controlling execution of Inventory tracking and returns processing cycle depending on whether or not a day is a workday.
aDayAndLoadWatcher-->>|ReturnsInQueue: This arc executes only if current day is a workday. Arrival of an entity at nReturnsInQueue along this arc does not necessarily trigger that node, because this is an AND arc. How things work when an entity reaches nReturnsInQueue along this arc is further explained under the description of that node.
nEnding inventory: This node calculates returns remaining at the end of each day. In addition to continuing the processing cycle, n also sends execution control to nResults to write daily statistics to a results file.
aEnding inventory-->>|ReturnsInQueue: This arc sets the beginning inventory for next day equal to the ending inventory of current day. It has a duration property of one day, so an entity traveling on it does not reach its termination node nReturnsInQueue until the next day. Arrival of an entity at along this arc does not necessarily trigger that node, because this is an AND arc. How things work when an entity reaches nReturnsInQueue along this arc is further explained under the description of that node.
nReturnsInQueue: While this is a Normal node, it is also a convergence node, because there is at least one AND arc terminating at this node. Convergence nodes fire only when all AND conditions preceding the node are satisfied. In this case, this node will not fire until beginning inventory for a given day is calculated and delivered by aEnding inventory-->>|ReturnsInQueue and number of new arrivals for the day is delivered by nDayAndLoadWatcher along aDayAndLoadWatcher-->>|ReturnsInQueue. It then updates the number of returns waiting in queue to be processed.
aReturnsInQueue--->|Ending inventory: This arc stops inventory tracking and returns processing cycle as soon as the number of days processed reaches the limit set in nInitializations.
nRemWinCapForNewArr: This node calculates Remaining Window Capacity for processing new arrivals on any given day and sends control to nWindowMisses to calculate number of new arrivals that will miss the required processing window.
nResults: This node for writing daily statistics is also another convergence node in this model. To make sure that this node is fired only once every day and that the daily statistics it writes to the results file is all current, both arcs (a and a) leading into this node are defined to be AND arcs.
It may have appeared to you that some
of the nodes in this model have very little content. Looking at the sequence of
execution of some of those nodes it may seem that they could easily be combined
into one node. This is an important issue. What and how much to incorporate into
a node is totally up to the analyst. Factors that are often balanced by the
analyst in deciding
"how to model it" are clarity, expandability, scalability and
execution speed. These are nonfatal judgment factors, since it is possible to
change things around fairly easily in NMOD models as the scope of a problem
Click to go to summaries of all examples