EXAMPLE: A MULTIPRODUCT PRODUCTION/ INVENTORY SYSTEM

12.2 EXAMPLE: A MULTIPRODUCT PRODUCTION/ INVENTORY SYSTEM

This section extends the production/inventory system studied in Section 12.1 from

a single product to multiple ones. The new system again operates under the lost sales discipline.

12.2.1 P ROBLEM S TATEMENT

The extended system is depicted in Figure 12.15. Accordingly, the production faci- lity produces product types 1, 2, and 3, and these are supplied to three distinct incoming customer streams, denoted by types 1, 2, and 3, respectively. The production facility produces batches of products, switching from production of one product type to another, depending on inventory levels. However, products have priorities in production, with product 1 having the highest priority and product 3 the lowest.

Modeling Supply Chain Systems 277

Warehouse

Production Facility

Inventory 1

Customer Stream 1

Inventory 2

Customer Stream 2

Inventory 3

Customer Stream 3

Figure 12.15 A production/inventory model with three products.

A raw-material storage feeds the production process, and finished units are stored in the warehouse. Customers arrive at the warehouse with product demands, and if

a demand cannot be fully satisfied by inventory on hand, the unsatisfied portion represents lost sales. Each product has its own parameters as per Table 12.1. The following assumptions are made:

There is always sufficient raw material in storage, so the production process never starves. Processing of each product type is carried out in lots of five units, and finished lots are placed in the warehouse. Lot processing time is deterministic as per Table 12.1. The production process experiences random failures, which may occur only while the production facility is busy. Times between failures are exponentially distributed with a mean of 200 minutes, while repair times are normally distributed, with a mean of

70 minutes and a standard deviation of 30 minutes (recall that if a negative repair time is sampled, another sample is generated until a non-negative value is obtained).

The warehouse implements a separate (R, r) inventory control policy for each product type. Note that this is actually a convenient policy when a resource needs to

be shared among multiple types of products. For instance, when the production process becomes blocked, it may be assigned to another product. In our case, the production facility may switch back and forth between the two highest priority products a few times before it turns to product type 3. It should be pointed out that other production- switching policies may also be employed, such as switching after the current product unit is produced, rather than the current production run.

Assume that we want to simulate the system for 100,000 hours, and estimate the following statistics:

Table 12.1 Parameters of the production/inventory model with three product types

Product Target Reorder

Demand Demand Type

Initial

Processing

Level Point

Inventory

Time (hours)

Interarrival Quantity Time (hours)

1 100 50 75 1 Exp(16) U(4, 10) 2 200

0.6 Exp(8) U(10, 15) 3 300

0.3 Exp(4) U(20, 30)

278 Modeling Supply Chain Systems Production-facility utilization, by product

Production-facility downtime probability Average inventory level, by product Percentage of customers whose demand is not completely satisfied, by product Average lost demand quantity given that it is not completely satisfied, by product

12.2.2 A RENA M ODEL

Since the current model is an extension of the earlier single-product version, its structure is similar to that of Figure 12.2. Accordingly, it has two main segments: inventory management and demand management. The inventory management segment is modified to model multiple inventory types with shared storage. It again circulates a product entity to produce batches of each product type, monitor inventories, and stop production when necessary. The demand management segment is modified to generate multiple types of customers and their demands. It also models the drawing down on inventories, and initiates production orders for each product type as necessary. In the next section, we examine the model logic of each segment in some detail.

12.2.3 I NVENTORY M ANAGEMENT S EGMENT

Figure 12.16 depicts the modified inventory management segment that models the production facility. The Create module, called Raw Material, operates precisely as in the previous example: It creates a single product entity that controls the packaging operation (see Section 12.1.3) of all product types.

The circulating product entity is detained in the Hold module, called Shall We Produce?, until the following condition becomes true:

Production Order (1) + Production Order (2) + Production Order (3) > 0, as shown in the Condition field of the dialog box in Figure 12.17. Here, the quantities

Production Order(k), k ¼ 1, 2, 3, are vector elements that assume each a value of 1 or

0 representing the status of pending orders by product type. More specifically, Produc- tion Order(k) ¼ 1 indicates that a production order is present for product k, while Production Order(k) ¼ 0 indicates absence thereof. When the logical expression in the Condition field is true, this indicates that at least one product order is present.

When multiple product orders are present, it is necessary to decide which product type to produce next. To this end, the circulating product entity proceeds to the Search module, called Which Product to Switch to?, whose dialog box is displayed in Figure

12.18. An incoming entity into this module triggers a search. Using an index variable that ranges from the Starting Value field contents to the Ending Value field contents, the Search module can perform various searches over the specified range, guided by a logical condition specified in the Search Condition field.

Various types of search can be selected in the Type field. For example, the modeler can search a range of expressions for the first one with a prescribed value; it can also search an entity queue or entity batch for the first entity with a prescribed attribute

Modeling Supply Chain Systems 279

Figure 12.16 Arena model of the inventory management segment with three product types.

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

280 Modeling Supply Chain Systems

Figure 12.18 Dialog box of the Search module Which Product to Switch to?

value, or one that satisfies a prescribed condition. The search result is returned in the Arena variable J, as shown in the Search Condition field; a positive J value returns the result of a successful search, while a returned value of J ¼ 0 signals a failed search.

In our case, the search is for the first product k in the range {1, 2, 3}, which satisfies the condition Production Order(k) ¼¼ 1. Recall that in our model, product types have production priorities with lower-numbered products having higher priority. Conse- quently, the search for the highest-priority pending order starts with product type 1 and proceeds in ascending product type number.

Following search completion, the circulating product entity enters the Assign module, called Current Product, whose dialog box is displayed in Figure 12.19. Here, the circulating product entity notes which product type to switch production to. This is accomplished by setting the variable Current Item to variable J, which now contains the product type index returned from the just completed search. Note that it is appro- priate here for Current Item to be a variable, since only one entity circulates in the inventory management segment. If multiple entities were to roam this segment, then Current Item would have to be an attribute in order to maintain the integrity of its value.

Next, the circulating product entity proceeds to traverse a standard Seize-Delay- Release sequence of three modules (Seize Process, Packaging, and Release Process,

respectively), which model the production of the current product type, as indicated by the Current Item variable. While the Seize and Release modules are identical to their counterparts in Section 12.1, the Delay module implements here a product-dependent processing time (using the values from Table 12.1), as shown in Figure 12.20. The requisite processing times are stored in the vector Processing Time, indexed by product types.

When processing of the current batch is done, that batch should be placed in the warehouse. To this end, the circulating product entity proceeds to the Assign module, called Update Inventory, whose dialog box is shown in Figure 12.21. The inventory

Modeling Supply Chain Systems 281

Figure 12.19 Dialog box of the Assign module Current Product.

Figure 12.20 Dialog box of the Delay module Packaging.

level of each product is modeled by a vector, called Inventory, which is indexed by product type. In a similar vein, the batch size of each product type is stored in the vector Batch Size of the same dimension. To update the inventory level of the current product type, the corresponding inventory level is simply incremented by the just-produced batch size (see the assignment in the first line of the Assignments field).

Clicking the Edit. . .button in Figure 12.21 pops up the Assignments dialog box for that line, displayed in Figure 12.22. The corresponding Assignments expression is:

Inventory(Current Item) = Inventory(Current Item) + Batch Size(Current Item) where the Other option in the Type field indicates an assignment to a vector element.

Another style of assignment to vectors will be introduced in Section 12.2.4. At this point, the circulating product entity needs to check whether the target value of the current product type has been reached, so it proceeds to the Decide module, called

282 Modeling Supply Chain Systems

Figure 12.21 Dialog box of the Assign module Update Inventory.

Figure 12.22 Dialog box of the Assignments field from the Assign module Update Inventory.

Check Target, whose dialog box is displayed in Figure 12.23. Note that inventory target values for product types 1, 2, and 3 are stored in the vector elements Target Stock(k), k ¼ 1, 2, 3, respectively, as evidenced by the logical expression in the Value field. The circulating product entity checks if the target level of the current product type has been reached. If it has, the product entity would take the exit branch from the Check Target module to the Assign module, called Stop Production, whose dialog box is shown in Figure 12.24. Here, the circulating product entity stops the production of the current production type by executing the assignment

Production Order(current item) = 0 :

It then loops back to the Hold module Shall We Produce? (see Figure 12.16) to identify the next product type (if any) to which production is to be switched.

If, however, the target level of the current product type has not been reached, the circulating product entity would take the exit branch from the Check Target module to

Modeling Supply Chain Systems 283

Figure 12.23 Dialog box of the Decide module Check Target.

Figure 12.24 Dialog box of the Assign module Stop Production.

the Seize module Seize Process (see Figure 12.16) to process the next unit of the current product type.

Finally, recall that the production facility experiences failures only in the busy state. This constraint is specified in the Failure module dialog spreadsheet, as shown in Figure 12.25. Here, the Uptime in this State Only field is set to BUSY to indicate that the production facility does not “age,” unless it is busy producing products. In contrast, leaving this field blank would allow failures to occur any time, even when the production facility is idle, since “aging” takes place continually.

284 Modeling Supply Chain Systems

Figure 12.25 Dialog spreadsheet of the Failure module.

12.2.4 D EMAND M ANAGEMENT S EGMENT

Figure 12.26 depicts the modified demand management segment, which models demand arrivals at the inventory facility. In this model, the arrival processes of the three product types are modeled by a tier of three Create modules on the left side.

Figure 12.27 depicts the dialog box of the Create module, which generates customer entities that carry demand for the first product type. In a similar vein, the demand processes of the three product types are modeled by a tier of three Assign modules, where the demand-product type and quantity are assigned to an incoming customer entity. Figure 12.28 depicts the dialog box of the Assign module, which generates customer demand quantities for the first product type. In this module, a product type is assigned to the customer entity , s attribute Type, and then a demand quantity is sampled and assigned to the customer entity , s attribute Demand.

In addition, the model keeps track of the total number of arrivals of each customer type in a vector of counters, called Total Customers, by incrementing the corresponding counter. The vector Total Customers in the third assignment was declared and assigned in the corresponding Assignments module, whose dialog box is shown in Figure 12.29. Here, the Type field was set to the Variable Array (1D) option, although the modeler can alternatively use the Other option, as illustrated in Figure 12.22.

Next, the customer entity needs to check whether there is sufficient inventory in the warehouse to satisfy the requested quantity of the requisite product type. To this end, all customer entities proceed to the Decide module, called Check Inventory, whose dialog box is depicted in Figure 12.30.

Figure 12.26 Arena model of the demand management segment for the production/inventory system with three product types.

Modeling Supply Chain Systems 285

Figure 12.27 Dialog box of the Create module that generates type 1 customer entities.

Figure 12.28 Dialog box of the Assign module that generates demand quantities for type 1 customer entities.

The availability of sufficient product is expressed by the logical expression in the Value field, keeping in mind that the product type information is stored in the Type attribute of the customer entity. If there is sufficient inventory in stock, then the demand of the current customer entity can be satisfied. In this case, the customer entity takes the exit branch to the Assign module, called Take Away From Inventory, where the level of the corresponding inventory type is decremented by the demand quantity. Figure 12.31 displays the dialog box of this module (bottom) and its associated Assignments dialog box (top), which pops up when the Edit. . . button is clicked.

286 Modeling Supply Chain Systems

Figure 12.29 Dialog box of Assignments for declaring and assigning the Total Customers vector.

Figure 12.30 Dialog box of the Decide module Check Inventory.

The customer entity then enters the Decide module, called Restart Production?, to check whether the reorder level is subsequently down-crossed as shown in the logical expression in the dialog box of Figure 12.32. Note that the logical expression in the Value field compares two vector elements: the inventory level of the currently requested product type and the reorder level of the same product type. Two cases are then possible: (1) there was sufficient inventory on hand to satisfy the incoming demand, or (2) there was insufficient inventory on hand. We next describe the scenarios that result from each case.

Consider first the case of sufficient on-hand inventory. In this case, the customer entity proceeds to the Assign module, called Order Production, to initiate a production order, as shown in its dialog box (bottom) and associated Assignments module (top) in Figure 12.33. Note that production is initiated by simply assigning a value of 1 to the variable in vector element Production Order(Type), which indicates shortage of that product type. Consequently, this shortage will be attended to in due time by the

Modeling Supply Chain Systems 287

Figure 12.31 Dialog spreadsheets of the Assign module Take Away From Inventory (bottom) and its associated Assignments dialog box (top).

production facility that attends to production orders according to their priority structure. Note further that these variables may be set to 1 multiple times by customer entities entering this module during periods of shortage. While these assignments may be redundant, they are harmless in that the correctness of the model , s state is maintained; moreover, the model , s Arena logic is greatly simplified. Finally, having finished all its tasks in the model, the customer entity enters the dispose module, called Dispose, to be removed from the model.

Consider next the case of insufficient on-hand inventory, which results here in the customer demand being lost. The customer entity then takes the other exit branch from the Decide module Check Inventory to the Assign module Lost Customer, whose dialog box (bottom) and two associated Assignments modules (middle and top) are depicted in Figure 12.34. Three assignments are executed in the Assignments field of the Assign module. The first assignment (middle dialog box) increments by 1 the appropriate element of the vector Lost, in order to track the number of lost customers by the type of product requested. The second assignment (top dialog box) records the quantity lost in the Amount Lost attribute of the current customer entity. Finally, the

288 Modeling Supply Chain Systems

Figure 12.32 Dialog box of the Decide module Restart Production?.

Figure 12.33 Dialog box of the Assign module Order Production (bottom) and its associated Assignments dialog box (top).

Modeling Supply Chain Systems 289

Figure 12.34 Dialog boxes of the Assign module Lost Customer (bottom) and its two associated Assignments modules (middle and top).

third assignment sets the inventory level of this product to 0. Note carefully that the order of assignments is important.

Next, the customer entity proceeds to the Record module, called Tally Amount Lost, to tally the current lost amount in the set Lost Quantities, as shown in the dialog box of Figure 12.35. Finally, the customer entity enters the dispose module, called Dispose, to be removed from the model.

290 Modeling Supply Chain Systems

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

12.2.5 M ODEL I NPUT P ARAMETERS AND S TATISTICS

This section details the input parameters of the model and its statistics. Recall that all input parameters, including vector-valued ones, are declared in the Variable module from the Basic Process template.

Figure 12.36 displays the Variable dialog spreadsheet (bottom), as well as the initial values of the Inventory variable (top). The dimension of a variable is indicated by the number of rows indicated in the button labels under the Initial Values column in Figure

12.36. Accordingly, the label 0 rows specifies no initial values, the label 1 rows

Figure 12.36 Dialog spreadsheet of the Variable module (bottom) and the Initial Values dialog spreadsheet of variable Inventory (top).

Modeling Supply Chain Systems 291 specifies a single initial value for an ordinary (one-dimensional) variable (or a vector of

identical values), whereas a label of the form n rows (for n > 1) specifies a vector-valued variable with the indicated dimension. The Clear Option column specifies the simula- tion time (if any) to reset to the initial value(s) specified. Typically, the System option is selected to activate initialization only at the beginning of each replication. Statistics collection of one-dimensional variables is enabled by checking the corresponding boxes under the Report Statistics column. However, statistics of vector-valued variables can

be collected through the Statistic module spreadsheet, and will be illustrated next. Recall that we used the Set element to track lost demand by product type (1, 2, or 3) in the Record module called Tally Amount Lost. To this end, we declare a three- dimensional Set, called Lost Quantities, in the Set module spreadsheet (from the Basic Process template panel), as shown in Figure 12.37.

Finally, the specification of statistics collection can also be made in the Statistic module spreadsheet, as illustrated in Figure 12.38. Note that statistics collected on vector-valued variables are specified separately for each vector element. The Stock on Hand and Production Order statistics (by product type) are time averages, and as such of type

Figure 12.37 Dialog spreadsheet of the Set module (bottom) and the Members dialog spreadsheet for Tally set Amount Lost (top).

Figure 12.38 Dialog spreadsheet of the Statistic module for specifying statistics collection.

292 Modeling Supply Chain Systems Time-Persistent, while Process States statistics are of type Frequency. The Lost Per-

centage statistics are obtained after the simulation stops, and as such are of type Output. Finally, the Amounts Lost statistics are customer averages, and as such of type Tally.

12.2.6 S IMULATION R ESULTS

Figure 12.39 displays the results of a simulation run of length 100,000 hours. An inspection of the Frequencies report shows that the production facility is busy about 64% of the time, idle about 14% of the time, and down about 22% of the time.

Figure 12.39 Simulation results for the multiproduct production/inventory system.

Modeling Supply Chain Systems 293 Note that if the system were to “age” continually (so that failures could occur at

any state), then the downtime probability would increase and the idle-time probabi- lity would decrease. However, the busy-time probability would not change (within simulation noise), since the work load does not change.

The fraction of time that a product type was pending varies in accordance to the priority structure of product types: about 20% for type 1, 38% for type 2, and 63% for type 3. As expected, the lowest-priority product type received significantly less attention from the production facility.

The statistics of stock on hand by product type reveal that the average inventory levels of all product types are below their reorder points, which indicates that the production facility is having a hard time keeping up with demand. This is largely due to failures as evidenced by the high downtime probability. Further evidence for this phenomenon is furnished by the minimum stock level statistics, all of which hit 0, indicating episodes of stock-out. Stock-outs are quantified by the percentage of loss entries in the Output section and the amount lost by product type in the Other section of the report.

Similarly to the previous example, system performance may be improved in a number of ways. Again, enhanced maintenance of the production facility would decrease its downtime. Finally, to avoid excessive neglect of orders with low-priority product types, the number of production switches among product types could be restricted.