~.. HEWLETT~~ PACKARD

Formulation of the Order-To-Ship ProcessSimulation Model

M. Shahid MujtabaInstruments and Photonics LaboratoryHPL-92-135December, 1992

modeling,simulation,Order-to-Ship cycle,systems modeling,systems simulation,systems, enterprisemodeling

The Order-To-Ship (OTS) process consists ofactivities between the time orders are receivedand products are shipped. This documentprovides a problem definition and description ofthe OTS process for an HP factory. A descriptionof a computer model and the status of the model'simplementation is also included. Additionally, weprovide a qualitative description of ourunderstanding of and approach to the OTSprocess. The paper also acts as a referencedocument for future summaries. We introduce theconcept of the general OTS abstraction and showits application as a common component in therepresentation of the entities and activities we arestudying. With this model we expect to examineissues such as how to increase responsiveness tocustomer orders while reducing levels of FinishedGoods Inventory (FGI).

Previously published as HPL-90-162, with security classification 'Internal Use Only'.

© Copyright Hewlett-Packard Company 1992

Internal Accession Date Only

Contents

1 INTRODUCTION 1

1.1 PURPOSE AND ORGANIZATION OF DOCUMENT. . . . . . . . . . . . . . . .. 1

1.2 PROBLEM STATEMENT 1

1.3 DEFINITIONS OF TERMS AND CONVENTIONS. . . . . . . . . . . . . . . . .. 2

1.4 OUR APPROACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4

2 GENERAL MODEL DESCRIPTION 5

2.1 PRELIMINARY MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5

2.2 AUGMENTED MODEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5

2.3 FORMAT OF DETAILED DESCRIPTION OF MODEL 7

2.3.1 PHYSICAL REALITY 8

2.3.2 MODEL ABSTRACTION. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

2.3.3 CURRENT IMPLEMENTATION . . . . . . . . . . . . .. 10

2.3.4 FUTURE IMPLEMENTATION 10

3 Detailed Model- Part I: SELL and DISTRIBUTE Environment 10

3.1 CUSTOMERS 10

3.2 VENDORS 11

3.3 CARRIERS......................................... 11

3.4 MARKETING 12

4 Detailed Model - Part II: PASSIVE ENTITIES 13

4.1 PRODUCT INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13

4.2 PARTS 14

4.3 ORDERS OF FINISHED PRODUCTS 15

4.3.1 ORDERS FROM END USERS OR NON-HP ENTITIES . . . . . . . . . .. 15

4.3.2 DC STOCK FILL FROM DIVISION 16

4.4 ORDER FORECASTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17

5 Detailed Model - Part III: SELL and DISTRIBUTE Block Components 18

5.1 SELL-PRODUCTS..................................... 18

5.2 DISTRIBUTION CENTERS .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19

6 Detailed Model - Part IV: FACTORY ENTITY 19

6.1 PROCESS-ORDERS.................................... 20

6.2 MANAGE-FORECASTS 20

6.3 PLAN PRODUCTION 21

6.4 PLAN-MATERIAL-REQUIREMENTS 22

6.5 PROCURE-PARTS 23

6.6 STORE-PARTS....................................... 24

6.7 PRODUCE-PRODUCTS 25

6.8 FILL-SHIP ORDERS 26

7 DISCUSSIONS 27

7.1 ONE MODEL - MULTIPLE VIEWS . . . . . . . . . . . . . . . . . . . . . . . . .. 27

7.2 MEASURES OF PERFORMANCE 28

7.3 OTS ABSTRACTION AND MODEL EXPANSION . . . . . . . . . . . . . . . . .. 28

7.4 FLOW OF CASH 28

8 CONCLUSION

9 ACKNOWLEDGEMENTS

11

29

29

1 INTRODUCTION

1.1 PURPOSE AND ORGANIZATION OF DOCUMENT

The Order to Ship (OTS) process in a Hewlett-Packard (HP) factory includes the activities thatoccur between the receipt of orders from and shipment of products to customers. This documentdescribes our efforts in studying the activities and entities of the OTS process, the model we derived,and the state of our current implementation.

While information was derived from different sources in the company, the bulk of our informationwas derived from one HP factory (HPFACT) with respect to one product, HPPROD. Therefore,this document is influenced strongly by activities for that product at that factory.

This section describes the background of the OTS process and related problems. Section 2 describesthe general model for the OTS process. Sections 3 through 6 describe components of the model ingreater detail. Section 7 provides discussions on the work to date.

1.2 PROBLEM STATEMENT

The factory is a complex system made up of many interacting components. Even when precisemathematical formulas or solutions exist for particular problems, their application may be in­tractible unless the approximations and assumptions used reduce the system to extreme simplicity.Furthermore, solutions derived from the study of a deterministic system may be inappropriate whenapplied to the stochastic nature of the real world.

One way to study stochastic behavior of systems is via discrete event simulation using randomnumbers to characterize the nature of the real system. Until recently, the tools for discrete eventsimulation were generally simulation software and languages based on FORTRAN. The results,long lists of numbers printed on reams of computer paper, required substantial interpretation effortby an analyst before they could be used by decision makers.

The advent of personal computers and workstations, interactive computation, improved graphicaluser interfaces, better programming environments, and more powerful programming concepts hassimplified both the implementation of the simulation and the presentation of the results. Thesesimplifications have propagated the use of discrete event simulation in situations in which it wouldnever have been considered in the past, because they allow more decision makers and designers touse the tools directly without the help of specially trained analysts.

During the past few years, isolated activities on the production line have been simulated on anindividual basis. Most simulations used mathematical models to address narrowly focused problemsof the production line specific to the particular facility under study, and large portions of themodeling effort was duplicated at each site. In our research, we decided to address the moregeneral problem of representing the whole factory and the interactions between its subsystems.We felt that the systems approach could help us build an environment in which we could capture,integrate and update the knowledge and insights of experts from different areas of the factory. Withthe creation of this environment, we felt that previously unanticipated questions could be answered

1

with relatively little incremental effort.

The accepted wisdom and the mainstream of conventional thinking in modeling and simulationrequires full knowledge and understanding of the system and clearly defined questions before themodel is built. Models are tailored to answer specific questions, and cannot be used easily toanswer new questions posed after the model has been built. In the past, these limitations weredue partly to the technology of developing simulations on a mainframe, and using batch processingwith minimal graphics. The limitations were acceptable due to the slower pace of change in thefactory.

We realize that our approach of building the general model of a factory requires the deploymentof substantial resources in a direction which appears counter to mainstream conventional thinking.However, we feel that technological advances in the areas of knowledge representation and objectoriented programming give us the tools to challenge the conventional approach. Our goal is tocreate a general approach to respond quickly to rapidly changing situations while bringing to bearthe multiple viewpoints of the different parts of the organization. The expected payoff of thegeneral approach is reduced duplication of effort each time a similar problem needs to be solved ata different factory or entity.

The assumption in the past was that production took up much of the lead time for delivery ofa product. Consequently, production has been the focus of much study and experimentation.However, just-in-time (JIT) techniques and better information systems have led to the situationwhere the bulk of the lead time for order fullfilment is not attributable to activities on the productionfloor.

The area of discrete event simulation of a factory model could provide insights in running thefactory, and identify key variables and cause and effect relationships in the system. An abstractrepresentation of the factory may be studied under different assumptions without experimentingwith and disrupting the factory itself. Simulation of the factory can be used for at least two differentpurposes - the study of existing operations and their improvements in factories, and the design andstudy of future factories.

1.3 DEFINITIONS OF TERMS AND CONVENTIONS

We will first define some terms and conventions that are used in the rest of this document. Wherea term is first introduced, it is shown in italics.

We define a factory as an entity which interacts with customers, vendors, and the corporate officefor the purpose of adding value to its inputs in order to generate outputs which are worth morethan the sum of the inputs and the resources consumed. Vendors provide needed material to thefactory, customers need and purchase production of the factory, and the corporate office coordinatesthe activities of multiple factories. Within the factory itself we include Manufacturing, Market­ing, Research and Development, Material Procurement, Shipping, Order Processing, Personnel,Accounting and other activities associated with an organization whose purpose is to make a profit.This definition of the factory encompasses what has traditionally been a division, and is broadenough to include a factory that crosses state and national boundaries. It also permits customersand suppliers to be treated as special cases of factories.

2

Reality is the physical world. A model is an abstracted representation of some portion of the physicalworld. It is made up of components which represent the aspects of reality that are of interest tous. The model includes within itself all information necessary to define its behavior. We need todraw the distinction between the model and the the data or external inputs acting upon it. Thedistinction between data and model is important since they represent the external and internalbehavior respectively of what we are studying. By keeping the data the same and changing themodel, we can study how internal behavior affects the outputs. By keeping the model the same andchanging the input data, we can see how the model responds to different environmental conditions.A simulation is the dynamic behavior of the model over time; the information within the modelinfluences and defines this behavior.

An OTS Entity is an entity which handles physical objects and which has some or all of the followingcharacteristics:

(a) it generates orders for physical objects and sends them to other OTS Entities(b) it sends physical objects to other OTS Entities(c) it receives orders from other OTS Entities(d) it accepts physical objects from other OTS Entities(e) it accumulates orders and physical objects within itself and reports on their values (inunits or dollar values) when requested(f) it provides or receives money in exchange for physical objects(g) it applies some transformation between input objects and output objects.

An OTS Abstraction is a conceptual abstraction of an OTS Entity.

At the time the model was being developed, movement of physical objects and information wasunder primary consideration. We did not explicitly model the movement of money in the modelbecause this was not uppermost in the mind of the people we were interviewing. We will placegreater emphasis on the movement of money in the future if feedback from readers suggests thatthis would be valuable. For the moment we treat money as an alternate measure of FGI and rawmaterial inventories.

A planned quantity is a computed or estimated value of some measure over a period of time orat a future point in time. A forecast or schedule is a sequence or list of planned quantities oversuccessive periods or points in time in the future.

The model will be represented diagrammatically and the notation used in the diagrams followsconventions similar to IDEF-01 . Circles are used in a context or environment diagram and showthe external relationships of an entity or function with respect to other entities or functions. Rect­angular blocks are used to represent the internal relationships between the sub functions of theentity or function. While a strong case could be made for representing sub functions as circles, fordiagrammatic consistency, circles and blocks are never used in the same diagram.

Dotted and heavy lines going into the left hand side of a block represent respectively informationand material that enter the block. Solid lines going into the top of a block represent commands

lIDEF-O is a hierarchical process modeling methodology. It describes, using a static graphical representation, thefunctional relationships of a system.

3

which require action from the block''. Solid lines, dotted lines, and heavy lines from the right handside of a block represent commands, information, and material (physical objects) respectively thatare generated and come out of the blo~k. One shortcoming of IDEF-O is that there is no provisionfor describing timing information. .

We shall adopt the following convention for textual description. Unless stated otherwise or obviousfrom the context of discussion, upper case letters (e.g. SELL PRODUCTS) will refer to the blocksin the figures representing the model. Words with upper case first letters (e.g. Orders) will referto the representation of physical objects or information flowing between blocks. Lower case letterswill be used to refer to the actual physical objects, functions or processes.

1.4 OUR APPROACH

After visiting different HP divisions and talking to people in different functions we developed ourpreliminary model of the OTS process using IDEF-O notation.

We implemented our preliminary model in KnowledgeCraft (KC? and in SLAM II4 • While SLAMII was faster during execution of the simulation, representing our problem and making changes wasmore convenient using KC. As a result, we continued our activities using KC for the model devel­opment and simulation, and an HP Series 9000 Model 300 computer under the HP-UX operatingsystem using the Xll Windows System for graphical display of data.

After developing our preliminary model, we talked in greater detail to some HP manufacturingdivisions. In early 1989, one HP Division (HPFACT) agreed to provide us with the insight anddata from a real HP factory. Over a period of several months, three of uss visited HPFACTperiodically. During each two-day visit, we talked to the experts representing the various functionsin the preliminary OTS model.

There is one physical factory, but the people who perform different functions hold different viewsof it. They abstract out and focus on facts important to maximizing what their success wasmeasured on, possibly ignoring relevant details which might be important to someone else. Whilewe had expected this, the impact of improving personal measures of success was brought to ourattention rather forcefully. We found that ignoring apparently irrelevant details sometimes resultedin different parts of the organization working at cross or even opposing purposes even though theyall were working towards the same high-level end goal of making a profit for the division.

We learned that some assumptions in our preliminary model of the factory required re-examination,and that the model itself required augmentation. In addition, the environment in which the factoryoperated affected the behavior and needed to be considered. However, the size ofthe project groupprecluded gathering more comprehensive information from entities outside HPFACT 6.

2There are two variations on these lines. (1) If the line ends with a single arrow at the top of the block, no responseis required by the receiver in addition to the action. (2) If the line ends with a double arrow at the top of the block,the block is required to provide a response to the sender, and the response is indicated by the single arrow at thesender end of the line.

3KnowledgeCraft is a software product of Carnegie Group, Inc.4SLAM II is a widely used general purpose simulation software product of Pritsker Companies.5 members of the Modeling and Simulation Project - Bob Ritter, Bob Joy, and Shahid Mujtaba6In this situation, we made working assumptions to enable us to recognize and remember that there were interac-

4

The OTS model represents a portion of the factory in a computer manipulable form; differentpeople using the OTS model are interested in solving different problems, and need to consider thedetails relevant to them. For example, material procurement is interested in how much it mightcost to shorten lead time for a part. Stores are interested in how to predict and reduce storagerequirements. Production planning is interested in fulfilling forecasted demand with minimum FGIand Work in Process (WIP).

The OTS model can raise the awareness of the impact of the actions and interests of one entity onanother. In addition to studying the problem of reducing FGI while improving delivery performance,other possible questions and problems for study using the OTS model include the costs of forecastinaccuracies, activities associated with order processing, dealing with long lead time parts, andtrading off the cost of greater generality in a product against the reduction in unit cost due togreater volume of fewer options7 .

2 GENERAL MODEL DESCRIPTION

2.1 PRELIMINARY MODEL

Figure 1 shows a breakdown of the Preliminary OTS Block diagram with eight functional blockslisted in the general chronological order in which they interact with orders. This figure demonstratesthe original formulation and conceptualization of our ideas on which the subsequent model morespecific to HPFACT was built.

Some simplifying assumptions were that orders did not require corrections or clarifications, andcould be shipped immediately when product units were available. Orders were never canceled,parts never ran short, and were always delivered on time.

2.2 AUGMENTED MODEL

Figure 2 shows the OTS Block diagram relating to HPFACT. It is the result of information gatheringactivities and intense discussions with HPFACT. While the eight functional blocks are the sameas in Figure 1, notice the additional lines and interactions among the various sub-blocks reflectingmore closely the operations at HPFACT. For instance, it shows Order Cancellation, which was notconsidered in the simplified version. A major new factor is interaction with Distribution Centers(DCs).

Figure 3 shows the SELL & DISTRIBUTE block, of which the HPFACT-OTS block is a component.The actual physical entities that comprise SELL-PRODUCTS include the sales offices, field andtelephone centers at the distribution centers where orders are taken verbally or through receiptof physical purchase orders and transformed into computer readable form for tracking and billingpurposes. In particular, sales office and interdivisional orders are entered into the central order

tions that we had not yet modeled.7for example, is it more cost effective to provide different interfaces on a product, or to build different versions of

the product, each with a different interface?

5

·Clean· Shipment Orders

Forecast Info

ProdJct Info

Par1s

ORDER TO SHIP:

Shipment Status

Current Orders

Reschedule Request

4-26-88 REV 1.0

Part Orders

Shipment

Figure 1: Preliminary Order-to-ship Block diagram

management system where they are consolidated and transmitted to the appropriate supplyingdivision, in this case, the HPFACT division. Orders received at telemarketing centers are entereddirectly into the supporting systems at the DCs, shown here as DC1-0TS, DC2-0TS and DC3­OTS, which are geographically located in different parts of the world. Note that Part Deliveryis received only by the HPFACT-OTS, whereas all the DCs and HPFACT-OTS have outgoingshipments. In addition, HPFACT-OTS supplies products to the DCs through DC Stock Fills.

Figure 4 shows the context diagram or environment in which the SELL & DISTRIBUTE blockexists. While its structure is similar to those in Figures 1 through 3, the use of circular rather thanrectangular blocks is a convention to indicate that this represents the outermost boundary of theproblem we are dealing with.

CUSTOMERS interact with the SELL & DISTRIBUTE block through Customer Requests and/orRequirements and Order Cancellations. SELL & DISTRIBUTE provides Product Shipments toCUSTOMERS. Forecast Information (which is actually an order forecast) is sent to SELL & DIS­TRIBUTE by MARKETING. Product Information is a quasi-static structural entity that changesonly when products are introduced or obsoleted and is presumed to be provided by RESEARCH

6

DC iXders cr> HPFACT

iXders cr> HPFACT

Cancel DC iXder

Cancel iXder

I HPFACT-rnDER TO SHIP: 5-10-90~iXder

~- ~~ PROCESSI 8l!"fx~d

I r;: OODERS , ~~ . > >I I I 'I Ordar History Cancel~ ~e'/lolaI I I I I iXder ShPment Shi:> list

Forecast InfoI I I A-' -:-~I MANAGE~~~r------ "FI~ ===1: FCIlECASTS------II ~L~-:. ~ - - - - 1 ~is.¥~<rF~n':v~y Plals ~~n~~yDC StWabliIy

Praftes II og - - - A--:'~ t"'" - - - - - - - - - - - - - - - - - - - - - - - > - - - -->------

_L ________[~ll:~ FGI

DC FGI levels I ~ - - - - - - - - - ~PradJclkJn Sched..Ies UOlY t>UIO anI r ~

II L - - - - - - -I --j - - - - ,1 PartI I ProdJclion Plans. I A Material ' Part iXdersProducl Info Stolus & Hislory I - i~ PLAN' Delivery------ ~ 11 I I II MATl R:;Qfl:'ran1 /Sd'redle

II Verdor ,c=m::::J Part Dut~ ~~e

Vendor Bushess: I : : Constants II • or Bad ParisJ

I I I 11 1<- -~PROCURE~'!!~- -> Part Contraclsl - - - - - - - - 1- - - - -11- - - - PARTS ~c-: - - - -->

I I u... r- "PmII I L - - - - - ~ _.u~

II 1Par1~~Pari Deliv8IV I I I 11 I Invoics 1<- ~~ STalE Eo-- SIippi"lg Orders

PARTS ' PIck UII I I P

III II LDn- HCi-dI ,wen1OrieS - - - -I". /' Products

'I : ~ - ~ ~art_~N~ .:ta~_ - ~~1=~;W' ~tsII

II L _____ 1-1- ErOJ!J::Lion_S!9.lu!./Hi!t ___ ~_____~\~,I

I ProdJclionP1ans.~1 Prodi),s FILLISHIP~ , s &I L ___ ~ Status & Hislory l,Fgs:iIih! ~.J! e!..aL ____ - ___ .:: ORDERS ~_, Dislrl:lulionL___ 'I L________________,

CenlerI ~ __ HPE.,AQI.EGLl~el!. ____________________ .J I Stock Fit~------------------------------~1-5 I Shj:JmenlSlalus

Figure 2: HPFACT Order-to-ship Block diagram

& DEVELOPMENT (R & D). The outputs of SELL & DISTRIBUTE are HPFACT, DC1, DC2and DC3 Shipments to CUSTOMERS, and Part Orders (orders for Parts, not partial orders) whichcause parts to enter the system through Part Delivery from VENDORS. Shipping Orders representinteraction with CARRIERS and Part Contracts represent the periodic agreements which are madewith VENDORS.

2.3 FORMAT OF DETAILED DESCRIPTION OF MODEL

Sections 3 through 6 describe the model in greater detail. The entities will be grouped into foursets:

(a) the components of the Context or Environment for SELL & DISTRIBUTE,(b) the class of PASSIVE ENTITIES which flow through the system,(c) the components of SELL & DISTRIBUTE, and(d) the components of a Manufacturing Entity.

Each major component and entity of the system under study will be described from four differentaspects:

7

CXder Ccn:eUation

Customer Req.Jests and/or Requi'emenls

W I SELL & DISTRIBUTE: 5-10-90

Dealers. End UserClear/Goverment OEM's & Cancel OrderInlernal ~OrderS on HPFACTBadOrdsr• / Orders on DC

~-~I SELLr PRODUCTSI ,I I 1DC CancelOrdersJ 1 on HPF~C JDC OrderI

I ~~ DC3I I r - OTS ~-,' ~ItsI 11

~ Ij"----il- II !~PF~l Cancel V~learI II 11 IDC Order Bad

I II- - - - ~:~~

Order~!!!fo__ ) ->A I ~

DC2~II OTS F.,' . Is

I II _I r ~ I I~----rl I I !DC I-Clear

I II I I I I Orders =~. Bad DC

III I onHPF Order

I I I A-~ OC1~s1 I r - - - - r l - - - - - 1" 1- OTS r"

Forecasl Info 1.:- - - - ~I ----- ....-----+----~II Pari Orders- _.., I I I I I

l1 ~'~~e------ I IDC FGl Levels 1 I I IVendor Busroess I I II &DC~bIIiIy

PQrformanc. I I II II Pr ft 11 I I Ai""""""" Orders.------ - - -;. c - 1- - - - -Vl:

'i....c ~ !!' - - - Y!- - - - - :i: V_I'"§'" PF ACTII:f- - - - - - - - - - - - - - - - OTS~-

-r..,

Pari Delivery I II

~LCg:l1f.9c1~>DC stock FI I I :r:I I DC Supply Plans & Target FGI Levels I ~. IsI ~------------------------~ I

1 1L _________ ~~~~~______________ J

Figure 3: SELL and DISTRIBUTE Block diagram

(a) physical reality - our understanding of the issues of the real system and components,(b) model abstraction,(c) current implementation - including the current simplifying assumptions, and(d) future implementation - the anticipated consequences of relaxing the current assumptions.

2.3.1 PHYSICAL REALITY

We shall describe our understanding of reality specifically with respect to HPFACT and try to for­malize and generalize our conclusions where possible. While recognizing the pitfalls in generalizingacross all of HP observations made at HPFACT, stating our observations formally can provide theframework for making changes expediently when it becomes apparent that generalized observationsare not general or accurate enough. Our observations and understanding reflect a snapshot intime, since the processes themselves were changing during study'', This showed the importance ofstructuring our model so that process changes could be incorporated easily and quickly.

Since our information is based on interviews with a limited number of people, our knowledge

8The rapidity of change is illustrated by the fact that when we reflected to HPFACT our understanding of theprocess we had acquired on the previous visit, we were sometimes told that the process had changed.

8

/

/ ~VendOf BushessPerformance

Part Deliveryor PerformanceFalure

e..... ..-

..... -j - -.;/ ~art /

Product Info Orders I

ForecastInfo __-.

Figure 4: Context or Environment for SELL & DISTRIBUTE

is neither complete nor detailed, but we shall incorporate more relevant details as they becomeavailable.

2.3.2 MODEL ABSTRACTION

Representing the fine details of the real system (assuming they are available) would require tremen­dous computational power and result in simulations that require excessive computer run-time. Forexample, a HP3000 class machine generates a material requirements plan over a weekend. Duringone simulation, tens or hundreds of such hypothetical plans may be generated. Furthermore, duringsimulation, the computer has the added burden of simulating activities that occur in the physicalworld, something not required for operational system computers. Abstraction and aggregation ofrelevant information from reality is vital for obtaining approximate answers to questions of interestin a timely fashion.

9

Where possible, we will try to identify components as special cases of the OTS Abstraction. OTSAbstractions interact with one another, and they can be hierarchical. So far, CUSTOMERS,VENDORS, CARRIERS, SELL & DISTRIBUTE, DC3 OTS, DC2 OTS, DCI OTS, HPFACTOTS, STORE PARTS, PRODUCE PRODUCTS, and FILL-SHIP ORDERS are clearly identifiableas OTS Abstractions. While the other entities (e.g. PROCESS ORDERS or PROCURE PARTS)have some of the characteristics of OTS Abstractions, they do not possess the primary characteristicof handling physical objects.

2.3.3 CURRENT IMPLEMENTATION

We discuss the simplifying assumptions on the data and model to prototype the whole systemrapidly to provide a framework for adding greater detail.

2.3.4 FUTURE IMPLEMENTATION

Finally, we will discuss additional detail and assumption change that can be incorporated intothe model to bring it closer to the Model Abstraction than the current implementation, and theramifications, consequences and results of doing so.

3 Detailed Model - Part I: SELL and DISTRIBUTE Environ­ment

3.1 CUSTOMERS

PHYSICAL REALITY Customers have varying characteristics and differing needs in termsof the urgency with which the product is needed. The sequence in which the order is filled maybe determined not only by the date of order receipt, but also by the urgency of the requirement.Customers may be spread out geographically.

Original Equipment Manufacturer (OEM) customers have contractual agreements for their orders;the lead times for delivery to their orders is set by contract. OEM units are taken into account inthe planning process when the orders are placed.

MODEL ABSTRACTION Each customer can be represented by an OTS Abstraction, andhas the following attributes: name, geographical location or locations where it needs the unit, andthe priority. The customers may be aggregated by class or as one large entity, depending on thelevel of detail required on the results.

CURRENT IMPLEMENTATION We currently assume that priorities are identical for allcustomers.

10

FUTURE IMPLEMENTATION We will add customer priority, and identify OEM, dealers,major customers, and internal customers separately. The rest of the trade customers will be lumpedtogether.

3.2 VENDORS

PHYSICAL REALITY Many to many relationships exist between vendors and parts. A singlevendor can supply many parts, and the same part can be supplied by multiple vendors. Lead time,volume, quality and vendor all affect the unit price of each part.

There are good reasons for both single-sourcing and multi-sourcing, but the trend is towards sup­porting and building long term relationships with primary and secondary sources. This requiresmanaging vendor relations, including such activities as keeping the vendor apprised of current andfuture plans, and making long term commitments for order quantities. The advantage to the ven­dor is the certainty of knowing that there exists a stable customer (HP) with a long term demandwho will accept all the vendor's production as long as the vendor maintains quality and deliveryperformance. This certainty encourages the vendor to invest in modern and more efficient facilities.

MODEL ABSTRACTION Each vendor may be represented as an OTS abstraction. Vendorsaccept part orders, and respond with acknowledgement dates and subsequently shipments fulfill­ing those orders. In our diagram, VENDORS accept Part Orders, and Part Deliveries representfulfillment of those orders.

CURRENT IMPLEMENTATION Each vendor provides a different part, and each part isprovided by only one vendor. The lead time for a part is known and is always constant; the partsare shipped by the vendor a fixed time after the order is received. The fixed time is different foreach part. The part price is fixed. At the moment, the acknowledge date for part shipment is notprovided and HPFACT uses the known lead time for planning purposes.

FUTURE IMPLEMENTATION The many to many relationship between vendors and partscan be established and simulated; this will introduce more complexity since different vendors couldsupply the same part at different prices with different lead times. The inter-relationship betweenunit price and order quantity can also be modeled and various operational purchasing policies (e.g.buying down lead time by paying a premium) tested. Statistical variation to the delivery timesand rejection rates are other additions we could make to the model inputs.

3.3 CARRIERS

PHYSICAL REALITY Carriers are responsible for transporting units between entities. Dif­ferent carriers transport parts from Vendors to HPFACT, and from HPFACT and the DCs tocustomers. Transportation include truck shipment, ocean freight and air freight. Units in transitare unavailable for use, and cannot be diverted. The major effect is to prevent in-transit units

11

from being available to the end user for consumption or to the supplier for reallocation. A furtherconstraint on Carriers is the minimum and maximum volumes that can be moved at any time.Some carriers can perform daily movement of products and materials, while others perform weeklyor less frequent movements.

MODEL ABSTRACTION Carriers can be treated as OTS Abstractions that provide timedelays between shipment and receipt of items.

CURRENT IMPLEMENTATION Currently, the carriers are arbitrarily classified and asso­ciated with each of the DCs, HPFACT, Customers, and Vendors, and the transit time for eachcarrier is assumed constant. The associated in-transit units are assumed to be associated with(belong to) the destination entities. Carriers move shipments daily.

FUTURE IMPLEMENTATION We can model the carriers in greater detail, treating theirtransportation capacities and characteristics as values that need forecasting and monitoring.

3.4 MARKETING

PHYSICAL REALITY Marketing collects information from various sources, including thetrade literature, state of the economy, opinions of field personnel, estimates of dealers and DCs,and knowledge of the competition, and puts it together to build the gross order forecast. For anexisting product, historical data, theoretical projections based on the data provided by sales people,advertising budget, cyclical changes, and targeted figures which are the preliminary forecasts madeat the beginning of the fiscal year, all affect the forecast.

Different parts of the forecast are of interest to different people. The short term forecast, up tothe lead time of the longest lead time part, is of interest to PLAN PRODUCTION and PRO­CURE PARTS. The longer term forecast is of interest to Corporate Materials which consolidatesthe requirements of all divisions to compute gross material requirements for negotiating volumecontracts.

MODEL ABSTRACTION MARKETING is an entity that accepts information from variousparts of the environment and periodically generates Forecast Info.

CURRENT IMPLEMENTATION MARKETING is an entity external to the SELL & DIS­TRIBUTE block, and the Forecast Info it generates is set currently to a constant value. Theforecasts are generated once a month, and provision has been made to allow different forecastvalues each month.

FUTURE IMPLEMENTATION As we obtain more information, we shall implement therules that are used by marketing to update the forecasts using historical data.

12

4 Detailed Model- Part II: PASSIVE ENTITIES

4.1 PRODUCT INFORMATION

PHYSICAL REALITY Each factory produces many products with different options madeup of multiple levels of subassembly. Certain subassemblies and parts may be duplicated in aproduct, while other subassemblies and parts are common across different products. Each productand subassembly requires lower level subassemblies and/or raw materials as well as productionoperation activities.

Establishing the unit value of the product is a complex issue. Accounting practice allocates differentvalues to a unit of the product at various stages in its existence. It has one value when it rolls offthe end of the production line, another value when it is loaded on the carrier on its way to thecustomer (and the values may differ according to the customer), and a different value when it isheld as FGI at the division or at DCs. Furthermore, the unit value of a product changes over timebased on the experience of cost over the previous periods.

FGI values are normally quoted as a discount from the list price. The unit value becomes importantwhen it is necessary to aggregate diverse products using a common and readily acceptable unit ofmeasure, namely dollars.

The particular product under study at HPFACT came with different options. There is a largenumber of common parts and a small number of specialized parts for each option. In the finalassembly, the product is made up of parts that are provided by vendors, or produced in a differentpart of HP. One example of parts produced in a different part of HP is PC boards which are madefrom raw boards onto which electronic components are placed.

MODEL ABSTRACTION Each product has a product structure, which is a list of the partand the quantity of each part that goes into the manufacture of each unit of the product. The unitcost of the product is more than the total cost of its components, since it also includes the cost ofsome transformation. The value of the product is different from its cost, and is dependent on thelocation.

CURRENT IMPLEMENTATION To simplify the computer model, we aggregate similarproducts, subassemblies, and parts together into fewer categories than those required in the realfactory. The level of aggregation is an engineering tradeoff; less aggregation provides more preciseresults, but requires greater computational power.

The product structure is treated as data to the factory model. In running experiments with thepreliminary OTS model, we used three hypothetical products made up of six different parts. Eachproduct is made up of three different kinds of parts, and there is only one level of assembly. Someparts are common and used in more than one product. With no intermediate subassembly level,the computational complexity was reduced, since the bill of materials explosion maps the productdemand directly into the parts requirements.

In the early phases of the experiments with the augmented OTS model, we are still using the

13

simplified hypothetical products, and the unit value of the product is independent of its location.

FUTURE IMPLEMENTATION The actual product structure will be used at some point inthe near future. As additional levels of information interpretation become necessary, we expect toexplore ways of setting the aggregation level dynamically. For example, the PC board subassem­bly could be introduced to examine the effect of additional levels of production scheduling andincreased computational complexity, and we could consider the effect of components that do notlend themselves to easy discretization (e.g. 0.01 oz of solder paste).

As long as we have only a few products or parts, it is easy to deal with units of each item. Whenthere are many different ones, we need a common measure, and the accounting unit and generallyaccepted measure is dollars. The pricing issue is a fairly complex one which needs to be resolvedsatisfactorily for the purpose of reducing everything into terms of dollars. A secondary measure isweeks of demand.

4.2 PARTS

PHYSICAL DESCRIPTION Parts are supplied by different vendors with different qualitylevels at different price volume combinations. Since the characteristics of parts are so tightlyassociated with vendors, a fuller description is given in the section under VENDORS.

MODEL ABSTRACTION Parts are physical objects that are passed between OTS Abstrac­tions, and are measured by number of units, weight or volume. Conversion into dollar values.permits a common measure across different parts and different units of measurement. A part issupplied by one or more vendors and the unit price is a function of the order quantity, lead time,and vendor. It could have other characteristics such as reject rate, shipment lot size, and shipmentfrequency which depend on order quantity, lead time, and vendor.

CURRENT IMPLEMENTATION Currently we measure parts in units or dollars only, andassume a single vendor with deterministic lead time per part. This assumption simplifies our currentsimulation activities.

Normally the reject rate is zero, but can be set to some percentage. We currently have no restrictionson shipment lot size.

The price of the part is used for computing raw parts inventory (RPI).

FUTURE IMPLEMENTATION When we consider the situation from the point of view ofa manufacturing division, there is a distinction between products and parts. However, from themore global view, the parts for one entity are the products for another entity, and each productcan always be considered to be made up of other products''.

9In the future, we could define everything as products, to avoid drawing artificial distinctions between part andproduct structures in the implementation.

14

4.3 ORDERS OF FINISHED PRODUCTS

4.3.1 ORDERS FROM END USERS OR NON-HP ENTITIES

PHYSICAL REALITY During the day, orders arrive at the sales office either from customersor sales representatives and are entered into the central order processing system system. Internalorders from other HP divisions are also entered into this system by their respective purchasingdepartments.

The system breaks down the individual orders into sub-orders, and transmits the consolidated sub­orders periodically to the supplying divisions where they are available for processing the followingmorning.

The orders received by divisions are checked for correctness and configuration consistency by orderprocessing. Each order is given an acknowledgement date, which is received by the sales office orHP division the following morning. This is the normal sequence and timing of events. In urgentcases, telephone communication between the sales office personnel and their counterparts in theorder processing department may reduce the time taken to receive a preliminary acknowledgementdate.

We could not identify an order that is typical for all divisions. Within one division, orders may rangeacross several orders of magnitude in dollar value. For orders of complex systems and instruments,there might be many parts and options to the order. For certain products, there might be only oneitem on the order. DCs receive their stock from the division 10. High volume original equipmentmanufacturer (OEM) orders, large dealer orders and internal HP orders are shipped directly fromthe division.

Orders usually have a required date. Depending on the nature of the product ordered, the customermay specify an earliest acceptable date (EAD) 11, before which the order should not be delivered.The latest acceptable date (LAD) is the latest date of receipt which would not cause inconveniencefor the customer. An important issue in customer satisfaction is delivery within an acceptablewindow, and the quoted lead time needs to reflect this. If the quoted lead time is too long, thecustomer may take business to a more responsive supplier. Order shipments may be specifiedas soon as possible (ASAP), so that the products will be shipped as soon as they are produced;if they are already in Finished Goods Inventory (FGI), the order may be filled from stock. Ingeneral, orders are filled in a first-in first-out (FIFO) fashion, although exceptions may occur whenprioritizing rules are used.

Orders may be modified or cancelled anytime before shipment, and sometimes an order that isshipped could be rejected and returned. In addition, the acknowledgement date may be modified.

Orders to be filled from distribution centers may be routed through the sales office or through thetelemarketing center 12 and can be processed and filled by the distribution center immediately ifthe required product is available in FGI. The DCs supply dealers and some end customers, but notinternal HP divisions.

10 discussed in more detail in the next section11 e.g. if the customer has to prepare the site12 Another working assumption

15

MODEL ABSTRACTION Each order that arrives at the SELL-PRODUCTS block includesthe customer name, the order date generated by the customer, some combination of DUE-DATE,EAD and LAD, and the number of units of each product ordered. There may be multiple itemson a single order. The orders are checked for correctness. The correct orders are exploded intosub-orders and routed to a DC or to a division according to some criteria (e.g. size of order,geographical location of customer), and the incorrect orders are referred back to the originator.

CURRENT IMPLEMENTATION The number of orders that can be placed by all the ex­ternal customers collectively each day is a parameter. We can use deterministic values to ensurerepeatability of orders received for each simulation run, or stochastic distributions to characterizethe system more accurately when the data is available. Order streams may also be specified from afile. Currently we use order inputs from a file. There is a mix of large and small orders dependingon the nature of the customer, and the order may be for multiple products.

Our current model has provisions for specifying earliest acceptable date (EAD), latest acceptabledate (LAD) and delivery date. If these are not specified, the EAD and required date are assumedto be the same as the order date (effectively making it ASAP), and the LAD as EAD + 5 days.While we have provisions for specifying priorities on orders, we currently give all orders the samepriority, and the order fill sequence is determined by the order filling policy of the shipping entity.

SELL-PRODUCTS directs an order to the appropriate entity according to the supplying entityspecified on the order.

FUTURE IMPLEMENTATION In future we expect to handle more sophisticated and com­plicated priority schemes, and to modify orders that are already in the system. Also, we expect toallow SELL-PRODUCTS to route the orders to the appropriate entity according to characteristicsof the customer.

Future experiments include varying order volumes and considering seasonal variational". In ad­dition, when customers are characterized individually, the supplying entity may be determineddirectly by the customer characteristics, rather than arbitrarily allocated by SELL PRODUCTS.

4.3.2 DC STOCK FILL FROM DIVISION

PHYSICAL REALITY DCs obtain their stock fill from the division. There are differentpolicies with respect to the stock fill by item and division. We are currently aware of severalpolicies in place.

One is that DCs place orders on the supplying division, just as other HP divisions do, and theirorders receive a high priority. In some cases, the supplying division recommends to the DC howmuch and when to order. The DC can use its discretion in accepting this. This gives the DCs thechoice of asking for less stock when they have too much. One inconvenience is that a large DC

131£ a uniformly distributed order stream has substantial theoretical benefits, that would provide motivation forstudying the reason behind the non-uniform distribution, and inducing order arrival in a more linear and regularfashion. Alternatively, we could look for ways to reduce sensitivity to non-uniform order streams.

16

order could be held up in shipping for lack of a few units which could just as easily be sent on alater shipment. It also means that space on air or ocean carriers must be reserved in anticipationof the orders instead of according to the production plan. A second inconvenience is when theunits available are insufficient to fill the total high-priority DC requirements. In this case a toughdecision on how to allocate the limited number of units available must be made, and the DCs wouldbe unable to receive what they ordered anyway.

A second policy is for the division to send all available units to the DCs. This provides flexibility tothe division since a shortage of a few units to the planned shipment does not hold up a shipment,and the division can send convenient shipping quantities instead of those specified in an order.However, this requires the DCs to react to unpredictable quantities of product inflow.

While it may appear that shipping all available units is the most expedient policy and requires theleast effort, there is a practical difficulty when it comes to international shipments. Although thetransfer is between different HP entities, movement of goods across international boundaries gen­erally requires filling units against an order quantity, and the financial and governmental approvalsmust be met against the number of units on the order. When the number of units is not exactlyequal to what is on the paperwork, it can cause some difficulties.

MODEL ABSTRACTION The DC Stock Fill represents the flow of products from the divisionto the DC for the purpose of redistribution. The flow of products may be initiated directly by thesupplying division or in response to a DC order.

CURRENT IMPLEMENTATION Currently, we compute the DC Supply Plans on a monthlybasis, and provide two options for the actual DC Stock Fill. One is to fill the plans as closely aspossible by DC each day until units run out. The other is to prorate limited availability of unitsaccording to the sum of current backlog and the DC Supply Plan, thus providing some realtimefeedback of the actual orders to the system, and reducing excess FGI at the DC where demand islower, and reducing backlog at the DC where demand is higher.

FUTURE IMPLEMENTATION We will provide means for the DC to place orders on HP­FACT and for specifying other strategies for allocating units to the DC when the units availablecannot fill the demand.

4.4 ORDER FORECASTS

PHYSICAL REALITY Forecast Info is a prediction of orders for products over time thatis generated and updated periodically by MARKETING. In spite of all the theories and toolsavailable, order forecasting appears to be an art rather than a science. The order forecast indicatesthe orders that will come in by time periods; it does not indicate the shipment or sales revenuesover those periods. At HPFACT, two forecasts are generated, the nominal order forecast, andthe contingent order forecast which is a certain percentage above the nominal. The percentage isdifferent for different products. It is generally higher for a new product, and lower for a matureproduct.

17

MODEL ABSTRACTION The Forecast Info is a set of lists of total quantity of each productthat is expected to be ordered over periods of time in the near future and is generated by Marketing.

CURRENT IMPLEMENTATION Forecast Info has zero product requirements in the earlydays, followed by an arbitrary distribution of quantity of products for a particular order. Thisassumption simplifies the initial conditions of the system, and permits all the state variables of thesystem (e.g. FGI, RPI) to be set initially to zero and allows them to build up to the correct values.A constant Forecast Info distribution is arbitrary, and generally relates to a mature product.

FUTURE IMPLEMENTATION We expect to look at the actual forecasts from HPFACT,and to examine the importance of accurate forecasts (or the penalties of inaccurate forecasts) duringproduct introduction and obsolescence. For a new product, the order forecast may show a gradualrise, or a big initial surge (when the dealer inventories need to be built up) followed by a dip andsubsequent recovery to a steady volume.

5 Detailed Model - Part III: SELL and DISTRIBUTE BlockComponents

5.1 SELL-PRODUCTS

PHYSICAL REALITY The SELL-PRODUCTS block represents a logical entity whose physi­cal realization is spread out over various physical areas. It represents the the sales and order takingactivities of the company. Sales Offices are spread out all over the world, and are co-ordinatedcentrally through the central order processing system, which accepts all order inputs from sales of­fices and other divisions. While the SELL-PRODUCTS function interacts mainly with the outsideworld, part of it interacts with internal HP divisions. As we add other HP entities or manufacturingdivisions to the OTS model, we do not need to add new SELL-PRODUCTS blocks.

MODEL ABSTRACTION The SELL-PRODUCTS block responds to Customer Requestsand/or Requirements and Order Cancellation from CUSTOMERS by re-routing and receiving theappropriate information from the DCs and the division or asking for clarification for Orders thatare not correct.

CURRENT IMPLEMENTATION SELL-PRODUCTS receives Customer Requirements, andtransmits them to the DCs or to HPFACT as Orders. Orders are routed arbitrarily to the DCsor HPFACT according to some specified ratios or percentages. Acknowledgement dates are notprovided to the customer.

FUTURE IMPLEMENTATION More features will be added so that we can handle OrderCancellation and provide acknowledgement dates to CUSTOMERS.

18

5.2 DISTRIBUTION CENTERS

PHYSICAL REALITY A DC in general has the purpose of acting as a giant warehouse hold­ing many different kinds of products which can be drawn and shipped out on demand. It is a bufferbetween some external customers and divisions. The DC is responsible for obtaining items in bulkfrom various locations, breaking them down, and then building up loads out of these items. Theloads are then sent out to customers. The primary emphasis is on breaking down bulk shipmentsof finished goods into single components and building up shipments out of the components. Man­ufacturing or assembly is non existent or very limited''"; in some ways, the DC can be considereda transshipment center or a broker. The DC would like to keep a minimum level of inventory, andincrease the number of times the inventory moves or turns over in a given period of time.

MODEL ABSTRACTION The DC is an OTS Abstraction which accepts orders, ships prod­ucts, DC Stock Fills, and may order products from divisions. Its measures of interest include thelevel of each item of FGI, and the amount of products/orders on backlog.

CURRENT IMPLEMENTATION Whenever orders are received at a DC, FGI is checkedfor the required items and quantities, and filled immediately if possible. Each time the DC receivesa DC Stock Fill, the backlog of orders is checked and filled according to some specified criteria.Currently, two order filling criteria are included: LIFO (last in, first out), in which the last orderreceived that is outstanding is filled first, and FIFO (first in, first out), in which the oldest order isfilled first. We have currently modeled the three DCs mentioned.

FUTURE IMPLEMENTATION The ability to model future DCs as they are created is fairlystraightforward, as well as the ability to model proposed DCs to see the effect on other parts of thesystem. We can also study more complex order filling criteria, such as the effects of eliminatingDCs entirely, or the effects of filling orders from DCs only.

6 Detailed Model- Part IV: FACTORY ENTITY

The factory entity is an OTS Abstraction which has the full set of characteristics of the abstraction.The HPFACT entity is an example of the factory entity. Other divisions can be modeled as factoryentities.

The factory entity is currently composed of the eight sub functions represented by the sub-blocks inFigure 2 and described in subsections 6.1 through 6.8. Since much of the information was derivedfrom HPFACT, the description of the sub functions is biased naturally towards those of HPFACT.

H e.g. packing manuals with products

19

6.1 PROCESS-ORDERS

PHYSICAL REALITY Orders are received by this functional block from the central orderprocessing system several times a day. During a batch run, the orders are checked, and subsequentlyan acknowledgement is sent to the order entry point. In addition, a Ship List of the prioritized listof orders to be shipped over the next few work days is generated and printed out for use by FILL­SHIP ORDERS. Orders in general have priorities associated with them, in addition to shippingconstraints regarding EAD and LAD, and all these characteristics are used in generating the ShipList.

If an order is urgent, the time can be reduced by using telephone communication, but the finalconfirmation only comes in after the overnight batch run. Finally, orders may be modified orcancelled after they have been received and acknowledged.

MODEL ABSTRACTIONS PROCESS ORDERS is the entity at the manufacturing divisionthat responds to Orders and Cancellations from Customers and DCs that are transmitted fromSELL PRODUCTS. It generates a Ship List and provides Shipment Status Data.

CURRENT IMPLEMENTATION In our current implementation all Orders received byPROCESS ORDERS are clean, and never cancelled or modified. Acknowledgement dates arenot provided to the customer. In addition, DCs do not place orders on the division.

FUTURE IMPLEMENTATION We expect to add the following enhancements to PROCESSORDERS: handling order cancellation and modification, generating an acknowledgement for theship date, and indicating priority values and unclean orders. We also expect to enable PROCESSORDERS to handle orders from DCs.

6.2 MANAGE-FORECASTS

PHYSICAL REALITY The Forecast Info by month is supplied and updated every forecastperiod by MARKETING. The latest Forecast Info, together with estimates of the shippabilityprofiles at each of the DCs and the division, called DC Shippability Profiles, are used to computethe Order Shipment Forecast. The shippability profile is an aggregated estimate of the fraction oforders received in a given month being shipped that month and following months. It needs to betaken into account because experience shows that not all the units of products ordered in a givenmonth are shipped the same month, in part because some customers specify an EAD which is sometime in the future.

The Order Shipment Forecast is an estimate of shipment volume of products of the quantitiesprovided in the Forecast Info. Note that the Order Shipment Forecast is an estimate of the require­ments specified by the customer, and therefore does not take into account the current Backlog andFGL At HPFACT, two sets of computations are performed, one for the nominal order forecast, andone based on an optimistic or contingent order forecast.

20

MODEL ABSTRACTION The MANAGE FORECASTS block receives Forecast Info, whichis a set of order forecasts. For each order forecast given, it computes the Order Shipment Forecastusing the Forecast Info and the DC Shippability Profiles from historical information.

CURRENT IMPLEMENTATION For the current model, we compute the Order ShipmentForecasts by multiplying the appropriate order forecast with the shippability profile. Currently, thedefault shippability profiles is assumed to be 100 % for the current month, and 0 % for subsequentmonths.

FUTURE IMPLEMENTATION We will use historical experience on the pattern of EADsto generate the DC Shipp ability Profiles and use that to compute the Order Shipment Forecasts.

6.3 PLAN PRODUCTION

PHYSICAL REALITY Plan Production uses the most recent set of Order Shipment Forecaststo compute the Production Schedules. It takes into account the production capacity, material onhand, and material on order. The Production Schedule is updated periodically, or whenever it isclear that actual production activities are so far from the planned that a new Production Scheduleis required. The Production Schedule determines in gross terms an estimate of the units of productsto be built in the near future. If it shows an amount that is less than what can be shipped, theunits need to be pro-rated on some basis.

The Production Schedule is the source for computing the DC Supply Plans (schedule of productsshipped to DCs) and the Facility Shipment Plan, the projected direct shipments out of the division,and the Target FGI Levels at the DCs and HPFACT-OTS. A certain period of the plan in the nearterm is the freeze period, which is a period of commitment necessary for resource and personnelplanning, and maintenance scheduling. The freeze period shields PRODUCE PRODUCTS fromhaving to react to temporary fluctuations in the order stream and provides stability on the produc­tion floor. Outside the freeze period, the plan may change within the limits of production capacityand material availability.

MODEL ABSTRACTION At each planning period, the Forecasts, Projections or Schedulesare computed as sequences of the following: for each month until the planning horizon, for eachDC and the division, and for each product, the following Planned or Estimated quantities arecomputed:

(a) Shipment Demand is the sum of the Backlog at the beginning of the month and the OrderShipment for that month(b) Demand on HPFACT from each DC and the division is computed from Shipment Demand,the FGI at the beginning of each month, and the Target FGI at the end of the month;(c) Production is the minimum of Total Demand on HPFACT, the capacity of the productionline, and material availability, if it is outside the freeze period, or the value that was computedin a previous forecast if it is within the freeze period.

21

(d) DC Supply is the same as Demand on HPFACT if Production can meet Demand onHPFACT, otherwise it is prorated with respect to Production(e) FGI and Backlog at month end are computed as by-products of this process.

The Production Schedule is a plan computed in monthly periods for each Order Shipment Forecast.The Daily Build Plans and the Daily Shipment Plans are derived from the appropriate monthlyprojections.

CURRENT IMPLEMENTATION We have generally implemented the system describedabove, with no no freeze period, and we do not take into account material availability. We alsoassume that excess production capacity on one product cannot be utilized for producing anotherproduct with insufficient production capacity. In line with the operating procedure for the HP­PROD at HPFACT, we use the nominal Production Schedule for generating the Daily Build Plan.

FUTURE IMPLEMENTATION The primary assumption made in our computations is thatlimits are hard (e.g. production capacity is fixed at certain levels), and that we are bound to thoselimits at all times. In practice, the effects of limits can be reduced or eliminated over the long run.For example, if the demand requires it, production capacity can be increased by allowing overtime,increasing the number of shifts, and working on weekends. In addition, if there is excess capacityon one line, and a shortage of capacity on another line, the labor portion of the capacity can beshifted easily by transferring people.

This block is one which could lend itself to appropriate application of Knowledge and Rule BasedSystems to capture human insights (e.g. which constraints can be relaxed, and over what periodof time) as well as Linear Programming methods.

6.4 PLAN-MATERIAL-REQUIREMENTS

PHYSICAL REALITY Plan Material Requirements generates a Materials Requirements Planfrom the Production Schedule. It uses the Product Structure generated by R&D to computeparts and subassemblies required for the final product, noting that some subassemblies may bebuilt up of other subassemblies. A Bill of Materials explosion computes the required quantities ofsubassemblies at every level until the level of purchased components. The Material RequirementsPlan is the result, indicating quantities of each subassembly and component required at each timeinterval to satisfy the Production Schedule. Note that the Material Requirements Plan indicatesthe requirements by usage over time, not the quantity that needs to be ordered which takes intothe account the amount of material on hand. A new Material Requirements Plan is generatedperiodically using the Production Schedule.

MODEL ABSTRACTIONS PLAN MATERIAL REQUIREMENTS uses the Production Sched­ule and the Product Info to make a Material Requirements Plan.

22

CURRENT IMPLEMENTATION We have implemented the current operating procedureat HPFACT to plan to the contingent Order Shipment Forecast. By doing so, there is enoughmaterial to increase the Production Schedule easily outside the freeze period in case a future OrderShipment Forecast for a given month comes in at a higher level than the current nominal OrderShipment Forecast.

Since there is only one level of assembly, the bill of materials explosion is fairly straightforward. Itis a direct multiplication of the Product Structure by number of units of product to produce theMaterial Requirements Plan.

FUTURE IMPLEMENTATION Multiple level subassemblies will increase computational re­quirements, and require keeping track of actual and projected parts and subassembly quantities.Common subassemblies will produce interactions which can show how much stability there is inmaterial requirements with respect to changing product demand. In the future, we may expandthe PCB assembly to give a second bill of materials explosion.

6.5 PROCURE-PARTS

PHYSICAL REALITY The Material Requirements Plan as defined above should not changeunless the Production Schedule changes. However, to order sufficient material, PROCURE PARTStakes into account the actual material on hand and projected deliveries in the near future, togenerate the Material Procurement Plan15. This is computed periodically at HPFACT, and isavailable so that materials or parts can be ordered to arrive when needed.

The ordering strategy depends on the material, relationship with the vendor, cost and other relevantfactors. Parts are classified as A, B or C parts. A parts generally need more attention than B or Cparts because they are large, expensive or used in large quantities, and require careful scheduling forordering and arrival. C parts are generally smaller and of lower value, and are bought in quantitywhenever a lower threshold of number of units is reached. Generally, whenever a new MaterialProcurement Plan is generated, there is sufficient work of ordering parts to keep the buyers busy.When required parts are ordered, either from an external vendor or another division, the order­acknowledge transaction occurs to provide verification on when the parts can be expected to showup. IT projected delivery dates from suppliers are not satisfactory, appropriate action can be takenbefore the situation becomes a crisis.

MODEL ABSTRACTION PROCURE PARTS generates a Material Procurement Plan fromcurrent material on hand, projected receipt of material, the Material Requirements Plan, and leadtime of parts. Parts are ordered according to the plan, and the information is sent to the STOREPARTS block, so that they can be prepared for the parts when they show up from the supplier.

Since there are many strategies for ordering different parts depending on the part classification andvendor, this block requires the ability to handle various strategies and applications of rules.

15Note that what we are calling the Procurement Plan may actually be called the MRP at HPFACT

23

CURRENT IMPLEMENTATION PROCURE PARTS uses the Material Requirements Planto generate the procurement plan. All Parts are ordered weekly on Monday mornings and we ignorethe A, B and C classifications. The lead-time of the part is deterministic, and the quantity of partsordered ensures sufficient parts on hand to support the Production Schedule. In line with theoperating procedure at HPFACT, we use the Material Requirements Plan associated with theContingent Production Schedule for ordering materials. At the moment we do not use ProjectedMaterial Availability in computing the Procurement Plan.

FUTURE IMPLEMENTATION We could make the system more realistic by spreading outthe ordering over the week. In addition, we could implement part specific order intervals on thebasis of the three classes of parts.

We could try different strategies for procuring parts, and assume that the part lead times havedifferent statistical properties. The parameters for the distributions may be set or changed in themiddle of a simulation run. In that event, it would be useful to compute an effective lead timeto use in ordering parts, and to use a pre-determined probability level of having the part in handwhen required.

The lead time of the material could change with the volume required or could be reduced by payinga premium for the part; these may be characterized in the model in the future.

Finally, we need to consider material already ordered and in transit in the Material ProcurementPlan, and to specify safety raw material stock levels.

6.6 STORE-PARTS

PHYSICAL REALITY STORE PARTS receives Part Deliveries from VENDORS that are arealization of the Part Orders issued by Procure Parts. In some divisions (not in HPFACT) itreceives subassemblies produced by PRODUCE PRODUCTS. STORE PARTS breaks down bulkpackaging and puts away material in a manner which allows quick retrieval.

STORE PARTS issues materials, parts and subassemblies when required by production throughParts Requests from Product Products. STORE PARTS is responsible for keeping track of materialon hand, and material about to be received.

The obvious constraint for STORE PARTS is that it cannot meet the requirements of productionif something required is missing; the conventional wisdom has been to buffer stock everything toprevent stockouts to keep the production line busy all the time.

In HPFACT, where possible, parts are received in packages that can be sent directly to the pro­duction line, so that STORE-PARTS can avoid handling individual parts. This of course requiresa certain amount of co-ordination with PROCURE PARTS.

MODEL ABSTRACTION STORE PARTS is an OTS Abstraction that responds to statusinformation on the quantity of parts and subassemblies on hand, and is able to accept shipments ofthese parts and issue them upon request. If the requested parts are not on hand to fulfill requests

24

from PRODUCE PRODUCTS, STORE PARTS sends as much as it can.

When Part Outages occur, both current and projected, resolution requires co-ordination with PRO­CURE PARTS.

CURRENT IMPLEMENTATION STORE PARTS does not store subassemblies. This re­flects the situation for HPFACT with respect to HPPROD. It keeps a running total of parts on handcalled the raw parts inventory (RPI), adding to it each time a shipment of new parts is received,and subtracting from it each time it fills a request from PRODUCE PRODUCTS.

FUTURE IMPLEMENTATION Since parts may not always arrive on time, STORE PARTSmay not be able to supply parts when requested. However, if parts are not available for some reason,advance notice will be given so that it is possible to modify the production plan, and co-ordinatewith PROCURE PARTS. This does not take into account catastrophic events which will force aemergency change in the production plan on the day of production.

6.7 PRODUCE-PRODUCTS

PHYSICAL REALITY Products are produced on the production floor, where all the requiredparts, materials and subassemblies for final assembly come together to produce the finished productor subassemblies of the factory according to the Production Plan. Each day, Produce Productsissues total Parts Requests approximately equal to the demand determined by the Daily Build Plan.Obviously, the maximum production is limited by the material availability and the productioncapacity which may be reduced by line failures or downtime.

At HPFACT, buffer storage at the Production Line is limited for most parts. When one bin ofparts is empty, the empty bin is sent to a staging area where a signal is sent to STORE PARTSto deliver another bin of the appropriate part within a certain guaranteed response time. The binof parts method of supplying parts is limited to parts where convenient quantities can fit into thebins. For large bulky items, the unit of part delivery may be a cart load.

On the production line itself, there are three different classes of material: the raw parts, the finishedunits, and units in some stage of completion (work in process).

There are several reasons why the number of units built is not equal to what is planned: some ofthem include line downtime, parts outage, or a large proportion of bad parts. If the Daily BuildPlan is not completed, somehow the shortfall units must be made up, or subsequent Daily BuildPlans modified.

MODEL ABSTRACTION PRODUCE PRODUCTS is an OTS Abstraction which convertsparts into products according to the Product Structure. The quantity of production is determinedby the Daily Build Plan and the available production capacity on the actual day itself.

PRODUCE PRODUCTS has an internal state called Work in Progress (WIP) which is a measureof the number of parts and finished goods on the production line. PRODUCE PRODUCTS makes

25

Parts Requests to STORE PARTS which responds with Parts to update WIP. There is a conversionfrom parts to products in WIP; subsequently units of Products are transfered from WIP to FGI ofFILL-SHIP ORDERS.

CURRENT IMPLEMENTATION In the current implementation, PRODUCE PRODUCTSasks for required parts at the beginning of the workday to complete planned production for theday, and assumes immediate delivery. The total production is available at the end of the work day.The aggregation level is total by day, rather than by bins of parts or units of production.

Production shortfalls on a given day are not made up immediately; they are ultimately correctedby insufficient FGI levels in a subsequent planning period.

Line downtime can be specified as a parameter ofthe model in terms offrequency and the percentageof planned production that is not completed.

FUTURE IMPLEMENTATION We will permit PRODUCE PRODUCTS to issue Parts Re­quests by empty bins. If parts are not available when expected, production will be held up causingdelay to orders, and at the same time, either or both of PRODUCE PRODUCTS and STOREPARTS would co-ordinate with PROCURE PARTS to get the problem resolved with VENDORS.

We will also implement the operating procedure used at HPFACT to utilize maximum capacity tobuild as many units as possible of the sum of Daily Build Plan and Cumulative Backlog Units.

We need to specify a general method for describing line downtime.

The level of abstraction and detail determines the frequency at which the interactions betweenSTORE PARTS, PRODUCE PRODUCTS, and FILL-SHIP PRODUCTS occur. At one extreme,we can model Parts being requested at the beginning of the day for production for the whole day,and generate the total daily production at the end of the day. This means that we can make asingle conversion between Parts and Products in WIP per day. At the other extreme, we can modelparts being requested by the bin as each bin is emptied, and the finished units being produced bythe unit, updating the WIP component values as each unit is produced.

6.8 FILL-SHIP ORDERS

PHYSICAL REALITY Finished Products are sent from WIP of PRODUCE PRODUCTS toFGI of FILL-SHIP ORDERS where they are logged into the computer system. FGI is used tofill shipments according to the SHIP LIST generated by PROCESS ORDERS. When the orderis shipped, the Shipment Status message to PROCESS ORDERS causes the latter to update itsinternal information status on orders.

There may be shipping constraints in terms of the total volume of units that can be shipped in aday, as well as the carrier size and the number of doors on the loading dock.

26

MODEL ABSTRACTIONS FILL-SHIP ORDERS is an OTS Abstraction that removes com­pleted units from the WIP of PRODUCE PRODUCTS to FGI, and fills units to orders accordingto the priority established by the Ship List, subject to capacity constraints.

CURRENT IMPLEMENTATION Since units are sent to FGI at the end of the day, allorders are filled and shipped at the end of the day. First, units are allocated to DCs, and thebalance of the units are then allocated to orders directly out of HPFACT. We currently supportthe selection of one of two possible strategies. One is to fill DC allocations by prorating accordingto the total current demand if there are insufficient units, and filling according to the DC ship planif there are sufficient units. From the balance, orders on HPFACT are shipped according to somespecified priority. The second strategy is to fill the planned shipment to each DC in order untilthere are no more units.

We currently do not take into account capacity constraints on FILL-SHIP ORDERS.

FUTURE IMPLEMENTATION The SHIP LIST is computed on the basis of the DAILYBUILD PLAN for the day. Since the number of units produced is usually approximately but notexactly equal to what is planned, it follows that FILL-SHIP ORDERS may not be able to ship thecurrent day's planned shipments, or there might be excess units. However, since the SHIP LISTlists the orders to be filled by priority in the next 5 days, a shortfall in units will result in ordersbeing pushed out, while excess units could allow orders to be shipped a little earlier.

Alternative strategies may be studied in the filling of orders, such as in the case of shortage of aparticular product it is better to hold up a large order by filling up the smaller orders, or to holdup many small orders while filling up large orders. In addition, it should be possible to study theeffect of partial order filling, and shipping and carrier capacity constraints.

7 DISCUSSIONS

The foregoing description and discussions reflect an abstraction of the order to ship process we areaddressing on the modeling and simulation project. Simplifying assumptions were made to ease theprototype implementation; where the assumptions were too far from reality, they were changed,and the implementation updated to bring the system closer to reality.

7.1 ONE MODEL - MULTIPLE VIEWS

We have presented an approach to building a model of an organization which reflects the internalworkings of various components, which can show different views and present different levels of detailto different users. For the moment the approach gives insights into various aspects of the productionprocess; further extension of the modeling activities could place more emphasis to aspects that arerelevant to the R&D and Marketing functions of the corporation.

27

7.2 MEASURES OF PERFORMANCE

The current measures of performance are based on order receipt and shipment at HPFACT, eachDC, and the aggregate result. Measures include time to ship after an order is received, numberor percentage of orders shipped on or after the due date, or some similar derived measure whichis an estimation of customer satisfaction. Since the measures differ from DC to DC, there are fewmeaningful comparisons among them, and the overall measure is not consistent. By using measuresfrom the point of view of the customer, it would be possible to measure customer satisfaction directlyrather than indirectly.

Other measures of performance include weeks, units or dollars of FGI, WIP and RPI and in-transititems.

The measures of performance can be affected by various factors. For example, a FIFO orderfilling strategy will give a lower measure on immediate shipments, and make delays on all ordersapproximately equal compared to a LIFO order filling strategy. On the other hand, a LIFO orderfilling strategy will give good performance on recent orders, while making late orders really late.

7.3 OTS ABSTRACTION AND MODEL EXPANSION

The OTS Abstraction has been found useful for describing model components, and for implementingthem. By defining a general purpose OTS Abstraction and simplying it for the specific modelcomponents, many properties of the Abstraction can be re-used. A future document will describethe formal specification and implementation in greater detail.

The current framework for the OTS model lends itself to expansion fairly easily. To study a differentfactory, we need to substitute a new block characterizing the factory for the HPFACT OTS block.To study the interaction of a second factory or facility on the existing system, we need to introducea block parallel to the HPFACT OTS block in the SELL & DISTRIBUTE block. In either case,the new block is another OTS Abstraction.

7.4 FLOW OF CASH

The focus of this model has been on the flow of materials and information, since this appears to bebe the area of interest of the people we have interacted with. We have used dollars as a measureof quantity as an alternate to using units of the product.

The flow of money can be included in our model by treating money as another entity such asproducts, and by creating additional transactions on the Order to Ship Process by including thedelay between the time the Order is shipped to the time payment is received. The impact wouldbe to make the model more complex and useful to an additional class of customers.

A more appropriate application of the flow of cash model may be to determine how to utilizeavailable funds to greater advantage or to make cash balance projections when that is of interest.We have not investigated this area in sufficient detail to make any definitive statements.

28

8 CONCLUSION

In this document, we have tried to provide a flavor of the scope of the Order to Ship Process, andthe entities of interest we are studying. As we come to the end of this document, the reader mayfind that some of the things stated here run counter to personal experience, or may have somethoughts on expanding the capabilities and usefulness of the system. Please share these thoughtswith the author who may be reached at U.S. telephone number 415-857-8617, or by electronic mailat mujtaba@hpl.hp.com.

9 ACKNOWLEDGEMENTS

The work reported in this paper was done by the team of Bob Ritter, Bob Joy, and the author,all of whom are affiliated with Hewlett-Packard Laboratories. On behalf of the team, the authorwould like to take this opportunity to thank the people in the operating divisions who so graciouslyprovided us the information with which we built the model and simulation. The author would alsolike to thank his team members, other colleagues and the reviewers for their helpful comments andassistance in the preparation of this document.

29