Design of Operations Planning and Control

Design of Operations Planning and Control
Systems (DOPCS)
School of Industrial Engineering
Eindhoven University of Technology
Authors:
J.W.M. Bertrand
J.C. Wortmann
J. Wijngaard
N.P. Suh
M.M. Jansen
J.C. Fransoo
A.G. de Kok
T.M. de Jonge
Table of Contents
Table of Contents
1 Principles of Design
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 What is Design? . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Design Process . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Functional Requirements: Definition and Characteristics
1.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Design Axioms . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Designers and Their Creative Process . . . . . . . . . . . .
1.9 Design for Manufacture . . . . . . . . . . . . . . . . . . . .
2 Conceptual Design, Detailed Design, and Integration
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Conceptual Design . . . . . . . . . . . . . . . . . . . .
2.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . .
2.4 Integration and Implementation . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
3
4
5
5
8
9
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
14
15
3 Hierarchical Production Planning

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Hierarchies in Planning . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 The Eindhoven Planning Framework . . . . . . . . . . . . . . . . .
3.4 Relation to other HPP Frameworks . . . . . . . . . . . . . . . . . .
3.5 Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Asymmetry in Supply Chain Planning, Schneeweiss Anticipation
3.7 Effectuation Lead Times . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 The Need for Control . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
18
20
21
23
26
27
4 A Note on the Design of Logistics Control Systems

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Design rules for product design. . . . . . . . . . . . . . . . . .
4.3 The Logistics Control System Design problem . . . . . . . . .
4.4 Modularity, information hiding, abstraction, and interfaces
4.5 The Production Unit Control design problem . . . . . . . . .
4.6 The Goods Flow Control Design Problem . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
31
32
33
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Appendix A Introduction to Production Control
38
Appendix B Production Units and Goods Flow Control
55
Appendix C Goods Flow Control Structure
93
Appendix D Production Control in a Complex Component Manufacturing Firm
128
Bibliography
187
CHAPTER
Principles of Design
Acknowledgment
This chapter is based on Chapter 1 and 2 from Principles of Design, written by N.P. Suh and used
with his permission. Some parts are a copy from his work and other parts are modified for the
purpose of this reader.
1.1
Introduction
Even simple questions related to design cannot be answered without first understanding the nature
of design, the creative processes involved in design, and the role of analysis in this process. Furthermore, an endless debate could follow from a discussion of design, because everyone has his or
her own notion of design-related issues, just as he or she does about the common cold. Therefore,
we must define several important terms such as Design, Functional Requirements (FRs), Design
Parameters (DPs), and Constraints. Although it may appear cumbersome and irrelevant to consider
design in a formal and rigid framework, the short-term burden of having to deal with the formal
framework may ultimately prove beneficial.
1.2
What is Design?
Design involves a continuous interplay between what we want to achieve and how we want to achieve
it. For example, on a grander scale, we may say what we want to achieve is to go to the moon,
whereas the how is the physical embodiment in the form of rockets and space capsules. On a
smaller scale, what we want to achieve may be the measurement of a minute amount of moisture
in plastic pellets, and how may be the special titration instrument. These examples show that
the objective of design is always stated in the functional domain, whereas the physical solution (the
actual operations planning and control system) is always generated in the implementation space.
The design procedure involves interlinking these two domains at every hierarchical level of the
design process. These two domains are inherently independent of each other. What relates these
two domains is the design.
To proceed, we must determine the designs objectives by defining it in terms of specific requirements, which will be called functional requirements (FRs). FRs are a minimum set of preferably
independent requirements that completely characterize the functional needs of the design in the
functional domain. By definition and thus in theory, each FR is independent of other FRs. However,
in practice this is nearly impossible because of the complexity of operations planning and control
systems. Therefore, we strive to make the functional requirements as independent as possible by
choosing them in a smart way. To satisfy these functional requirements, a set of design parameters
(DPs) must be created. DPs are the key variables created by the design process to fulfill the FRs.
The set of DPs forms the design space, within decisions and design choices will be made. By making
these design choices, the operations planning and control systems is designed. The design process
involves relating these FRs of the functional domain to the DPs in the design space and finally by
making design choices in the implementation space. This is illustrated in Figure 1.1, where DPs in
the design space are chosen to satisfy FRs in the functional domain.
Design may by formally defined as the creation of synthesized solutions in the form of products,
processes or systems that satisfy perceived needs through the mapping between the FRs in the
functional domain and the DPs of the design space, through the proper selection of DPs that satisfy
2
Chapter 1. Principles of Design
Functional space
FR1
Design space
FR3
DP1
DP4
FR2
DP2
FR 4
DP5
DP3
DP6
Implementation space
Goods Flow Control
PU1
PU2
PU3
Figure 1.1. Design is defined as the mapping process from the functional space to the implementation space to satisfy the designer-specified FRs.
FRs. This mapping process is non-unique, the actual outcome depends on a designers individual
creative process. Therefore, there can be an infinite number of plausible design solutions and
mapping techniques. The design axioms (Section 1.6) provide the principles that the mapping
technique must satisfy to produce a good design, and offer a basis for comparing and selecting
designs.
1.3
Design Process
The design process which is illustrated in Figure 1.2, shows that the design process begins with
the recognition of a societal or business need. The need is formalized, resulting in a set of FRs in
the functional domain to satisfy the given set of needs. The selection of FRs, which defines the
design problem, is left to the designer. Once the need is formalized, DPs are chosen, such that
all FRs are included. The structure of DPs is analyzed and compared with the original set of FRs
through a feedback loop. When the set of DPs does not fully satisfy the specified FRs, then one
must either come up with a new set, or change the FRs to reflect the original need more accurately.
This iterative process continues until the designer produces an acceptable result. The next step is
to generate ideas to create an organizational structure (or a product) for the operations planning
and control system. This structure is created by making design choices, i.e. by selecting a value for
the different DPs. A value can be more than a number here, it can be a decision rule for the way
products are taken from stock for example. In describing the design process, it was stated that the
later step is the definition of the problem to be solved in terms of FRs; that is, we must establish
the FRs from the needs that the final product or process must satisfy. This is clearly one of the most
critical stages in the design process. This definitional step requires insight into the problem, and
a knowledge base encompassing issues related to the problem. Poor problem definition leads to
unacceptable or unnecessarily complex solutions.

How do we actually determine FRs to satisfy the perceived needs? There are two distinct
approaches, depending on whether we are attempting to create a major new innovation or whether
the goal is to improve an existing design, such as a car door.
When the goal is to create design solutions that have not previously been in existence, FRs
must be defined in a solution-neutral environment; i.e., the functional space. In many cases the
establishment of an acceptable (or correct) set of FRs may require an iterative process. The most
desirable iteration cycle, next to no iteration, is the reiteration at the conceptual stage of the
design process itself, as other going through other phases with a mediocre design would be time
inefficient and, above all, extremely costly. Once the conceptual design is completed, the expected
performance of the resultant design concept can be compared with the original perceived needs. If
they differ, then an improved set of FRs can be established without incurring the cost of making and
testing hardware and/or software.
One of the major problems in design is that designers do not state explicitly the FRs that
their design must satisfy. They try to design intuitively and do not recognize the probable need
to reiterate the establishment of FRs until a satisfactory design results. When a new set of FRs is
established, the corresponding solution may be completely different from those previously tried.
It may be useful to state once more the importance of proper problem definition in design: the
perceived needs must be reduced to an imaginative set of FRs as the first and most critical stage of
the design process. In the absence of a proper set of FRs, a good design is not likely to result.
The final output of the design process is information in the form of drawings, specifications,
tolerances, and other relevant knowledge required to create the implementation concept. The
design solution should be as simple as possible, so the design output can be conveyed with minimal
effort. The total information involved should therefore be as small as possible.
1.4
Functional Requirements: Definition and Characteristics
Since the designer can arbitrarily define the FRs to meet a certain perceived need, an acceptable set
of FRs is not necessarily unique. Two designers might have chosen different sets of FRs, depending
on their judgments of the perceived needs. The implementation concept will be very different
depending on the particular set of FRs chosen. However, in the final analysis, the implementation
Shortcomings:
discrepancies,
failure to improve
Reformulate
Societal/
business need
Recognize &
formalize (code)
Compare
Ideate &
create
Product,
prototype,
process
Analyze
and/or
test
Functional
requirements &
constraints
Product attributes
Marketplace/
implementation
Figure 1.2. The design loop. More effective synthesis requires enhanced creativity, more powerful
analysis, and improved decision bases. (Adapted from Wilson, 1980)
concept must satisfy the perceived needs. When designing a new operations planning and control
system, it is difficult to choose the correct set of FRs on the first try, but we will provide the reader
with some guidelines in this reader.
Corresponding to a set of FRs, there can be many design solutions, all of which satisfy the same
set of FRs. When the original set of FRs is changed, a new solution must be found. The new solution
may not be derived by simply modifying the previously obtained solutions that were acceptable only
for the original set of FRs. Many designers often make the mistake of trying to adapt or modify an
existing solution when the FRs are changed by the addition of new FRs to the original ones, rather
than seeking a completely new solution.
To reiterate, a good designer must have the ability to choose a minimum number of FRs at each
hierarchical level of the FR tree. Some designers are proud that their design products can perform
more functions than were originally specified. In this case, they have overdesigned the product.
Consequently, it is more complex, more costly, and less reliable than is necessary. The designer who
creates such a solution should go back and search for a simpler solution.
1.5
Constraints
Constraints in the context of axiomatic design represent the bounds on an acceptable solution.
They are of two kinds: input constraints, which are constraints in design specifications, and system
constraints, which are constraints imposed by the system in which the design solution must function.
The input constraints are usually expressed as bounds on size, weight, materials, and cost, whereas
the system constraints are interfacial bounds such as geometric shape, capacity of machines, and
even the laws of nature.
It is sometimes difficult to determine when a certain requirement should be classified as an FR
or as a constraint. In many cases cost is a constraint rather than an FR: its precise value is unimportant, as long as it does not exceed a given limit. Another distinguishing feature of constraints is that
they do not normally have tolerances associated with them, whereas FRs typically have tolerances.
As we go through the design process, zig-zagging between the functional, design and implementation spaces, what used to be DPs at a higher level of the DP hierarchy may become constraints
at a lower level of the DPs hierarchy. It becomes easier to select a set of FRs when the problem is
highly constrained. The more constraints there are in a given design problem, the easier it becomes
to narrow down the possible choices for FRs. In some cases the number of FRs at a given level of
the FR hierarchy may be very small due to a large number of constraints, which should simplify the
design process. The probability of the same set of FRs being chosen by all designers increases as the
number of constraints is increased. As the choice for FRs decreases with the increase in constraints,
the number of permutations for selecting FRs decreases, which should force convergence to a similar set of FRs. This is the case when and only when the imposed constraints on all designers are
exactly identical.
1.6
Design Axioms
As discussed in Section 1.3, the first step in design is to define a set of FRs that satisfy the perceived
needs for an operations planning and control system. The second step is the creation of the right set
of DPs. The central question is: As we map DPs in the FR space, are there certain rules or axioms
that are satisfied by a good design? The uncovering of these axioms has provided significant
insight to the design process itself, and forms the scientific basis for design and synthesis (Suh et al.
1978a,b).
The basic goal of the axiomatic approach is to establish a scientific foundation for the design
field, so as to provide a fundamental basis for the creation of an operations planning and control system. This is a significant difference from the conventional design process, which has been
dominated by empiricism and intuition. Without scientific principles, the design field will never
be systematized, and thus will remain a subject that is difficult to comprehend, codify, teach, and
practice.
By definition, axioms are fundamental truths that are always observed to be valid and for which
there are no counterexamples or exceptions. Axioms may be hypothesized from a large number of
observations by noting the common phenomena shared by all cases; they cannot be proven or
derived, but they can be invalidated by counterexamples or exceptions.
There are two design axioms that govern good design. Axiom 1 deals with the relationship
between functions and physical variables, and Axiom 2 deals with the complexity of design. These
axioms can be stated in a variety of semantically equivalent forms. The declarative (or procedural)
form of the axioms is (Suh, 1984):
Axiom 1 The Independence Axiom
Maintain the independence of FRs.
Axiom 2
The Information Axiom

Minimize the information content of the design.
Axiom 1 states that during the design process, as we go from the FRs in the functional domain with
DPs in the design space, the mapping must be such that a change in a particular DP must affect
only its referent FR. Axiom 2 states that, among all the designs that satisfy the Independence Axiom
(Axiom 1), the one with minimum information content is the best design. The term best is used
in a relative sense, since there are potentially an infinite number of designs that can satisfy a given
set of FRs. Axioms 1 and 2 may be restated as follows:
Axiom 1 The Independence Axiom
Maintain the independence of FRs.
Alternate Statement 1: An optimal design always maintains the independence of FRs.
Alternate Statement 2: In an acceptable design, the DPs and the FRs are
related in such a way that specific DP can be adjusted to satisfy its corresponding FR without affecting other functional requirements.
Axiom 2
The Information Axiom

Minimize the information content of the design.
Alternate Statement: The best design is a functionally uncoupled design
that has the minimum information content.
Note what we stated earlier, satisfying the two Axioms stated by Suh here could only be reached
in product design or in a hypothetical and optimal situation. This is not possible for operations
planning and control systems because these systems are very complex. Although one might strive
to independent FRs, one will probably notice quickly that this is unfeasible in reality. Therefore, we
would advice to choose the FRs in a smart way by choosing a set of FRs which are as independent
as possible but also such a set that the number of FRs is kept at a minimum.
The following example is provided to build understanding for the Axioms, but is not one-toone applicable to operations planning and control systems. Take a refrigerator door design as an
example. The question is: if there are two FRs for the refrigerator door (access to the stored food
and minimal energy loss) is a vertically hung door a good design? We can see that the vertically
hung door violates Axiom 1 because the two specified FRs (i.e., access to the contents and minimum
energy use) are coupled by the proposed design. When the door is opened to take out milk, cold air
in the refrigerator escapes and gives way to the warm air from outside. What, then, is an uncoupled
design that somehow does not couple these two FRs? One such uncoupled design of the refrigerator
door is the horizontally hinged and vertically opening door used in chest-type freezers. When the
door is opened to take out what is inside, the cold air does not escape since cold air is heavier than
the warm air. Therefore, this type of chest freezer door does satisfy the first axiom.
We may note here that when we refer to the satisfaction of the FRs, the solution is understood
to satisfy the original FRs within a certain tolerance band; that is, even in the case of the chest-type
refrigerator door, there is some energy loss upon removal of the contents. However, if the FR is
stated so that the energy loss is to be less than 10 calories per opening of the door, and if the energy
loss associated with the chest refrigerator does satisfy this requirement, then it is an acceptable
solution.
Uncoupled, coupled, and decoupled
Design can be separated into three groups: uncoupled, coupled, and decoupled (or quasi-coupled)
designs. An uncoupled design satisfies Axiom 1, whereas a coupled design renders some of the
functions dependent on other functions, and thus violates Axiom 1. A coupled design may be
decoupled; when the coupling is due to an insufficient number of DPs in comparison with the
number of FRs that must be kept independent, we may accomplish this by adding extra components,
which increases the number of DPs. A decoupled design may be inferior to an uncoupled design in
the sense that it may require additional information content.
Functional coupling should not be confused with physical coupling, which is often desirable
as a consequence of Axiom 2. Integration of more than one function in a single part, as long as
the functions remain independent, should reduce complexity. An example that illustrates the use
of physical integration without compromising functional independence is the bottle/can opener
design discussed in the following example.
Suppose that we are interested in designing a simple, low cost bottle/can opener that can be
operated manually. The FRs of the device are:
F R1 = Open beverage bottles.
F R2 = Open beverage cans.
By definition, the two FRs are independent, but no mention is made of concurrency; that is, we
sometimes wish to open a bottle or a can, but not both simultaneously.
A simple device that satisfies the above set of FRs is shown in Figure 1.3. This is a very simple
opener that can be made by stamping a sheet metal strip. In this design the means for achieving
the two FRs independently are embodied in the same physical device rather than in two separate
components. Therefore, minimal information content is required to manufacture the device. Are
the FRs coupled by the design? The design does not couple the FRs, because the act of opening
cans does not interfere with or compromise the requirement of opening bottles. The FRs would
be coupled only if there were an FR to open bottles and cans simultaneously, which is not the
case here. The two separate functions are fulfilled by one physical piece, but without functional
coupling. Physical integration without functional coupling is advantageous, since the complexity of
the product is reduced, in line with Axiom 2.
Before leaving this section, it should be noted again that the identification of the ultimate optimal design having minimum information content cannot be guaranteed; also, there is no method for
generating all potential designs. We can only identify the best design on a relative basis among those
proposed, using Axioms 1 and 2. However, the ability to eliminate unacceptable or unpromising
ideas in their early stages enhances the creative part of design, and reduces the cost of development
and the chance for failure.
Figure 1.3. Can and bottle opener. This bottle/can opener satisfies two FRs: (1) opens cans, and
(2) opens bottles. If the requirement is not to perform these two functions simultaneously, then this
physically integrated device satisfies two independent FRs.
1.7
Hierarchy
There are two very important facts about design and the design process, which should be recognized
by all designers:
FRs and DPs have hierarchies and they can be decomposed.
FRs at the i th level cannot be decomposed into the next level of the FR hierarchy without first
going over to the design space and developing a solution that satisfies the i th level FRs with
all the corresponding DPs. That is, we have to travel back and forth between the functional
domain and the design space in developing the FR and DP hierarchies.
In this section we explore these two aspects of FRs and DPs. In considering the design of a refrigerator door in Section 1.6, we initially confined our attention to the most important problems.
We considered the energy loss and the access to the food in the refrigerator. We did not concern
ourselves with the specific ways in which the door was to be hung, or about the insulation technique. Only after we decide whether or not the door should be hung vertically should we worry
about other details. This is always the case in all design processes. The FRs and DPs can always be
decomposed into a hierarchy. Indeed, we are extremely fortunate that this is so, because we may
focus on only a limited number of FRs at a time, thereby reducing the complexity of the design task
immensely. The intricacy of the design task increases rapidly with the rise in the number of FRs at
a given level of the FR hierarchy.
A previous discussion touched on the need to alternate between the functional domain and the
design space in the design process. This is illustrated further here. As stated previously, the design
process begins in the functional domain with the specification of the first level of FRs. Suppose we
wish to design a passenger vehicle that can transport people within a city. We may specify the first
level of FRs for the vehicle to be the following:
F R1 = Ability to move forward.
F R2 = Ability to move backward.
F R3 = Ability to change directions.
F R4 = Ability to stop.
Having stated these four first-level FRs, we must now conceptualize a physical vehicle that can
satisfy them. Without completing this conceptualization process, we cannot decompose these firstlevel FRs further into lower level FRs. We must switch to the design space from the functional
domain, and vice versa, in order to be able to proceed with the design process. Indeed, the design
process requires that we switch between the functional domain and the design space each time we
move down the hierarchy. For example, in the case of the passenger vehicle, one of the solutions for
satisfying F R1 and F R2 is to use a battery-powered d.c. electrical motor and a double-pole switch.
Then F R1 and F R2 can be further decomposed in the context of this implementation space.
The designer must recognize and take advantage of the existence of the functional and design
hierarchies. A good designer can identify the most important FRs at each level of the functional
tree by eliminating secondary factors from consideration. Less-able designers often try to consider
all the FRs of every level simultaneously, rather than making use of the hierarchical nature of FRs
and DPs. Consequently, the design process becomes too complex to manage.
It is easier to illustrate the nature of the functional and design space hierarchy by analyzing
an existing product. For example, the functional hierarchy and the design space of a lathe are
shown in Figures 1.4 and 1.5 respectively. By comparing these two figures, it should be clear that
we cannot simply construct the entire FR hierarchy without referring to the DP hierarchy at each
corresponding level. That is, without having decided to use a tailstock, we could not have stated
the three FRs: tool holder, positioner, and support structure.
9
Metal
removal
device
Power
supply
Workpiece
rotation
source
Longitudinal
clamp
Speed
changing
device
Workpiece
support and
toolholder
Support
structure
Tool holder
Positioner
Support
structure
Rotation
stop
Tool holder
Tool
positioner
Figure 1.4. Lathe functional hierarchy.
Lathe
Power
Motor drive
supply
Clamp
Head stock
Handle
Gear box
Tailstock
Bed
Spindle
assembly
Feed screw
Frame
Bolt
Pin
Tapered
bore
Carriage
Figure 1.5. Lathe system design space hierarchy.
1.8
Designers and Their Creative Process
The ideational part of the design process is a creative process. How does one become creative? A
number of people have tried to answer this question (Shaw, 1986). A creative person has a number
of unique qualities. Such a person tends to be a risk-taker who is willing to accept failures, has a
good memory and a vast store of knowledge rooted in many fields, knows how to use analogies and
how to extrapolate and interpolate from known applications to a new situation, reduces a complex
array of facts, data points and information to a limited number of critical sets of variables, and
combines known facts to create a new solution. To create through analogy, the person must have a
10
multidisciplinary background. Thomas Edison made many inventions using analogical techniques
(Jenkins, 1987). Most inventive processes are hit-or-miss activities, requiring much trial and error
and being an alert observer. Often people chase after worthless ideas because they do not know
that their ideas have basic flaws. The axioms described in this reader provide criteria and thus
streamline the hit-or-miss process. The axioms, particularly Axiom 1 (see Section 1.6), provide
guidelines regarding the functions to be satisfied and the way in which they are to be satisfied.
There are good and not-so-good designers; one of the attributes of a good designer is the
ability to satisfy the perceived needs with a minimal set of independent FRs. As the number of
FRs increases, so the solution becomes more complex. Therefore, it is necessary to satisfy only the
absolutely essential functions at a given stage of design. Normally, when a problem is presented to
a designer, it looks very complicated, with, a large number of variables. A good designer has the
ability to identify only the most important requirements and ignore those of secondary importance
for consideration at a later stage. This ability requires a broad as well as an in-depth grasp of the
issues involved. This ability can be cultivated, but only with great difficulty.
Furthermore, a good designer must he able to operate in the conceptual world of the functional
as well as the implementation space. For example, the designer must know how FRs are independent of each other, in order to choose a set FRs which are least independent, avoiding unnecessary
complexity. Many designers often evolve things that cannot be manufactured, or can be manufactured only with great difficulty and expense, because they do not clearly define and analyze the
relationship between DPs and FRs. In order to avoid this situation, the designer must be familiar
with manufacturing processes, the laws of nature, and basic scientific principles.
The choice of FRs depends on the way in which the designer hopes to satisfy a set of needs.
The determination of a good set of poorly defined perceived needs requires skill and sometimes
extensive market study. This is an important step in the design process, because the final design
cannot be better than the set of FRs that it was created to satisfy. In addition to the FRs, designers
often have to specify constraints. There can be many different kinds of constraints such as cost,
geometrical size or weight. Often these constraints have a limiting effect on design as explained
earlier. Constraints differ from FRs in that, as long as the product designed does not exceed the
constraints, then the solution is acceptable, whereas a specific range of design values must be
maintained for each FR at all times.
1.9
Design for Manufacture
In the field of manufacturing, the most important words are productivity and reliability. Productivity may be defined as the total output value of the factory divided by the total input. Although
such terms as labor productivity have been used, they are becoming useless measures in modern
manufacturing operations, since the total direct labor cost is becoming a smaller fraction of the
total manufacturing cost. Often the material is the dominant cost item, followed by indirect costs
in discrete parts manufacturing. In view of the importance of productivity and reliability in manufacturing, we need to understand the relationship between design and manufacturing.
The basic question related to design for manufacturability is: How do we assure that the design decisions incorporate manufacturing concerns? The key answer is this: when the product and
process designs do not harm design axioms at all levels of the FR, DP, and Process Variable (PV)
hierarchies, then the product should be implementable. On the other hand, if the process or the
product involves coupled designs, then it will be more difficult to implement, because the manufacturing steps taken during the later stages of production can affect or undo the work of earlier
stages. When the design axioms are satisfied by the product and the process, the implementability
of the product is assured (Suh, 1985).
The design axioms can better ensure design for manufacture if we develop specific corollaries
or design rules, based on the axioms, applicable to specific instances of manufacturing. Stoll (1986),
in his review paper, gives the following design rules for efficient manufacture, which can be easily
developed for certain specific cases from the design axioms.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11
Minimize the total number of parts.

Develop a modular design.
Use standard components.
Design parts to be multifunctional.
Design parts for multi-use.
Design parts for ease of fabrication.
Avoid separate fasteners.
Minimize assembly directions.
Maximize compliance.
Minimize handling.
If these rules are used indiscriminately, it is obvious that the designer may act incorrectly and
violate the axioms. Therefore, if rules are to be developed, their use must be constrained to specific
situations. For example, the first rule may not be correct if the total number of parts is minimized
at the expense of coupling FRs, since this violates Axiom 1.
CHAPTER
Conceptual Design, Detailed Design, and Integration
2.1
Introduction
In this chapter we explain what in designing an operations planning and control system is meant
by and what has to be included in the conceptual design, the detailed design, and the integration
and implementation phase. Industrial engineering students are used to work with numbers and
would like to make calculations right from the start of a project. They will experience that this
approach will not be helpful in designing an operation planning and control system. In designing
such a system, (in depth) calculations are primarily made in the integration phase, in which these
calculations are going to be automated in order to make it possible to adjust the design and quickly
recalculate what the influence of the change in design will be. Important in designing an operations
planning and control system is that there is a qualitative analysis which provides the right arguments
that underpins the design made. The main task in designing a system is not to make the right
calculations, but to design a system which is robust for changes in the environment and at the same
time provides the best performance.
The explanation in this chapter is focused on a production system. However, this will not
say that the structure cannot be used in designing other kind of systems. We have already seen
successful applications of this design structure in the spare parts and transport industry. The final
design one makes, has to state exactly (in terms of rules) when to execute what process with which
resources. However, before one reaches this goal, one will experience that a huge solution space
exists. In coping with this solution space, the rules made, the feasibility of the entire system,
and the responsibilities provided to each actor in the system are extremely important to clearly
declare. Although some design choices might not be optimal in designing an operations planning
and control system, which is by definition complex, it is more important to design a system that is
feasible and satisfying the requirements, while being at the same time robust (stable and can cope
with uncertainty) than an optimal system which is unstable and unreliable.
What follows in the remaining sections is an explanation of the conceptual design in Section 2.2. Next, the detailed design is explained in Section 2.3 and finally the integration and
implementation phase is explained in Section 2.4
2.2
Conceptual Design
As mentioned before, the largest pitfall for industrial engineers who are unknown with design of
operations planning and control systems is to start making calculations right away. The first step
one should make in designing is get an understanding of the problem. By interviewing company
employees, experts in the field of industry or experts in designing operations planning and control
systems, and by reading background material, one can get an throughout understanding of the
company and of its industry.
With this knowledge, one can make the second step, which is to define the scope of the system.
By setting the right boundaries, one knows what is and what is out of scope. By taking this step,
all possible team members understand which processes are taken into account in the system to be
designed. Moreover, it helps to form the right and a complete set of Functional Requirements (FRs),
which is the next step.
First, one has to state the FRs for the entire system. In most cases when designing an operations
planning and control system, this is done by setting a certain service level that has to be met, for
12
Chapter 2. Conceptual Design, Detailed Design, and Integration
13
example 95% of the orders has to be delivered within two days. Another important FR that is often
used is to maximize the companies profits or to minimize its costs.
After stating the FRs for the entire system, one can focus on the processes that have to be
executed in the production system. One often sees that there is a large number of processes that
is executed sequentially or in parallel. As it is too difficult to take into account the whole process
at once and it is neither useful to look at each process separately, one has to define production
units (PUs) as explained in Chapter ?? and explained in more detail in Chapter ??. By doing so,
the process is decoupled, in that sense that PUs can operate (relatively) independent of each other.
Independent means that for each PU FRs can be defined and that it can make its own rules regarding
for example lead times, production hours, and safety stock. The relationship between these PUs will
be determined and controlled by the Goods Flow Control (GFC), as introduced in Chapter ?? and
explained in more detail in Chapter ??. Four main reasons can be identified to decouple a processes:
The two successive processes are not synchronized in either speed, setup or uncertainty. When
one would not decouple these processes, it would be extremely difficult to design a feasible,
controllable and thereby robust system.
There is a difference in the opportunity to vary resources. If the resources for two processes
cannot or hardly be exchanged, it would not make any sense to model the two processes in
the same PU.
There is a difference in commonality. This is, when a certain process uses a different batch
size of the products or if the product changes in a certain way that the unit used in the one
process is not comparable to the unit used in the other process.
There is a difference in information available. If one or two processes have a (relatively)
long lead time, new information can become available, for example a more accurate demand
forecast as we show in the following example. The lead time of making cheese including
maturation can take up to a couple of years. However, the actual demand for this cheese is
not known exactly until the customer demands the order, which can be only a few days before
transportation to the customer (i.e. the order lead time (or customer-required lead time) is
much shorter than the production lead time (or supply chain feasible lead time)).
After the production units have been designed, it is useful to identify the Customer Order Decoupling Point (CODP). This point is located between two PUs and indicates the moment from which
products are made to order, while all (semi-finished) products till this point are made to stock and
thus based on the expected demand instead of based on the actual demand. It is preferred to position this point as far as possible from the customer, as upstream (early in the complete process) as
possible. This is beneficial because actual orders are known, and production can be based on these
orders. The advantage is that products can be made for known customers and thereby (safety)
stock and process times can be minimized and the service level can be maximized. However, in
most cases the production lead time will be longer than the order lead time, which forces the point
of the CODP more downstream. This is however less beneficial as one has to produce based on
an estimated demand and as a consequence one may have to build (safety) stocks to meet service
levels.
Now the production process has been divided in several PUs, modules that coordinate the
different PUs have to be designed. One of these units is the Goods Flow Control (GFC). This unit
coordinates the different PUs as well as for example the different stock points in the supply chain.
In its function, it receives information of inventory levels and order information and provides orders
to the production units how much and when to produce to meet the FRs of the entire system. An
important separation that has to be made in the GFC is between the detailed decisions regarding the
products, so when to produce how much of which products and the aggregate decisions regarding
the resources, when are resources used and for which PU.
When all modules (PUs and others) have been created, FRs have to be set for each of the
modules. If each of the modules meets its FRs also the entire system will meet its FRs, in a well
14
designed system. These FRs can be for example that the inventory level at a certain stock point must
be such that in 95% of (internal) demand can be satisfied from stock or that a PU must produce
98% of the orders within four weeks.
In making a design, one needs to keep in mind the relation between Production and Sales as
introduced in Section ??. In many situations Production has to make what Sales has sold. However,
this is not a desirable situation, which can lead to an unwanted and unstable process. Therefore,
one should use the following four insights in designing an operations planning and control system,
which will lead to a coordination between Production and Sales:
Order definition. A Sales order is rarely to never the same as a Production order because of
the positioning of the CODP as explained earlier.
Order acceptance. It is advisable for production to make an order acceptance function. This
is a function defined by the system designer with which Sales can determine whether an order
can be accepted without creating an uncontrollable situation for Production.
Seperation or responsibilities. As PUs are decoupled and operate relatively independent, so
must Sales and Production work relatively independent in the sense that each department has
its own responsibilities. For example, it is not the responsibility of Sales to make a production
plan because this department has not enough insights and knowledge in Production to make
these decisions.
Sales and Operations Planning. To make sure that there is a good coordination between
Production and Sales, a so called Sales and Operations Planning (S&OP) has to be organized
periodically. In this meeting, sales orders are converted into production orders and the forecast of Sales is used to tune the Production planning.
Considering an order acceptance function for the system is the last step in making a conceptual
design. Although the design now has been finished, a very important step has to be executed in
making the conceptual design final. The feasibility in terms of lead time and capacity of the FRs set
for the modules as well as for the entire system have to be checked. In other words, it has to be
checked whether the products can be produced in the requested time and whether there is enough
capacity to do this. One has to keep in mind that a feasible and robust system that satisfies the FRs
is preferred above an optimal system. If one has defined a service level of 98%, one should not
design a system that optimizes the service level at the expense of the robustness of the system as
this might lead to a complex and overdesigned system.
In checking the feasibility of the FRs of the modules and the entire system, key is to make
simple calculations and not to go in depth too much. In the detailed design (Section 2.3) one can
do this deeper analysis. Important is that one can make a lead time analysis and that the variability
in the demand and processes is related to the utilization (and thus capacity) by making simple
calculations (see also for formulas Hopp & Spearman (2000)). Another important point is to first
perform a feasibility check for each of the modules, after which it is easier to make a feasibility
check for the entire system. When the entire system is feasible and satisfactory, the conceptual
design can be considered as final. However, this does not imply that the design cannot be changed
if necessary. As one may have noticed, the number of calculations made in the conceptual design is
minimal, while the qualitative analysis is crucial.
2.3
Detailed Design
The detailed design takes the conceptual design as a staring point. In this phase the modules and
structure designed in the conceptual design is considered as given. Only in case the design can be
improved by using a certain technique, it is desirable to change the design. However, it is important
to keep in mind that a system is desired which meets the FRs.
The detailed design phase starts with understanding the conceptual model. After this, rules
are made for each of the modules such that the FRs can be met. For example, one can decide
to implement the (s,S) inventory rule for a certain stock point. Another example of rules are the
15
production rules First In First Out (FIFO) and Least Processing Time (LPT). Important in choosing
the right rule is that the system meets the FRs, while at the seem time staying feasible. Key is
to respect the decisions made in the conceptual design. In the conceptual design PUs have been
designed and decoupled, such that each unit can operate relatively independent. In the detailed
design therefore rules have to be based on the information which is only locally available, i.e. the
PUs cannot influence PUs and do might not know the design of other PUs. This means that a PU
can only make decisions based on the information that it receives from other sources (for example
orders from the GFC) or information that is available in the PU itself.
During the design of rules for each of the PUs, one has to make assumptions. These assumptions can be based on the demand of the final product or the subsequent PU) and on the supply (of
the raw material or the previous PU). In making assumptions it is preferred that these are adapted
in an iterative way and that there is a good ground for making these assumptions.
There is a number of important factors and insights that have to considered when making the
detailed design. Important factors in designing the rules for each of the PUs are for example the
set up times and set up costs (for example by using a lot sizing rule). Also the use of sequencing
rules and the assessment between cost, speed, and reliability of certain resources is an important
consideration. Lastly, also the simultaneous need of resources for certain processes can be a challenging problem. For example for engineers which can be used in production as well as in testing,
it is important to provide a rule to which PU they have to give priority.
As one has noticed, again in this phase a minimum to no calculations are made, it is primarily
describing which rules have to be used in the execution of the process. So, most important is that
rules are made and that they are underpinned with arguments. These rules have to ensure that the
system meets its FRs while at the same time the system remains feasible and stable.
2.4
Integration and Implementation
The last phase in designing an operations planning and control system is the integration and implementation phase. We define integration as the coupling of the different PUs into one system and
implementation as implementing the system in a software package to test the system and to make
adjustments in case necessary. Finally, the system can be implemented in the company.
The integration of the different PUs and modules with each other is rather simple if the detailed
design has been executed well. Whereas the total process has been decoupled, it should still be clear
how the PUs are linked to each others, which products are passed from the one PU to the other and
in which form: one by one, by a batch or in a different way. Also note that a timely production
in case of, for example, an assembly process should already be incorporated in the detailed design
(when to produce which product).
The implementation can still be a challenging task, also when a good detailed design is available. All PUs have to be implemented in the right way and the right connections between the PUs
have to be implemented. However, the first step is the decision of a proper software package based
on the goal of the implementation; a system designer might have different needs than a daily planner. Regardless of the user, it is essential that the tool has a clear and user friendly dashboard on
which the user easily can adjust the settings of the system and moreover from which it is easy to
read all desired performance indicators, which can be called the input and output of the tool.
After the system has been implemented in a software tool, it should be verified and validated.
Verification is checking whether the tool performs as it has to, does it provide the desired outputs.
Whereas validation is the check whether the model provides an output that is reasonable with respect to the reality. After these checks the model can be used to calculate the performance indicators
and (small) adjustments in conceptual of detailed design can be made to improve the designed system, i.e. increasing the systems performance under the same or lower cost assuming the current
design meets the desired performance levels. When a satisfactory result has been obtained, the
system can be implemented in the company. However, this step falls out of the design scope of this
reader.
CHAPTER
Hierarchical Production Planning
Acknowledgment
This chapter contains work of the PhD Thesis of M.M. Jansen and parts of Chapter 12 from the
Handbooks of Operations Research: Supply Chain Management: Design, Coordination and Operation
written by J.C. Fransoo and A.G. de Kok. The work has been used with their permission.
3.1
Introduction
Supply Chain Planning concerns a large collection of decisions taken over time that coordinate the
primary process of a firm (or multiple firms). These decisions are taken at various organizational
levels, with various levels of detail, concerning activities over different time intervals and with different magnitudes of (financial) implications. A classical ordering of these decisions was proposed
by Anthony (1965). Anthony distinguishes three hierarchical levels of decision making: strategic
planning, tactical planning (management control), and operational control.
At the strategic level, organizational goals are established and decisions are taken about the
long term development of resources needed to achieve these goals. The decisions at this level
are aimed to guarantee the continuity of the firm and have large financial implications. Decisions
include for example the placement and construction of production facilities and warehouses, and
the acquisition and disposal of production equipment.
At the tactical level, it is decided how facilities and equipment are utilized to achieve the organizational goals. This is the level where the Sales and Operations Planning (cf. Olhager, Rudberg,
& Wikner, 2001) of the firm takes place and decisions are often directly related to the budget.
Capacity levels, workforce, and aggregate production quantities for families are decided on at this
level. Tactical decisions also include targets for stock levels and workloads, priorities, and lead
times. If change-over of machine setups is expensive or requires considerable time, also lot-sizes
are determined at this level.
At the operational level, decision making is effective on shorter time intervals and detailed
information is available on the current and future state of the supply network and future demand.
At this level, detailed plans are made and executed to meet the targets set by, and with the resources
made available by the tactical planning level. Decisions include the release of production orders to
PUs, and the commence of activities carried out in the PUs to produce these orders to plan.
The remainder of the chapter is structured as follows. First in Section 3.2 we describe what a
hierarchical production planning (HPP) is and which frameworks have been used in the past. Next,
the Eindhoven Planning Framework is discussed in Section 3.3 and its relation to other frameworks
in Section 3.4. In addition we describe the three different types of uncertainty common in supply
networks in Section 3.5 of which we will explain the asymmetry of information in more detail in
Section 3.6 as an introduction to the hierarchy of Schneeweiss, which can also be found in the same
section. Finally we conclude this chapter with the important concept of effectuation lead times in
Section 3.7.
3.2
Hierarchies in Planning
We define hierarchical production planning as follows: Hierarchical production planning is a structural approach to the problem of coordinating activities in the primary process of the firm where the
16
Chapter 3. Hierarchical Production Planning
17
authority and responsibility to make decisions is distributed over levels and each higher level determines the constraints within which lower levels are free to pursue local objectives. A hierarchical
production planning system adheres to the following fundamental rules:
higher level decisions precede lower level decisions in time;
the part of the primary process of the firm that is effected by a higher level decision is not
smaller than the part that is affected by a lower level decision;
the period of time over which a higher level decision is effective is not smaller than the period
of time over which a lower level decision is effective;
the planning horizon at a higher level is not smaller than the planning horizon at a lower
level.
Decisions with regard to the different components of planning of supply chain operations have traditionally been analyzed independently from one another by researchers. Research addressing the
scheduling problem, the (multi-echelon) inventory problem, and the aggregate capacity planning
problem have hardly been interconnected while maintaining their own characteristics. On the contrary, in the late 1960s and early 1970s attempts have been made from each of these domains to
expand the scope of research and apply their available specific methods to other components of the
supply chain planning problem. In these approaches, the specific nature of each of the components
has however been disregarded, and the problems have developed into conceptually monolithic
models. An illustration is the work on combining lot sizing and scheduling (see, e.g. Dauzre-Prs
& Lasserre, 1994), in which two models remain to exist, but a final solution is obtained by iterating
between the two models.
Managers were however still faced with this multitude of different problems in the supply
chain planning domain. They solved these issues by organizing these decisions in a hierarchical
manner. Meal (1984) analyzes and describes these hierarchies and links them to the hierarchical
planning hierarchies introduced by Hax & Meal (1973) and Bitran & Hax (1977).
Decisions with regard to the planning of supply chain operations have traditionally been taken
at the operational level. Meal (1984) argues that this was necessarily decentralized due to the lack
of good information processing technology. In this approach, which he names the conventional
approach, operations planning decisions were an integral part of the decision making power of the
line managers in all parts and at all levels in the organization. Decisions were only coordinated
marginally, and certainly not in a systematic manner. Due to the emergence of large-scale information processing technology in the 1970s, initiatives were taken to create large-scale comprehensive
models of planning operations. Meal (1984) calls this the centralized approach, which is based
on a tendency to create central decision functions which are given the power to control in detail the
planning decisions of the operational process in all parts of the organization.
There are a number of difficulties associated with these centralized monolithic decision models
(see also Fleischmann & Meyr (2002)). The models tend to be very big and complex. This makes the
analysis of the models and finding an optimal solution very difficult and requires a decomposition
of the model in order to be able to solve this. Model decomposition is a widely used strategy
in solving optimization problems. Apart from the complexity in the mathematical sense, there
are also a number of organizational and people-related difficulties associated with the centralized
approach. The most important difficulty is that there appears to be no owner of the monolithic
model. Responsibilities within organizations tend to be dispersed over a number of people. The
monolithic model assumes it is a single organizational unit deciding about a large number of details
across the entire organization. If we assume that the higher-level management would actually own
the model and make these decisions, a number of people and model related difficulties come about:
Detailed figures do not mean much to higher-level managers.
Detailed figures give a false sense of security because they may be highly unreliable, not only
if they refer to some future state of the system (e.g., forecast of exogenous data), but also if
they refer to the current state of the system (data quality problems).
18
Centralized planning takes away authority from local managers further down the hierarchy
and reduces their responsibility, which is not in line with the dominant management philosophy of self-containedness and autonomous groups. Apart from that, it is also contradictory
to a principle from control theory, which states that responsibility and decision authority
should be matched with the opportunity to control. This last issue is extensively discussed by
McPherson & White Jr. (1994), who state that Planning at superior levels must be consistent
with control capabilities at subordinate levels, while planning at subordinate levels must be
consistent with achieving the superior goals of the hierarchy.
A model never captures the complete richness of a situation. As a consequence, a local planner
down the hierarchy will always have more information and a better representation of the
actual processes than a (higher-level) model.
All this leads to the fact that a decomposition of the problem is required in order to be able to find a
solution to the planning problem that can also be implemented within an organization. If a decision
problem is decomposed and a hierarchy is constructed, higher levels of the hierarchy will need to
aggregate the lower level models. This aggregation is necessary to overcome the difficulties just
listed. Furthermore, this decomposition will lead to more or less independent units along the supply
chain, that are self-contained with regard to their control within the unit, but receive objectives and
constraints to be taken into account from an aggregate and centralized control function. This is
in line with the idea of separating goods flow control and production unit control, as explained in
Chapters ?? to ??. A consequence of this approach is that lead times of the various production units
are fixed and are input to the system rather than output.
The planned lead time is essential to the coordination of goods flows in the supply network.
The planned lead time of an item is the time between the release of an order and the planned
availability of the goods in the items stock point. Note that the fixed lead time we are discussing
here is the internal lead time of the controlled part of the supply chain that needs to be distinguished
from the external lead time promised to any customers of this supply chain. The external lead time
must vary to reflect the work load changes over time. As a consequence of this approach, workload
control is executed over the supply chain. The planned lead time is input both to the SCOP level
and to the PU level. It is exogenous to the SCOP problem and should not be confused with the flow
time of an order. For the PU, the planned lead time determines the due date of orders released to
it. Note also, that the planned lead time is the time until the planned availability of the order and
not necessarily its planned downstream usage. These lead times are then essentially modeled in
exactly the same way as in MRP (Orlicky, 1975). We will discuss this issue further in Section 3.8.
In summary, we can state that hierarchical decomposition of the supply chain planning problem has
two essential characteristics, namely:
Aggregation, which is necessary to construct higher level models;
Fixed lead times, which are needed as a control mechanism.
3.3
The Eindhoven Planning Framework
Using the PU concept we define the supply network as follows: The supply network is a set of PUs
separated by controlled stock points, which add value to the goods flow and to which production
orders are released by a central coordination authority. We note that this definition of the supply
network is specific to this reader. A more general definition of the supply chain includes noncentrally coordinated supply networks such as pure pull systems.
The physical structure of the goods flow (i.e. input-output relations of items between PUs)
is defined by the bill-of materials (BOM). The BOM specifies the number and type of each item
consumed in the production of a unit of another item.
The PU receives production orders from a control level that is hierarchically positioned directly
above the PU control level. This level is called the supply chain operations planning (SCOP) level.
An order consists of an item, a quantity to be produced, and a due date. According to de Kok &
19
Supply Chain Design
Aggregate Planning
Customer
orders
Accepted
orders
SCOP
Order
acceptance
Parameter
setting
Confirmed
leadtime
Order and resource release
Supply
chain
control unit
Supply
chain
control unit
Supply
chain
control unit
Figure 3.1. Position of supply chain operations planning in the planning hierarchy.
Fransoo (2003) it is the responsibility of the SCOP level to coordinate the release of materials and
resources in the supply network under consideration such that customer service constraints are met
at minimal costs.
SCOP in most industries deals with an horizon up to several months typically with weekly time
buckets. In some industries, e.g. bulk chemicals, this function may have an horizon as short as a
couple of weeks with daily buckets, whereas in other industries, e.g., pharmaceuticals, the horizon
may be as long as a couple of years with monthly time buckets. All is determined by the typical
effectuation lead times of the industry and the lead times that customers are willing to accept.
Next to the SCOP function, an order acceptance function (often called Available-To-Promise engine
in current planning software) needs to be introduced in the control loop in order to control the
total amount of work accepted by the supply chain, and to externalize the portion of the customerperceived lead time that is due to varying demand that cannot be processed within the fixed and
controlled lead time. Finally, a parameter setting function needs to coordinate the safety stock,
lead time, and workload parameters of the supply chain. This system is depicted in Figure 3.1.
Note that the functions discussed here only relate to the planning of operations, i.e. the release
of materials and resource triggered by actual demand downstream. In this discussion, we abstain
from other functions, such as supply chain design, the planning of seasonal or other controlled
inventories, lotsizing, transportation planning, etc. For a full description of this hierarchy, we refer
to Fleischmann & Meyr (2002).
There is a central control of order releases in the supply network. Put differently, the boundaries of the supply network are given by those PUs that receive their orders from a single central
coordination authority called the SCOP function. PUs in the network need not necessarily be part
of a single firm but we assume that agreements are made with subcontractors that are similar to
those made with company-owned PUs. The final stages of the supply network may operate on a
make-to-order (MTO) basis. These stages are excluded from the scope of the supply network under
20
consideration in this reader. All last stages in scope are thus followed by stock points that constitute the customer-order-decoupling-point (CODP). The items in these stock points are referred to
as CODP items.
It is the task of the SCOP function to balance the supply and demand in the supply network.
Specifically, it is the objective of the SCOP to satisfy demand for CODP items timely while making
efficient use of inventories and other resources in the network. In the SCOP model, marginal costs
are attached to the variables corresponding to planned inventories and resource usage.
We refer to the planning framework that we have described above as the Eindhoven Planning
Framework (EPF) that is extensively described by Bertrand, Wortmann, & Wijngaard (1990) and
extended by de Kok & Fransoo (2003). The framework is graphically represented in Figure 3.1.
The aggregate production planning level specifies the production volume for the critical capacities
in the PUs. Within these aggregate constraints, the SCOP level plans the order releases at item
level. Input to the SCOP level are furthermore the actual inventory levels in the stock points and
work-in-progress (WIP) levels in the PUs, and a detailed forecast of future CODP item demand.
The SCOP function and PU control function are furthermore influenced by parameter settings that
specify costs, service targets, safety stocks et cetera.
Two elements of the SCOP function are displayed separately in Figure 3.1. The goods flow
model stipulates how materials are consumed and produced over time in the supply network given
the planned lead times and the BOM. The abilities and limitations of the PU are captured in the
anticipated PU model (anticipation model for short). From the perspective of SCOP, the PU is a
black box transformation of input materials into output materials. The anticipated PU model is a
representation of the finite capacity that is used for production and is necessary for the planned
production to be reliable (i.e. to ensure that goods are available as planned with high probability).
Anticipation is an important concept in the work of Schneeweiss (2003), whose application to the
EFP we discuss in Section 3.6.
3.4
Relation to other HPP Frameworks
Hierarchical production planning (HPP) has various advantages over integrated or monolithic production planning. First and foremost it is in line with the prevalent industrial practice to place
decisions authority at the lowest or most decentralized part of the organization that is competent.
A principle from control theory states that the authority and responsibility to make decisions should
be matched with the authority to control (cf. de Kok & Fransoo, 2003). Besides, detailed decisions made at lower organizational levels typically take effect over shorter periods of time requiring
shorter planning horizons. Secondly, including all details in a single model leads to a large-scale
formulation that becomes computationally too expensive to solve. Frequent updating of the details
exacerbates this problem. Thirdly, central collection of the data that is input to such a model is a
considerable effort that leads to delays and high costs.
There are various frameworks described in the literature, of which the most important are
the MIT framework of hierarchical production planning (cf. Hax & Meal, 1973; Bitran, Haas, &
Hax, 1981, 1982; Hax & Candea, 1984; Bitran & Tirupati, 1993) and the MRP II framework (cf.
Vollmann, Berry, & Whybark, 1984). Similar frameworks are for example proposed in Miller (2002);
Silver, Pyke, & Peterson (1998); Hopp & Spearman (2000). In summary, the major differences of
the EPF with the MIT framework and the MRP II framework are the PU concept that introduces
locality in decision making (the PU needs only to consider the deployment of its own resources and
not material availability) and the concept of anticipation which allows separated decision making
functions.
The MIT Framework
The MIT framework focuses on the aggregation and disaggregation of decisions as a means of complexity reduction in a way that is largely analogous to decomposition techniques found in mathematical programming (see Shapiro, 1979, 1993). There are three levels of aggregation in the MIT
21
framework: items are aggregated into families and families into types. Items of the same type are
similar in terms of processing times and costs. Products belonging to the same family furthermore
share the same setups on machines such that change-overs are required only when a product from
another family needs to be produced. Finally, items may differ in characteristics such as color,
packaging, and size.
Various papers treat the aggregation and disaggregation of plans (see for example Axster,
1981, 1986; Rogers, Plante, Wong, & Evans, 1991). The main concern is to obtain plans at various
levels that are consistent (do the quantities match) and feasible (does the detailed availability of
materials and resources permit a disaggregation of the plan) (cf. Gelders & van Wassenhove, 1982)).
Note that these considerations are relevant only if there is no information asymmetry.
Although the MIT framework allows for management interaction at each hierarchical level,
the objective of the hierarchical decomposition it to create a computationally tractable problem.
Hierarchical levels are not clearly defined in terms of responsibilities and organizational scope.
Decisions at various level are taken at the same moment in time and there is no difference in the
type of information available at various levels (i.e. there is no information asymmetry).
Materials Resource Planning
Another important HPP framework is Materials Resource Planning (MRP II) which is widely used in
practice. It owes its popularity to the American Production and Inventory Control Society (APICS)
who embraced MRP II as the solution to the planning of supply chain operations. Whereas the
MIT framework starts from a capacity planning problem, the core of the MRP II framework is
materials coordination. The MRP II framework has three hierarchical levels: long-range planning,
intermediate-range planning and short-term planning.
The long-range planning level is an aggregate level where capacity availability is matched with
the planned production volumes. This is the level where the Sales & Operations Planning (S&OP)
(cf. Olhager et al., 2001) takes place. Families of items are planned at this level that have similar
demand and production requirements. The input to the S&OP process is a long term aggregate
forecast of demand. The planning periods are long (e.g. a month).
At the intermediate-range level, the family planning is disaggregated into requirements for individual CODP items using a detailed short-term forecast. Planning periods at this level are shorter
than at the long-range planning level (e.g. a week). The result of the disaggregation step is the
Master Production Schedule (MPS) which is subsequently translated into planned releases of orders through the Materials Requirements Planning algorithm. Checks for capacity and materials
availability can take place at this level. However, these checks only create warnings (exceptions)
that need to be addressed by the human planner. They are not actually taken into account in the
planning algorithm.
The short-term level is concerned with the coordination of the load of the resources. The
primary decision taken at this level is the moment of dispatching of a job. Dispatching decisions are
taken online. That is, they are triggered by events (e.g. the completion of processing a job) and not
taken at fixed points in time. They are furthermore based on relatively simple rules (e.g. operation
due date, shortest processing time, workload rules et cetera).
In the MRP II framework, the allocation of material shortages is the responsibility of the shortterm order release function. Such an allocation is clearly a myopic decision as the dispatching of
jobs does not change the MRP schedule. Consequently, materials are allocated to jobs that are
dispatched first rather than to jobs that have the highest priority.
3.5
Uncertainty
Hopp & Spearman (2000) notice that there are two types of variation in production systems: controllable variation and random variation. Controllable variation is the direct consequence of decisions whereas random variation is beyond the control of the firm as a collective. In the setting of
Hierarchical Production Planning (HPP), this definition is ambiguous. Indeed, the monolithic perspective on production planning entails there is a single decision function. The difference between
22
controllable and random is defined by whether or not the firm can influence it or not. The variation concept of Hopp & Spearman is applicable to a single decision function. On the other hand,
in the setting of HPP there are multiple decision functions and the question which is controllable
variation and which is random variation depends on the level in the hierarchy. More specifically, it
depends on the model used at a specific level. The distinction between controllable variation and
random variation is thus partly a matter of the design of the HPP system.
Some events cannot be controlled directly at a specific level but can still be influenced or
at least anticipated. It is therefore instructive to talk about explained variation and unexplained
variation with regard to a specific model. Variation that is explained by a model is the part of the
dynamics in the production system that is predicted by the model given the recorded state of the
system and higher level inputs (e.g. aggregate plans, parameters, and forecasts). Variation that
is not explained is the part of the dynamics that cannot be known (a priori) or that is simply not
modeled. Note that the unexplained variation may still be controlled at a lower hierarchical level.
Note furthermore that, even though the information is available, not all information is necessarily
utilized in a model whereby the part of the variation that is explained may be smaller than the
part of the variation that in principle can be explained. An example are time phased planning
and scheduling models where, although it is possible to determine the occurrence of individual
events, only the aggregate number of events is accounted for in the model. Unexplained variation
is often referred to as uncertainty. We distinguish three types of unexplained variation in HPP:
environmental uncertainty, information asymmetry, and artefactual uncertainty which are discussed
in more detail below.
It is often not possible or practical to isolate various types of uncertainty and characterize the
related variables separately. Often, the available (historic) information does not identify the precise
source of variations and even if it does, the number of observations for each specific type of variation
may be too small to characterize them reliably. Also from a modeling perspective it is preferable to
limit the different types of variation in order to keep it simple and tractable. Indeed, it is argued by
Hopp & Spearman (2000) that it is often not relevant to know the type of uncertainty in production
processes. One is typically interested in the effect of the uncertainty on the flow in the PU. It does
not matter whether a delay in an operation is caused by unavailability of an operator or a machine
breakdown.
Environmental uncertainty
Environmental uncertainty is the difference between reality and the part of reality that can be
captured in a model. In most manufacturing and distribution systems literature where uncertainty
plays a role, it is considered to be an environmental phenomenon. On the one hand there is the area
of inventory management (see for example Silver et al. (1998); Zipkin (2000)) where the supply
network faces stochastic periodic demand and the challenge is to minimize stock levels subject to
customer service level constraints. On the other hand there is the area of production planning (particularly of job-shops, see for example Buzacott & Shanthikumar (1993); Altiok (1997)) where the
production system faces order arrivals with stochastic times between them, where processing times
are random, and where the challenge is to balance load with capacity such that the variability of
throughput times is controlled. Types of environmental uncertainty that are commonly considered
in manufacturing systems are:
processing and setup time uncertainty;

capacity uncertainty;
machine break-downs;
yield uncertainty.
Processing time uncertainty is perhaps the most studied type of uncertainty, particularly in the
context of queueing models (cf. Kleinrock, 1975; Tijms & Wiley, 2003) and queueing network models (cf. Jackson, 1957; Baskett, Chandy, Muntz, & Palacios, 1975; Whitt, 1983; Bitran & Tirupati,
23
1988)). Capacity uncertainty is studied in the context of inventory management in Ciarallo, Akella,
& Morton (1994) and yield in Henig & Gerchak (1990). A review on models considering machine
outages is made by Li, Blumenfeld, Huang, & Alden (2009). Uncertainty also has an important
secondary effect. PUs typically have multiple resources that carry out operations for an order. Delay
of one operation affects the start of the other operation and in this way uncertainty propagates
through the PU. Hopp and Spearman refer to this propagation of uncertainty as flow variability. It
is well known from the theory on queueing models that flow variability increases the waiting time
of jobs before resources.
Information asymmetry
Another source of unexplained variation that is inherent to HPP is information asymmetry. Information asymmetry refers to the fact that the information status at the time of decision making differs
for the various hierarchical levels. Information asymmetry has two causes. Firstly, the lower level
typically has more detailed information than the higher level. The operator who is responsible for
starting an operation on a machine sees more than the master planner does when releasing orders
to the PU. Secondly, the decision at the lower level is taken at a later time and therefore, the decision maker at the lower level can take into account recent events that the higher level decision
maker cannot. As a result, the actions at the lower level deviate from the anticipated actions even
if the lower level is explicitly modeled. Such actions may concern for example setups, dispatching
and sequencing, and batch sizes.
Artefactual uncertainty
Whereas environmental uncertainty and information asymmetry are types of unexplained variation
that are perhaps unintended or uncontrollable, there is also a part of the unexplained variation that
is artefactual. Where information asymmetry refers the part of the information that is available,
artefactual uncertainty refers to which part of the information is used and in which way. Artefactual
uncertainty is the part of the variation that is left unexplained through the choice of design of the
model. This is particularly true for the anticipation function. For reasons previously mentioned, the
anticipation model is usually an implicit representation of the PU. Many details are ignored in the
model to make the SCOP model tractable. One example is the time phased nature of rolling schedule
planning. Details about the individual events in a period are discarded and instead, only the count
of certain event (e.g. arrivals, departures) are tracked. As a result of "leaving out the details", the
anticipated dynamics in the PU differ from the actual dynamics even if there is no environmental
uncertainty or information asymmetry. Consider the following simple example. Every three days, a
customer places an order with a company that operates a planning with time buckets of a week (no
weekends). Demand for this customer is modeled as the quantity ordered per time bucket. That is,
the demand for this customer is 2.33 on average with a standard deviation of 0.47. This standard
deviation is a measure of the unexplained variation of demand for this customer which is entirely
artefactual for the time between two orders is precisely known. Another example of artefactual
unexplained variation is the aggregation of item or job types. Due to the aggregation, type specific
information such as processing time or routings is lost.
3.6
Asymmetry in Supply Chain Planning, Schneeweiss Anticipation
After constructing a hierarchical planning structure, often the resulting planning situation is characterized by asymmetry of information. Essentially having different levels of control (strategic,
tactical, and operational) being owned by different organizational units leads to different information statuses. So, the hierarchical structuring of decision making introduces the challenge of
coupling decision making functions at different levels. A formal framework for the coupling of decision making functions at different hierarchical levels is proposed by Schneeweiss (2003). Decision
hierarchies are described in terms of a top level and a base level whose decision making functions
are coupled through several recurring stages of interdependence.
24
SCOP
SCOP
Goods flow model
Instruction
Goods flow model
Anticipation
model
Anticipation
model
Anticipation model
Anticipation model
Instruction (taken into

account the anticipation
model outcomes)
Instruction (taken into

account the anticipation
model outcomes)
Ex-ante
feedback
PU control
PU control
Implementation
PU operations
Effectuation lead time
t=0
t=1
Time
Figure 3.2. Schneeweiss decision hierarchy.

The first stage of interdependence is anticipation. Before giving its instruction, the top level
anticipates the base levels reaction by either implicitly or explicitly modeling the behavior of the
base level in the top levels model. The decision is thus based on some model of the base level and
called the anticipated base model. Schneeweiss describes anticipation as the bottom-up influence of
the base level on the top level. The next stage is called instruction and refers to the communication
of the top level decision to the base level. This stage is the top-down influence of the top level on
the base level. The last stage is ex-ante feedback. In this stage, information is collected about the
state of the PUs and stock points in the supply network which is used to update the SCOP model.
In Figure 3.2 we show the conceptual framework of Schneeweiss. The PU control function
is the base level and the SCOP function is the top level. The PU control level is a function that
returns the starts of operations taking into account the PU control objective and the PU control
action space. The PU control objective is referred to by Schneeweiss as the soft constraints. These
are partially private and partially bottom-up. The private part may for example be to minimize the
amount of overtime used or to limit the number of setups on machines. The bottom-up objective
is to complete orders no later than their due date. The action space is determined by the hard
constraints. These constraints are derived from the physical properties of the manufacturing system
and cannot be violated. We assume that there is no possibility to negotiate instructions from the
PU. This restriction is only a modeling point of view. In practice such negotiations may take place
but we assume that these negotiations are ad-hoc and in the realm of human interventions. Schalla,
Fransoo, & De Kok (2001) have further analyzed the various types of anticipation that may exist. In
general, the anticipated base model can be constructed based on aggregating information and/or
on aggregating the base level model itself. We will now first discuss the aggregation of the base
model itself. Aggregation referring to the model part explicitly deals with complexity reduction. At
the top level the decision making process is represented by an aggregate and simple model in order
to reduce complexity and to distribute detailed decisions to lower planning levels. We can thus
distinguish the following anticipation types with regard to the model:
Explicit Model: The base level model as seen at the top level is exactly the same as the original
base level model.
25
Implicit Model: The base level model as seen at the top level is different than the original base
level model.
Consequently, the terms explicit and implicit with regard to anticipation refer to the fact whether
the top-level base model (including the objective functions) is exactly the same as the base-level
base model. If this is the case, we call this explicit anticipation; if this is not the case, we call this
implicit anticipation. Explicit anticipation thus uses a detailed model of the base level, whereas
implicit anticipation uses an aggregate model of the base level.
The second type of aggregation to construct an anticipation model is aggregation of information. This type of aggregation is related to uncertainty and effectuation time. In the context of
the questions related to the anticipation function, special attention regarding information is paid to
the concept of information asymmetry. Information asymmetry basically entails the fact that when
making a decision at a higher level, the amount and quality of information may be different from
when the lower level decision is made (later), and again different from when the actual execution
of the decision is taking place. The fact that information asymmetry exists, leads to the necessity
to anticipate at a higher level decision what may happen at the lower levels decisions. We can thus
distinguish the following anticipation types with regard to information:
Exact Information: The base level information as seen at the top level is exactly the same as
the original base level information.
Approximate Information: The base level information as seen in the top level is different than
the original base level information.
Consequently, the terms exact and approximate refer to the fact whether the top level model has
exact information of the base level status. Note that in most cases some time elapses between the
moment at which the top level makes its decision (instruction) and the moment at which the base
level makes its (final) decision. This difference in effectuation lead times of top level decisions and
base level decisions usually entails a difference in the information status between the top level and
the base level, resulting in information asymmetry and automatically in approximate anticipation.
Taking all combinations between anticipation types referring to the modeling part and anticipation types referring to the information part, de Kok & Fransoo (2003) distinguish three types of
anticipation, based on the various types of aggregation used to construct the anticipation function
as discussed above. The three types are:
Explicit Model / Exact Information (EE)
Explicit Model / Approximate Information (EA)
Implicit Model / Approximate Information (IA)
Note that the combination of exact information and implicit model does not make sense, since there
does not seem to be a clear reason for constructing an implicit model (i.e. more aggregate than the
detailed model) if exact information is available. Further note that information asymmetry more
often than not will lead to the fact that approximate information is the only information that can be
used in the anticipatory model at the higher level. Given the fact that only approximate information
can be used, it is not a priori clear whether the use of an explicit and detailed model is better than
the use of an implicit model. Later, Schneeweiss (2003) distinguishes four types of anticipation:
In explicit exact anticipation, there is no difference between the PU decision function and the
anticipation model. Information asymmetry may still exist due to the fact that decisions are
taken at different points in time, but in principle the top level has access to precisely the same
information as the base-level.
In explicit approximate anticipation, all aspects of the base level decision function are represented in the anticipation function but some aspects are approximated. As an example,
Schneeweiss mentions the replacement of a characterization of the entire distribution of a
random variable by its expectation.
26
In implicit anticipation, it is attempted to capture the "behavior" of the PU that is relevant to

the SCOP level in a model that is different from the PU decision function.
In non-reactive anticipation, the anticipation function is effectively absent. The behavior of
the PU is captured in generic characteristics only that do not depend on the order release
decisions.
Non-reactive anticipation models are typically found in the inventory management literature where
it is assumed that an order has an exogenous lead time that is independent of the state of the PU and
the size of the order. A similar non-reactive anticipation model is found in Materials Requirements
Planning (MRP).
Another example of explicit anticipation functions are iterative simulation and optimization
approaches (see for example Hung & Leachman, 1996; Byrne & Bakir, 1999; Kim & Kim, 2001;
Byrne & Hossain, 2005). If the base level follows a fixed set of rules that are precisely mapped
onto the simulation model, then the simulation model can be thought of as an explicit anticipation
model. Apart from the question to what extent it is possible and practical to develop and maintain
such a simulation model, convergence of such iterative approaches is not guaranteed. Although
some favorable simulation results with respect to convergence have been found by Irdem, Kacar, &
Uzsoy (2010), this convergence is not consistent in the sense that the deviations between planned
values and simulated values becomes smaller with each iteration.
With a few exceptions, anticipation functions for SCOP are thus implicit. Particularly, an abstraction is made from the events occurring in continuous time. Besides, the PU control function
is typically not modeled explicitly. Resources are sometimes represented collectively by a single
aggregate resource or are omitted altogether if they are of little influence to the dynamics in the
PU. Abstractions of this sort are made for several reasons. Firstly, computational tractability of the
SCOP model is a concern. Secondly, detailed stipulation of the PU decision making function would
take away the decision authority from the PU which is in conflict with the principles of hierarchical
planning. Besides, information asymmetry makes the detailed information upon which detailed
decisions are based uncertain. Consequently, the explicit anticipation model need not necessarily
be more accurate than the implicit anticipation model. Whereas explicit exact anticipation implies
that it is possible to formulate a monolithic model, implicit anticipation implies the existence of
multiple decision levels and therefore hierarchical production planning.
3.7
Effectuation Lead Times
Asymmetry in the decision making hierarchy and the necessity to anticipate is primarily caused by
the fact that it takes time to implement a decision. We will denote this time as effectuation lead
time, as introduced earlier. The effectuation lead time is the time that passes between the moment
a decision is made and the moment that the consequences of this decision can be observed in the
operation of the supply chain. In supply chain planning decisions, the length of the effectuation
lead times can be determined based on the product and process structure: the bill of material and
the bill of resources.
An example of an effectuation lead time is the procurement time of components. If the procurement lead time for a component i is L i , then ri (t), the quantity procured at the start of period t
is supposed to be available for further assembly or sales at the start of period t + L i . The immediate
decisions {ri (t)} are dependent on the exogenous demand forecasts { Di (t, t + s)}, s 0, defined as:
Di (t, t + s)
forecast of forecast of exogenous demand for item i in period t +s as decided

on at the start of period t, t 0, s 0, i.
Assuming supply is reliable and L i is realized, we may expect that pi (t, t + L i ) = ri (t), where we
define pj (t, t + s) as

pj (t, t + s)
27
forecast of quantity of item i that becomes available at the start of period

t + s as determined at the start of period t, t 0, s 0, i,
Reflecting the decision of the supplier to ship as late as possible. Note that pi (t, t + L i ) is only
a planned decision from the perspective of the organization ordering the item. For the supplier
this may be either a firm decision, in case the supplier has to start immediately with processing
and transporting the order for item i, or a planned decision, in case the effectuation lead time
incorporates some slack time.
Suppose that at time t the planned decision is taken according to the above equation. At the
start of period t + 1 we generate new forecasts { Di (t + 1, t + s)}, s 1. It is now well possible that,
e.g. due to a decrease in demand for item i it is decided to change the decision made earlier, i.e.
pi (t + 1, t + L i ) 6= pi (t, t + L i ).
Following the discussion of planned versus firm decisions, we can see that dependent on the
incorporation of slack time into the procurement time, it is possible or not to change the earlier
decision. Flexibility can be further modeled by the choice of the (time-dependent) resource constraints.
Information asymmetry itself can be described using the following example. Consider again
item i with planned lead time, i.e. the effectuation lead time of the material order release decision,
L i . Often suppliers receive forecasts about future orders in some period t multiple times in order
to take consecutive decisions on e.g. buying production equipment, hiring and training people and
procurement of materials. As stated above the forecasts { Di (t s, t)} for period t made at the
start of an earlier period t s differ for different s. Thus the procurement orders derived from
these forecasts change over time, so that the suppliers decision to buy production equipment is
based on different information than the suppliers decision to procure materials. This asymmetry in
information needs to be taken into account when designing the decision hierarchy or supply chain
control structure. The effectuation lead time thus leads to differences between the moments in time
that certain decisions must be taken. Also, it means that decisions are often taken a substantial
time before the actual action in the physical process takes place. As a consequence the decision
maker in fact feeds forward in terms of control theory rather than feeds back as is often suggested
in hierarchical production planning frameworks. In order to feed forward, the decision maker
essentially anticipates the events over the period of time until his decision is effectuated.
It should be realized that the effectuation lead time is not only related to the bills of materials
and bills of resources, but is also a characteristic of the supply chain planning and control system.
In many cases, the time buckets at higher levels of decision making are larger than at lower levels
(Meal, 1984). Further, the frequency at which decisions are made, revised or processed is less at
higher levels of decision making (the hierarchical structures of Gershwin (1994) are based upon
this premise). This means that changes in the actual (physical) process, e.g., changes in demand,
may not be observed directly. Further, if they are observed, there may be a delay in processing the
consequences of this observation. This processing time due to the decreased frequency of decision
making at higher levels should be included in the effectuation lead time.
Along a time line, it clearly shows that the various SCOP decisions need to be timed along
the lead time characteristics of the supply chain, both the physical lead time and the information
processing lead time. This is depicted in Figure 3.3 and was discussed in detail in Subsection 3.7.
3.8
The Need for Control
Anticipation models need to capture the base level behavior in a sufficiently accurate manner. In this
sense, accurate refers to the predictive quality of the anticipation model. When designing a decision
structure, two different approaches can be taken when constructing the anticipation functions. The
first approach is to try and capture the base level behavior as completely as possible by enriching
the anticipation function by as many details as known about the base level. The second approach is
to design the decision function at the base level in such a way that the actual anticipation becomes
Accept order
Release
28
Customer perceived order lead time
Information lead time

Unit lead time
Figure 3.3. Decision moments driven by lead time structure.

straightforward. In this case, the objective of the base level is to realize a set of targets set by the
top level (see also McPherson & White Jr. (1994), for a discussion on this matter). We will refer
to this situation as a controlled situation. An example of such a design is the reliance on planned
lead times maintained by workload control methods (Bertrand & Wortmann, 1981; Bertrand et al.,
1990; Wiendahl, 1987, 1995; Van Ooijen, 1991).
It is neither obvious nor conclusive whether working with planned lead times is a correct approach, since current research is not conclusive and there are researchers that advocate the use of
variable lead times. Kanet & Sridharan (1998) demonstrate results by which the use of detailed
scheduling information in material procurement reduces the inventory of components that are controlled by MRP. Tardiff (1995) and Hopp & Spearman (2000) in their concept called Capacitated
MRP (or MRP-C) calculate the expected Work-in-Process (WIP) and then adjust the lead times of the
products accordingly, by building ahead those items that would be late due to longer lead times
caused by higher WIP levels. Based on work by Buzacott (1989), a research line has been developed which integrates the capacity and material planning perspectives completely using so-called
generalized kanban systems (Frein, Di Mascola, & Dallery, 1995). The assumptions are however
very strict such as Poisson arrivals of items orders and FIFO dispatching at resource level. These
assumptions are mostly not satisfied due to the periodic review nature of the supply chain planning
process, which leads to coordinated release decisions.
Apart from the mathematical complexity of applying detailed scheduling on a supply chain
wide scale, approaches that use detailed scheduling information to update the supply chain plan
abstain from two basic principles that we have outlined earlier, namely the organizational hierarchical concerns and the asymmetry in information. Since the scheduling decision is generally the
domain of some lower-level organizational function than the supply chain planning decision, taking this scheduling decision at a higher level may infringe upon this organizational design (Meal,
1984). With regard to information asymmetry, note that the actual schedule will be constructed
at a later stage when more information will be available. As a consequence, the actual schedule
may be very different from the projected detailed schedule constructed to make the supply chain
plan. In fact the more detailed scheduling of materials will then lead to additional constraints on
the operational schedule. This issue is not addressed in the paper by Kanet & Sridharan (1998)
discussed above. Given only slight variations in for example the operating times, the impact on the
schedule in various environments may be substantial (see e.g. Lawrence, 1997), for an example of
this in a job shop). Unfortunately, this interaction between the supply chain planning level and the
detailed scheduling level has not been researched under asymmetric information conditions, so we
do not know the impact of this effect on the operational performance.
With regard to dynamically adjusting the information based on aggregate status (workload)
information of the shop floor, the impact is even less clear. Much will depend upon the actual stability of the workload prediction between the moment that the supply chain planning decision is
taken and the moment the actual execution takes place, i.e. the quality of the expected workload as
an anticipator of the actual lead time. If this quality is good, then the method should work fairly
well in the manufacturing environments for which it was designed. In situation with multiple items
and multiple resources it is however very difficult to give accurate predictions of the lead time and
29
to adjust the supply chain plan accordingly. This will lead to very complex models and will lead
to performance and accuracy problems (Hopp & Spearman, 2000). The situation is however very
different when multiple actors conduct collaborative planning actions across independent companies in the supply chain. In that case, the planned lead times act as a coordination aid between the
various actors in the supply chain and planned lead times allow for independent planning of parts
of the supply chain.
CHAPTER
A Note on the Design of Logistics Control Systems
Acknowledgment
This Chapter is a transcription of the paper A Note on the Design of Logistics Control Systems
written by J.W.M. Bertrand and is reproduced with his permission.
4.1
Introduction
In this paper we present a systematic approach to the process of designing logistics control systems.
Logistics has been described as "...the managerial problems raised by production, inventory and
distribution... " (preface of: Graves et al., 1993).
Since a long time logistics is a widely researched area. Among the first published results in this
field were the determination of the economic order quantity (Harris, 1913) and the determination
of the number of servers needed in order to achieve a certain service rate (Erlang, 1917). Since
then, and in particular after World War II, a rich flow of research has emerged in fields such as
inventory control, production control, capacity control, and supply chain control, resulting in an
impressive number of methods and techniques for logistics decision making for all kinds of decision
problems. In parallel, research has been done on the characteristics of logistics control situations,
leading to production typologies such as the product-process matrix, and tables that show what
type of logistics techniques is suited for solving what type of decision problem in what type of
production situation. Overviews of these results can be found in textbooks such as Silver et al.
(1998), and Hopp and Spearman (2000). A lot of models and techniques are available nowadays
to support the design of logistics control system in real life production situations. However, the logistics control system design process itself has received much less attention over the last decades. A
thorough discussion of the general logistics control design problem can be found in Bertrand, Wortmann, Wijngaard (1990). The authors provide a design typology , a generic hierarchical control
framework, and an explicit account of the design questions that need to be answered in the design
process. However, no guidance is given regarding how these design questions should be answered.
Examples of detailed designs for the logistic control of specific real life situations can be found in
Hax and Meal (1975), Bertrand and Wortmann (1981), and Schneeweiss and SchroLder (1992).
However, the design process discussed in these reports is largely implicit and specific for the real life
situation at hand. No generic guidance is given. In Schneeweiss (2003), building on concepts from
general systems theory (see Mesarovic et al., 1970), a detailed account is given of the anatomy of
hierarchical production control systems, providing a concise terminology for describing production
systems and their control. However, this account does not discuss the problem of how to design the
control system.
Research on the process of product design is ample, and has a long tradition. It has resulted
in different types of output streams, ranging from explanatory research into the organization of the
design process, and into the conditions that lead to an effective and efficient design process (e.g.
Allen, 1987), to normative research about how to structure the design process (e.g. Suh, 1990),
and to descriptive research about how design approached have played a role in the evolution of
products and industries (Baldwin and Clark, 2000).
In this paper we take the formal prescriptive rules for structuring the design process in Product
Design as used in Suh (1990) and reported in Baldwin and Clark (2000) as a starting point for
developing similar formal prescriptive rules for structuring the process in Logistics Control Systems
30
Chapter 4. A Note on the Design of Logistics Control Systems
31
Design. We start in section 2 with a short presentation of design principles for product design.
Then, in section 3, we present a formal description of the logistics control design problem. Next
in section 4 we give characteristics of the logistics control design problem. In section 5 we discuss
the Production Unit Control design problem, and in section 6 we discuss the Goods Flow Control
design problem.
4.2
Design rules for product design.
Many papers and books have been published that give rules for how to design a complex product.
In this paper we use the terminology and rules presented in Suh (1990), and Baldwin and Clark (
2000). What follows is a short summary of their descriptions of the design process.
Design starts with specifying the Functional Requirements (FR) for the product to be designed.
The design process involves the search for a product, specified by the Design Parameters (DP), that
satisfies these functional requirements. This process consists of the execution of one or more design
tasks, a design task being the task to specify one or more of the design parameters. From a design
perspective, an artifact (or product) is characterized by an individual set of the design parameters.
The categories in the set, such a material, length, width etc., make up the dimensions of the design
space of the product. A particular point in this design space therefore specifies a particular product.
The space of all possible designs can be extremely large, ill-structured, and difficult to search.
Therefore Baldwin and Clark (2000) distinguish hierarchical design parameters. For these parameters the designers choice has the character of a logical switch, and a "yes" brings a new set of design
parameters into existence. Decisions on a hierarchical design parameters precede decisions on the
non-hierarchical design parameters, and are used to delimit and bound the space of designs. As a
result the design problem gets manageable, given the knowledge and resources available. Design
would be relatively easy if design parameters would be independent of each other, and each design
parameter would only influence one functional aspect. However, design parameters often depend
on each other and have interacting effects on functionality. Thus, the success of the design process
largely depends on the knowledge in the design team about these interdependencies and interactions. Hierarchical relationships and interdependencies among design parameters can be mapped
in the Design Structure Matrix (DSM), (Steward 1981, 1981a, Ulrich and Eppinger, 1995, Smith
and Eppinger, 1997).
In a DSM, the individual design parameters are assigned in the same order to the rows and
columns of a square matrix. For each row, one puts a mark (x) in the element (a, b) of the matrix
if the specification of design parameter a requires knowledge about design parameter b. Specifying
the value of a design parameter is a design task. Thus, the DSM of a design problem corresponds
one-to-one with the task structure Matrix (TSM), (Smith and Eppinger, 1997). The TSM reveals
the hierarchical relationship between design tasks and the interdependencies, that can be modelled
as precedence relationships. The TSM shows how to organize the design process. Often groups of
design tasks can be identified where design tasks within a group are mutually interdependent, and
interdependencies between design tasks belonging to different groups are sparse or dont even exist. Design tasks belonging to different groups can be performed relatively independently. However,
for design tasks within a group, some form of interdependence-breaking coordination is required
to avoid endless iterations. This can be done by assigning each group of strongly interdependent
design tasks to a separate design team, with short communication lines and high information exchange within the design team. The remaining interdependencies between groups of design tasks
can be resolved by, for instance, adding constraints for design rules to individual design parameters, based on design knowledge about the interactions between them. However, since design
knowledge generally will be imperfect, interactions in the design of complex products cannot be
entirely avoided.
Baldwin and Clark (2000) introduce the concepts of modularity and design rules in their discussion of how to manage the complexity of the design process. Modules are units in a larger
system that are structurally independent of one another, but work together to achieve to the overall
32
functional requirements. The first step in the design process is therefore to define a framework (or
a conceptual design) that allows for independence of structure and integration of function. They
state that ".....A complex system can be managed by dividing it up into smaller pieces and looking
at each one separately. When the complexity of one of the elements crosses a certain threshold,
that complexity can be isolated by defining a separate abstraction that has a certain interface. The
abstraction hides the complexity of the element; the interface indicates how the element interacts
with the larger system.....".
In the process of defining modules, the systems architect, overseeing the interdependencies,
first introduces design rules that are imposed on each of the design teams as constraints to create
independence among the modular design tasks. Modular independence is further achieved by information hiding during the modular design process. Information hiding is making sure that each
modular design team realizes its design without using any information about how any of the other
design teams solved its design problem. Information hiding guarantees that the design modules
can perform independently from one another. If furthermore guarantees that, in the future, the
design of each module can be improved independently, as long as the systems design rules are respected. By respecting the design rules and the defined interfaces, modules can evolve individually
and independently to improve the functioning of the product as a whole. Design rules, modularity,
information hiding and interfaces are therefore important principles for developing products that
can relatively easily be further improved in future (re)designs.
4.3
The Logistics Control System Design problem
In this section we give a short description of the problem of designing Logistics Control Systems.
We start by defining what we consider to be given at the start of the design project. Then we define
the functional requirements and the design parameters and discuss characteristics of the Logistic
Control Systems design problem.
For a given Logistics Control System design problem, we assume that the scope of the total
system to be controlled is known. The boundaries of the system are set defining by:
the set of end-products that are produced by the system
the set of raw materials that are input to the system
The internal structure of the system to be controlled is given by:
the bills of material that relate each end-product via a number of specific intermediate products to the raw materials used by each end-product
the processes, that convert (raw) materials into higher value states (including the intermediate products stated in the bills of materials) and finally into the end-product state.
per process, the set of resources types needed to execute the process, the setup time, the
change-over costs, the amount of resource needed, the processing yield, etc. The functional
requirements regarding the performance of the Logistics Control System can be expressed in
variables such as:
the delivery performance relative to demand for end-items, possibly conditioned on specific
patterns in end-item demand,
total logistics related costs; these are costs that vary as function of logistics decisions taken in
the control system.
The design parameters of the Logistics Control System design problem are the following:
for each of the resource types, the decision function that determines the availability of the
amount of resource of this type, as a function of time.
for each process, the decision function that determines (directly or indirectly) the time during
which the process is executed to bring materials into higher value states.
33
For real life production systems, solving the Logistics Control System design problem can be a
formidable task because:
the design space, having as many dimensions as the sum of different resource types and
processes, can be very large.
many interdependencies exist between these design parameters.
Fortunately enough, very many combinations of possible decision functions lead to evidently poor
performance and can therefore be easily ruled out. However, design parameters in Logistics Control System design do not pertain to features for which a choice must be made from a well defined
range of values, but pertain to decision functions, operating on the state of the system. Very many
different decision functions may be reasonable candidates for each particular decision problem (design parameter). Thus for complex design problems the remaining space of all decision functions
that are reasonable candidates will still be overwhelmingly large. It follows that, like in product
design, the first phase in the design process should the determination of the control system architecture. The control system architecture serves to break many of the interdependences between
design parameters and create (modular) sets of design tasks that can be solved independently, and
which, when solved, also solve the overall design problem. In the next section we will show how
the principles behind, modularity, abstraction, information hiding and interfaces could be applied
to the design of Logistics Control Systems.
4.4
Modularity, information hiding, abstraction, and interfaces
Like in product design, the person that develops the logistics control systems architecture must
be very knowledgeable in the field of logistics control systems design. He/she must have detailed
knowledge of the interdependencies that may exist between design parameters as a function of
the characteristics of the products, the processes, and the resources. A design structure matrix
can be used to map the dependence relationships between the design parameters. In production systems, the dependence relationships between resources and processes mainly stem from the
material-requirements relationships between the items produced by the processes and the capacityrequirements relationships between processes and resources. Listing the processes and the resource
types in the same order along the rows and columns of a square matrix, a design structure matrix
can be determined, the elements of which indicate whether the decisions function in the row depends on the decision function in the column. Such a matrix will reveal that each process decision
function depends on all process decision functions upstream in the material flow (because the materials produced by these upstream processes must be available for executing the process), and on
the resource decision function for all the resource types needed for its own execution, and for the
execution of all these upstream processes. This points towards a very high level of interdependency
between the design parameters (decision functions) in Logistics Control System design. However,
in most production systems material flows are unidirectional, and in most production systems specialized resource types are used for different process types. The control systems architect can take
advantage of these special types of relationship between design parameter when developing the
systems architecture. Modularization The special structure of the interdependencies in production
systems suggests to form ijmodules by grouping specific sequences of process into sets Pi i 1...,
N , and to such that the processes in set Pi can be executed with the resources in set Ri , and the
resources in set Ri are only used ijgroup specific resource types into sets Rj j 1,..N for executing
processes in P . A combination of processes and resources P , R can systems P,R ,i 1,...,N, ii is the
first step in creating a modular design. Other iii be defined as a production unit (PU). Using its
resources, a PU executes a sequence of processes on raw materials, in order to produce the PU-end
items. A PU therefore can be considered as a subsystem of the production system. Decomposing the
overall production system in N such sub ijmodules may be necessary, for instance the system that
coordinates the Production Units to achieve the overall systems performance could also be defined
as a module. We refer to this systems as the Goods Flow Control System. We first concentrate on
34
modular PUs. Information hiding requires that each PU functions independently from the internal
state or functioning of any other part of the system. Interactions between PUs are confined to the
interfaces and are based on abstractions that describe the performance of the PU in response to
inputs. For instance common abstractions regarding the performance of a PU are its lead time and
its capacity. Defining these abstractions precedes the specification of the PU design task, and allows
for the design task to be expressed as, for instance:
specify capacity decision functions and processing decision functions that guarantee that each
order to produce up to X items of any PU-end item is completed within Y days after release,
on the condition that total number of orders released per day does not exceed Z, and that raw
materials are always available.
This description also reveals the nature of the interfaces of this (to be designed) production unit
with its environment:
an interface with the system that release production orders to the unit
an interface with the system that supplies raw materials to the production unit
an interface with the system to which completed products are delivered.
Modular functional requirements We have seen that abstraction plays an important role in defining
the interfaces and the performance requirements for each of the PU modules. The architect has to
define interfaces between the Production Units, and the interface between the logistics control function of each of the PUs and the Goods Flow Coordination System. The Goods Flow Control System
thus coordinates performance of the Production Units to achieve the logistics performance targets
for the overall production system, and can only do so via the interfaces. Thus, if N Production Units
are defined, then at least N+1 ijControl Systems must be designed and integrated in order to solve
the overall Logistics Control System design problem. Integration is the process of connecting the
(modular) subsystems, testing their combined performance, and fine-tuning the separate designs in
order to achieve end-item performance according to specification. The functional requirements of
each PU are expressed in the volume and timing of delivering the of PU-end items, and the total
logistics related costs in the PU. Before specifying functional requirements the systems architect first
has to identify the constraints on the possible performance of a PU. Knowledge about constraints
can be obtained from the reference models of production systems and their control available in
literature. Reference models characterize specific types of production systems such as job shops,
flow shops, flow lines, assembly lines, project shops, etc. The architect can use these reference
models to select appropriate global control models for each PU, and to make initial decisions on the
interfaces between the modules and Goods Flow Control, the performance variables per module,
and the logistics related cost budget per module. We can distinguish three types of interfaces:
material supply interfaces
control interfaces
product delivery interfaces
Material supply and product delivery interfaces are physical and are given as soon as the boundaries
of the PUs are defined. Also PUend-items result from this choice. Control interfaces are determined
thereafter. Control interfaces are related to the way in which the required performance of a PU
is specified. Different options are available here. For instance, the performance of a PU could be
expressed as an agreed time to produce an order for the PU-end items issued by Goods Flow Control,
(if the PU works on a make-to-order basis), or in a percentage of demand for each of the PU-end
items to be delivered out-of stock, (if the PU works on a "manufacturer managed inventory" basis),
under a constraint on the volume. The two choices lead to different interfaces between modules in a
design. With the make-to-order interface, Goods Flow Control controls the stock of PU-end items by
issuing production orders to the PU; with the PU-managed inventory, the PU itself directly controls
the stock of PU- end items in response to demand PU-end items, in order to achieve a performance
target specified by Goods Flow Control.
4.5
35
The Production Unit Control design problem
We next discuss the design of Production Unit Control Systems. The PU design space consists of
the decision functions regarding the resource types and the processes in the PU. The PU functional
requirements specifications consist of the target values specified by the architect regarding volume
and timing of production of PU-end items in response to specific patterns in demand for PU-end
items, under a constraint on logistics related costs assuming raw materials are ample. We assume
that the design principle of information hiding is used. This implies that each PU can achieve its
performance without having information about how the design problem of any other PU is solved,
and how the design problem for Goods Flow Control is solved. The actual output of a PU, however,
may be affected by the output of other PUs, for instance if a PU involved in preceding processes
does not deliver sufficient raw materials. Such interdependencies are managed at the Good Flow
Control level. An important performance measure for a PU control system is its logistics related
costs. The major components of logistics related costs are:
costs of capacity variation

costs of capacity slack
costs of work-in-process
costs of setting up a process
costs of running the production unit system.
Depending on the costs allowed, a production unit can realize very different performances.
In the limit, if there is no constraint on costs, a production could produce any amount of each of
its PU end items with a throughput time that is equal to the raw processing time. On the other
hand, if there exist hard constraints on costs and capacity utilization, the throughput time would
include waiting times for resources to be available, and constraints would be put on production
batch sizes. It follows that, when specifying the PUC design problems, the system architect must
estimate what combination of performance and costs are possible (without of course first solving
each of the many design problems that could be specified), and specify a design problem that he/she
estimates to be solvable. It is very likely therefore that the design problem specified contains slack,
that is, there will exist solutions to the design problem that deliver the specified performance at
lower costs then specified by the costs constraint. If this would not be the case, the system architect
would demand the design problem to be solved to optimality, and we know that practically all real
life design problems are computationally intractable. Design therefore is not about finding optimal
solutions but about finding satisfactory solutions, which of course can be improved gradually over
time. To realize his design, the PUC designer must know in detailed terms how, for each of the
processes and resource types in the PU, the above costs components depend on certain aspects
of the decision functions. For this design, the designer builds detailed models of the Production
Unit and searches the PU design space for finding decision functions that satisfy the functional
requirements under the given costs constraint. Depending on the type of production system (job
shop, flow shop, flow line, etc.) the number of design parameters may be large or small. The
designer will try to reduce design complexity by decreasing the degrees of freedom. This can be
done by for instance by coupling the processing times of processes such that equal amounts of items
are produced (same production batch size for consecutive processes) or by coupling processing
times of processes to resource availability (continue processing as long a resource is available),
and control amounts produced by controlling resource availability. Depending on the total costs
constraint, certain constraints may imposed on the decision functions. Examples of constraints that
the designer might put on the decision functions are:
this process should never be performed for less than x time units,
process I on resource A should never be performed directly after process J,
availability of resource K should never be increased with more than y units per week,
on resource R, at maximum z units of time per week should be spent on changing over,
36
average overall utilization of resources per period should at least be equal to r% of available
capacity.
Such internal constraints are translated by the designer into operational constraints on the performance of the PU level, for instance constraints on production volume, on volume changes, on
production order release patterns, and on production order throughput times. The operational constraints per PU specify the conditions under with the PU can realize its performance and are input
to the design of the Goods Flow Control System.
4.6
The Goods Flow Control Design Problem
Goods Flow Control coordinates the logistics performance of the PUs such that the overall logistics
control targets are obtained within the given budget. The design parameters (decision functions)
for Goods Flow Control pertain to the output requirements of PU-end items. These are artificial
design parameters, that is, they result from the definition of the PUs. Goods Flow Control does not
directly influence the availability of resources, nor the execution of the processes. These decision
variables are controlled by the PUs. Suppose that for each of the PUs the output that can be
obtained under specified conditions (the operational constraints) is known at the start of the design
of the Goods Flow Control System. Then, the output of a PU is specified in terms of the PU-end
items. Thus the function of Goods Flow Control is to select, from among all possible PUs-end
items output values, the ones that together realize the systems overall output requirements, while
respecting the operational constraints of the PUs and the constraint on total logistics related costs.
Various options are available for specifying output requirements per PU. One option, which is used
in a make-to-order setting, is to specify orders for PU-end items that have to be completed within a
specific lead time. In this case the orders to be delivered would be the decision variable of Goods
Flow Control. Another option, which is used in a manufacturer managed inventory situation, is
to specify a demand forecast for PU-end items and require that the PU can deliver out of stock
on the conditions that the actual demand is within a certain bandwidth around a specific demand
forecast. In this case the demand forecast would be the decision variable of the Goods Flow Control.
Under both options, Goods Flow Control must respect the constraints per PU, and must check for
the validity of the conditions under which these outputs within the constraints can be achieved.
Since the output of each PU may constrain future outputs of other PUs, Goods Flow Control must
take into account the material requirements relationships between PU-end items. Moreover it must
take into account the operational constraints per PU. The main difficulty in the Goods Flow Control
design problem results from the operational constraints specified by the various PUs in the system.
Different PUs may specify very different operational constraints; for instance one PU may formulate
a constraint of variations in the volume of total production overtime, while another PU may allow
for practically unlimited volume fluctuations but impose a serious constraint on the production
batch size. The Goods Flow Control design problem is to specify a decision function that specifies
output requirements for the PUs such that, if realized by the PU, together lead to production system
output that satisfies the output requirements. The output of a PU is constrained by the availability of
the raw materials needed for its processes. These raw materials are produced by other PUs. Since
all PUs in a production system can differ in their responsiveness (operational constraints), Goods
Flow Control may need to build in some slack in the time-phasing of the materials inputs of a PU
and the materials outputs of the PUs feeding this PU. Then, on the short term, inputs and outputs of
PUs must be decoupled and stocks of PU-end items act as decoupling points in the material flow in
the production system. Decoupling in the material flow may also be needed for two other reasons.
First going upstream the material flow, uncertainty about demand for items increases. Goods Flow
Control may want to build in some slack in availability of items to compensate for this (increasing)
uncertainty in demand. A well-known demand uncertainty decoupling point is the customer-orderdecoupling point, where downstream all production processes are executed to satisfy customer
orders already placed and upstream all production processes are executed in anticipation of future
customer orders. Decoupling may also occur for items which result from processes with stochastic
37
yield. Second, items may exist which are common components for different items down stream. For
such items, Goods Flow Control may want to allocate the amounts produced only after production,
resulting in a decoupling of production of the common component from production of the items
that consume that common component. For a more detailed account of decoupling points we refer
to Bertrand et al. (1990). For the Goods Flow Control design problem, the designer may evaluate
specific control models based on knowledge of reference models available in literature. For instance,
if, for each of the PUs defined in the system, capacity can always be made available such that output
of each PU is only constrained by available raw materials and by a deterministic manufacturing lead
time, echelon stock control or MRP-I might be considered as a Goods Flow Control mechanism. As
another example, suppose that some PUs are seriously constrained in the output volume that can
be obtained, while others are not, or that PUs strongly differ in the costs involved in changing the
output volume over time. In such a case, the designer might use a chase strategy for PUs with high
resource-flexibility and a level strategy for PUs with low resource-inflexibility. This would require
temporary advancing of output of resource-inflexible PUs, relative to the output of resource flexible
PUs, and would lead to the temporary buildup and builddown of stocks for specific PU-end items.
Such PU-end items would temporary store "capacity". Similar control mode choices may follow if
PUs differ in production order batch size requirements (leading to cycle stocks for specific PU enditems), or if certain PUs operate processes with uncertain processing yields (leading to or the need
for safety stock of specific PU-end items).
APPENDIX
Introduction to Production Control
Acknowledgment
This Appendix consists of Chapter 1 of the book Production Control: a Structural and Design Oriented
Approach, written by J.W.M. Bertrand, J.C. Wortmann, and J. Wijngaard and is reproduced with
their permission.
38
Chapter A. Introduction to Production Control
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
APPENDIX
Production Units and Goods Flow Control
Acknowledgment
their permission.
55
Chapter B. Production Units and Goods Flow Control
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
APPENDIX
Goods Flow Control Structure
Acknowledgment
their permission.
93
Chapter C. Goods Flow Control Structure
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
APPENDIX
Production Control in a Complex Component Manufacturing Firm
Acknowledgment
their permission.
128
Chapter D. Production Control in a Complex Component Manufacturing Firm
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
Bibliography
Adam, N. R., Bertrand, J. W. M., & Surkis, J. (1987). Priority assignment procedures in multi-level
assembly job shops. IIE Transactions, 19, 311-328.
Allen, T. (1987). Managing the flow of technology. Cambridge, Mass.: Harvard University Press.
Altiok, T. (1997). Performance analysis of manufacturing systems. Berlin: Springer Verlag.
Anthony, R. N. (1965). Planning and control systems: A framework for analysis. Harvard University
Press.
Axster, S. (1981). Aggregation of product data for hierarchical production planning. Operations
Research, 29(4), 744756.
Axster, S. (1986). On the feasibility of aggregate production plans. Operations Research, 34(5),
796800.
Axster, S., & Jnsson, H. (1984). Aggregation and disaggregation in hierarchical production
planning. European Journal of Operational Research, 17, 338-350.
Baker, K. R., & Bertand, J. W. M. (1981). An investigation of due date assignment rules with
constraint tightness. Journal of Operations Management, 1, 109-120.
Baldwin, C. Y., & Clarck, K. B. (2000). Design rules, volume 1: The power of modularity. Cambridge,
Mass.: The MIT Press.
Baskett, F., Chandy, K. M., Muntz, R. R., & Palacios, F. G. (1975). Open, closed, and mixed networks
of queues with different classes of customers. Journal of the ACM (JACM), 22(2), 260.
Bechte, W. (1987). Theory and practice of load-oriented manufacturing control. International
Journal of Production Control, 26, 375-396.
Bemelmans, R. P. H. G. (1986). The capacity aspect of inventories. Springer.
Bertand, J. W. M., & Van Ooijen, H. P. G. (1988). The control of categories of work order flow rates.
(Working Paper Bdk/KBS/88, Eindhoven University of Technology)
Bertrand, J. W. M. (1985). Multi-product optimal batch sizes with in-process inventories and multi
work centers. IIE Transactions, 17, 157-163.
Bertrand, J. W. M., & Wortmann, J. C. (1981). Production control and information systems for
component manufacturing shops (Vol. 1). Amsterdam: Elsevier.
Bertrand, J. W. M., Wortmann, J. C., & Wijngaard, J. (1990). Production control: A structural and
design oriented approach (Vol. 11). Amsterdam: Elsevier.
Bitran, G. R., Haas, E. A., & Hax, A. C. (1981). Hierarchical production planning: A single stage
system. Operations Research, 29(4), 717743.
Bitran, G. R., Haas, E. A., & Hax, A. C. (1982). Hierarchical production planning: A two-stage
system. Operations Research, 30(2), 232251.
Bitran, G. R., & Hax, A. C. (1977). On the design of hierarchical production planning systems.
Decision Sciences, 8(1), 28-55.
187
BIBLIOGRAPHY
188
Bitran, G. R., & Tirupati, D. (1988). Multiproduct queueing networks with deterministic routing:
Decomposition approach and the notion of interference. Management Science, 34(1), 75100.
Bitran, G. R., & Tirupati, D. (1993). Hierarchical production planning. In (Vol. 4, p. 523-568).
North-Holland.
Brown, R. G. (1977). Materials management systems. Wiley.
Burbidge. (1971). The principles of production control (Third ed.). Macdonald and Evans.
Buzacott, J. A. (1989). Queueing models of kanban and mrp controlled production systems. Engineering Costs and Production Economics, 17, 3-20.
Buzacott, J. A., & Shanthikumar, J. G. (1993). Stochastic models of manufacturing systems. PrenticeHall.
Byrne, M. D., & Bakir, M. A. (1999). Production planning using a hybrid simulationanalytical
approach. International Journal of Production Economics, 59(1-3), 305311.
Byrne, M. D., & Hossain, M. M. (2005). Production planning: An improved hybrid approach.
International Journal of Production Economics, 93, 225229.
Ciarallo, F. W., Akella, R., & Morton, T. E. (1994). A periodic review, production planning-model
with uncertain capacity and uncertaint demand - optimality of extended myopic policies. Management Science, 40(3), 320332.
Conway, R. W., Maxwell, W. L., & Miller, L. W. (1967). Theory of scheduling. Addison-Wesley.
Cosmetatos, G. P. (1976). Some approximate equilibrium results for the multi-server queue (m/g/r).
Operations Research Quarterly, 27, 615-620.
Dauzre-Prs, S., & Lasserre, J. B. (1994). Integration of lotsizing and scheduling decisions in a
job-shop. European Journal of Operational Research, 75, 413-426.
de Kok, A. G., & Fransoo, J. C. (2003). Planning supply chain operations: definition and comparison
of planning concepts. Handbooks in operations research and management science, 11, 597676.
De Koster, M. B. M. (1989). Capacity oriented analysis and design of production systems. Springer.
Durlinger, P. P. J. (1989). Estimating waiting times in dual constraint production systems (Tech.
Rep.). Eindhoven University Research Report, TUE/BDK/KBS/01.
Durlinger, P. P. J., & Bertrand, J. W. M. (1983). Balancing logistics related costs in multi-phase
production systems (Tech. Rep.). Eindhoven University Research Report, TUE/BMK/KBS/09.
Erlang, A. K. (1918). Solutions of some problems in the theory of probabilities of significance in
automatic telephone exchanges. The Post Office Electrical Engineers Journal, 10, 189-197.
Everdell. (1984). Master scheduling. APICS Training Aid. APICS.
Fleischmann, B., & Meyr, H. (2002). De kok, a.g. and s.c. graves (eds.) supply chain management.
In (chap. Planning hierarchy, modeling, and advanced planning systems). Amsteram: NorthHolland.
Frein, Y., Di Mascola, M., & Dallery, Y. (1995). On the design of generalized kanban control systems.
International Journal of Operations and Production Management, 15(9), 158-184.
Fryer, J. S. (1973). Operating policies in multi echelon dual-constraint job shops. Management
Science, 19, 1001-1012.
BIBLIOGRAPHY
189
Fryer, J. S. (1974). Labor flexbility in multi echelon dual-constaint job shops. Management Science,
20, 1073-1080.
Gailbraith, J. R. (1973). Designing complex organzations. Addison-Wesley.
Gelders, L. F., & van Wassenhove, L. N. (1982). Hierarchical integration in production planning:
Theory and practice. Journal of Operations Management, 3(1), 2735.
Gershwin, S. B. (1994). Manufacturing systems engineering. Engleweed Cliffs: Prentice Hall.
Graves, S. C., Rinnooy Kan, A. H. G., & Zipkin, P. H. (1993). Logistics of production and inventory
(Vol. 4). Amsterdam: Elsevier.
Harris, F. (1913). How many parts to make at once. Factory, The Magazine of Management, 10,
135-136.
Hax, A. C., & Candea, D. (1984). Production and inventory management (Vol. 1). Prentice-Hall
Englewood Cliffs, NJ.
Hax, A. C., & Meal, H. C. (1973). Hierarchical integration of production planning and scheduling.
(Tech. Rep.). MIT, Sloan School of Management.
Henig, M., & Gerchak, Y. (1990). The structure of peridodic review policies in the presence of
random yield. Operations Research, 38(4), 634643.
Hopp, W. J., & Spearman, M. L. (2000). Factory physics (Second ed.). Boston: McGraw-Hill.
Hung, Y. F., & Leachman, R. C. (1996). A production planning methodology for semiconductor
manufacturingbased on iterative simulation and linear programming calculations. IEEE Transactions on Semiconductor Manufacturing, 9(2), 257269.
Irdem, D. F., Kacar, N. B., & Uzsoy, R. (2010). An exploratory analysis of two iterative linear
programmingsimulation approaches for production planning. Semiconductor Manufacturing,
IEEE Transactions on Semiconductor Manufacturing, 23(3), 442455.
Jackson, J. R. (1957). Networks of waiting lines. Operations Research, 5(4), 518521.
Jenkins, R. V. (1987). Words, images, artifacts and sound: Documents for the history of technology.
British Journal of History of Science, 20, 39-57.
Kanet, J. J., & Hayya, J. C. (1982). Priority dispatching with operation due dates in a job shop.
Journal of Operations Management, 2, 167-175.
Kanet, J. J., & Sridharan, S. V. (1998). The value of using scheduling information in planning
material requirements. Decision Sciences, 29(2), 479-497.
Karmaker, U. S. (1987). Lot-sizes, manufacturing lead times and in-process inventories. Management Science, 33, 409-418.
Kim, B., & Kim, S. (2001). Extended model for a hybrid production planning approach. International
Journal of Production Economics, 73(2), 165173.
Kleinrock, L. (1975). Queueing systems, volume i: theory. Wiley Interscience.
Lawrence, S. R. (1997). Heuristic, optimal, static, and dynamic schedules when processing times
are uncertain. Journal of Operations Management, 15(1), 71-82.
BIBLIOGRAPHY
190
Li, J., Blumenfeld, D. E., Huang, N., & Alden, J. M. (2009). Throughput analysis of production
systems: recent advances and future topics. International Journal of Production Research, 47(14),
38233851.
McPherson, R. F., & White Jr., K. P. (1994). Management control and the manufacturing hierarchy:
Managing integrated manufacturing organizations. International Journal of Human Factors in
Manufacturing, 4(2), 121-144.
Meal, H. C. (1978). Studies in operations management. In (chap. A Study of Multi-Stage Production
Planning). Elsevier.
Meal, H. C. (1984). Putting production decisions where they belong. Harvard Business Review, 84,
102-111.
Mesanovic, M. D., Macko, D., & Takahara, Y. (1970). Theory of hierarchical multilevel systems. New
York: Academic Press.
Miller, T. C. (2002). Hierarchical operations and supply chain planning. Springer Verlag.
Nelson, R. T. (1967). Labor and machine limited production systems. Management Science, 13,
648-671.
Olhager, J., Rudberg, M., & Wikner, J. (2001). Long-term capacity management: Linking the perspectives from manufacturing strategy and sales and operations planning. International Journal
of Production Economics, 69(2), 215225.
Orlicky, J. A. (1975). Material requirements planning. New York: McGraw-Hill.
Plossl, G. W. (1987). Throughput time control. International Journal of Production Research, 26,
493-500.
Plossl, G. W., & Welch, W. E. (1979). The role of top management in the control of inventory. Reston
Publ. Co.
Reiser, M., & Lavenberg, S. S. (1980). Mean value analysis of closed multichain queueing networks.
Journal Association For Computing Machinery, 27, 313-322.
Rogers, D. F., Plante, R. D., Wong, R. T., & Evans, J. R. (1991). Aggregation and disaggregation
techniques and methodology in optimization. Operations Research, 39(4), 553582.
Schalla, A. J., Fransoo, J. C., & De Kok, A. G. (2001). Hierarchical anticipation in advanced planning
and scheduling systems. (Working Paper TUE/TM/LBS/01-02. Eindhoven: University of Technology Eindhoven)
Schneeweiss, C. (2003). Distributed decision making (Second ed.). Springer.
Schneeweiss, C., & Schrder, H. (1992). Planning and scheduling the repair shops of the deutsche
lufthansa ag: A hierachical approach. Production and Operations Management, 1, 22-33.
Shanthikumar, J. G., & Buzacott, J. A. (1981). Open queueing network models of dynamic job
shops. International Journal of Production Research, 19, 255-266.
Shapiro, J. F. (1979). Mathematical programming: structures and algorithms. Wiley.
Shapiro, J. F. (1993). Mathematical programming models and methods for production planning
and scheduling. In (Vol. 4, pp. 371443). North-Holland.
Shaw, M. C. (1986). Creative design. CIRP Annals, 35(2), 461-465.
BIBLIOGRAPHY
191
Siegel, G. B. (1971). An investigation of job shops scheduling for jobs with assembly constraints
[unpublished]. Unpublished doctoral dissertation, Cornell University.
Silver, E. A., Pyke, D. F., & Peterson, R. (1998). Inventory management and production planning and
scheduling. New York: J. Wiley and Sons.
Smith, R. P., & Eppinger, S. D. (1997). Identifying controlling features of engineering design
iterations. Management Science, 43, 276-292.
Solberg, J. J. (1981). Capacity planning with a stochastic workflow model. AIIE Transactions, 13,
116-122.
Stecke, K. E., & Solberg, J. J. (1985). The optimality of unbalancing both workloads and machine
group sizes in closed queueing networks of multi-server queues. Operations Research, 33, 882920.
Steward, D. V. (1981a). The design structure system: A method for managing the design of complex
systems. IEEE Transactions in Engineering Management, 28, 71-84.
Steward, D. V. (1981b). System analysis and management: Structure, strategy and design. New York:
Petrocelli Books.
Stoll, H. W. (1986). Design for manufacture: An overview. Applied Mechanics Review, 39, 13561364.
Suh, N. P. (Ed.). (1985). Manufacturing and productivity. NY: Plenum Publishing.
Suh, N. P. (1990). The principles of design. New York: Oxford University Press.
Suri, R. (1983). Robustness of queueing networks formulae. Journal Association for Computing
Machinery, 30, 564-594.
Tardiff, V. (1995). Detecting scheduling infeasibilities in multi-stage finite capacity production environments. (Unpublished PhD Dissertation, Ecanston: Northwestern University)
Tijms, H. C., & Wiley, J. (2003). A first course in stochastic models. Wiley Online Library.
Ulrich, K. T., & Eppinger, S. D. (1995). Product design and development. New York: McGraw-Hill.
Van Beek, P. (1981). An application of decomposition and dynamic programming to the n-product,
1-machine problem. Methods of Operations Research, 41, 63-67.
Van Donselaar, K. H. (1989). Material coordination under uncertainty. Unpublished doctoral dissertation, Eindhoven University of Technology.
Van Ooijen, H. P. G. (1991). Controlling different flow rates in job-shop like production departments. International Journal of Production Economics, 23, 239-249.
Vollmann, T. E., Berry, W. L., & Whybark, D. C. (1984). Manufacturing planning and control systems.
Homewood, Ill. : Dow Jones-Irwin.
Whitt, W. (1983). The queueing network analyzer. Bell System Technical Journal, 62(9), 2779
2815.
Wiendahl, H. P. (1987). Belastungorientierte fertigungs-steuerung. Carl Hanser.
Wiendahl, H. P. (1995). Load-oriented manufacturing control. Berlin: Springer.
BIBLIOGRAPHY
192
Williams, T. M. (1984). Special products and uncertainty in production/inventory systems. European Journal of Operational Research, 15, 46-54.
Wilson, D. R. (1980). An exploratory study of complexity in axiomatic design. Unpublished doctoral
dissertation, MIT.
Wortmann, J. C. (1984). Production management systems - strategies and tools for design. In
(p. 91-106). Elsevier.
Zipkin, P. H. (2000). Foundations of inventory management. McGraw-Hill New York.

Design of Operations Planning and Control

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Design of Operations Planning and Control

Încărcat de

Drepturi de autor:

Formate disponibile

Design of Operations Planning and Control

3 Hierarchical Production Planning

4 A Note on the Design of Logistics Control Systems

Appendix A Introduction to Production Control

Appendix B Production Units and Goods Flow Control

Appendix C Goods Flow Control Structure

Appendix D Production Control in a Complex Component Manufacturing Firm

Chapter 1. Principles of Design

Chapter 1. Principles of Design

unacceptable or unnecessarily complex solutions.

Functional Requirements: Definition and Characteristics

Chapter 1. Principles of Design

Chapter 1. Principles of Design

The Information Axiom

The Information Axiom

Chapter 1. Principles of Design

Chapter 1. Principles of Design

Chapter 1. Principles of Design

Figure 1.4. Lathe functional hierarchy.

Figure 1.5. Lathe system design space hierarchy.

Designers and Their Creative Process

Chapter 1. Principles of Design

Design for Manufacture

Chapter 1. Principles of Design

Minimize the total number of parts.

Conceptual Design, Detailed Design, and Integration

Chapter 2. Conceptual Design, Detailed Design, and Integration

Chapter 2. Conceptual Design, Detailed Design, and Integration

Chapter 2. Conceptual Design, Detailed Design, and Integration

Integration and Implementation

Hierarchical Production Planning

Chapter 3. Hierarchical Production Planning

Chapter 3. Hierarchical Production Planning

The Eindhoven Planning Framework

Chapter 3. Hierarchical Production Planning

Supply Chain Design

Order and resource release

Chapter 3. Hierarchical Production Planning

Relation to other HPP Frameworks

Chapter 3. Hierarchical Production Planning

Chapter 3. Hierarchical Production Planning

processing and setup time uncertainty;

Chapter 3. Hierarchical Production Planning

Asymmetry in Supply Chain Planning, Schneeweiss Anticipation

Chapter 3. Hierarchical Production Planning

Goods flow model

Goods flow model

Instruction (taken into

Instruction (taken into

Effectuation lead time

Figure 3.2. Schneeweiss decision hierarchy.

Chapter 3. Hierarchical Production Planning

Chapter 3. Hierarchical Production Planning

In implicit anticipation, it is attempted to capture the "behavior" of the PU that is relevant to

Effectuation Lead Times

forecast of forecast of exogenous demand for item i in period t +s as decided

Chapter 3. Hierarchical Production Planning

forecast of quantity of item i that becomes available at the start of period

The Need for Control

Chapter 3. Hierarchical Production Planning

Customer perceived order lead time

Information lead time

Figure 3.3. Decision moments driven by lead time structure.

Chapter 3. Hierarchical Production Planning