EXAMPLE: A PRODUCTION/INVENTORY SYSTEM

12.1 EXAMPLE: A PRODUCTION/INVENTORY SYSTEM

This section presents a generic model of a production/inventory system (Altiok [1997]) consisting of a production facility that is subject to failure, which supplies a warehouse with one type of product. This generic model illustrates how an inventory control policy regulates the flow of product between production and inventory facilities.

12.1.1 P ROBLEM S TATEMENT

Consider a production/inventory system where the production process (e.g., pack- aging) is comprised of three stages:

1. Filling each container unit (e.g., bottles)

2. Sealing each unit

3. Placing labels on each unit For modeling purposes, the processing times of individual stages are combined into a

single-stage processing time. Figure 12.1 depicts a schematic diagram of the system. A raw-material storage source feeds the production process, and finished product units (units, for short) are stored in a warehouse. Customers arrive at the warehouse with product requests (demands), and if

a request cannot be fully satisfied by on-hand inventory, the unsatisfied portion represents lost sale. The following assumptions are made:

There is always sufficient raw material in storage, so the process never starves. Product processing is carried out in lots of five units, and finished lots are placed in the warehouse. Lot processing time is uniformly distributed between 10 and 20 minutes.

266 Modeling Supply Chain Systems

Process

Warehouse

Demand Raw

Material Lost

Customers Figure 12.1

A generic production/inventory system.

The production process experiences random failures that may occur at any point in time (see Chapter 11 for more details). Times between failures are iid exponentially distributed with a mean of 200 minutes, while repair times are iid normally distributed, with a mean of 90 minutes and a standard deviation of 45 minutes. The warehouse operations implement the (R, r) inventory control policy with target level R ¼ 500 units and reorder point r ¼ 150 units. The interarrival times between successive customers are iid uniformly distributed between 3 to 7 hours, and individual demand quantities are distributed uniformly be- tween 50 and 100 units. For programming simplicity, demand quantities are allowed to

be any real number in this range; however, for integer demand quantities one can use the Arena function ANINT(UNIF(50, 100) ). On customer arrival, the inventory is immediately checked. If there is sufficient stock on hand, that demand is promptly satisfied. Otherwise, the unsatisfied portion of the demand is lost. The initial inventory is 250, so the production process is initially idle.

We are interested in the following performance measures:

1. Production process utilization

2. Downtime probability of the production facility

3. Average inventory level at the warehouse

4. Percentage of customers whose demand is not completely satisfied

5. Average lost demand quantity, given that it is not completely satisfied The production/inventory problem described previously, though fairly elaborate, is

still a gross simplification of real-life supply-chain systems. More realistic problems have additional wrinkles, including multiple types of products, multiple production stages, production setups, startups, cleanups, and so on.

12.1.2 A RENA M ODEL

Having studied the problem statement, we now proceed to construct an Arena model of the system under study. Figure 12.2 depicts our Arena model of the production/ inventory system.

The model is composed of two segments: Inventory management segment. This segment keeps track of product unit entities.

Entity definitions can be inspected and edited in the spreadsheet view of the Entity module from the Basic Process template panel. In this part of the model, the packaging process takes a unit of raw material from its queue, processes it as a batch of five, and adds the finished lot to the warehouse inventory, represented by the variable Inventory. Thus, when a lot entity completes processing, Inventory is incremented by five, and the simulation logic branches to one of two outcomes as follows: (1) If Inventory

Modeling Supply Chain Systems 267

Figure 12.2 Arena model of the production/inventory system.

up-crosses the target level (variable Target Stock), then production stops until the reorder point (variable Reorder Point) is down-crossed again. (2) Processing of a new batch starts immediately when the reorder point is down-crossed (recall that we always have sufficient raw material, so the production process never starves by assumption). Demand management segment. This segment generates customers and their demands and adjusts variable Inventory upon customer arrival. It monitors the value of Inventory, and triggers resumption of suspended production when the reorder point is down- crossed. It also keeps track of lost demand (customers whose demand is not fully satisfied).

In addition, input and output data logic is interspersed in the two segments above. This logic consists of input/output modules (variables, resources, statistics, etc.) that set input variables, compute statistics, and generate summary reports.

In subsequent sections, we proceed to examine the Arena model logic of Figure 12.2 in some detail.

12.1.3 I NVENTORY M ANAGEMENT S EGMENT

We begin with the inventory management portion of the logic. The Create module, called Raw Material, generates product units for the packaging (batching) operation.

A Hold module, called somewhat whimsically Shall We Produce?, serves to control the start and stop of the operation by feeding product units into a sequence of Seize, Delay, and Release modules (called Seize Process, Packaging, and Release Process,

268 Modeling Supply Chain Systems respectively, in the Arena model), all drawn from the Advanced Process template panel.

The actual processing (packaging in our case) takes place at the Delay module, called Packaging Process, where the packaging time of a batch is specified as Unif(10, 20) minutes.

The Create module Raw Material was initialized by populating it with a single product entity (at time 0), and therefore the interarrival time is irrelevant. Furthermore, by setting the Max Arrivals field to 1, the Create module will deactivate itself thereafter. The product entity circulates in the model repeatedly, with each cycle representing a production cycle.

The circulating product entity then proceeds to the Hold module, called Shall We Produce?, to test if production is turned on. The state of production (Off ¼ 0 or On ¼ 1) is maintained in the variable Production, which is initially set to 0. Recall that the Hold module performs a gating function on an entity by scanning for the truth or falsity of

a logical condition, as shown in the Hold dialog box in Figure 12.3. If the condition (in our case, Production ¼ 1) is true, then the product entity proceeds to the next module. Otherwise, it waits in queue Shall We Produce?.Queue until the condition becomes true before being allowed to proceed. The circulating product entity then proceeds to queue Packaging Queue in the Seize Process module and seizes the server immediately (being the only one in contention for the Packaging Process resource).

Figure 12.4 depicts the dialog boxes of the Seize and Release modules, Seize Process and Release Process, which contain resource information. The Seize module has a queue called Packaging Queue, where product entities await their turn for one unit of resource Packaging Process to perform the packing operation at module Packaging. Once the resource becomes available, it is seized by the highest-ranking product (in this case, rank 1). While the current process is in progress, the Seize module bars any additional product entities from entering it. On service completion, the Release module (which never denies entry) releases one unit of resource Packaging Process, as indi- cated by the Release dialog box in Figure 12.4. Note that an entity may seize a number

Figure 12.3 Dialog box of the Hold module Shall We Produce?.

Modeling Supply Chain Systems 269

Figure 12.4 Dialog spreadsheets of the Seize module Seize Process (left) and Release module Release Process (right).

of resources (when available) simultaneously. Further, an entity may release a number of owned resources simultaneously.

A spreadsheet view of the Resource module with an entry for Packaging Process is shown at the bottom of Figure 12.5 with its Failures field (associating resources to failures) popped up (top). All failure/repair data (uptimes and downtimes) are specified in the Failure spreadsheet module (see Chapter 11), as illustrated in Figure 12.6.

The inventory level at the warehouse is maintained by the variable Inventory, initially set to 250. Whenever the circulating product entity (batch of five units) enters the Assign module, called Update Inventory, it adds a batch of five finished units (variable Batch Size) to the warehouse inventory by just incrementing Inventory by the batch size.

The circulating product entity then proceeds to the Decide module, called Check Target, whose dialog box is shown in Figure 12.7. Here, the circulating product entity tests whether the inventory target level has been up-crossed. The test can result in two outcomes:

Figure 12.5 Dialog spreadsheet of the Resource module showing resource Packaging Process (bottom) with its Failures dialog spreadsheet (top).

Figure 12.6 Dialog spreadsheet of the Failure module.

270 Modeling Supply Chain Systems

Figure 12.7 Dialog box of the Decide module Check Target.

If the inventory target level has been up-crossed, then the circulating product entity moves on to the following Assign module, called Stop Production, and sets Production ¼ 0 to signal that production is suspended. Otherwise, the circulating product entity does nothing.

Either way, the circulating product entity has completed its sojourn through the system and would normally be disposed of (at a Dispose module). However, since the Packaging module is never starved and no delay is incurred since its departure from the Packaging module, we can “recycle” the circulating product entity by always sending it back to the Packaging module to play the role of a new arrival. This modeling device is logically equivalent to disposing of a product entity and creating a new one. However, it is computationally more efficient, since it saves us this extra computational effort, so that the simulation will run faster. We recommend that model run optimiza- tions by means of circulating entities (or any other logically correct modeling device) should be routinely sought to speed up simulation runs. The emphasis here is on “logically correct” optimizations. Note carefully that if the packaging operation were allowed to starve, then our previous computational “shortcut” would be invalid, and we would have to dispose of and create new entities throughout the simulation run.

12.1.4 D EMAND M ANAGEMENT S EGMENT

In this section, we continue with the demand management segment of the logic. The source of customer demand at the warehouse is the Create module, called

Customer Arrives, whose dialog box is depicted in Figure 12.8. The arrival pattern of customers is specified to be random with interarrival time distribution Unif(3, 7). Each arrival is an entity of type Customer (customer entity) with its private set of attributes (e.g., a demand quantity attribute, called Demand). On arrival, a customer entity first enters the Assign module, called Customer Demand, where its Demand attribute is

Modeling Supply Chain Systems 271

Figure 12.8 Dialog box of the Create module Customer Arrives.

assigned a random value from the Unif(50, 100) distribution. The customer entity then proceeds to the Decide module called Check Inventory to test whether the warehouse has sufficient inventory on hand to satisfy its demand. The test can result in two outcomes:

1. If the value of variable Inventory is greater or equal to the value of attribute Demand, then the current demand can be satisfied and the customer entity takes the True exit to the Assign module, called Take Away From Inventory, where it decrements the inventory by the demand amount. It next proceeds to the Decide module, called Restart Production, to test whether the Reorder Level variable has just been down-crossed. If it has, the customer entity proceeds to the Assign module, called Production Start, to set Production ¼ 1, which would promptly release the circulating product entity currently detained in the Hold module Shall We Produce?, effectively resuming the production process. Either way, the customer entity proceeds to be disposed of at the Dispose module, called Dispose1.

2. If the value of variable Inventory is strictly smaller than the value of attribute Demand, then the current demand is either partially satisfied or not at all. Either

way, the customer entity proceeds to the Assign module, called Lost Customer, where it sets the Inventory variable to 0. It also updates the variable Lost, which keeps track of the number of customers to-date whose demand could not be fully satisfied (Lost ¼ Lost þ 1), and the attribute called Amount Lost, which keeps track of the demand lost by the current customer (Amount Lost ¼ Demand – Inventory). The customer entity next enters the Record module, called Tally Amount Lost, to tally the lost quantity per customer whose demand was not fully satisfied. Finally, the customer entity proceeds to be disposed of at module Dispose1.

The user-defined variables involved in the model can be set or inspected by clicking on the Variable module of the Basic Process template panel. This yields the spreadsheet view of the module, as exemplified in Figure 12.9.

272 Modeling Supply Chain Systems

Figure 12.9 Dialog spreadsheet of the Variable module.

12.1.5 S TATISTICS C OLLECTION

Figure 12.10 displays the dialog spreadsheet of the Statistic module for the production/ inventory model. It includes a Time-Persistent type statistic, called Stock on Hand, for the Inventory variable, and another called Production On, for the expression Produc- tion ¼ 1. The statistical outputs for Inventory consist of the average value, 95% confidence interval, and minimal and maximal values of the inventory level ever observed during the replication. The statistical output for Production ¼ 1 is the percentage of time this expression is true, that is, the probability that the packaging process is set to produce. (Keep in mind, however, that the production process may experience downtimes.) Recall that this method of time averaging expressions can be used to estimate any probability of interest, including joint probabilities. Statistics collection can also be affected by checking the requisite boxes under the Report Statistics column in the Variable module (see Figure 12.9).

Figure 12.10 also includes a Frequency type statistic, called Process States, which estimates the state probabilities of the packaging process, namely, the probabilities that the packaging process is busy or down (recall that, in fact, the packaging process is never idle).

The Output type statistic in Figure 12.10 is used to calculate the percentage of customers that experienced some lost demand. The corresponding Expression field there indicates that when the replication terminates, the variable Lost is divided by the variable Total Customers to yield the requisite percentage.

Figure 12.11 displays the dialog box of the Record module, called Tally Amount Lost. Whenever a customer entity enters this module, the expression (in this case, the variable) Amount Lost is evaluated and the resultant value is tallied. When the replica- tion terminates, the output report will contain a Tallies section summarizing the average

Figure 12.10 Dialog spreadsheet of the Statistic module.

Modeling Supply Chain Systems 273

Figure 12.11 Dialog box of the Record module Tally Lost Amount.

amount lost per customer. Note carefully that since we tally a loss only when it occurs, this average is conditional on the event that a customer actually experienced a loss. If we were to include in the tally a value of 0 (no loss) for every customer with a fully satisfied demand, then the resulting average would provide us with the unconditional average of lost demand per customer. Obviously, the conditional average loss must be larger than the unconditional average loss.

12.1.6 S IMULATION O UTPUT

Figure 12.12 displays reports of the results of a simulation run of length 1,000,000 minutes (slightly less than 2 years). An inspection of the results of Figure 12.12 is quite instructive vis-a-vis the per- formance of the production/inventory model.

The expression Amount Lost Per Customer in the Tally section indicates that the average lost demand per customer who experienced some loss was about 26 units. The Half Width column estimate the half-length of respective confidence intervals at the 95% confidence level. The Stock on Hand variable in the Time Persistent section shows that the inventory up- crossed occasionally its target level. However, this happened only rarely, since the Production variable in the Time Persistent section assumed the value On ¼ 1 about 99.72% of the time. Most of the time the inventory level was lower, averaging around 106 units—well below the reorder level, r ¼ 150. The Output statistic Lost Percentage in the Output section reveals that 22.3% of the customers had their demand either partially satisfied or not satisfied at all. Finally, the Frequencies section estimates the state probabilities (BUSY, FAILED, and IDLE) of the production process. These are, respectively, 68.95% (resource utilization), 30.82% (downtime probability), and 0.23% (idle probability). Note that the average uptime and the average downtime are very close to their theoretical values (in this case, the downtime probability is equal to the ratio of expected downtime to expected cycle length).

274 Modeling Supply Chain Systems

Figure 12.12 Simulation results for the production/inventory model.

Much more information can be gleaned from the statistical output of Figure 12.12, but these items will not be pursued further (we encourage you to complete the analysis of the simulation results).

12.1.7 E XPERIMENTATION AND A NALYSIS

In this section, we will experiment with selected model parameters, so as to improve the customer service level of fill rate (probability that the demand of an arriving customer is fully satisfied). Clearly, the fill rate is quite low. Our performance metric of interest is the complementary probability of partially or fully unsatisfied demands. Figure 12.12 estimates this probability as 22.3% (the value of Lost Percentage in the Output section). How can we modify the system to decrease this probability to an “acceptable” level? In inventory-oriented systems such as the one under consideration, the only way to increase the fill rate is to increase the level of inventory on hand. In our case, we may attempt to achieve this goal in two ways.

Modeling Supply Chain Systems 275 The first way of increasing the fill rate is to modify the original production/

inventory system by investing more in maintenance activities. This will reduce downtimes and make the process more available for production. Figure 12.13 displays the estimated performance changes in the modified production/inventory model when the average repair time is reduced to 70 minutes with a standard deviation of

30 minutes. The reduction in repair time in Figure 12.13 represents an improvement of about 16% in maintenance activities, as compared with the downtime probabilities in Figure 12.12. The resulting reduction in the percentage of partially or fully unsat- isfied demands has dropped significantly from 22.3% to 12.14%. This reduction represents a more than 45% improvement in the fill rate.

The second way of increasing the fill rate is to modify the original production/ inventory system by increasing the reorder level parameter. The inventory level would then hit the reorder level sooner and production would resume earlier, thereby dec- reasing the chance of an inventory shortfall. Figure 12.14 displays the estimated per- formance changes in the modified production/inventory model when the reorder level parameter is doubled.

Figure 12.13 Simulation results for the production/inventory model with reduced downtimes.

276 Modeling Supply Chain Systems

Figure 12.14 Simulation results for the production/inventory model with doubled reorder level.

However, the second way of increasing the fill rate does not work well for our system, because the inventory level was below the reorder level most of the time, and consequently, the production process was busy most of the time anyway. The per- centage of unsatisfied customers is marginally improved from 22.3% to about 21.98%, but we would like to do better. This analysis leads us to conclude that a significant improvement in the fill rate can be achieved only by improving the production process, rather than by modifying our inventory replenishment policy.