Read Formulation of the Order-To-Ship Process Simulation Model text version


Formulation of the Order-To-Ship Process Simulation Model

M. Shahid Mujtaba Instruments and Photonics Laboratory HPL-92-135 December, 1992

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

The Order-To-Ship (OTS) process consists of activities between the time orders are received This document and products are shipped. provides a problem definition and description of the OTS process for an HP factory. A description of a computer model and the status of the model's implementation is also included. Additionally, we provide a qualitative description of our understanding of and approach to the OTS process. The paper also acts as a reference document for future summaries. We introduce the concept of the general OTS abstraction and show its application as a common component in the representation of the entities and activities we are studying. With this model we expect to examine issues such as how to increase responsiveness to customer orders while reducing levels of Finished Goods Inventory (FGI).

Internal Accession Date Only

Previously published as HPL-90-162, with security classification 'Internal Use Only'. © Copyright Hewlett-Packard Company 1992



1.1 PURPOSE AND ORGANIZATION OF DOCUMENT. . . . . . . . . . . . . . . .. 1.2 PROBLEM STATEMENT 1.3 DEFINITIONS OF TERMS AND CONVENTIONS. . . . . . . . . . . . . . . . .. 1.4 OUR APPROACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..


1 1 2 4


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


5 5 7 8 9

2.2 AUGMENTED MODEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.3 FORMAT OF DETAILED DESCRIPTION OF MODEL 2.3.1 2.3.2 2.3.3 2.3.4 PHYSICAL REALITY MODEL ABSTRACTION. . . . . . . . . . . . . . . . . . . . . . . . . . . .. CURRENT IMPLEMENTATION FUTURE IMPLEMENTATION

. . . . . . . . . . . . .. 10 10

3 Detailed Model- Part I: SELL and DISTRIBUTE Environment



10 11


3.3 C A R R I E R S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 MARKETING



Detailed Model 4.1 4.2 4.3



PRODUCT INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13 PARTS ORDERS OF FINISHED PRODUCTS 4.3.1 4.3.2 14 15



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

5 Detailed Model -

Part III: SELL and DISTRIBUTE Block Components


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 6.3 PLAN PRODUCTION 6.4 PLAN-MATERIAL-REQUIREMENTS 6.5 PROCURE-PARTS 20 21 22 23

6.6 STORE-PARTS....................................... 24 6.7 PRODUCE-PRODUCTS 6.8 FILL-SHIP ORDERS


25 26


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



29 29






The Order to Ship (OTS) process in a Hewlett-Packard (HP) factory includes the activities that occur between the receipt of orders from and shipment of products to customers. This document describes 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 information was 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 describes the general model for the OTS process. Sections 3 through 6 describe components of the model in greater detail. Section 7 provides discussions on the work to date.



The factory is a complex system made up of many interacting components. Even when precise mathematical formulas or solutions exist for particular problems, their application may be intractible 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 when applied to the stochastic nature of the real world. One way to study stochastic behavior of systems is via discrete event simulation using random numbers to characterize the nature of the real system. Until recently, the tools for discrete event simulation were generally simulation software and languages based on FORTRAN. The results, long lists of numbers printed on reams of computer paper, required substantial interpretation effort by an analyst before they could be used by decision makers. The advent of personal computers and workstations, interactive computation, improved graphical user interfaces, better programming environments, and more powerful programming concepts has simplified both the implementation of the simulation and the presentation of the results. These simplifications have propagated the use of discrete event simulation in situations in which it would never have been considered in the past, because they allow more decision makers and designers to use 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 an individual basis. Most simulations used mathematical models to address narrowly focused problems of the production line specific to the particular facility under study, and large portions of the modeling effort was duplicated at each site. In our research, we decided to address the more general 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. With the creation of this environment, we felt that previously unanticipated questions could be answered


with relatively little incremental effort. The accepted wisdom and the mainstream of conventional thinking in modeling and simulation requires full knowledge and understanding of the system and clearly defined questions before the model is built. Models are tailored to answer specific questions, and cannot be used easily to answer new questions posed after the model has been built. In the past, these limitations were due partly to the technology of developing simulations on a mainframe, and using batch processing with minimal graphics. The limitations were acceptable due to the slower pace of change in the factory. We realize that our approach of building the general model of a factory requires the deployment of 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 object oriented programming give us the tools to challenge the conventional approach. Our goal is to create a general approach to respond quickly to rapidly changing situations while bringing to bear the multiple viewpoints of the different parts of the organization. The expected payoff of the general approach is reduced duplication of effort each time a similar problem needs to be solved at a different factory or entity. The assumption in the past was that production took up much of the lead time for delivery of a 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 situation where the bulk of the lead time for order fullfilment is not attributable to activities on the production floor. The area of discrete event simulation of a factory model could provide insights in running the factory, and identify key variables and cause and effect relationships in the system. An abstract representation of the factory may be studied under different assumptions without experimenting with and disrupting the factory itself. Simulation of the factory can be used for at least two different purposes - the study of existing operations and their improvements in factories, and the design and study of future factories.



We will first define some terms and conventions that are used in the rest of this document. Where a term is first introduced, it is shown in italics. We define a factory as an entity which interacts with customers, vendors, and the corporate office for the purpose of adding value to its inputs in order to generate outputs which are worth more than the sum of the inputs and the resources consumed. Vendors provide needed material to the factory, customers need and purchase production of the factory, and the corporate office coordinates the activities of multiple factories. Within the factory itself we include Manufacturing, Marketing, 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 broad enough to include a factory that crosses state and national boundaries. It also permits customers and 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 physical world. It is made up of components which represent the aspects of reality that are of interest to us. The model includes within itself all information necessary to define its behavior. We need to draw the distinction between the model and the the data or external inputs acting upon it. The distinction between data and model is important since they represent the external and internal behavior respectively of what we are studying. By keeping the data the same and changing the model, we can study how internal behavior affects the outputs. By keeping the model the same and changing 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 model influences and defines this behavior. An OTS Entity is an entity which handles physical objects and which has some or all of the following characteristics: (a) it (b) it (c) it (d) it (e) it units (f) it (g) it generates orders for physical objects and sends them to other OTS Entities sends physical objects to other OTS Entities receives orders from other OTS Entities accepts physical objects from other OTS Entities accumulates orders and physical objects within itself and reports on their values (in or dollar values) when requested provides or receives money in exchange for physical objects 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 was under primary consideration. We did not explicitly model the movement of money in the model because this was not uppermost in the mind of the people we were interviewing. We will place greater emphasis on the movement of money in the future if feedback from readers suggests that this would be valuable. For the moment we treat money as an alternate measure of FGI and raw material inventories. A planned quantity is a computed or estimated value of some measure over a period of time or at a future point in time. A forecast or schedule is a sequence or list of planned quantities over successive periods or points in time in the future. The model will be represented diagrammatically and the notation used in the diagrams follows conventions similar to IDEF-0 1 . Circles are used in a context or environment diagram and show the external relationships of an entity or function with respect to other entities or functions. Rectangular blocks are used to represent the internal relationships between the sub functions of the entity or function. While a strong case could be made for representing sub functions as circles, for diagrammatic 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 information and 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, the functional relationships of a system.


which require action from the block''. Solid lines, dotted lines, and heavy lines from the right hand side of a block represent commands, information, and material (physical objects) respectively that are generated and come out of the blo~k. One shortcoming of IDEF-O is that there is no provision for describing timing information. . We shall adopt the following convention for textual description. Unless stated otherwise or obvious from the context of discussion, upper case letters (e.g. SELL PRODUCTS) will refer to the blocks in the figures representing the model. Words with upper case first letters (e.g. Orders) will refer to the representation of physical objects or information flowing between blocks. Lower case letters will be used to refer to the actual physical objects, functions or processes.



After visiting different HP divisions and talking to people in different functions we developed our preliminary model of the OTS process using IDEF-O notation. We implemented our preliminary model in KnowledgeCraft (KC? and in SLAM II 4 · While SLAM II was faster during execution of the simulation, representing our problem and making changes was more convenient using KC. As a result, we continued our activities using KC for the model development and simulation, and an HP Series 9000 Model 300 computer under the HP- UX operating system using the Xll Windows System for graphical display of data. After developing our preliminary model, we talked in greater detail to some HP manufacturing divisions. In early 1989, one HP Division (HPFACT) agreed to provide us with the insight and data from a real HP factory. Over a period of several months, three of us s visited HPFACT periodically. During each two-day visit, we talked to the experts representing the various functions in the preliminary OTS model. There is one physical factory, but the people who perform different functions hold different views of it. They abstract out and focus on facts important to maximizing what their success was measured on, possibly ignoring relevant details which might be important to someone else. While we had expected this, the impact of improving personal measures of success was brought to our attention rather forcefully. We found that ignoring apparently irrelevant details sometimes resulted in different parts of the organization working at cross or even opposing purposes even though they all 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 factory operated affected the behavior and needed to be considered. However, the size ofthe project group precluded 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 response is 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 the sender 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 Mujtaba 6In this situation, we made working assumptions to enable us to recognize and remember that there were interac-


The OTS model represents a portion of the factory in a computer manipulable form; different people using the OTS model are interested in solving different problems, and need to consider the details relevant to them. For example, material procurement is interested in how much it might cost to shorten lead time for a part. Stores are interested in how to predict and reduce storage requirements. Production planning is interested in fulfilling forecasted demand with minimum FGI and Work in Process (WIP). The OTS model can raise the awareness of the impact of the actions and interests of one entity on another. 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 forecast inaccuracies, activities associated with order processing, dealing with long lead time parts, and trading off the cost of greater generality in a product against the reduction in unit cost due to greater volume of fewer options 7 .





Figure 1 shows a breakdown of the Preliminary OTS Block diagram with eight functional blocks listed in the general chronological order in which they interact with orders. This figure demonstrates the original formulation and conceptualization of our ideas on which the subsequent model more specific to HPFACT was built. Some simplifying assumptions were that orders did not require corrections or clarifications, and could be shipped immediately when product units were available. Orders were never canceled, parts never ran short, and were always delivered on time.



Figure 2 shows the OTS Block diagram relating to HPFACT. It is the result of information gathering activities and intense discussions with HPFACT. While the eight functional blocks are the same as in Figure 1, notice the additional lines and interactions among the various sub-blocks reflecting more closely the operations at HPFACT. For instance, it shows Order Cancellation, which was not considered 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 and telephone centers at the distribution centers where orders are taken verbally or through receipt of physical purchase orders and transformed into computer readable form for tracking and billing purposes. In particular, sales office and interdivisional orders are entered into the central order

tions that we had not yet modeled. 7 for 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?


·Clean· Shipment Orders ORDER TO SHIP: Shipment Status Current Orders


REV 1.0

Forecast Info

Reschedule Request

ProdJct Info Part Orders



Figure 1: Preliminary Order-to-ship Block diagram

management system where they are consolidated and transmitted to the appropriate supplying division, in this case, the HPFACT division. Orders received at telemarketing centers are entered directly into the supporting systems at the DCs, shown here as DC1-0TS, DC2-0TS and DC3OTS, which are geographically located in different parts of the world. Note that Part Delivery is received only by the HPFACT-OTS, whereas all the DCs and HPFACT-OTS have outgoing shipments. 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 block exists. While its structure is similar to those in Figures 1 through 3, the use of circular rather than rectangular blocks is a convention to indicate that this represents the outermost boundary of the problem we are dealing with. CUSTOMERS interact with the SELL & DISTRIBUTE block through Customer Requests and/or Requirements and Order Cancellations. SELL & DISTRIBUTE provides Product Shipments to CUSTOMERS. Forecast Information (which is actually an order forecast) is sent to SELL & DISTRIBUTE by MARKETING. Product Information is a quasi-static structural entity that changes only when products are introduced or obsoleted and is presumed to be provided by RESEARCH


DC iXders cr> HPFACT iXders cr> HPFACT Cancel DC iXder Cancel iXder



I III Forecast Info






, 'I Ordar History I iXder ShPment






Cancel ~


----------DC StWabliIy


A-' MANAGE = 1:-:-~IFCIlECASTS~~~r II ~L ~ ~

II I "FI ~





-----DC FGI levels

Producl Info

_L _ _ _ _ _ _ _ _ II og - - - A--:'~ t"'" - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > [~ll:~ FGI I~ - - - - - - - - ~PradJclkJn Sched..Ies UOlY t>UIO an I r ~


L -







~is.¥~<rF~n':v~y Plals


-----Vendor Bushess

~ 11I

:I I

ProdJclion Plans. Stolus & Hislory

-I --j I I I I






Verdor : : Constants

Material - i~ P L A N ' II MATl R:;Qfl:'ran




~'!!~- ->

l -------I II I I I II II II 'I II II I I IL


11 1<- -~PROCURE 1- - - - -11- - - PARTS ~

L -


Part Dut~ · or Bad Paris

' Delivery /Sd'redle


Part iXders






Pari Deliv8IV

I Invoics










PIck U P Products


Part Contracls

- - - -->

_. u ~

1<- ~~

SIippi"lg Orders






L _____

L___ ' I



ProdJclion P1ans.~1 Status & Hislory l,Fgs:iIih! ~.J!

-I". /' ~ - ~ ~art_~N~ .:ta~_ - ~~1=~;W' ~ts 1-1- ErOJ!J::Lion_S!!./Hi!t _ _ _ ~ _ _ _ _ _ ~ \

Dn HCi-dI ,wen 1OrieS - - Prodi),s




I ~ __ HPE.,AQI .EGLl~el!. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

e!..aL ____ - ___ .:: ORDERS L________________,



, s ~,


1-5 I

~------------------------------~ Shj:JmenlSlalus

Dislrl:lulion Cenler Stock Fit

Figure 2: HPFACT Order-to-ship Block diagram

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



Sections 3 through 6 describe the model in greater detail. The entities will be grouped into four sets: (a) the (b) the (c) the (d) the components of the Context or Environment for SELL & DISTRIBUTE, class of PASSIVE ENTITIES which flow through the system, components of SELL & DISTRIBUTE, and components of a Manufacturing Entity.

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


CXder Ccn:eUation

Customer Req.Jests and/or Requi'emenls


Dealers. End User Inlernal

Goverment OEM's






I 1 I


Cancel Order


Clear/ Bad


~OrderS on HPFACT

/ Orders on DC





r -






DC Orders on HPF~C


Cancel Order



DC3 OTS ~-,'

~ I





II I II I I ~ I II I ~----rl I I 1 II II I

II 11


- - -



DC2 OTS F.,'

! ~PF~l

~ I I

I I I I I A-~ 1" 1-



IDC Order

Bad Order . ~IIs



- - - - r

I I I I I l



DC Orders =~. onHPF

I-Clear Bad DC Order





-----Vendor Busroess PQrformanc.

Forecasl Info

-----Pari Delivery

_.., I I - - -;. c -


1.:- - - - ~I

I I I 1- -


I I Ai :i: V_I'"§'" PF ACTII:



Pari Orders

I II II -Vl: f- -

- - - - - .... -----+----~II I I I I IDC FGl Levels 1 I I I


II Pr ft 'i....c ~ !!'




- - -

Y!- -- -- -- --




I I DC stock FI I I I I DC Supply Plans & Target FGI Levels I I _________ ~------------------------~ J I L ______________


l1 ~'~~e :r:



""""""" Orders.



. ~Is

Figure 3: SELL and DISTRIBUTE Block diagram

(a) (b) (c) (d)

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



We shall describe our understanding of reality specifically with respect to HPFACT and try to formalize and generalize our conclusions where possible. While recognizing the pitfalls in generalizing across all of HP observations made at HPFACT, stating our observations formally can provide the framework for making changes expediently when it becomes apparent that generalized observations are not general or accurate enough. Our observations and understanding reflect a snapshot in time, since the processes themselves were changing during study'', This showed the importance of structuring 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 the process we had acquired on the previous visit, we were sometimes told that the process had changed.


Forecast Info _ _-.




..... - j - -.;

/ Orders


Product Info


Part Delivery or Performance Falure




Bushess Performance

Figure 4: Context or Environment for SELL & DISTRIBUTE

is neither complete nor detailed, but we shall incorporate more relevant details as they become available. 2.3.2 MODEL ABSTRACTION

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


Where possible, we will try to identify components as special cases of the OTS Abstraction. OTS Abstractions interact with one another, and they can be hierarchical. So far, CUSTOMERS, VENDORS, CARRIERS, SELL & DISTRIBUTE, DC3 OTS, DC2 OTS, DCI OTS, HPFACT OTS, STORE PARTS, PRODUCE PRODUCTS, and FILL-SHIP ORDERS are clearly identifiable as 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 characteristic of handling physical objects.



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



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


Detailed Model ment


Part I: SELL and DISTRIBUTE Environ-


PHYSICAL REALITY Customers have varying characteristics and differing needs in terms of the urgency with which the product is needed. The sequence in which the order is filled may be 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 in the planning process when the orders are placed.

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


We currently assume that priorities are identical for all


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 lumped together.



PHYSICAL REALITY Many to many relationships exist between vendors and parts. A single vendor 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 supporting and building long term relationships with primary and secondary sources. This requires managing vendor relations, including such activities as keeping the vendor apprised of current and future plans, and making long term commitments for order quantities. The advantage to the vendor is the certainty of knowing that there exists a stable customer (HP) with a long term demand who will accept all the vendor's production as long as the vendor maintains quality and delivery performance. This certainty encourages the vendor to invest in modern and more efficient facilities. Each vendor may be represented as an OTS abstraction. Vendors accept part orders, and respond with acknowledgement dates and subsequently shipments fulfilling those orders. In our diagram, VENDORS accept Part Orders, and Part Deliveries represent fulfillment of those orders.


Each vendor provides a different part, and each part is provided by only one vendor. The lead time for a part is known and is always constant; the parts are shipped by the vendor a fixed time after the order is received. The fixed time is different for each part. The part price is fixed. At the moment, the acknowledge date for part shipment is not provided and HPFACT uses the known lead time for planning purposes.


FUTURE IMPLEMENTATION The many to many relationship between vendors and parts can be established and simulated; this will introduce more complexity since different vendors could supply the same part at different prices with different lead times. The inter-relationship between unit 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 times and rejection rates are other additions we could make to the model inputs.



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


from being available to the end user for consumption or to the supplier for reallocation. A further constraint 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 weekly or less frequent movements. MODEL ABSTRACTION Carriers can be treated as OTS Abstractions that provide time delays between shipment and receipt of items. CURRENT IMPLEMENTATION Currently, the carriers are arbitrarily classified and associated with each of the DCs, HPFACT, Customers, and Vendors, and the transit time for each carrier 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 their transportation capacities and characteristics as values that need forecasting and monitoring.



PHYSICAL REALITY Marketing collects information from various sources, including the trade 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 an existing 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 made at 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 to the lead time of the longest lead time part, is of interest to PLAN PRODUCTION and PROCURE PARTS. The longer term forecast is of interest to Corporate Materials which consolidates the requirements of all divisions to compute gross material requirements for negotiating volume contracts. MODEL ABSTRACTION MARKETING is an entity that accepts information from various parts of the environment and periodically generates Forecast Info. CURRENT IMPLEMENTATION MARKETING is an entity external to the SELL & DISTRIBUTE block, and the Forecast Info it generates is set currently to a constant value. The forecasts are generated once a month, and provision has been made to allow different forecast values each month. FUTURE IMPLEMENTATION As we obtain more information, we shall implement the rules that are used by marketing to update the forecasts using historical data.




Detailed Model- Part II: PASSIVE ENTITIES


PHYSICAL REALITY Each factory produces many products with different options made

up of multiple levels of subassembly. Certain subassemblies and parts may be duplicated in a product, while other subassemblies and parts are common across different products. Each product and subassembly requires lower level subassemblies and/or raw materials as well as production operation activities. Establishing the unit value of the product is a complex issue. Accounting practice allocates different values to a unit of the product at various stages in its existence. It has one value when it rolls off the end of the production line, another value when it is loaded on the carrier on its way to the customer (and the values may differ according to the customer), and a different value when it is held as FGI at the division or at DCs. Furthermore, the unit value of a product changes over time based 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 important when it is necessary to aggregate diverse products using a common and readily acceptable unit of measure, namely dollars. The particular product under study at HPFACT came with different options. There is a large number of common parts and a small number of specialized parts for each option. In the final assembly, the product is made up of parts that are provided by vendors, or produced in a different part of HP. One example of parts produced in a different part of HP is PC boards which are made from raw boards onto which electronic components are placed.

MODEL ABSTRACTION Each product has a product structure, which is a list of the part and the quantity of each part that goes into the manufacture of each unit of the product. The unit cost of the product is more than the total cost of its components, since it also includes the cost of some transformation. The value of the product is different from its cost, and is dependent on the location. CURRENT IMPLEMENTATION To simplify the computer model, we aggregate similar products, subassemblies, and parts together into fewer categories than those required in the real factory. The level of aggregation is an engineering tradeoff; less aggregation provides more precise results, but requires greater computational power.

The product structure is treated as data to the factory model. In running experiments with the preliminary OTS model, we used three hypothetical products made up of six different parts. Each product is made up of three different kinds of parts, and there is only one level of assembly. Some parts 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 product demand directly into the parts requirements. In the early phases of the experiments with the augmented OTS model, we are still using the


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 in the near future. As additional levels of information interpretation become necessary, we expect to explore ways of setting the aggregation level dynamically. For example, the PC board subassembly could be introduced to examine the effect of additional levels of production scheduling and increased computational complexity, and we could consider the effect of components that do not lend 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. When there are many different ones, we need a common measure, and the accounting unit and generally accepted measure is dollars. The pricing issue is a fairly complex one which needs to be resolved satisfactorily for the purpose of reducing everything into terms of dollars. A secondary measure is weeks of demand.



PHYSICAL DESCRIPTION Parts are supplied by different vendors with different quality levels at different price volume combinations. Since the characteristics of parts are so tightly associated with vendors, a fuller description is given in the section under VENDORS. MODEL ABSTRACTION Parts are physical objects that are passed between OTS Abstractions, 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 is supplied 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 shipment frequency which depend on order quantity, lead time, and vendor. CURRENT IMPLEMENTATION Currently we measure parts in units or dollars only, and assume a single vendor with deterministic lead time per part. This assumption simplifies our current simulation activities.

Normally the reject rate is zero, but can be set to some percentage. We currently have no restrictions on 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 of a manufacturing division, there is a distinction between products and parts. However, from the more global view, the parts for one entity are the products for another entity, and each product can 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 and product structures in the implementation.


4.3 4.3.1



PHYSICAL REALITY During the day, orders arrive at the sales office either from customers

or sales representatives and are entered into the central order processing system system. Internal orders from other HP divisions are also entered into this system by their respective purchasing departments. The system breaks down the individual orders into sub-orders, and transmits the consolidated suborders periodically to the supplying divisions where they are available for processing the following morning. The orders received by divisions are checked for correctness and configuration consistency by order processing. Each order is given an acknowledgement date, which is received by the sales office or HP division the following morning. This is the normal sequence and timing of events. In urgent cases, telephone communication between the sales office personnel and their counterparts in the order processing department may reduce the time taken to receive a preliminary acknowledgement date. We could not identify an order that is typical for all divisions. Within one division, orders may range across 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 one item on the order. DCs receive their stock from the division 10. High volume original equipment manufacturer (OEM) orders, large dealer orders and internal HP orders are shipped directly from the division. Orders usually have a required date. Depending on the nature of the product ordered, the customer may 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 inconvenience for the customer. An important issue in customer satisfaction is delivery within an acceptable window, and the quoted lead time needs to reflect this. If the quoted lead time is too long, the customer may take business to a more responsive supplier. Order shipments may be specified as 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. In general, orders are filled in a first-in first-out (FIFO) fashion, although exceptions may occur when prioritizing rules are used. Orders may be modified or cancelled anytime before shipment, and sometimes an order that is shipped 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 the telemarketing center 12 and can be processed and filled by the distribution center immediately if the required product is available in FGI. The DCs supply dealers and some end customers, but not internal HP divisions.

discussed in more detail in the next section if the customer has to prepare the site 12 Another working assumption


11 e.g.


MODEL ABSTRACTION Each order that arrives at the SELL-PRODUCTS block includes the 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 items on a single order. The orders are checked for correctness. The correct orders are exploded into sub-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 external customers collectively each day is a parameter. We can use deterministic values to ensure repeatability of orders received for each simulation run, or stochastic distributions to characterize the system more accurately when the data is available. Order streams may also be specified from a file. Currently we use order inputs from a file. There is a mix of large and small orders depending on 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 acceptable date (LAD) and delivery date. If these are not specified, the EAD and required date are assumed to 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 same priority, 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 entity specified on the order.

FUTURE IMPLEMENTATION In future we expect to handle more sophisticated and complicated priority schemes, and to modify orders that are already in the system. Also, we expect to allow SELL-PRODUCTS to route the orders to the appropriate entity according to characteristics of the customer.

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



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

One is that DCs place orders on the supplying division, just as other HP divisions do, and their orders receive a high priority. In some cases, the supplying division recommends to the DC how much and when to order. The DC can use its discretion in accepting this. This gives the DCs the choice 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 for studying the reason behind the non-uniform distribution, and inducing order arrival in a more linear and regular fashion. Alternatively, we could look for ways to reduce sensitivity to non-uniform order streams.


order could be held up in shipping for lack of a few units which could just as easily be sent on a later shipment. It also means that space on air or ocean carriers must be reserved in anticipation of the orders instead of according to the production plan. A second inconvenience is when the units available are insufficient to fill the total high-priority DC requirements. In this case a tough decision on how to allocate the limited number of units available must be made, and the DCs would be 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 to the 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 the least effort, there is a practical difficulty when it comes to international shipments. Although the transfer is between different HP entities, movement of goods across international boundaries generally requires filling units against an order quantity, and the financial and governmental approvals must be met against the number of units on the order. When the number of units is not exactly equal to what is on the paperwork, it can cause some difficulties.

MODEL ABSTRACTION The DC Stock Fill represents the flow of products from the division to the DC for the purpose of redistribution. The flow of products may be initiated directly by the supplying division or in response to a DC order. CURRENT IMPLEMENTATION Currently, we compute the DC Supply Plans on a monthly basis, and provide two options for the actual DC Stock Fill. One is to fill the plans as closely as possible by DC each day until units run out. The other is to prorate limited availability of units according to the sum of current backlog and the DC Supply Plan, thus providing some realtime feedback of the actual orders to the system, and reducing excess FGI at the DC where demand is lower, and reducing backlog at the DC where demand is higher. FUTURE IMPLEMENTATION We will provide means for the DC to place orders on HPFACT and for specifying other strategies for allocating units to the DC when the units available cannot fill the demand.



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


MODEL ABSTRACTION The Forecast Info is a set of lists of total quantity of each product that 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 early days, followed by an arbitrary distribution of quantity of products for a particular order. This assumption simplifies the initial conditions of the system, and permits all the state variables of the system (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) during product introduction and obsolescence. For a new product, the order forecast may show a gradual rise, or a big initial surge (when the dealer inventories need to be built up) followed by a dip and subsequent recovery to a steady volume.


Detailed Model Components




PHYSICAL REALITY The SELL-PRODUCTS block represents a logical entity whose physical realization is spread out over various physical areas. It represents the the sales and order taking activities of the company. Sales Offices are spread out all over the world, and are co-ordinated centrally through the central order processing system, which accepts all order inputs from sales offices and other divisions. While the SELL-PRODUCTS function interacts mainly with the outside world, part of it interacts with internal HP divisions. As we add other HP entities or manufacturing divisions to the OTS model, we do not need to add new SELL-PRODUCTS blocks. MODEL ABSTRACTION The SELL-PRODUCTS block responds to Customer Requests and/or Requirements and Order Cancellation from CUSTOMERS by re-routing and receiving the appropriate information from the DCs and the division or asking for clarification for Orders that are not correct. CURRENT IMPLEMENTATION SELL-PRODUCTS receives Customer Requirements, and transmits them to the DCs or to HPFACT as Orders. Orders are routed arbitrarily to the DCs or HPFACT according to some specified ratios or percentages. Acknowledgement dates are not provided to the customer. FUTURE IMPLEMENTATION More features will be added so that we can handle Order Cancellation and provide acknowledgement dates to CUSTOMERS.




PHYSICAL REALITY A DC in general has the purpose of acting as a giant warehouse holding many different kinds of products which can be drawn and shipped out on demand. It is a buffer between some external customers and divisions. The DC is responsible for obtaining items in bulk from various locations, breaking them down, and then building up loads out of these items. The loads are then sent out to customers. The primary emphasis is on breaking down bulk shipments of finished goods into single components and building up shipments out of the components. Manufacturing or assembly is non existent or very limited''"; in some ways, the DC can be considered a transshipment center or a broker. The DC would like to keep a minimum level of inventory, and increase 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 products, DC Stock Fills, and may order products from divisions. Its measures of interest include the level of each item of FGI, and the amount of products/orders on backlog.

CURRENT IMPLEMENTATION Whenever orders are received at a DC, FGI is checked for the required items and quantities, and filled immediately if possible. Each time the DC receives a 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 order received that is outstanding is filled first, and FIFO (first in, first out), in which the oldest order is filled first. We have currently modeled the three DCs mentioned.

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


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 factory entities. The factory entity is currently composed of the eight sub functions represented by the sub-blocks in Figure 2 and described in subsections 6.1 through 6.8. Since much of the information was derived from HPFACT, the description of the sub functions is biased naturally towards those of HPFACT.


e.g. packing manuals with products




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

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

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

CURRENT IMPLEMENTATION In our current implementation all Orders received by PROCESS ORDERS are clean, and never cancelled or modified. Acknowledgement dates are not provided to the customer. In addition, DCs do not place orders on the division. FUTURE IMPLEMENTATION We expect to add the following enhancements to PROCESS ORDERS: handling order cancellation and modification, generating an acknowledgement for the ship date, and indicating priority values and unclean orders. We also expect to enable PROCESS ORDERS to handle orders from DCs.



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

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


MODEL ABSTRACTION The MANAGE FORECASTS block receives Forecast Info, which is a set of order forecasts. For each order forecast given, it computes the Order Shipment Forecast using the Forecast Info and the DC Shippability Profiles from historical information. CURRENT IMPLEMENTATION For the current model, we compute the Order Shipment Forecasts by multiplying the appropriate order forecast with the shippability profile. Currently, the default shippability profiles is assumed to be 100 % for the current month, and 0 % for subsequent months. FUTURE IMPLEMENTATION We will use historical experience on the pattern of EADs to generate the DC Shipp ability Profiles and use that to compute the Order Shipment Forecasts.



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

The Production Schedule is the source for computing the DC Supply Plans (schedule of products shipped 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 near term is the freeze period, which is a period of commitment necessary for resource and personnel planning, and maintenance scheduling. The freeze period shields PRODUCE PRODUCTS from having to react to temporary fluctuations in the order stream and provides stability on the production floor. Outside the freeze period, the plan may change within the limits of production capacity and material availability.

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

(a) Shipment Demand is the sum of the Backlog at the beginning of the month and the Order Shipment 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 production line, and material availability, if it is outside the freeze period, or the value that was computed in a previous forecast if it is within the freeze period.


(d) DC Supply is the same as Demand on HPFACT if Production can meet Demand on HPFACT, 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 monthly projections.

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

FUTURE IMPLEMENTATION The primary assumption made in our computations is that limits are hard (e.g. production capacity is fixed at certain levels), and that we are bound to those limits 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 capacity on one line, and a shortage of capacity on another line, the labor portion of the capacity can be shifted easily by transferring people.

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



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

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


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

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

FUTURE IMPLEMENTATION Multiple level subassemblies will increase computational requirements, 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 in material requirements with respect to changing product demand. In the future, we may expand the PCB assembly to give a second bill of materials explosion.



PHYSICAL REALITY The Material Requirements Plan as defined above should not change unless the Production Schedule changes. However, to order sufficient material, PROCURE PARTS takes into account the actual material on hand and projected deliveries in the near future, to generate the Material Procurement Plan 15. This is computed periodically at HPFACT, and is available 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 relevant factors. Parts are classified as A, B or C parts. A parts generally need more attention than B or C parts because they are large, expensive or used in large quantities, and require careful scheduling for ordering and arrival. C parts are generally smaller and of lower value, and are bought in quantity whenever a lower threshold of number of units is reached. Generally, whenever a new Material Procurement 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 orderacknowledge transaction occurs to provide verification on when the parts can be expected to show up. IT projected delivery dates from suppliers are not satisfactory, appropriate action can be taken before the situation becomes a crisis.

MODEL ABSTRACTION PROCURE PARTS generates a Material Procurement Plan from current material on hand, projected receipt of material, the Material Requirements Plan, and lead time of parts. Parts are ordered according to the plan, and the information is sent to the STORE PARTS 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 and vendor, 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


CURRENT IMPLEMENTATION PROCURE PARTS uses the Material Requirements Plan to generate the procurement plan. All Parts are ordered weekly on Monday mornings and we ignore the A, B and C classifications. The lead-time of the part is deterministic, and the quantity of parts ordered ensures sufficient parts on hand to support the Production Schedule. In line with the operating procedure at HPFACT, we use the Material Requirements Plan associated with the Contingent Production Schedule for ordering materials. At the moment we do not use Projected Material Availability in computing the Procurement Plan. FUTURE IMPLEMENTATION We could make the system more realistic by spreading out the ordering over the week. In addition, we could implement part specific order intervals on the basis of the three classes of parts.

We could try different strategies for procuring parts, and assume that the part lead times have different statistical properties. The parameters for the distributions may be set or changed in the middle of a simulation run. In that event, it would be useful to compute an effective lead time to use in ordering parts, and to use a pre-determined probability level of having the part in hand when required. The lead time of the material could change with the volume required or could be reduced by paying a 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 Procurement Plan, and to specify safety raw material stock levels.



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

STORE PARTS issues materials, parts and subassemblies when required by production through Parts Requests from Product Products. STORE PARTS is responsible for keeping track of material on hand, and material about to be received. The obvious constraint for STORE PARTS is that it cannot meet the requirements of production if something required is missing; the conventional wisdom has been to buffer stock everything to prevent 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 production line, so that STORE-PARTS can avoid handling individual parts. This of course requires a certain amount of co-ordination with PROCURE PARTS.

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


from PRODUCE PRODUCTS, STORE PARTS sends as much as it can. When Part Outages occur, both current and projected, resolution requires co-ordination with PROCURE PARTS.

CURRENT IMPLEMENTATION STORE PARTS does not store subassemblies. This reflects the situation for HPFACT with respect to HPPROD. It keeps a running total of parts on hand called 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 PARTS may 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-ordinate with PROCURE PARTS. This does not take into account catastrophic events which will force a emergency change in the production plan on the day of production.



PHYSICAL REALITY Products are produced on the production floor, where all the required parts, materials and subassemblies for final assembly come together to produce the finished product or subassemblies of the factory according to the Production Plan. Each day, Produce Products issues 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 production capacity 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 of parts is empty, the empty bin is sent to a staging area where a signal is sent to STORE PARTS to deliver another bin of the appropriate part within a certain guaranteed response time. The bin of parts method of supplying parts is limited to parts where convenient quantities can fit into the bins. 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 finished units, 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 of them include line downtime, parts outage, or a large proportion of bad parts. If the Daily Build Plan is not completed, somehow the shortfall units must be made up, or subsequent Daily Build Plans modified.

MODEL ABSTRACTION PRODUCE PRODUCTS is an OTS Abstraction which converts parts into products according to the Product Structure. The quantity of production is determined by 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 measure of the number of parts and finished goods on the production line. PRODUCE PRODUCTS makes


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

CURRENT IMPLEMENTATION In the current implementation, PRODUCE PRODUCTS asks for required parts at the beginning of the workday to complete planned production for the day, 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 corrected by insufficient FGI levels in a subsequent planning period. Line downtime can be specified as a parameter ofthe model in terms offrequency and the percentage of planned production that is not completed.

FUTURE IMPLEMENTATION We will permit PRODUCE PRODUCTS to issue Parts Requests by empty bins. If parts are not available when expected, production will be held up causing delay to orders, and at the same time, either or both of PRODUCE PRODUCTS and STORE PARTS 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 to build 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 between STORE 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 a single conversion between Parts and Products in WIP per day. At the other extreme, we can model parts being requested by the bin as each bin is emptied, and the finished units being produced by the unit, updating the WIP component values as each unit is produced.



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

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


MODEL ABSTRACTIONS FILL-SHIP ORDERS is an OTS Abstraction that removes completed units from the WIP of PRODUCE PRODUCTS to FGI, and fills units to orders according to 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, all orders are filled and shipped at the end of the day. First, units are allocated to DCs, and the balance of the units are then allocated to orders directly out of HPFACT. We currently support the selection of one of two possible strategies. One is to fill DC allocations by prorating according to the total current demand if there are insufficient units, and filling according to the DC ship plan if there are sufficient units. From the balance, orders on HPFACT are shipped according to some specified priority. The second strategy is to fill the planned shipment to each DC in order until there 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 DAILY BUILD PLAN for the day. Since the number of units produced is usually approximately but not exactly equal to what is planned, it follows that FILL-SHIP ORDERS may not be able to ship the current day's planned shipments, or there might be excess units. However, since the SHIP LIST lists the orders to be filled by priority in the next 5 days, a shortfall in units will result in orders being 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 a particular product it is better to hold up a large order by filling up the smaller orders, or to hold up many small orders while filling up large orders. In addition, it should be possible to study the effect of partial order filling, and shipping and carrier capacity constraints.



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




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




The current measures of performance are based on order receipt and shipment at HPFACT, each DC, and the aggregate result. Measures include time to ship after an order is received, number or percentage of orders shipped on or after the due date, or some similar derived measure which is an estimation of customer satisfaction. Since the measures differ from DC to DC, there are few meaningful comparisons among them, and the overall measure is not consistent. By using measures from the point of view of the customer, it would be possible to measure customer satisfaction directly rather than indirectly. Other measures of performance include weeks, units or dollars of FGI, WIP and RPI and in-transit items. The measures of performance can be affected by various factors. For example, a FIFO order filling strategy will give a lower measure on immediate shipments, and make delays on all orders approximately equal compared to a LIFO order filling strategy. On the other hand, a LIFO order filling strategy will give good performance on recent orders, while making late orders really late.



The OTS Abstraction has been found useful for describing model components, and for implementing them. By defining a general purpose OTS Abstraction and simplying it for the specific model components, many properties of the Abstraction can be re-used. A future document will describe the formal specification and implementation in greater detail. The current framework for the OTS model lends itself to expansion fairly easily. To study a different factory, 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 introduce a block parallel to the HPFACT OTS block in the SELL & DISTRIBUTE block. In either case, the new block is another OTS Abstraction.



The focus of this model has been on the flow of materials and information, since this appears to be be the area of interest of the people we have interacted with. We have used dollars as a measure of 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 as products, and by creating additional transactions on the Order to Ship Process by including the delay between the time the Order is shipped to the time payment is received. The impact would be 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 utilize available 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.




In this document, we have tried to provide a flavor of the scope of the Order to Ship Process, and the entities of interest we are studying. As we come to the end of this document, the reader may find that some of the things stated here run counter to personal experience, or may have some thoughts on expanding the capabilities and usefulness of the system. Please share these thoughts with the author who may be reached at U.S. telephone number 415-857-8617, or by electronic mail at [email protected]



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 author would like to take this opportunity to thank the people in the operating divisions who so graciously provided us the information with which we built the model and simulation. The author would also like to thank his team members, other colleagues and the reviewers for their helpful comments and assistance in the preparation of this document.



Formulation of the Order-To-Ship Process Simulation Model

33 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate


You might also be interested in

Microsoft Word - Textile_Technology_Syllabus.doc
Modelling and analysis of business process reengineering
Microsoft Word - M&S Final.doc
Formulation of the Order-To-Ship Process Simulation Model