9802717

Networked Inventory Management
by
Distributed Object Technology
PROEFSCHRIFT
M.A.A.P. Verwijmeren
Verwijmeren, Martinus Antonius Adrianus Petrus
Networked Inventory Management by Distributed Object Technology /

Martinus Antonius Adrianus Petrus Verwijmeren. - Leidschendam: KPN Research. -Ill.
PhD thesis Eindhoven University of Technology. -With ref. -With summary in Dutch.
Keywords: logistics management, information technology, supply chain management, inventory

management, networked organisations, computer networks, object-oriented systems, distributed
systems
NUGI 687 / 855

ISBN 90-72125-62-2
Cover picture by Marieke Kavelaars
 1998 Koninklijke KPN NV, KPN Research, Leidschendam, The Netherlands
Copyright reserved. Subject to the exceptions provided for by law, no part of this publication may be
reproduced and/or published in print, by photocopying, on microfilm or in any other way without the
written consent of the copyright owner; the same applies to whole or partial adaptations. The
copyright owner retains the sole right to collect from third parties fees payable in respect of copying
and/or take legal or other action from this purpose.
by
Distributed Object Technology
PROEFSCHRIFT
ter verkrijging van de graad van doctor

aan de Technische Universiteit Eindhoven,
op gezag van de Rector Magnificus, prof.dr. M. Rem,
voor een commissie aangewezen door het College voor Promoties
in het openbaar te verdedigen
op woensdag 14 oktober 1998 om 16.00 uur
door
Martinus Antonius Adrianus Petrus Verwijmeren
geboren te Breda
Dit proefschrift is goedgekeurd door de promotoren:
prof.ir. P. van der Vlist
en
prof.dr.ir. A.J.M. Vermunt

To my grandparents, wondering from above.
To my parents, supporting from behind.
To Marieke, standing by my side.
Preface
Preface
Human civilisation is developing faster then ever before. Change seems to be the only
constant for people living now. We are experiencing globalisation of our economy and, at
the same time, we are facing individualisation of our society. Driving forces for these
developments are, amongst others, logistics management and information technology. In
this context, the research described in this book studies information systems for supply
chain management, that are based on computer network technology.
I owe a great deal of thanks to all the people who in some way supported me in
conducting this PhD study. Thanks to Prof. Tilanus, who helped me in starting up
research after my graduation. I express my gratitude to the former graduate students, who
contributed vital elements to the research: Lucas van Rijen, Rajkov van Grinsven, Lucian
Toia and Erik van het Hof. Thanks to the supervisors from university, in particular to Prof.
Van der Vlist and Prof. Vermunt who guided me through the research process, and to
Prof. Wortmann and Prof. Nieuwenhuis for their valuable comments in the final stage.
I am grateful to KPN, TPG and KPN Research for giving me the opportunity to
conduct research in the middle of the fascinating business dynamics of logistics and
telecommunications. The investment in research enables continuous innovation, which is
the only way to continue business in continuously changing markets. Many thanks to the
management of KPN Research for funding the research. Despite, or because of the risks, it
was a real pleasure to do my PhD study in the mixture of academia and business. Thanks
to the many colleagues I have met through the years, who gave me inspiration with lively
in-depth discussions as well as relaxed social chats.
A healthy private life, in which dear persons give me comfort and joy, is essential
to succeed in the job. I deeply respect my parents, who laid the foundation of this work by
bringing me up, facilitating my education and showing interest in my occupations. In
addition, I appreciate my friends and family for accepting me to be less involved in social
life in the last few years. Finally, I owe countless hugs to my dear girlfriend Marieke, who
had to do without me so often, who helped me to make progress, and who tolerated my
absence, even when I was present.
As a young boy, I wondered together with my grandparents about the way the world
runs. Later on, I developed the ambition to do some research myself. With the completion
of this dissertation my ambition comes true. Unlike the majority of the world population, I
am living in lucky circumstances, that enabled me to make this intellectual discovery tour.
Although it was a lot of work, I feel it as a rewarding privilege to contribute a little bit to
the knowledge of mankind. At the end, I am glad that I have learned very much during
this valuable stage of my life. However, I am much more happy that I am still wondering.
I
Preface
Martin Verwijmeren, July 1998
II
Contents
Contents
1. Introduction 1
1.1 Research problem 1
1.1.1 Context 1
1.1.2 Objective 3
1.1.3 Limitation 7
1.2 Research method 8
1.2.1 Methodology 8
1.2.2 Framework 11
1.2.3 Report 13
2. Supply chain management analysis 15

2.1 Introduction 15
2.2 Issues in supply chain management 15
2.2.1 Supply chain management 16
2.2.2 Integral inventory management 20
2.2.3 Networked organisation management 24
2.3 Networked inventory management requirements 28
2.3.1 Integral inventory management requirements 31
2.3.1.1 Base Stock Control 33
2.3.1.2 Material/Distribution Requirements Planning 34
2.3.1.3 Line Requirements Planning 35
2.3.2 Networked organisation management requirements 36
2.3.2.1 Configuration flexibility 36
2.3.2.2 Timing flexibility 37
2.3.2.3 Algorithm flexibility 39
2.4 Conclusion 40
3. Networked inventory management design 43

3.1 Introduction 43
3.2 Integral inventory management design 43
3.2.1 Integral inventory management model 44
3.2.1.1 System model 44
3.2.1.2 System variables 47
III
Contents
3.2.1.3 System equations 54

3.2.2 Integral inventory management properties 62
3.2.2.1 Base Stock Control 62
3.2.2.2 Material/Distribution Requirements Planning 67
3.2.2.3 Line Requirements Planning 72
3.3 Networked organisation management design 78
3.3.1 Networked organisation management model 78
3.3.1.1 System model 78
3.3.1.2 System variables 82
3.3.1.3 System equations 84
3.3.2 Networked organisation management properties 87
3.3.2.1 Configuration flexibility 87
3.3.2.2 Timing flexibility 93
3.3.2.3 Algorithm flexibility 99
3.4 Conclusion 105
4. Case study implementation 107

4.1 Introduction 107
4.2 Logistics management 107
4.2.1 Current situation 108
4.2.2 Future scenario 114
4.3 System application 117
4.3.1 Application of NIMISs 118
4.3.2 NIMISs and Business Information Systems 122
4.4 Conclusion 126
5. Computer network technology analysis 127

5.2 Issues in computer network technology 127
5.2.1 Computer network technology 128
5.2.2 Distributed system technology 133
5.2.3 Object-oriented system technology 136
5.3 Distributed object technology requirements 139
5.3.1 Distributed system technology requirements 143
5.3.1.1 Local computing 143
5.3.1.2 Heterogeneous computing 144
5.3.1.3 Transparent computing 144
IV
Contents
5.3.2 Object-oriented system technology requirements 145

5.3.2.1 Object classification 146
5.3.2.2 Attribute encapsulation 146
5.3.2.3 Operation invocation 147
5.4 Conclusion 148
6. Distributed object technology design 151

6.2 Object-oriented system technology design 151
6.2.1 Object Modelling Technique 152
6.2.1.1 Object model 155
6.2.1.2 Dynamic model 174
6.2.1.3 Functional model 188
6.2.2 Object-oriented system properties 190
6.2.2.1 Object classification 190
6.2.2.2 Attribute encapsulation 192
6.2.2.3 Operation invocation 194
6.3 Distributed system technology design 195
6.3.1 Common Object Request Broker Architecture 196
6.3.1.1 Object Request Brokers 197
6.3.1.2 Interface Definition Language interfaces 199
6.3.1.3 Services and Facilities 200
6.3.2 Distributed system technology properties 201
6.3.2.1 Local computing 202
6.3.2.2 Heterogeneous computing 204
6.3.2.3 Transparent computing 205
6.4 Conclusion 207
7. Prototype system implementation 209

7.2 Information technology 209
7.2.1 Prototype tools 210
7.2.2 Prototype objects 215
7.3 System operation 219
7.3.1 Prototype installation 219
7.3.2 Prototype use 223
7.4 Conclusion 229
V
Contents
8. Conclusion 231
8.1 Outcomes of the research 231
8.1.1 Supply chain management analysis 232
8.1.2 Networked inventory management design 234
8.1.3 Case study implementation 235
8.1.4 Computer network technology analysis 236
8.1.5 Distributed object technology design 238
8.1.6 Prototype system implementation 239
8.2 Issues for further research 240
8.2.1 Supply chain management analysis 240
8.2.2 Networked inventory management design 241
8.2.3 Case study implementation 241
8.2.4 Computer network technology analysis 242
8.2.5 Distributed object technology design 242
8.2.6 Prototype system implementation 242
References 245
Abbreviations 257
Summary 261
Samenvatting 269
Curriculum vitae 277
VI
Chapter 1 Introduction
1. Introduction
1.1 Research problem
1.1.1 Context
This research focuses on the mutual impact of trends in logistics management and
information technology. On the one hand the need for supply chain management is
growing, while on the other hand the possibilities of computer network technology are
booming. The suggestion behind the study described here, is that supply chain
management can be enhanced with the help of computer network technology. A major
challenge is to discover potential synergy between the business trend and the technology
trend.
Logistics concerns the efficient, as well as the effective flow and storage of goods, services
and related information from points of origin to points of consumption, for the purpose of
conforming to customer requirements [CLM, 1991]. In logistics there are active objects
which provide capacity, comprising resources for production, transportation and storage,
and there are passive objects which demand capacity, comprising goods, information and
money [Verwijmeren, 1994b]. Logistics management aims at the optimal planning,
control and monitoring of goods, information and money flows across production,
transportation and storage resources. This is done using expertise in supply and demand,
in addition to inventory and capacity. Optimisation in logistics management focuses on
satisfying market requirements, expressed in mutually agreed quality aspects, such as
time, place, quantity and condition, for minimal costs [Vermunt, 1993].
1
Introduction Chapter 1
Logistics management has been performed since the beginning of civilisation.

Eminent examples of early logistics management are: the supply of materials to Egyptian
pyramids, the Silk Route from the Far East to European markets, the acquisition of exotic
spices by the United East India Company (Verenigde Oostindische Compagnie) from the
Indonesian archipelago, as well as the military organisation for bringing munitions, food
and facilities to the battlefield, as applied by the French emperor Napoleon Bonaparte.
Nowadays, logistics management is of prime importance for businesses, due to its possible
impact on business results.
The current trend in logistics management is supply chain management, focusing
on the inter-organisational management of goods flows between independent organisations
in supply chains, such as raw material winners, component manufacturers, finished
product manufacturers, wholesalers and retailers. In supply chain management, the logic
of integration is extended outside the boundaries of a firm, to include suppliers and
customers. This integrative approach to planning, control and monitoring of product
flows, from suppliers to end users, aims at improved customer service at reduced overall
costs [Ellram, 1991] [Jones, 1985]. Recent initiatives in this field are Quick Response
(QR), Continuous Replenishment (CR), Vendor Managed Inventory (VMI) and Efficient
Consumer Response (ECR) [Kurt, 1993] [Whiteoak, 1993] [Rogers, 1994] [Palmer, 1995].
Information technology is the discipline dealing with resources for, and applications of,
automated information processing. Resources in information technology include computer
systems as well as communication networks. Computers are becoming more and more
interconnected through networks, while networks gain computers as network elements.
Thus, the borders between computer technology and communication technology are fading
away. Applications of information technology range from business to private, from stand-
alone to networked, from a single information medium to multimedia, and from internal
machine processing to user interactive applications. Information technology provides
humanity with the ability to keep in touch without travelling, while it enables businesses to
improve efficiency and effectiveness, as well as to develop new business [Jong, 1997]
[Ericsson, 1995].
The present day information technology has many predecessors. Examples of early
information technology are: the introduction of the electromagnetic telegraph by Samuel
Morse, the creation of the telephone by Alexander Graham Bell, the invention of the first
computers like the Mark I and ENIAC and the development of the ARPANET, which laid the
basis for the Internet. In this era of rapid developments, there is a great challenge for
organisations in coping with modern information technology.
2
The current trend in information technology is computer network technology,

focusing on the integration of computers and communication networks, thus creating a
world-wide network of communicating computers [Harasim, 1993] [Ericsson, 1995]. Due
to advances in technology, the capacity for computing, storage and transmission of
information is increasing at a fast pace. The emphasis in the optimisation of information
processing can therefore shift from technical efficiency to functional effectiveness. This
has been demonstrated by the emergence of electronic mail, Electronic Data Interchange
(EDI), wide area networks, object-oriented programming, distributed computing, the
Internet, its World Wide Web (WWW) and Intranets.
1.1.2 Objective
To discover potential synergy between the business trend and the technology trend, this
research aims at the development of new logistics information systems which support
supply chain management and are based on computer network technology. Supply chain
management requires new information systems that are able to provide both integration
and flexibility. Computer network technology allows information systems to be made up of
self-contained components that operate at different locations. Thus, supply chain
management induces new functional requirements for information systems, whereas new
technical requirements might be satisfied by computer network technology.
The study targets at some particular areas in supply chain management and
computer network technology. Two major issues in the field of supply chain management
are integral inventory management and networked organisation management. In the area
of computer network technology, major issues are distributed system technology and
object-oriented system technology.
In Figure 1-1 a typical supply chain is shown, in which the goods flow starts as raw
materials at natural resources and ends with products at final customers. Raw material
winners keep raw materials on stock and supply them to component manufacturers.
Component manufacturers have an inventory of materials at the start of the production
process and an inventory of components at the end. Product manufacturers hold
inventories of products and components, the latter being supplied by component
manufacturers. Wholesalers buy products from product manufacturers and hold central
and regional stock in central and regional distribution centres respectively. Retailers get
their supply from wholesalers and have products in local stock for sales to final customers.
3
Natural Material Component Product Final

resources winner manufacturer manufacturer Wholesaler Retailer customers
Integration Integration Integration Integration Integration
Material Material Component Component Product Central Regional Local

stock stock stock stock stock stock stock stock
Central and procedural

Opposition Stock-point Goods Information
information system
Figure 1-1 Non-integral inventory management by opposition between organisations,

using central and procedural information systems
In today’s world, most supply chains still do not profit from supply chain management
from natural resources to final customers. Instead, the supply chains struggle with non-
integral inventory management due to opposition between organisations. As shown in
Figure 1-1, in a vast majority of supply chains the scope of integral inventory management
is limited to one organisation. Buyers and sellers of different organisations try to create
win-loose situations with their own organisation being the winner, thus limiting the scope
of integration. The organisations in the supply chain each apply hierarchical control to
achieve internal integration. The limited integral inventory management within one
organisation is usually realised by a central and procedural information system that
measures and controls the inventory from one central site in the organisation. For the
inventory management of all stock-points in the organisation, such a central and
procedural information system imposes mandatory instructions which are generated by
fixed routines.
Due to the increase of competition and dynamics in today’s markets, organisations
are forced to further improve their business performance. In particular, customers require
a better price-quality ratio of products as well as a more dynamic product assortment.
Supply chain management can contribute to the required performance improvements, both
in terms of productivity and flexibility. There are two ways to extend the integration
beyond organisational boundaries. Either hierarchical control must be raised to cover all
organisations in a supply chain, or lateral control between the organisations has to be
introduced.
4

Integration
Central and procedural

Domination Stock-point information system Goods Information
Figure 1-2 Integral inventory management by domination of one organisation over others,
using a central and procedural information system
So far, very few supply chains have realised supply chain management from natural
resources to final customers, by one organisation dominating the other organisations in the
supply chain. As presented in Figure 1-2, a dominant organisation can make use of
hierarchical control to achieve integral inventory management across organisational
boundaries. The subordinate organisations in the supply chain are forced to obey to the
instructions of the dominant organisation. The integral inventory management enforced by
one dominant organisation is usually accomplished with one central information system
with fixed procedures, ruling the underlying stock-points of the subordinate organisations
in the supply chain.
This type of supply chain management, where one organisation dominates the
others, could improve productivity of the supply chain, including lower costs of inventory
and better inventory related quality (customer service). These results comply to customer
requirements with respect to a better price-quality ratio of products offered. However,
integral inventory management, as imposed by one dominant organisation, does not
contribute to the flexibility of the supply chain, which is needed to offer customers a more
dynamic product assortment. Because subordinate organisations are bound to one
dominant organisation, they can not easily change their portfolio in the supply chain or
switch to other supply chains.
5

Integration

Distributed and object-oriented

Co-operation Stock-point information system Goods Information
Figure 1-3 Integral inventory management by co-operation across networked

organisations, using distributed and object-oriented information systems
To obtain the required flexibility, supply chains could introduce supply chain management
from natural resources to final customers, by co-operation across a network of
organisations. As is shown in Figure 1-3, networked organisations apply lateral control to
achieve integral inventory management beyond their organisational boundaries. When
compared to non-integral inventory management in supply chains due to opposition
between organisations, the extension of integral inventory management beyond
organisational boundaries can increase the productivity of supply chains, by reducing
inventory related costs and improving inventory related quality (customer service). When
compared to integral inventory management by domination of one organisation, co-
operation across networked organisations can also increase the flexibility of the supply
chains. Networked organisations can frequently change their positions in supply chains to
respond to changing market circumstances. In the context of networked organisations,
new supply chains emerge to create promising products, while supply chains for outdated
products disappear.
The central and procedural information systems currently applied in supply chains, are not
suitable for integral inventory management across networked organisations. These systems
can not simultaneously support the integration required for integral inventory
management as well as the flexibility required for networked organisations. In central
systems, information processing can be integrated across locations, but then the different
organisations in supply chains do not have autonomy over their own functionality and
data, whereas autonomy is an inherent feature of networked organisations, which enables
their flexibility. Procedural systems can provide integrated functions, but they lack the
6
flexibility to easily adapt functionality and data to changing conditions in supply chains,
whereas flexibility is an intrinsic property of networked organisations.
Supply chain management is becoming a vital issue for improving the productivity
and flexibility in supply chains. However, existing information systems are not suitable for
integral inventory management across networked organisations. Developments in the field
of computer network technology are removing the need to use central and procedural
information systems. Distributed system technology is becoming mature, that might better
meet the requirements of supply chain management, when compared to central systems.
Moreover, object-oriented system technology is maturing, that might better satisfy the
requirements related to supply chain management, when compared to procedural systems.
Given the opportunities of supply chain management, the shortcomings of existing
information systems and the developments in computer network technology, the main
objective of the research is to:
show the functional and technical feasibility of information systems

for integral inventory management across networked organisations
using distributed and object-oriented system technology
The information systems to be studied in this research are called Networked Inventory
Management Information Systems (NIMISs) [Verwijmeren, 1996a]. The extent to which
the objective is reached, provides answers to the questions whether and how new
information systems conforming to the specified functionality and technology could be
developed. More generally, the research results provide insight into the potential synergy
between supply chain management and computer network technology.
1.1.3 Limitation
The research is limited to the feasibility of information systems for integral inventory
management across networked organisations, making use of distributed and object-
oriented system technology. Many related issues are not considered in the study.
Limitations of the research apply to supply chain management as well as to computer
network technology.
From the functional perspective of supply chain management, only integral inventory
management and networked organisation management are considered. While integral
inventory management is included in the research objective, related functionality such as
capacity management, operations management, human resource management and
financial management are beyond the scope of the research. Within integral inventory
7
management, the focus is on alternative information processing in already known

inventory management algorithms, and not on the comparative performance of different
algorithms, nor on the creation of new algorithms.
Other functionality included in the research, concerns facilities for management of
networked organisations. The focus is on processing of state-dependent information such
as demand forecasts within and across organisations, and not on determination,
standardisation and exchange of state-independent data, like product master data,
inventory norm levels, and message formats in Electronic Data Interchange (EDI). Issues
related to networked organisations, such as business process redesign, organisational
culture, transfer pricing and strategic decision making, are excluded from the research.
From the technical perspective of computer network technology, only distributed system
technology and object-oriented system technology are addressed. While distributed system
technology is incorporated in the study, related technical engineering issues, such as
internal processor architectures, low-level communication protocols, database
management mechanisms and operating system details, are beyond the research scope.
The focus is on functionality of application software which is distributed over locations,
and not on comparative platform performance, nor on technical improvements in
hardware components, communication protocols, database systems and operating systems.
Other technology incorporated in the research, is object-oriented system
technology. The focus is on the engineering principles of object-oriented system
technology in application software, and not on the comparison of object-oriented design
methods and object-oriented programming languages, nor on the improvement of object-
oriented system concepts and object-oriented computer platforms. Issues related to object-
oriented system technology, such as other system paradigms, maintenance of systems,
reusability of components and management of system development projects, are excluded
from the research.
1.2 Research method
1.2.1 Methodology
Science stands both for knowledge, a set of statements, and for research, the process which
has knowledge as its product [Wesley, 1982]. Although there is no strict border between
scientific and non-scientific knowledge, typical characteristics of scientific knowledge are
the correctness of the statements as well as their richness of information [Leeuw, 1990]. If
8
a statement can not be tested, its correctness can be neither falsified nor proven. If a
statement is correct by definition, it does not contain any sensible information. Hence, it
should in principal be possible to test a scientific statement and it must in theory be
possible to reject it [Leeuw, 1990] [Vries, 1985]. Research methodology is the doctrine of
methods, that is, the application of logic in the fields of science. It is concerned with the
organisation of research to ensure that the outcomes represents scientific knowledge.
Methodology links the type of knowledge coming from research to the type of process
which led to that outcomes.
The product of research is knowledge, which can be captured in several forms,
ranging from single statements to theories [Leeuw, 1990]. Single statements can be
definitions and empirical, analytical or normative claims. The knowledge captured in
single statements is rather limited. A theory is knowledge represented in a collection of
coherent and generic statements. The knowledge embedded in a theory is more
comprehensive than that in a single statement. The knowledge to be generated in this
study is incorporated into a design, which is a model of a system to capture knowledge of
that system. A design represents a set of coherent statements that state what happens when
reality conforms to certain conditions. In the spectrum of knowledge forms, a design
claims less knowledge than a theory, but contains more knowledge than a single
statement.
Research is a process for producing knowledge, which can be organised according to the
empirical cycle [Leeuw, 1990]. In the empirical cycle, induction and deduction are applied
successively to arrive at tested and informative statements. Induction is a way of reasoning
from particular statements to generic statements, whereas deduction reasons from generic
statements to particular statements. Induction in the empirical cycle concerns taking some
preliminary observations in reality and construction of hypotheses for generic description
or explanation of the observed reality. Based on deduction in the empirical cycle,
particular statements about reality are deduced from the generic hypotheses to test their
correctness. Depending on the similarity between specific observations in reality and the
particular statements about reality, the hypotheses are either rejected or accepted.
To generate the design of the system aimed at in this study, the research process is
organised according to the model cycle, which is similar to the empirical cycle but
specialised in system oriented research [Leeuw, 1990]. The model cycle starts with an
analysis of observations in the environment of a desired system. Using induction,
observations in the system environment are used to arrive at requirements for the system to
be designed. Based on the requirements, a generic design of the system is created, that
specifies a model of the system to be realised. From the design, an implementation of the
9
system in a particular system environment is deduced. The system implementation tests

the fit of the system design in the particular system environment.
10
1.2.2 Framework
While the research methodology specifies the fundamental approach, the particular stages
of this study and their dependencies are specified in a research framework. In Figure 1-4
the research framework for this study is presented. The framework is a specialisation of
the model cycle, which is applied to show the feasibility of the systems. The framework
comprises three phases: analysis, design and implementation. In the framework a
distinction is also made between the functional and technical view of the systems,
representing logistics management and information technology respectively. Combination
of the three phases and the two viewpoints leads to six research stages in between the
introduction and the conclusion. To clarify the relationship between the research stages,
their main inputs and outputs are explained.
11
Logistics management Information technology
Introduction (1)
Supply chain management Computer network technology

analysis (2) analysis (5)
Networked inventory management Distributed object technology

design (3) design (6)
Case study Prototype system

implementation (4) implementation (7)
Conclusion (8)
Figure 1-4 Research framework
The inputs for the introduction are the trends observed in logistics management and
information technology, while the outputs are the objective to be achieved and the method
to be applied. Those outputs are inputs for all other research stages, and therefore they are
not mentioned explicitly in the explanation of the remaining stages.
The inputs for the conclusion are the research objective and method stated in the
introduction, in addition to the results of the six research stages. The outputs of the
research conclusion are the outcomes of the research with respect to logistics management
and information technology, as well as issues for further research in those areas.
The inputs for the supply chain management analysis are the research objective and
method, while the computer network technology analysis provides implicit input. The
12
outputs of the supply chain management analysis are observations in the functional system
environment and functional requirements for the information systems.
The inputs for the networked inventory management design are the functional
requirements from the supply chain management analysis, and implicitly the distributed
object technology design. The outputs of the networked inventory management design are
a model that specifies the information systems and an explanation of the functional
properties of the systems.
The inputs for the case study implementation are the networked inventory
management design of the systems, and implicitly the prototype system implementation.
The outputs of the case study implementation are a description of a functional system
environment and a demonstration of the application of the information systems in the
particular environment of logistics management.
The inputs for the computer network technology analysis are the research objective and
method, while implicit input comes from the supply chain management analysis. The
outputs of the computer network technology analysis are observations in the technical
system environment and technical requirements for the information systems.
The inputs for the distributed object technology design are the technical
requirements from the computer network technology analysis, and implicitly the
networked inventory management design. The outputs of the distributed object technology
design are a model that specifies the information systems and an explanation of the
technical properties of the systems.
The inputs for the prototype system implementation is the distributed object
technology design of the systems, and implicitly the case study implementation. The
outputs of the prototype system implementation are a description of a technical system
environment and a demonstration of the operation of the information systems in the
particular environment of information technology.
1.2.3 Report
In this report the research is documented in a structure that is in line with the previously
presented research framework. Each of its stages is discussed in a separate chapter. The
chapter numbers for the respective stages are shown between brackets in Figure 1-4.
In Chapter 1, the research introduction is given, including the objective and method
of the study. In Chapters 2 to 4, the functional stages of the research framework are
described. In Chapter 2, supply chain management is analysed as one of the trends in
logistics management. Chapter 3 deals with the design of systems for networked inventory
13
management. Chapter 4 is dedicated to the case study implementation of the information

systems.
In Chapters 5 to 7, the technical research stages are reported. The analysis of
computer network technology is described in Chapter 5. In Chapter 6, the design of the
information systems using distributed object technology is explained. Then, in Chapter 7
the prototype system implementation is addressed. Finally, in Chapter 8 the conclusion of
the research is stated.
To gain a complete understanding of the ins and outs of the research, the complete
document should be studied. Chapter 1 ‘Introduction’ and Chapter 8 ‘Conclusion’ are
relevant to all types of readers as they provide overviews of the starting and finishing
conditions of the research respectively. There are some suggestions for readers with
specific interests. Those who favour logistics management and functional aspects of
related information systems should focus on Chapters 2 to 4. Those who are interested in
information technology can best concentrate on Chapters 5 to 7.
A guideline for readers whose primary interest is in the theoretical background of
the information systems, is to focus on Chapter 2 ‘Supply chain management analysis’ and
Chapter 5 ‘Computer network technology analysis’. Those interested in the internal
structure and behaviour of the information systems should go into Chapter 3 ‘Networked
inventory management design’ and Chapter 6 ‘Distributed object technology design’. For
those who want to know how the systems fit into functional and technical practice,
Chapter 4 ‘Case study implementation’ and Chapter 7 ‘Prototype system implementation’
are the most relevant parts of the document.
14
Chapter 2 Supply chain management analysis
2. Supply chain management analysis
2.1 Introduction
In this chapter, supply chain management and related issues are analysed. The inputs for
the supply chain management analysis are the research objective and method (Chapter 1),
while the computer network technology analysis provides implicit input (Chapter 5). The
outputs of the supply chain management analysis are observations in the functional system
environment and functional requirements for the information systems studied.
In section 2.2, issues in supply chain management are analysed. After a discussion
on supply chain management, integral inventory management and networked organisation
management are explained. In section 2.3, functional requirements for the information
systems are specified. The requirements related to integral inventory management are
followed by the requirements related to networked organisation management.
2.2 Issues in supply chain management

Logistics management is a very broad business and research area, in which supply chain
management covers the part that focuses on integral logistics management across
organisations. Currently, much attention is paid to supply chain management, because
management of logistics activities across organisations offers opportunities to further
increase business performance after internal integration has been reached.
One of the vital competencies for improvement of business performance is integral
inventory management, since in many cases significant costs are related to having either
too many or too few products in stock. To cope with the growing dynamics in competitive
15
Supply chain management analysis Chapter 2
markets, the flexibility of organisations could be improved by co-operation with other

organisations in a network, so networked organisation management is also becoming a
vital competence for organisations.
The issues in supply chain management that are studied further, are illustrated in
Figure 2-1, with references to the sections where they are discussed. Supply chain
management (SCM) encompasses aspects of integral inventory management (IIM) and
networked organisation management (NOM). Networked inventory management (NIM) is a
concept at the intersection of integral inventory management and networked organisation
management.
Logistics management
SCM: Supply chain management

(2.2.1)
IIM: NIM: NOM:

Integral Networked Networked
inventory inventory organisation
management management management
(2.2.2) (2.3) (2.2.3)
Figure 2-1 Issues in supply chain management
2.2.1 Supply chain management

In Figure 2-2 world-wide supply chains are illustrated, including various natural
resources, final customers, organisations, resources and products. The supply chain
entities are related by the product flows between them. Any path in the network, linking
the entities from natural resources to final customers, represents one particular supply
chain. In addition to the feed forward flows of materials, the links of a supply chain are
related via the feedback flows of information [Stevens, 1989]. Flows of money also go
across the supply chain entities, to compensate for transactions.
16
A supply chain typically crosses several organisational boundaries as the materials

flow from raw materials suppliers through to the end customers [Scott, 1991].
Organisations in supply chains can be raw material winners, component manufacturers,
finished product manufacturers, wholesalers and retailers. As most organisations deal with
multiple buyers and suppliers, they form a complex business network comprising many
interdependent supply chains.
The processes in supply chains include passive objects which demand capacity and
active objects which provide capacity [Verwijmeren, 1994b]. Passive objects in supply
chains are goods, information and money, whose status can be changed by active objects.
Goods represent, amongst others, raw materials, components or finished products, while
information includes orders, plans, bills, notifications and the like, while money refers to
amounts of cash or money deposited in bank accounts. Active objects in supply chains can
be categorised into resources for production, transportation and storage. Production
resources focus on change of material, transport resources deal with change of place and
storage resources are devoted to change of time. Active objects not only work on goods,
but also process information and money [Verwijmeren, 1995].
Figure 2-2 World-wide supply chains
Due to increasing competition, companies are required to improve their business

performance. More and more markets have been liberalised in recent years, resulting in
global market places with severe competition. The increased competition between the
17
numerous players in the open markets, has resulted in a relative shift of power from
suppliers to customers. Whereas previously customers in a local market place were bound
to local companies and companies could rely on those captive customers, in the global
market place customers can choose between a greater variety of offerings from an
increased number of suppliers.
In the open markets just one superior performer can raise the competitive threshold
for companies around the world. Good performers drive out the inferior, because the
lowest price, the highest quality, the best service available from any one of them soon
becomes the standard for all competitors [Hammer, 1993]. In this way, customers get more
power in telling suppliers the specifications of the products they need, the delivery dates
they accept and the prices they allow. As a consequence, customers become accustomed to
being offered with a wide assortment of products, easily available at attractive prices and
certain to perform to specification [Scott, 1991]. Ultimately, customers ask for mass
customisation, for which suppliers have to deliver products at affordable prices, with
enough variety so that nearly every customer feels that he buys a customised product [Pine,
1992].
Customer requirements due to the increase of competition include a better price-
quality ratio of products as well as a more dynamic product assortment. To cope with those
customer requirements, companies are forced to improve their business performance.
Demand for a better price-quality ratio requires improvement of the business productivity,
which can be achieved by realising cost reduction (efficiency increase) or quality
improvement (effectiveness increase) in the business processes. Demand for a more
dynamic product assortment implies that businesses have to enhance their flexibility, so
that their business processes can cope with a broader product range and can adapt to a
varying product portfolio.
One of the ways to improve business performance is supply chain management, which
concerns the inter-organisational management of goods flows between independent
organisations. Supply chain management is an integral approach to planning, control and
monitoring of total materials flows from suppliers to end users, aiming at improved
customer service at reduced overall costs [Ellram, 1991] [Jones, 1985]. It focuses on the
final customer, who creates demand, which in turn supports the existence of the supply
chain to provide the customer with products. When there is no dominant organisation in a
supply chain, with hierarchical control over other organisations, every organisation in the
supply chain has its own strategic and operational management units to control its own
processes. From this perspective, supply chain management concerns the co-ordination of
operational management units from different organisations in a supply chain, within the
18
constraints imposed by their respective strategic management units, aiming at an optimal

exchange of goods, information and money between the organisations to meet customer
requirements [Verwijmeren, 1994b].
The realisation of supply chain management is a complex process in which the
scope of integration is extended beyond organisational boundaries. Logistics management
typically starts from a stage of fragmented local process optimisation. Subsequent
integration stages inside an organisation are single function integration, integration of
adjacent functions and organisation-wide integration. Supply chain management starts
when the scope of integration is extended from internal to external co-ordination, a stage
that takes into account customers and suppliers in the supply chains [Stevens, 1989]
[Christopher, 1994]. The scope of supply chain management can ultimately grow to
integral management of whole supply chains, from natural resources to final customers.
Supply chain management encompasses diverse functional areas, such as inventory
management, operations management and capacity management. Some particular
concepts for supply chain management are Quick Response (QR), Continuous
Replenishment (CR), Vendor Managed Inventory (VMI) and Efficient Consumer Response
(ECR) [Kurt, 1993] [Whiteoak, 1993] [Rogers, 1994] [Palmer, 1995]. ECR is a set of
strategies developed by the grocery industry that allows an entire channel to act like a
single firm by taking away barriers to information and product flows in order to improve
competitiveness. The ECR strategies are efficient store assortments, efficient replenishment,
efficient promotion and efficient product information.
Supply chain management is a concept for organisations to achieve higher productivity

and greater flexibility, thus responding to customers who require a better price-quality
ratio and a more dynamic product assortment. Supply chain management represents an
opportunity for organisations to utilise assets, particularly inventory, more effectively,
while decreasing the ownership and management risks of vertical integration [Ellram,
1991]. Instead of local optimisation, supply chains are co-ordinated to optimise overall
performance. By examining the trade-offs in supply chains across organisations, less
inventory or capacity is required to achieve the same service level [Ellram, 1989]. Because
inventory costs per product, due to space, capital and obsolescence can fall, more products
can be offered simultaneously, while new products can be introduced more rapidly. In
addition, the co-operative attitude of the organisations participating in supply chain
management, makes it easier to establish supply chains for new products.
The core principle behind supply chain management is the reduction of uncertainty
in decision making processes of organisations in supply chains. Supply chain management
can reduce uncertainties related to supplier performance, manufacturing processes and
19
customer demand [Davis, 1993]. To reduce those uncertainties, a collective framework for
supply chain management is needed. Elements in that framework are the recognition of
the required customer service level for end users, the positioning of stock-points along the
supply chain and the development of policies for managing the supply chain as a single
entity [Jones, 1985]. The policies must ensure that the control system is well damped at
each stage, that time delays are reduced and that market demand flows throughout the
chain with minimum distortion [Towill, 1996].
The co-ordination of the management processes in a supply chain requires
information exchange between the organisations in the supply chain. The extra availability
of information in decision making units reduces uncertainty, resulting in better control
and finally in improved performance [Sheombar, 1995]. For the exchange of proprietary
information, such as sales and forecasts, a collaborative attitude of the supply chain
partners is needed [Walker, 1994]. The required co-operation is encountered in
organisations that apply networked organisation management.
2.2.2 Integral inventory management

By focusing on the inventory aspect, a network of supply chains can be considered as a
network of stock-points connected through transit processes. Raw materials, components,
assemblies and finished products all represent inventory at the various stages of production
and distribution. Inventory occurs at all places in a supply chain, both in storage processes
and in production and in transportation processes. Inventory in a storage process is called
stock-point inventory, while inventory in production and transportation processes is called
transit inventory.
Instead of classification by the type of process in which inventory resides, inventory
can also be categorised by the reason for its existence in supply chains [Wijngaard, 1985]
[Donselaar, 1987] [Hoekstra, 1987] [Graves, 1988] [Monhemius, 1989] [Fogarty, 1991]
[Graves, 1993]. Inventory can either be classified as purposely ‘desired inventory’ or
necessarily ‘required inventory’. There are at least four categories of so-called desired
inventory. Speculative inventory is held for profiting from expected price changes.
Strategic inventory exists to secure critical supply during crises. Capacity inventory is held
to level and smooth occupation of resources when demand or supply shows structural
fluctuation. Promotional inventory, held to provide product visibility to customers, can
also be classified as desired inventory.
Ideally, no extra inventory would exist in a supply chain other than the categories
of desired inventory mentioned above. Nevertheless, there are at least four categories of so-
called required inventory, needed to cope with uncertainties and inflexibility in the
demand and supply processes. Lead time inventory is required because of throughput times
20
of processes and buffer inventory is required to uncouple operations. These two categories
can be put under the heading transit inventory. Furthermore, lot size inventory is required
for processing materials in batches and safety inventory is required to compensate for the
stochastic behaviour of processes. These two categories can be grouped under the heading
stock-point inventory.
Inventory
Excess
Desired
Required
Shortage


Figure 2-3 Inventory categories in supply chains
In Figure 2-3 inventory categories in supply chains are plotted for a particular supply
chain, from natural resources to final customers. For every stage in the supply chain the
inventory levels are indicated per category. Given the levels of the desired as well as the
required inventory, there would ideally be no extra inventory categories in a supply chain.
However, excess inventory and inventory shortage (negative inventory) occur due to
imperfect inventory management. It is an old truth that inventory management is one of
the decisive factors in determining whether a firm makes a profit or a loss [Whitin, 1957].
Excess inventory has a negative impact on business performance, in particular on
productivity, as it increases inventory related costs like costs for capital, space and
obsolescence. Inventory shortage also harms business performance, as it reduces inventory
related revenues coming from product availability for customer service.
Excess inventory and inventory shortage are both caused by uncertainties in
quantifying and timing of supply and demand, which are not adequately dealt with by the
present inventory management systems. Through amplification, minor uncertainties in
downstream supply chain stages may develop major unforeseen variability in upstream
stages. Amplification is a non-technical term implying a response from some part of a
system which is greater than would at first seem to be justified by the causes [Forrester,
21
1961]. Due to this system dynamics phenomenon, a small change in demand at some
points of sale to final customers could result in large demand fluctuations in the supply
chain some stages upstream. The amplification is the negative result of the lack of proper
inventory management systems in supply chains, and the forthcoming delays and
distortions in information flows through the supply chains. In many forecasting
procedures, growth rates are extrapolated, even though this is not justified. There is also a
tendency to order ahead when deliveries slow down or during price rises. Moreover,
production orders may differ from sales orders for inventory accumulation, to fill supply
pipelines and for speculation.
A traditional way of coping with uncertainties in demand and supply has been to
hold more inventory [Scott, 1991]. However, in competitive markets, fighting
uncertainties by inventory increase might not be a valid remedy, because inventory
holding costs might become prohibitive. To raise the price-quality ratio of products in
response to increased customer requirements, alternative measures have to be considered.
Integral inventory management is one of the directions for tackling uncertainties in supply
chains without increasing inventory.
Integral inventory management concerns the co-ordinated planning, control and

monitoring of inventory levels in stock-points throughout supply chains, in order to
maximise overall supply chain performance. Supply chains can be represented as multi-
echelon or multi-stage inventory systems. As integral inventory management can be
perceived as co-ordination of the echelons from one virtual point of view, it is also known
as centralised control of multi-echelon inventory systems [Zijm, 1992] [Graves, 1993]
[Lee, 1993] [Diks, 1996] [Houtum, 1996] [Stenger, 1996].
Several algorithms exist for integral inventory management, such as Base Stock
Control [Magee, 1958] [Clark, 1960], Material (and Distribution) Requirements Planning
(MRP/DRP) [Orlicky, 1975] [Martin, 1983] [Martin, 1993] and Line Requirements
Planning [Donselaar, 1989]. Material Requirements Planning (MRP) and Distribution
Requirements Planning (DRP) manage inventory in supply chains with the help of time-
phased demand and inventory levels, using values for the current moment and for future
periods. Base Stock Control (BSC) works against final customer demand and integral
inventory (or echelon stock), rather than against demand generated by replenishment
orders from the next downstream stock-point in the supply chain [Clark, 1960] [Silver,
1985]. LRP also makes use of final customer demand and integral inventory, but works
also with time-phased demand and inventory levels, like MRP/DRP [Donselaar, 1990].
Non-integral inventory management is also called decentralised inventory control
or single echelon management. A category of algorithms for non-integral inventory
22
management is Statistical Inventory Control (SIC), also called re-order point techniques
[Silver, 1985] [Donselaar, 1989] [Fogarty, 1991]. SIC ignores the implications of decisions
at one stock-point for the inventory levels of other stock-points. Replenishment orders tend
to become progressively larger and less frequent further upstream in the supply chain. As
a consequence, it takes a long time before changes in customer demand influence the
behaviour of upstream stock-points.
Whereas orders in non-integral inventory management are based on current and
local inventory status only, integral inventory management typically uses more
information than just current and local inventory status in a stock-point to determine
orders. The extra information is used to obtain coherence in the management of the
inventory levels at the stock-points of a supply chain. Because integral inventory
management uses more information in its decision making algorithms, it requires more
information exchange across supply chain processes than non-integral inventory
management [Lee, 1992].
Integral inventory management is a means for businesses by which they can raise their
productivity, including cost reduction and quality improvement. In general, integral
inventory management produces superior results when compared to non-integral inventory
management [Lee, 1993] [Axsäter, 1994] [Hausman, 1994] [Stenger, 1996]. Integral
inventory management can decrease costs incurred by holding excess inventory or due to
encountering inventory shortage, and can also increase revenues related to product
availability for customer service.
In non-integral inventory management, the implications of decisions at one stock-
point for the inventory levels of other stock-points are ignored. A consequence of the lack
of coherent management is amplification of variations in the supply chains [Donselaar,
1989]. Thus, non-integral inventory management leads to high uncertainties, which have
to be compensated by high inventory norm levels to reach a certain target level for product
availability. The explanation for the inferior performance of SIC when compared to BSC,
MRP/DRP and LRP, is that it does not use information on future demand or inventory levels
in downstream stages.
The use of information on inventory in other stages or on expected demand in
future periods, reduces the uncertainties in the decision making processes. Hence, better
ordering decisions can be made, ultimately leading to reduced inventory levels at the
stock-points, without harming service levels. Because BSC, MRP/DRP and LRP exploit
dependencies of stock-points in supply chains, they outperform SIC, assuming that the
parameters are optimal in all algorithms. BSC is triggered by customer demand, which
often varies less than upstream ordering, so inventory levels can be decreased. MRP/DRP
23
exploits the time-varying and dependent nature of demand and inventory levels, resulting
in uncertainty reductions and hence lower inventories. LRP makes supply chains even
more transparent, resulting in more robust management when compared to MRP/DRP and
further reduction of inventory levels.
From an inventory management perspective, there is a distinct advantage in using
integral inventory management, both within as well as across organisations. However,
despite the theoretical benefits of integral inventory management, there may be
organisational reasons for applying non-integral inventory management [Hausman, 1994].
In particular, information flows can be restricted or can be costly so that integral inventory
management may not be feasible [Lee, 1993]. Companies that apply networked
organisation management have less restrictions with respect to information flows, while
information systems can reduce costs of processing information in supply chains.
2.2.3 Networked organisation management

Supply chains are managed by their participating organisations. Within organisations, the
co-ordination of activities is based on a hierarchy. Higher organisational levels control
lower organisational units through instructions and feedback. Across organisations, the
market is the co-ordination mechanism. In the market place, an organisation agrees upon
activities with external actors. Organisations can either perform business activities in-
house, thus co-ordinating through their hierarchy, or they can out-source activities to
suppliers, implying co-ordination by the market. Organisational boundaries occur where
co-ordination through a hierarchy is interrupted by the market mechanism.
Whether it is best to manage business activities through hierarchies or markets can
be determined with the help of the transaction cost approach [Williamson, 1975]
[Williamson, 1981]. A transaction occurs when goods or services are transferred from one
stage of activity to another. Organisations try to minimise costs associated with
transactions by selecting the most appropriate co-ordination mechanism. Transactions are
internalised when the costs of co-ordination by a hierarchy (internal co-ordination) and
internal production are less than the costs of co-ordination by the market (external co-
ordination) and external production, whereas externalisation occurs when the internal
costs are higher than the external costs. The higher the uncertainty, complexity, frequency
and asset specificity of transactions, the higher the costs for external co-ordination, the
more likely these transactions are to be internalised. The trade-off between internal versus
external co-ordination plus production costs, results in efficient boundaries across
organisations.
Co-ordination by the market can be differentiated to the duration of the
relationships between a buyer and a seller [Sheombar, 1995]. The market mechanism
24
might co-ordinate one time transactions between buyers and sellers with short-term
relationships. Each time a transaction is needed, a new agreement has to be established by
the buyer and the seller. Alternatively, the market mechanism can co-ordinate multiple
transactions as part of a contract between a buyer and a seller that have a long-term
relationship. In that case, the contract agreed upon can be considered as a super
transaction established in the market. Co-ordination by hierarchy includes several types of
organisation management [Miles, 1992] [Mintzberg, 1983]. In functional organisation
management, an organisation is divided into functionally specialised departments that
together make complete products. It allows firms to achieve the necessary size and
efficiency for mass production. In divisional organisation management, organisations are
split up in divisions that specialise in particular products. These product oriented divisions
operate as nearly autonomous companies to their respective customers, while corporate
management serves as an investment banker in strategic decisions. Finally, matrix
organisation management combines elements of both functional and divisional
organisation management.
Market Networked organisations Hierarchy
Loose relationships Semi-stable relationships Fixed relationships
Organisation Relationship
Figure 2-4 Networked organisations between markets and hierarchies
An alternative to co-ordination by either market or hierarchy is networked organisation

management. A networked organisation is an organisation (actor, company or business
unit) with its own strategic control unit, that co-operates with other organisations at a
tactical and operational level, within its strategic constraints, in order to gain mutual
benefits [Verwijmeren, 1996a]. Typical characteristics of networked organisation
management include autonomous control, common goals, mutual trust, information
25
exchange, close co-operation and variable coupling [Thorelli, 1986] [Powell, 1990] [Scott
Morton, 1991] [Miles, 1992] [Webster, 1992] [Ching, 1996]. Organisation types that
include aspects of networked organisation management are the Value-Adding Partnership
[Johnston, 1988], the Virtual Corporation [Davidow, 1992], the Lean Enterprise
[Womack, 1994] and the Extended Enterprise [Browne, 1995].
In networked organisation management, several organisations are linked by
relationships in between markets and hierarchies. Together, they make up a network
which can be tight or loose depending on the number, intensity and type op interactions
between the members [Thorelli, 1986]. A network in this context is a set of organisations
which are connected by semi-stable relations [Aken, 1998]. The relationships have a
certain durability, but are not fixed. In principle, the network can be broken without
destroying the organisations in the network. Figure 2-4 illustrates how networked
organisations are positioned between markets and hierarchies when considering the
strength of the relationships between the organisational units. In pure markets, the
relationships between organisations are extremely loose. A short-term relationship occurs
for a one time transaction and then disappears. In pure hierarchies, the relationships
between organisational units are completely fixed. The relationships exist indefinitely,
possibly for the lifetime of the entire organisation.
A network of networked organisations is the intermediate between on the one hand
the vertically integrated firm and on the other hand the open market. In contrast to an
open market, there is some joint commitment among networked organisations to establish
and cultivate relationships [Ching, 1996]. Whereas in a closed hierarchy there is unity of
ownership, power and loyalty, in a network of networked organisations there is no single
trinity, but distributed ownership, power and loyalty instead [Aken, 1998]. Instead of
contracts in markets and employment in hierarchies, the normative basis in networked
organisations consists of complementary strengths. In networked organisations the climate
is oriented to mutual benefits, as compared to the suspicion in the market and the
formalities in a hierarchy. Furthermore, the means for communication across networked
organisations are relationships, instead of prices in the market and routines in a hierarchy
[Powell, 1996].
Stable, internal and dynamic networks represent three common types of networked
organisations [Miles, 1992]. In a stable network, one core organisation maintains tight
relationships with a limited set of outside suppliers and distributors that also serve
organisations outside the network. These business partners are carefully selected by the
core firm and closely tied by contractual arrangements. An internal network consists of
organisational units within one organisation, buying and selling among themselves at
26
prices established in the open market. To verify the price and quality of the products
which are part of internal transactions, the organisational units have a regular opportunity
to buy and sell outside the network.
In a dynamic network, independent organisations are linked together for temporary
production and then disassembled to become part of another network [Miles, 1992]. These
dynamic networked organisations can participate in various supply chains for different
products simultaneously. In a dynamic network, business functions such as development,
manufacturing and distribution could be performed by independent organisations in the
network [Miles, 1986]. Brokers may be used to locate and group these different
organisations. As a substitute for lengthy trust building processes based on experience,
information systems with broad access are used to mutually verify contributions.
A stable network applies the logic of a functional organisation to serve stable
demand and uses the logic of market contracts to their business partners, who also work
for other customers to maintain their competitive fitness [Miles, 1992]. The logic of an
internal network is on the one hand the shared utilisation of resources, as in matrix
organisations, and on the other hand the creation of a market inside a firm. A dynamic
network is partly based on the logic of a divisional organisation, by focusing on different
products and markets. For the rest, a dynamic network is driven by the availability of
numerous organisations in the market that are willing to participate in temporary
networks.
Networked organisation management provides businesses with the opportunity to increase

flexibility, including the ability to process more different products simultaneously as well
as the ability to more frequently introduce new products and remove outdated ones.
Hierarchies and markets support productivity and flexibility respectively, but they are not
geared to support them simultaneously, as required in competitive markets. By combining
the benefits of both hierarchy and market, networked organisations can increase the
flexibility of organisations, while remaining as efficient as hierarchies [Thorelli, 1986].
Networked organisations can obtain more flexibility than hierarchies, because they
represent autonomous units with great willingness to co-operate with others [Miles, 1986].
Instead of advocating resource accumulation, a networked organisation focuses on its own
strengths and uses voluntary relationships to respond to dynamic market demand [Miles,
1992] [Snow, 1992]. In networked organisation management, the scale and management
associated with large companies is combined with the flexibility, creativity and low
overheads usually found in small companies [Johnston, 1988].
Networked organisations are able to couple and uncouple other organisations with
less cost and time than hierarchies [Miles, 1992]. Hierarchies in vertically integrated firms
27
are slow to react upon rapidly changing customer requirements with creative product
offerings, because they are bound to an installed base of dedicated resources that can not
be adapted immediately. It is easier for a networked organisation to make a link with a
business partner than for a hierarchy to buy and integrate an organisation. In cases when a
business partner no longer fits in the strategy, it is easier to end the co-operation than it is
to remove an organisational unit from an organisation [Aken, 1998]. Networked
organisations operate in an organisation network that meets customer demands for that
particular moment, and adapt their position in the network to cope with complex and
changing customer demands. So, networked organisation management is a means to
increase flexibility in supply chains, which is needed to provide customers with a more
dynamic product assortment.
In networked organisation management, the flexibility of the market mechanism is
as far as possible, combined with the technical specialisation and efficiency of functional
organisation management, the market responsiveness and effectiveness of divisional
management, and the balanced orientation and asset transfer capabilities of matrix
organisation management [Miles, 1986] [Miles, 1992]. Pure markets provide ultimate
flexibility, because there are no direct dependencies between actors, and prices alone
determine production and exchange [Powell, 1990]. Markets fulfil some co-ordination but
can not achieve integration, as there is no control to reach a common objective. Prices are
a simplifying communication mechanism, which can hardly capture the difficulties of
complex and dynamic exchange of products. Hence, markets become less efficient when
dealing with supply chains that need extensive information exchange to offer a more
dynamic product assortment.
2.3 Networked inventory management requirements

Both higher productivity and greater flexibility are needed in supply chains to offer
customers products with a better price-quality ratio and a more dynamic product
assortment. The analysis of the issues in supply chain management shows that integral
inventory management could increase productivity in supply chains. Co-ordination with
the help of information exchange can reduce inventory excess or shortage, and can
improve product availability for customer service, so contributing to a better price-quality
ratio. The analysis further indicates that networked organisation management could
increase flexibility in supply chains. Co-ordination through the best of market and
hierarchy enables coupling of organisations in networks with minimum cost and time to
respond to changing demand, so contributing to a more dynamic product assortment.
28
Thus, integral inventory management and networked organisation management are

supplementary directions for improvement of business performance in supply chains.
Ideally, both issues in supply chain management should be combined to satisfy customer
requirements. The combination of integral inventory management (IIM) and networked
organisation management (NOM) is called networked inventory management (NIM)
[Verwijmeren, 1996a] [Verwijmeren, 1997]. In Figure 2-5 the simultaneous achievement
of integral inventory management and networked organisation management is depicted.
Networked Networked Networked

organisation organisation organisation
Integral inventory management

Suppliers Customers
Operational process
Goods flow Information flow
including a stock-point
Figure 2-5 Networked inventory management
In supply chains with opposition between the organisations, the scope of integral inventory
management is limited to the organisational boundaries. Opposition does not allow
inventory management within an organisation to become integrated with the inventory
management of other organisations in the supply chains. Integral inventory management
could be achieved in supply chains where one organisation dominates the others. The
dominant organisation then places a hierarchy on top of the subordinate organisations to
control the supply chain.
In contrast to organisations with opposition relationships, in networked inventory
management the scope of integration is expanded to a network of organisations. The
inventory levels in stock-points of different organisations are managed in a coherent way.
Compared to integration through hierarchical control by one dominant organisation,
networked inventory management achieves integral inventory management by lateral
control across the networked organisations. Co-operation between networked
organisations makes it possible to co-ordinate the inventory management inside an
organisation with the inventory management of other organisations in the supply chains.
Currently, no information systems appear to be available which are geared to networked

inventory management. Existing information systems for supply chain management either
29
miss adequate support for integral inventory management or lack facilities for networked
Information systems that come closest to the required functionality for integral
inventory management are the commercially available Enterprise Resource Planning (ERP)
systems, as offered by, amongst others, Baan, MFG/PRO, Oracle, JD Edwards, PeopleSoft
and SAP [Andersen, 1995] [Lierop, 1996] [Berenschot, 1997] [Ovum, 1997] [Ten Hagen,
1997] [Coopers, 1998] [Verwijmeren, 1998]. ERP systems provide extensive functionality
for, amongst others, logistics management, financial management and human resource
management within organisations. In the client-server architectures of ERP systems, local
client systems interact with a central server to provide internal business processes with
integral functionality. Many of these systems provide multi-site functionality for
management of an internal network, consisting of organisational units within one
organisation. However, due to the use of a central server, the ERP systems lack the
autonomy for management across networked organisations in external networks and miss
the flexibility needed by networked organisations in dynamic networks.
Information systems that come closest to the required functionality of networked
organisation management are inter-organisational information systems emerging from
coupling local systems through Electronic Data Interchange (EDI) [Wierda, 1991] [Vlist,
1991] [Suomi, 1992] [Vlist, 1992] [Vlist, 1994]. In EDI based inter-organisational systems,
local computers exchange information in a standard data format that can be interpreted by
the communicating computers. These systems provide facilities for networked organisation
management, as they respect the autonomy and flexibility of networked organisations.
However, with their focus on standardised data exchange between computers, the EDI
based inter-organisational systems do not provide the logic for integral inventory
management.
30
SCM: Supply chain management
IIM: NIM: NOM:

Integral Networked Networked
inventory inventory organisation
management management management
Networked inventory management requirements
Integral inventory management: Networked organisation management:

• Base Stock Control • Configuration flexibility
• Material/Distribution Requirements Planning • Timing flexibility
• Line Requirements Planning • Algorithm flexibility
NIMIS
Figure 2-6 Networked inventory management requirements
To increase productivity and flexibility of supply chains, information systems for

networked inventory management are needed, but these systems are not yet commonly
available. Therefore, the feasibility of information systems that support networked
inventory management is studied. These information systems are called Networked
Inventory Management Information Systems (NIMISs). As presented in Figure 2-6,
networked inventory management (NIM) imposes functional requirements on the
information systems being studied. The functional requirements for NIMISs come partly
from integral inventory management (IIM) and partly relate to networked organisation
management (NOM). The requirements for the information systems are explained below.
2.3.1 Integral inventory management requirements

Conforming to the research objective, NIMISs need to support networked inventory
management (NIM), so the information systems have to provide functionality for integral
inventory management (IIM). To show the functional feasibility of information systems for
31
networked inventory management, three relevant functional requirements related to

integral inventory management are imposed on the systems to be designed. The NIMISs
should provide functionality for:
1. Base Stock Control (BSC)

2. Material/Distribution Requirements Planning (MRP/DRP)
3. Line Requirements Planning (LRP)
Due to practical research limitations, these functional requirements do not represent an

exhaustive list of possible algorithms for integral inventory management. However, when
compared to non-integral inventory management, the requirements comprise both aspects
of integration in the time dimension of inventory management and aspects of integration
in the place dimension of inventory management. MRP and LRP integrate over time, while
BSC and LRP integrate over place. Therefore, these requirements could also give insight
into the feasibility of related types of algorithms for integral inventory management to be
supported by the information systems.
The requirements concerning integral inventory management are extensions to Statistical

Inventory Control (SIC), an algorithm for non-integral inventory management. In SIC a
local inventory level is managed in an instantaneous way by making replenishment
decisions based on the costs, lead times, service and statistics of that stock-point, ignoring
the implications of decisions at one stock-point for the inventory levels of other stock-
points [Silver, 1985]. Figure 2-7 illustrates how the integral inventory management
algorithms BSC, MRP/DRP and LRP extend on the non-integral SIC algorithm [Donselaar,
1987].
On the horizontal axis, the place focus of the inventory management algorithms is
plotted, divided into local or integral inventory. SIC and MRP both manage local inventory
levels, that is, the inventory on hand (and on order) at a stock-point. In contrast, BSC and
LRP manage integral inventory levels, that is, the inventory on hand (and on order) at a
stock-point plus all the inventory present in downstream stock-points and processes. The
transition from local to integral inventory represents integration in the place dimension of
inventory management.
On the vertical axis, the time focus of the inventory management algorithms is
depicted, divided into instantaneous or time-phased management. In SIC and BSC, the time
focus is instantaneous, that is, only the current inventory levels are managed. However, in
both MRP and LRP the management is time-phased. These algorithms deal with the
management of current and future inventory levels. The transition from instantaneous to
32
time-phased management represents integration in the time dimension of inventory

management.
Local Integral
inventory inventory
Time-phased
Time focus
MRP LRP management
Instantaneous
SIC BSC management
Place focus
Figure 2-7 Inventory management algorithms
2.3.1.1 Base Stock Control
Given the research objective to achieve integral inventory management, a first functional
requirement for the information systems is that they provide functionality to manage
inventories in an integral way according to Base Stock Control (BSC). BSC makes use of
the principles of the base-stock system [Magee, 1958], in which each stock-point in the
supply chain works against actual customer demand, rather than against demand
generated by replenishment orders from the next downstream stock-point in the supply
chain [Silver, 1985]. Instead of managing the local inventory level, BSC manages the
integral inventory level of a stock-point.
The integral inventory level or echelon stock for a particular stock-point is the
inventory on hand (and on order) at the stock-point plus the inventory on hand in, and in
transit between (on order in), all downstream stock-points [Clark, 1960] [Donselaar, 1989]
[Donselaar, 1990]. BSC re-orders as soon as the integral inventory level drops below the
base stock level, which is the norm for the integral inventory level. A common type of BSC
is an (s, S) system, in which enough is ordered to raise the inventory position to the base
stock level S, when the integral inventory level is lower than s [Silver, 1985].
33
BSC is a response to the problems associated with SIC. In BSC, ordering decisions at
any stock-point in the supply chain are made as a result of customer demand, whereas SIC
is triggered by orders from the next downstream stock-points. In many cases, there is less
variability in the customer demand than in the next downstream stock-point ordering
[Forrester, 1961]. Hence, when compared to SIC, lower safety stocks can be achieved by
BSC [Silver, 1985]. Although BSC uses customer demand information to decide on
replenishments, BSC is still based on each stock-point suddenly ordering from the next
higher echelon.
2.3.1.2 Material/Distribution Requirements Planning
Given the research objective to achieve integral inventory management, a second

functional requirement for the information systems is that they should provide
functionality to manage inventories in an integral way according to Material and
Distribution Requirements Planning (MRP/DRP). When compared to SIC, the inventory
management in MRP is time-phased, that is, it deals with the management of current and
future inventory levels. MRP manages inventory in supply chains with the help of time-
phased inventory levels, derived from time-phased demand information. An MRP system
consists of a set of logically related procedures, decision rules, and records, designed to
translate a master production schedule into time-phased net requirements for a stock-point
and into planned order releases to cover the net requirements of the stock-point [Orlicky,
1975].
MRP begins with a master production schedule that provides the timing and
quantities of production of all products to be sold to customers [Silver, 1985]. With the
help of the bill of materials, the gross requirements for components are determined per
time period. Then, the existing inventory levels are allocated to the gross requirements to
produce a time series of net requirements. Next, the net requirements are translated to
planned receipts. Finally, these planned receipts are shifted back in time, over the lead
time, resulting in planned order releases. These planned order releases are translated into
gross requirements for the next lower component level in the bill of materials. For
components at this next lower level, the gross requirements are used to derive the planned
order releases step by step, and so on.
Distribution Requirements Planning (DRP) systems are twins of MRP systems. DRP is
simply the application of the MRP principles to the management of inventories in
distribution [Martin, 1983] [Martin, 1993]. In DRP, for each downstream stock-point from
which customers are supplied, a master schedule with its gross requirements is developed.
Through allocation of existing inventory levels, net requirements for the stock-point are
obtained. These net requirements are translated into planned receipts and planned orders
34
respectively. The planned orders are translated into gross requirements for the next
upstream stock-points. DRP is a very natural extension of MRP, that addresses the
drawbacks of using independent control of the same product at different locations [Silver,
1985].
MRP/DRP seeks to overcome the weaknesses of traditional decision rules in
manufacturing and distribution. MRP/DRP takes into account the time varying nature of
demand for products and makes use of the dependent nature of requirements [Silver,
1985]. With the explosion of planned orders, MRP/DRP makes the expected gross
requirements known for the upstream stock-points, but not the information which led to
these dates and quantities, like considerations with respect to requirements, netting, lot-
sizing and off-setting. In a stochastic environment, MRP/DRP might be too rigid, possibly
resulting in nervousness of plans and rapidly decreasing performance as soon as the
environment becomes highly uncertain [Donselaar, 1989].
2.3.1.3 Line Requirements Planning
Given the research objective to achieve integral inventory management, a third functional
requirement for the information systems is that they should provide functionality to
manage inventories in an integral way according to Line Requirements Planning (LRP).
LRP can be regarded as a mixture of BSC and MRP, as it incorporates time-phased as well as
integral inventory levels [Donselaar, 1989]. Similarly to BSC, LRP makes use of integral
inventory or echelon stock, but at the same time, LRP works with time-phased inventory
levels, like is done in MRP.
In LRP, the base stock level in BSC is turned into a time-phased re-order point level,
based on a time series of forecasted demand or planned requirements [Donselaar, 1989].
Not only order suggestions for the current period are generated, but also a time series of
planned orders is made. As opposed to MRP, LRP explodes not only information on
expected requirements, but also information on inventory levels of downstream stock-
points to upstream stock-points.
LRP has the advantage over BSC that is exploits the time varying nature of
requirements. When compared with MRP, the main advantage of LRP is the fact that the
distortion of information with respect to requirements is minimal, because LRP explodes
inventory levels and requirements separately and in their basic form to upstream stock-
points. Requirements for components are directly derived from the requirements for final
products, so they are not distorted, for example, by lot-sizing in intermediate stock-points.
In a stochastic environment, LRP results in relatively robust plans, but under some
conditions LRP may be too rough, as it ignores management restrictions or inventory
imbalances in downstream stock-points [Donselaar, 1989].
35
2.3.2 Networked organisation management requirements

Conforming to the research objective, NIMISs should support networked inventory
management (NIM), so the information systems also have to provide functionality for
networked organisation management (NOM). To show the functional feasibility of
information systems for networked inventory management, three relevant functional
requirements related to networked organisation management are imposed on the systems
to be designed. The NIMISs should provide functionality for:
1. Configuration flexibility
2. Timing flexibility
3. Algorithm flexibility
Because of practical research limitations, these functional requirements do not represent

an exhaustive list of possible facilities for networked organisation management. However,
when compared to hierarchical organisation management, the requirements include major
aspects of the flexibility and autonomy required for networked organisations.
Configuration flexibility focuses on autonomy with respect to the place of management,
whereas timing flexibility deals with autonomy in the time of management and algorithm
flexibility deals with autonomy in the type of management. Therefore, these requirements
could also provide insight into the feasibility of related types of facilities for networked
organisation management to be supported by the information systems.
2.3.2.1 Configuration flexibility
Given the research objective to achieve networked organisation management, a fourth

functionality for configuration flexibility. Instead of management in a rigid configuration,
configuration flexibility provides networked organisations with autonomy in their place of
management. To respect the autonomy of a networked organisation, the information
systems should represent separate decision making units that can work independently of
other information systems within the network of organisations.
The need for configuration flexibility also applies to information systems for
integral inventory management across networked organisations. Every information system
involved in integral inventory management should be an independent decision making
unit for the management of its stock-points, which can act separately of systems managing
other parts of the network. This decentralisation of decision making units must ensure that
the information systems can reflect the structure of networked organisations, which are, by
nature, based on decentralised management.
36
One aspect of configuration flexibility is that NIMISs should have the ability to
establish a configuration that fits a network of organisations. The efforts needed to
establish a configuration of information systems for integral inventory management across
networked organisations should be kept to a minimum. Particularly in a dynamic network
of organisations, a requirement is that a configuration of information systems can easily be
adapted to the frequently changing structure of networked organisations.
A second aspect of configuration flexibility is that NIMISs should be able to work
independently of other information systems used by networked organisations. Those
systems support business functions other than networked inventory management, such as
the management of purchase, production, distribution, sales, finance, quality and human
resources. The scope of integration of the other information systems is typically limited to
a single process, a department or an organisation. While NIMISs are devised for integration
across organisations in supply chains, the other systems mainly cover functions that do not
require integration across organisations. These intra-organisational information systems
face frequent changes, either due to incremental updates of customised legacy systems or
due to new releases of standard application software. As most organisations in a network
experience this instability of their dedicated internal systems, it is hardly possible to
develop and maintain integration across these systems. Operation of NIMISs independently
of other information systems makes the integral inventory management across networked
organisations less vulnerable to changes in these internal systems.
With respect to configuration of management systems, three approaches exist:
decentralised, central and hierarchical management [Meal, 1984] [Bertrand, 1990]. Until
recently, integral management could exclusively be achieved by central or hierarchical
systems. However, due to advances in information technology, it is becoming feasible to
realise integral management with the help of decentralised systems [Timmermans, 1993].
Instead of interaction with a central co-ordination unit to obtain integral management,
decentralised systems can co-ordinate themselves by exchanging information across the
systems. The decentralised configuration has been introduced in the context of a
manufacturing system organised around cells [Barekat, 1989] [Love, 1989] [Mustakim,
1990] [Rohloff, 1993]. It has been shown that MRP can be formulated in a decentralised
manner with messages passing between inventory stages in the opposite direction to the
material flow [Buzacott, 1997].
2.3.2.2 Timing flexibility
Given the research objective to achieve networked organisation management, a fifth

functionality for timing flexibility. Instead of management with rigid timing, timing
37
flexibility provides networked organisations with autonomy in the time of their

systems should allow the use own decision timetables, irrespective of decision timetables
applied by other systems within the network of organisations.
The need for timing flexibility also applies to information systems for integral
inventory management across networked organisations. Every information system
involved in integral inventory management should be able to use its own decision
timetable to manage its stock-points, irrespective of the timing principles used by systems
that manage other parts of the network. This decentralisation of decision timetables
relieves information systems in a networked organisation of the obligation to perform
synchronous management with other information systems in a network.
One aspect of timing flexibility is that the review moments in a NIMIS should be
allowed to differ from review moments in other systems. Review moments are the points
in time at which the system reviews the inventory level of stock-points. Networked
organisations should have the possibility to specify their own review moments in the
information systems. Because all information systems in a network have this autonomy in
review moments, a NIMIS must be able to cope with systems that apply other review
moments than its own.
A second aspect of timing flexibility is that NIMISs should be able to use plan
moments which are different from plan moments encountered in other systems. Plan
moments are the points in time included in plans to specify expected amounts of products
in the future. Networked organisations should have the freedom to apply their own plan
moments in their information systems. As a consequence, the NIMISs must be able to cope
with plan moments that may differ per system.
With respect to review moments in inventory management systems, there is a
distinction between periodic review versus continuous review. In a periodic review system,
the time between subsequent re-ordering and planning decisions is fixed, whereas in a
continuous review system, the inventory levels are monitored continuously and decisions
can be made immediately [Fogarty, 1991]. With respect to plan moments, their is a
practical distinction between bucketed versus bucketless plans. In a bucketed system, all
events are accumulated into a fixed number of time buckets, while in a bucketless system,
events are stored by more detailed event dates, because the future is not divided into
predetermined periods [Gray, 1989]. In systems with continuous review and bucketless
plans, the inventory management becomes event-driven. Computations can be performed
at any instant due to the occurrence of an event. The times at which calculations are
carried out can be spaced at arbitrary intervals which need not be the same and need not
even be the same at all stages [Buzacott, 1997].
38
2.3.2.3 Algorithm flexibility
Given the research objective to achieve networked organisation management, a sixth

functionality for algorithm flexibility. Instead of management with rigid algorithms,
algorithm flexibility provides networked organisations with autonomy in the type of their
systems should allow the use of own decision rules, irrespective of decision rules applied
by other systems within the network of organisations.
The need for algorithm flexibility also applies to integral inventory management
across networked organisations. Every information system involved in integral inventory
management should be allowed to use its own decision rules to manage its stock-points,
irrespective of the algorithms used by systems that manage other parts of the network. The
inventory management algorithm used in the information systems is required to be either
BSC, MRP/DRP or LRP. The decentralisation of decision rules relieves the information
systems in a networked organisation of the obligation to perform homogeneous
management with other information systems in a network.
One aspect of algorithm flexibility is that NIMISs must be able to select either BSC,
MRP/DRP or LRP as their integral inventory management algorithm. This gives networked
organisations the autonomy to choose the algorithm which seems most suitable for the
integral inventory management of their stock-points. When the circumstances in a
network change, the NIMISs should have the possibility to adapt their integral inventory
management algorithms.
A second aspect of algorithm flexibility is that NIMISs should be able to make
transitions between any combination of BSC, MRP/DRP or LRP as used in a network. Because
networked organisations are allowed to choose their own algorithms for integral inventory
management, the information systems in a network of organisations may apply different
algorithms. A NIMIS must have the ability to cope with systems that apply heterogeneous
integral inventory management algorithms.
There is growing insight into the need to differentiate inventory management
algorithms for different stock-points. Because stock keeping units (SKUs) have different
characteristics, differentiation of the applied inventory management algorithms can
increase individual performance of SKUs. The type of management to be applied should be
tuned to the processes to be managed [Bemelmans, 1991]. In a broader contingency
perspective, the applicability of a particular inventory management algorithm in a
particular situation, is dependent on the characteristics of the specific situation, like the
processes being managed, the products being processed and the markets being served
[Leeuw, 1996]. These characteristics can be used for segmentation of inventory
39
management situations. For every segment an appropriate management algorithm can be

selected. Because the characteristics can vary per SKU, the type of decision rules and the
values of the steering parameters can differ per SKU.
2.4 Conclusion
Supply chain management is an integrative approach to planning, control and monitoring
of total materials flow from suppliers to end users, aiming at improved customer service at
reduced overall costs. This approach is a means for organisations to improve their
performance, in particular to achieve higher productivity and greater flexibility. This is
needed to respond to customers who require products with a better price-quality ratio and a
more dynamic product assortment. Important issues in supply chain management are
integral inventory management and networked organisation management.
Integral inventory management, instead of non-integral inventory management,
can contribute to higher productivity in supply chains. Integral inventory management
focuses on the co-ordinated planning, control and monitoring of inventory levels at stock-
points throughout supply chains, in order to maximise overall supply chain performance.
Besides purposely desired inventory and necessarily required inventory, there would
ideally be no extra inventory in supply chains. Existing inventory excesses and shortages
can be reduced with the help of integral inventory management.
Networked organisation management, instead of hierarchical organisation
management, is a means to achieve greater flexibility in supply chains. A networked
organisation is an organisation with its own strategic control unit, that co-operates with
other organisations at a tactical and operational level, within its strategic constraints, in
order to gain mutual benefits. Dynamic networks of organisations are particularly suited
for flexibility improvements, because the participating networked organisations link
together for temporary production and then disassemble to become part of another
network.
The combination of integral inventory management and networked organisation
management is called networked inventory management. Currently, no information
systems for supply chain management appear to be available that give adequate support for
both integral inventory management and networked organisation management. This
induces functional requirements for new information systems for networked inventory
management (NIMISs).
Functional requirements related to integral inventory management are the
provision of functionality for: Base Stock Control (BSC), Material/Distribution
Requirements Planning (MRP/DRP) and Line Requirements Planning (LRP). The
40
information systems should provide functionality to manage inventory in an integral way

according to these three algorithms. When compared to non-integral inventory
management, these requirements comprise integration in the time dimension as well as
integration in the place dimension, by using extra information on time-phased demand or
integral inventory.
Functional requirements related to networked organisation management are the
provision of functionality for: configuration flexibility, timing flexibility and algorithm
flexibility. The information systems should represent separate decision making units, that
allow the use of own decision timetables, and that can cope with different decision rules.
When compared to hierarchical organisation management, these requirements allow
autonomy of networked organisations with respect to the place of management, the time of
management and the type of management.
41
Chapter 3 Networked inventory management design
3. Networked inventory management

design
3.1 Introduction
In this chapter, a functional design of information systems for networked inventory
management is specified. The inputs for the networked inventory management design are
the functional requirements from the supply chain management analysis (Chapter 2),
whereas implicit input comes from the distributed object technology design (Chapter 5).
The outputs of the networked inventory management design are a model that specifies
NIMISs and an explanation of the functional properties of the information systems.
In section 3.2, the integral inventory management design of the information
systems is specified, representing one part of the networked inventory management design.
The integral inventory management design includes a model of NIMISs as well as an
explanation of their properties related to integral inventory management. The networked
organisation management design of the information systems, the other part of the
networked inventory management design, is specified in section 3.3. Subsequently, the
facilitation of networked organisation management by NIMISs is modelled and their
properties related to networked organisation management are explained.
3.2 Integral inventory management design

As part of the functional design of information systems for networked inventory
management, an integral inventory management (IIM) design is specified. This design
43
Networked inventory management design Chapter 3
must be consistent with the networked organisation management (NOM) design. Together,
these two designs specify the overall networked inventory management (NIM) design of
NIMISs in this study. To satisfy the functional requirements with respect to integral
inventory management, the information systems must provide functionality for Base Stock
Control (BSC), Material/Distribution Requirements Planning (MRP/DRP) and Line
Requirements Planning (LRP).
3.2.1 Integral inventory management model

With the help of a model of the information systems, it is specified how the integral
inventory management is achieved by NIMISs. The integral inventory management model
includes a system model that positions the information systems in their environment of
inventory management. Furthermore, the variables that are used in the systems are
identified. Those system variables are categorised by the elements in the system
environment to which they relate: a strategist, customers, an operational process,
inventory and suppliers. In addition, system equations are given that specify the
relationships between the variables for integral inventory management.
3.2.1.1 System model
The information systems designed in this study are called Networked Inventory
Management Information Systems (NIMISs). A major design decision is the determination
of the system boundaries of one NIMIS. In order to support networked inventory
management, it is decided that one NIMIS manages the inventory of just one stock-point for
just one single Stock Keeping Unit (SKU). A stock-point is a location where an inventory
of products can be stored. A SKU is a product type for which inventory is held in a stock-
point. A single SKU stock-point (SSS) contains one product type at a certain location. As a
NIMIS manages only the inventory level of one product type at one location, it is an
information system with extremely basic functionality and an extremely basic architecture.
These extremely basic information systems are loosely coupled to one another in networks,
in order to support integral inventory management.
Unlike a central system, a NIMIS does not manage the stock-points of all SKUs in a
product structure (bill of materials) or distribution structure, but instead focuses on one
SKU. Individual SKUs can be identified by a vertical and horizontal decomposition of
product and distribution structures. For every SKU, a one-level product or distribution
structure can be derived that specifies the explosion of demand towards supplying SKUs.
To obtain integral inventory management across the overall production and distribution
structures, a NIMIS is installed for every single SKU stock-point.
44
NIMIS S1 NIMIS C1
S1 C1
NIMIS S2 NIMIS X1 NIMIS C2
S2 X1 C2
NIMIS S3 NIMIS C3
S3 C3
NIMIS Networked Inventory Management

Information System
Information flow
Goods flow Operational process including one
single SKU stock-point
Figure 3-1 Network view of integral inventory management
In Figure 3-1 the integral inventory management model of the information systems is
presented from a network viewpoint. The network could represent some supply chains in
consumer electronics for example. Single SKU stock-point S1 could contain lasers, while
stock-point S2 holds chips and stock-point S3 has an inventory of casings. Then, stock-
point X1 could be an inventory of one type of Compact Disc (CD) players, assembled from
the components at the stock-points S1, S2 and S3. The stock-points C1, C2 and C3 might be
inventories of CD players at dealers in different regions who sell the CD players to local
consumers.
45
Co-operation Co-operation
agreement agreement
Strategist
New Solved
Current parameter exception
parameter values Unsolved
values exception
Supplier Customer
plans plans
Supplier Customer
Suppliers orders
NIMIS orders Customers
Actual Actual
supply demand
Input orders Actual inventory Output orders

Goods flow NIMIS Information System
Operational process including

Information flow one single SKU stock-point
Figure 3-2 System view of integral inventory management
In Figure 3-2 the integral inventory management model of the information systems is
presented from a system viewpoint. The relevant environment of a NIMIS consists of the
entities with which a NIMIS has a relationship. One of the entities is the ‘operational
process’ that includes just one single SKU stock-point (SSS), for which the NIMIS manages
the inventory level. Then, there are ‘customers’ that demand products from the SSS and
‘suppliers’ that supply products to the SSS. From the viewpoint of a NIMIS, every
demanding SSS represents a customer, while every supplying SSS represents a ‘supplier’.
These customers and suppliers can either be part of the same organisation or belong to
different organisations. In addition, there is a so-called ‘strategist’, who supervises the
information system for integral inventory management. The strategist sets the parameter
values and solves exceptions that emerge in the system. At a stock-point where several
SKUs are stored, there are multiple NIMISs, which may be monitored and controlled by one
and the same strategist. For setting the parameter values and solving exceptions, the
strategist must have information available on the relevant environment of the NIMIS,
including the customers, the suppliers and the operational process. It is assumed that there
46
is a conceptual database from which the strategist can obtain consistent information on the
NIMIS environment. Between the strategist and its customers and suppliers, there are co-
operation agreements. As part of the co-operation, the strategist can communicate with
customers and suppliers, for setting the parameter values and solving possible exceptions.
A NIMIS receives orders from customers which specify their current demand for
products. Besides orders, customers may send plans that contain information for integral
inventory management. Based on the customer orders received, a NIMIS sends output
orders to the operational process to take products out of stock and ship them to customers.
From the operational process, a NIMIS receives information on actual demand, actual
supply and actual inventory. With the information coming from customers and from the
operational process, a NIMIS computes supplier orders and supplier plans. Supplier orders
specify current demand for products to be supplied to the single SKU stock-point. Supplier
plans contain extra information for integral inventory management. The strategist reads
current values of parameters from the system and writes new parameter values to the
system. The strategist receives unsolved exceptions from the NIMIS, and after solving the
exceptions, the strategist forwards the solved exceptions to the system.
3.2.1.2 System variables
The integral inventory management model of the information systems includes a

specification of the system variables. Every NIMIS contains a uniform set of variables that
is used to provide the required functionality for integral inventory management. All
system variables relate to the entities in the environment of a NIMIS. Hence, the variables
in a NIMIS can be divided into variables that are related to either its strategist, customers,
operational process, inventory or suppliers. Those categories of system variables are
discussed below.
47
Table 3-1 Strategist related variables
Variable notation Variable description

Rr Time of review moment Rr
in the NIMIS
r Index to review moment Rr
in the NIMIS
Ppr Time of plan moment Ppr
at review moment Rr in the NIMIS
pr Index to plan moment Ppr
NPr Number of plan moments Ppr
In Table 3-1 the variables in a NIMIS are given that are related to the strategist who
controls the NIMIS. Review moments are the points in time at which a NIMIS reviews the
inventory level of its stock-point by examination of current variable values and
computation of new values. The review moment Rr is the r-th moment at which the NIMIS
reviews the inventory since the start of its lifetime. The index r is equal to zero for the first
review moment and is increased by one for all following review moments during the
lifetime of the system. Plan moments are the points in time included by a NIMIS in plans to
specify expected amounts of products. Plan moment Ppr is the p-th plan moment in the
plans computed by the NIMIS at review moment Rr. In the index pr, the value of p is equal
to zero for the first plan moment at review moment Rr, and is increased by one for the
following plan moments. At review moment Rr, a NIMIS computes quantities of products
for all plan moments P0r to PNPr, so the plans computed at review moment Rr contain NPr
plus one plan moments.
48
Table 3-2 Customer related variables

Cc Name of customer Cc
c Index to customer Cc
NC Number of customers Cc
Individual Customer Demand Order
ICDO(Cc, Rr) received from customer Cc
at review moment Rr
ACDO(Rr) Aggregate Customer Demand Order
computed at review moment Rr
Individual Customer Demand Plan
ICDP(Cc, Rr, Ppr) received from customer Cc
at review moment Rr
for plan moment Ppr
Aggregate Customer Demand Plan
ACDP(Rr, Ppr) computed at review moment Rr
for plan moment Ppr
In Table 3-2 the customer related variables for integral inventory management in a NIMIS
are given. The names of the customers are contained in Cc, where c denotes an index to
the customers, ranging from 1 to NC, the number of customers a NIMIS deals with.
The Individual Customer Demand Order ICDO(Cc, Rr) gives the quantity of
products ordered by customer Cc at review moment Rr. The total number of products
ordered by all customers at review moment Rr is specified in the Aggregate Customer
Demand Order ACDO(Rr). The Individual Customer Demand Plan ICDP(Cc, Rr, Ppr)
contains the expected quantity of products at review moment Rr, that customer Cc will
order at plan moment Ppr. Finally, in the Aggregate Customer Demand Plan ACDP(Rr,
Ppr) the total number of products expected at review moment Rr to be ordered at plan
moment Ppr is given.
49
Table 3-3 Operational process related variables

Actual Inventory
AI(Rr) at review moment Rr
after Actual Supply and Demand
at review moment Rr
Actual Demand
AD(Rr) at review moment Rr
after Actual Supply
at review moment Rr
Actual Supply
AS(Rr) at review moment Rr
before Actual Demand
at review moment Rr
Output Process Order
OPO(Cc, Rr) related to customer Cc
at order moment Rr
Input Process Order
IPO(Ss, Uu, Rr) related to supplier Ss
for product unit Uu
at review moment Rr
The variables in a NIMIS that relate to the operational process are given in Table 3-3. The
Actual Inventory AI(Rr) contains the number of products that are available in the single
SKU stock-point at review moment Rr. The observed demand from the stock-point, since
the last review moment up until review moment Rr, is stored in the Actual Demand
AD(Rr), while the observed supply to the stock-point, since the last review moment up
until review moment Rr, is captured in the Actual Supply AS(Rr). Actual Supply AS(Rr)
takes place before Actual Demand AD(Rr), while the Actual Inventory AI(Rr) is measured
after the Actual Supply AS(Rr) and Actual Demand AD(Rr).
The Output Process Order OPO(Cc, Rr) gives the quantity of products that has to be
taken out of stock because they were ordered by customer Cc at order moment Rr. The
Input Process Order IPO(Ss, Uu, Rr) indicates the quantity of product units Uu that will be
supplied to the stock-point after some time because they were ordered at supplier Ss at
review moment Rr.
50
Table 3-4 Inventory related variables

IN Inventory Norm
LS Lot Size
LT Lead Time
Uu Name of product unit type Uu
u Index to product unit type Uu
NU Number of product unit types Uu
EF(Uu) Explosion Factor
for product unit type Uu
Transit Inventory Plan
TIP(Rr, Ppr) at review moment Rr
for plan moment Ppr
Exclusive Inventory Position Plan
EIPP(Rr, Ppr) at review moment Rr
for plan moment Ppr
Inventory Supply Plan
ISP(Rr, Ppr) at review moment Rr
for plan moment Ppr
Inclusive Inventory Position Plan
IIPP(Rr, Ppr) at review moment Rr
for plan moment Ppr
In Table 3-4 the variables in a NIMIS are shown that relate to the inventory in a single SKU
stock-point that is managed by the system. The Inventory Norm IN is the norm for the
inventory level at the stock-point. The Lot Size LS indicates how many products have to be
ordered together. The ordered quantity has to be a multiple of the Lot Size LS. The time it
takes between the ordering of products at suppliers and the time of supply to the stock-
point is specified in the Lead Time LT. The names of the product units that go into the
product type stored at the stock-point, are specified in Uu, where u is an index to the
product units, ranging from 1 to NU, the number of different product units that compose
the product held at the stock-point. The Explosion Factor EF(Uu) denotes how many
product units Uu are needed for one product, for which inventory is held at the stock-point.
The Transit Inventory Plan TIP(Rr, Ppr) states how many products at review
moment Rr are in transit to the stock-point and will be received at plan moment Ppr. Those
51
products are in transit between stock-points of suppliers and the stock-point of the NIMIS,
as they have already been ordered at the supplier, but have not yet been received at the
stock-point, due to the Lead Time LT. The inventory level that is expected at review
moment Rr to be available at plan moment Ppr if no further orders are released to
suppliers, is specified in the Exclusive Inventory Position Plan EIPP(Rr, Ppr). The
Inventory Supply Plan ISP(Rr, Ppr) gives the number of products that are expected at
review moment Rr to be supplied to the stock-point at plan moment Ppr. The Inclusive
Inventory Position Plan IIPP(Rr, Ppr) indicates the inventory level at the stock-point at
plan moment Ppr, as expected at review moment Rr, if further supply is according to the
Inventory Supply Plan ISP(Rr, Ppr).
52
Table 3-5 Supplier related variables

Ss Name of supplier Ss
s Index to supplier Ss
NS Number of suppliers Ss
Supplier Allocator
SA(Uu, Ss) for product unit Uu
from supplier Ss
Aggregate Supplier Demand Plan
ASDP(Uu, Rr, Ppr–LT) for product unit Uu
at review moment Rr
for plan moment Ppr–LT
Individual Supplier Demand Plan
ISDP(Ss, Uu, Rr, Ppr–LT) sent to supplier Ss
for product unit Uu
at review moment Rr
for plan moment Ppr–LT
Aggregate Supplier Demand Order
ASDO(Uu, Rr) for product unit Uu
at review moment Rr
Individual Supplier Demand Order
ISDO(Ss, Uu, Rr) sent to supplier Ss
for product unit Uu
at review moment Rr
The supplier related variables in a NIMIS are presented in Table 3-5. The names of the
suppliers are held in Ss, where s is an index to the suppliers, ranging from 1 to NS, the
number of suppliers a NIMIS deals with. The Supplier Allocator SA(Uu, Ss) specifies how
many product units Uu per product at the single SKU stock-point are supplied by supplier
Ss.
The Aggregate Supplier Demand Plan ASDP(Uu, Rr, Ppr–LT) gives the quantity of
product units Uu that at review moment Rr, are expected to be ordered from suppliers at
plan moment Ppr–LT. The Individual Supplier Demand Plan ISDP(Ss, Uu, Rr, Ppr–LT)
allocates the values of the ASDP(Uu, Rr, Ppr–LT) to the suppliers of the product units.
Thus, the ISDP(Ss, Uu, Rr, Ppr–LT) gives the number of product units Uu to be ordered
53
from supplier Ss, at plan moment Ppr–LT as expected at review moment Rr. The total
number of product units Uu ordered at review moment Rr is included in the Aggregate
Supplier Demand Order ASDO(Uu, Rr). The Individual Supplier Demand Order ASDO(Ss,
Uu, Rr) specifies how many product units Uu are ordered at review moment Rr with
supplier Ss.
3.2.1.3 System equations
The integral inventory management model of NIMISs includes system equations that
specify the relationships between the system variables. The system equations are used in
the information systems to compute values for the variables in a NIMIS. For the variables
related to the strategist, customers, operational process, inventory and suppliers, the
system equations are explained below.
Table 3-6 System equations for strategist variables
System equation Variable description
R r = set by the strategist or Review moment Rr
derived from events in the NIMIS
with: r = 0,1,2,...
Pp r = set by the strategist or Plan moment Ppr
at review moment Rr
derived from events
in the NIMIS
p r = 0,1,2, ..., NPr ∧

with:
P0 r = Rr
In Table 3-6 the system equations in a NIMIS are given for the variables that are related to
the strategist. The review moments Rr are the moments at which a NIMIS manages its
inventory level. The review moments can be set by the strategist as a pre-defined series of
points in time. Alternatively, the review moments could be the points in time at which
events occur that may trigger inventory management. Relevant events are a change in the
actual inventory level, due to demand or supply, as well as the receipt of new demand
plans from customers.
The plan moments Ppr are the points in time for which the information system
computes expected values. The number of plan moments NPr limits the length of the plan
at review moment Rr. In a NIMIS, the plan moments Ppr and the number of plan moments
54
NPr may differ per review moment Rr. For every review moment, the plan moments can be
pre-defined by the strategist as future points in time. Alternatively, the plan moments
could be the future points in time at which demand or supply is expected. The events
concerning demand are included in the plans received from customers, while the events
related to supply can be derived from the plans sent to suppliers.
At review moment Rr, a NIMIS evaluates orders and plans from customers to
manage its inventory level and generates both orders and plans for suppliers. The plan
moments Ppr in the plans, at review moment Rr, are the points in time at which the NIMIS
intends to review its inventory level. Hence, the next review moment Rr+1 of the NIMIS will
normally be at plan moment P1r as identified in the plans of the NIMIS at review moment
Rr .
Table 3-7 System equations for customer related variables
Cc = set by the strategist Name of customer Cc
with: c = 1,2, ..., NC

ICDO(Cc , Rr ) = received from customer Cc Individual Customer Demand Order
received from customer Cc
at review moment Rr
NC Aggregate Customer Demand Order
ACDO( Rr ) = ∑ ICDO( Cc , Rr )
c =1
ICDP(Cc , Rr , Ppr ) = received from customer Cc Individual Customer Demand Plan

received from customer Cc
at review moment Rr
for plan moment Ppr
NC Aggregate Customer Demand Plan
ACDP( Rr , Ppr ) = ∑ ICDP(Cc , Rr , Ppr ) computed at review moment Rr
c=1
for plan moment Ppr
In Table 3-7 the system equations regarding the customer related variables are shown. The
names of customers Cc are set by the strategist. A NIMIS gets an Individual Customer
Demand Order ICDO(Cc, Rr) from the respective customer Cc. The Aggregate Customer
Demand Order ACDO(Rr) is equal to the sum of the ICDO(Cc, Rr) for the review moment
Rr .
55
A NIMIS gets an Individual Customer Demand Plan ICDP(Cc, R, Ppr) from customer
Cc that was created at review moment Rr and contains the expected order quantity for plan
moment Ppr. The Aggregate Customer Demand Plan ACDP(Rr, Ppr) equals the sum of the
received ICDP(Cc, Rr, Ppr) from all customers Cc at review moment Rr for plan moment
Ppr.
Table 3-8 System equations for operational process related variables

Actual Inventory
AI ( Rr ) = received from the operational process at review moment Rr
after Actual Supply and Demand
at review moment Rr
Actual Demand
AD( Rr ) = received from the operational process at review moment Rr
after Actual Supply
at review moment Rr
Actual Supply
AS( Rr ) = received from the operational process at review moment Rr
before Actual Demand
at review moment Rr
Output Process Order
OPO(Cc , Rr ) = ICDO(Cc , Rr ) related to customer Cc
at review moment Rr
Input Process Order

IPO(Ss , Uu , Rr ) = ISDO( Ss ,Uu , Rr ) related to supplier Ss
for product unit Uu
at review moment Rr
The system equations for the variables related to the operational process are given in Table
3-8. The Actual Inventory AI(Rr) is received from the operational process at review
moment Rr. A NIMIS also gets the Actual Demand AD(Rr) and Actual Supply AS(Rr) from
the operational process at review moment Rr.
The Output Process Order OPO(Cc, Rr), which the system sends to the operational
process, is equal to the Individual Customer Demand Order ICDO(Cc, Rr) received at
review moment Rr from customer Cc. The Input Process Order IPO(Ss,Uu, Rr) is equal to
56
the Individual Supplier Demand Order ISDO(Ss,Uu, Rr) created at review moment Rr to
order product units Uu at supplier Ss. The IPO(Ss, Uu, Rr) is forwarded to the operational
process, while the ISDO(Ss, Uu, Rr) is sent to the supplier.
Table 3-9 System equations for inventory related variables

IN = set by the strategist Inventory Norm
LS = set by the strategist Lot Size
LT = set by the strategist Lead Time
Uu = set by the strategist Name of product unit type Uu
with: u = 1,2,..., NU
EF(Uu) = set by the strategist Explosion Factor
for product unit type Uu
For BSC: Transit Inventory Plan
b ASDO(U u , Ri ) at review moment Rr
TIP( Rr , P0 r ) = ∑
EF (U u ) for plan moment P0r
i= a
when the NIMIS applies BSC
Ra −1 ≤ P0 r − LT < Ra ∧
with:
Rb < P0 r ≤ Rb +1
For MRP/DRP and LRP: Transit Inventory Plan

b ASDO(U u , Ri ) at review moment Rr
TIP ( Rr , Ppr ) = ∑
EF (U u ) for plan moment Ppr
i= a
when the NIMIS applies
Ra −1 ≤ Pp −1r − LT < Ra ∧
with: MRP/DRP or LRP
Rb ≤ Ppr − LT < Rb +1
for: Rr < Ppr < Rr + LT

and
TIP ( R r , Pp r ) = 0
for: Ppr = Rr ∨ Ppr ≥ Rr + LT
EIPP( Rr , Ppr ) = Exclusive Inventory Position Plan
p p at review moment Rr
AI ( Rr ) + ∑ TIP( Rr , Pir ) − ∑ ACDP( Rr , Pir ) for plan moment Ppr
i =0 i=0
57

For BSC: Inventory Supply Plan
ISP( Rr , P0 r ) = at review moment Rr
for plan moment P0r
  IN − EIPP( Rr , P0 r )  
max 0, roundup  ⋅ LS  when the NIMIS applies BSC
  LS  
For MRP/DRP and LRP: Inventory Supply Plan
(
ISP Rr , Ppr = 0 ) at review moment Rr
for plan moment Ppr
for: Ppr < Rr + LT when the NIMIS applies
and MRP/DRP or LRP
ISP(Rr , Ppr ) =
  p−1  
  IN − EIPP(Rr , Ppr ) − ∑ISP(Rr, Pir ) 
max0,roundup i=0  ⋅ LS
  LS  
   
   
for: Pp r ≥ R r + L T
p Inclusive Inventory Position Plan

IIPP( Rr , Ppr ) = EIPP( Rr , Ppr ) + ∑ ISP( Rr , Pir )
at review moment Rr
i=0
for plan moment Ppr
In Table 3-9 the system equations are presented for the variables in a NIMIS that relate to
inventory. The values for the Inventory Norm IN, the Lot Size LS and the Lead Time LT
are set by the strategist. In addition, the names of the product units Uu that compose a
product at the single SKU stock-point, are specified by the strategist, while the number of
different unit types NU is derived from the specified product units. The number of product
units Uu that go into one product stored at the stock-point, is set by the strategist in the
Explosion Factor EF(Uu).
The Transit Inventory Plan TIP(Rr, Ppr) relates to the previously released Aggregate
Supplier Demand Orders ASDO(Uu, Ri ) that were released less than the Lead Time LT ago
since the review moment Rr. These orders have led to in transit inventory that will arrive
within the Lead Time LT, calculating from the review moment Rr. The Transit Inventory
Plan TIP(Rr, Ppr) depends on the selected algorithm for integral inventory management. If
the NIMIS works according to the BSC algorithm, at any review moment Rr there is only one
plan moment P0r that coincides with the review moment Rr. In BSC, the Transit Inventory
58
Plan TIP(Rr, P0r) specifies the total amount of products which are in transit to the stock-
point at review moment Rr, but have not been received yet at the stock-point. For the
MRP/DRP and LRP algorithm, the Transit Inventory Plan TIP(Rr, Pp ) states, at review
r
moment Rr, which in transit inventory will arrive just before plan moment Ppr.
The Exclusive Inventory Position Plan EIPP(Rr, Ppr) at review moment Rr for plan
moment Ppr, equals the Actual Inventory AI(Rr) at review moment Rr, plus the total
expected supply due to the Transit Inventory Plan TIP(Rr, Ppr) from the first plan moment
P0r to the current plan moment Ppr, minus the total expected demand due to the Aggregate
Customer Demand Plan ACDP(Rr, Ppr) from the first plan moment P0r to the current plan
moment Ppr.
For BSC, the Inventory Supply Plan ISP(Rr, P0r) relates to the Inventory Norm IN,
the Lot Size LS and the Exclusive Inventory Position Plan EIPP(Rr, P0r). In MRP/DRP and
LRP, the ISP(Rr, Pp ) is forced to be zero for plan moments Pp which are less than the Lead
r r
Time LT ahead of the current review moment Rr, because no new supply is allowed to be
scheduled within this time period. For the plan moments equal to or greater than review
moment Rr plus Lead Time LT, the ISP(Rr, Ppr) at review moment Rr relates to the
Inventory Norm IN, the Lot Size LS, the Exclusive Inventory Position Plan EIPP(Rr, Ppr)
and the sum of the ISP(Rr, Ppr) from the first plan moment P0r to the previous plan
moment Pp-1r.
Finally, the Inclusive Inventory Position Plan IIPP(Rr, Ppr) at review moment Rr for
plan moment Ppr, is equal to the Exclusive Inventory Position Plan EIPP(Rr, Ppr), plus the
sum of the Inventory Supply Plan ISP(Rr, Ppr) from the first plan moment P0r to the
current plan moment Ppr.
Table 3-10 System equations for supplier related variables
Ss = set by strategist Name of supplier Ss
Supplier Allocator
SA(U u , S s ) = set by the strategist for product unit Uu
from supplier Ss
For BSC: Aggregate Supplier Demand Plan

ASDP(Uu , Rr , P0 ) = for product unit Uu
r
at review moment Rr
[IN + ACDP( Rr , P0 ) − AI( Rr ) − TIP( Rr , P0 )] for plan moment P0r
⋅EF(Uu ) − ASDO(Uu , Rr )
59

For MRP/DRP: Aggregate Supplier Demand Plan
ASDP (U u , Rr , P0 r ) = 0 for product unit Uu
at review moment Rr
and
for plan moment P0r and Ppr–LT
ASDP(Uu , Rr , Pp r − LT ) =
when the NIMIS applies MRP/DRP
ISP( Rr , Ppr ) ⋅ EF (Uu )
for: Pp r > P0 r + LT
For LRP: Aggregate Supplier Demand Plan

ASDP(Uu , Rr , P0r ) = for product unit Uu
at review moment Rr
 b b 
 IN + ∑ ACDP( Rr , Pir ) − AI( Rr ) − ∑ TIP( Rr , Pir ) for plan moment P0r and Ppr–LT
 i=0 i =0 
when the NIMIS applies LRP
⋅EF(Uu ) − ASDO(Uu , Rr )
with: Pbr ≤ P0 r + LT < Pb +1r

and
ASDP (U u , Rr , Pp r − LT ) =
ACDP ( Rr , Pp r ) ⋅ EF (U u )
for: Ppr > P0 r + LT
For BSC: Individual Supplier Demand Plan

ISDP( Ss , U u , Rr , P0 r ) = sent to supplier Ss
ASDP(U u , Rr , P0 r ) ⋅ SA(U u , Ss ) for product unit Uu

at review moment Rr
for plan moment P0r
For MRP/DRP and LRP: Individual Supplier Demand Plan
ISDP( S s , U u , Rr , P0 r ) = sent to supplier Ss
ASDP(U u , Rr , P0 r ) ⋅ SA(U u , S s ) for product unit Uu
at review moment Rr
and
for plan moment P0r and Ppr–LT
ISDP( Ss , U u , Rr , Ppr − LT ) =
ASDP(U u , Rr , Ppr − LT ) ⋅ SA(U u , S s ) MRP/DRP or LRP
for: Ppr > P0 r + LT
60

For BSC: Aggregate Supplier Demand Order
ASDO (U u , Rr ) = ISP ( Rr , P0 r ) ⋅ EF (U u ) for product unit Uu
at review moment Rr
For MRP/DRP and LRP: Aggregate Supplier Demand Order
b for product unit Uu
ASDO(Uu , Rr ) = ∑ ISP ( Rr , Pir ) ⋅ EF (Uu )
at review moment Rr
i=0
with: Pbr < Rr +1 + LT ≤ Pb+1r
MRP/DRP or LRP
Individual Supplier Demand Order
ISDO( S s , U u , Rr ) = ASDO(U u , Rr ) ⋅ SA(U u , Ss ) sent to supplier Ss
for product unit Uu
at review moment Rr
The system equations that apply to the supplier related variables in a NIMIS are presented
in Table 3-10. The names of the suppliers Ss are set by the strategist. In the Supplier
Allocator SA(Uu, Ss), the strategist specifies how many product units Uu per product at the
single SKU stock-point are supplied by supplier Ss.
In BSC, the Aggregate Supplier Demand Plan ASDP(Uu, Rr, P0r), at review moment
Rr and plan moment P0r, is equal to the Inventory Norm IN, plus the ACDP(Rr, P0r), minus
the Actual Inventory AI(Rr), minus the Transit Inventory Plan TIP(Rr, P0r), multiplied by
the Explosion Factor EF(Uu), minus the Aggregate Supplier Demand Order ASDO(Uu, Rr).
Hence, in BSC the ASDP(Uu, Rr, P0r) is not affected by the Lot Size LS. The ASDO(Uu, Rr)
is subtracted, because this order increases the in transit inventory to the stock-point and
decreases the inventory at suppliers. When suppliers evaluate the plan, the order quantity
will have been booked off from their inventory and will thus count as more integral
inventory downstream, resulting in less demand in the ASDP(Uu, Rr, P0r).
In MRP/DRP, the Aggregate Supplier Demand Plan ASDP(Uu, Rr, t) is dependent on
plan moment Ppr. For the first plan moment P0r at review moment Rr, the ASDP(Uu, Rr,
P0r) is zero by definition. The ASDP(Uu, Rr, Ppr–LT) for product unit Uu at review moment
Rr for plan moment Ppr–LT greater than P0r, is equal to the Inventory Supply Plan ISP(Rr,
Ppr), multiplied by the Explosion Factor EF(Uu) for product unit Uu.
In LRP, the Aggregate Supplier Demand Plan ASDP(Uu, Rr, t) also depends on plan
moment Ppr. For the first plan moment P0r at review moment Rr, the ASDP(Uu, Rr, P0r) is
equal to the Inventory Norm IN, plus total demand due to the Aggregate Customer
Demand Plan ACDP(Rr, Ppr) from the first plan moment P0r to the last plan moment Pbr
61
within the scope of the Lead Time LT, minus the Actual Inventory AI(Rr), minus the total
supply due to the Transit Inventory Plan TIP(Rr, Ppr) from the first plan moment P0r to the
last plan moment Pbr, the outcome being multiplied by the Explosion Factor EF(Uu),
minus the Aggregate Supplier Demand Order ASDO(Uu, Rr). The latter order is
subtracted, because it becomes in transit inventory to the stock-point, which contributes to
the integral inventory level of the stock-point. For further plan moments, the ASDP(Uu, Rr,
Ppr–LT) equals the ACDP(Rr, Ppr), multiplied by the Explosion Factor EF(Uu).
The Individual Supplier Demand Plan ISDP (Ss, Uu, Rr, P0r) in BSC, MRP/DRP and
LRP is equal to the Aggregate Supplier Demand Plan ASDP(Uu, Rr, P0 ) multiplied by the
r
Supplier Allocator SA(Uu, Ss). In MRP/DRP and LRP, the Individual Supplier Demand Plan
ISDP(Ss, Uu, Rr, Prr–LT), for further plan moments, equals the ASDP(Uu, Rr, Ppr–LT)
multiplied by the Supplier Allocator SA(Uu, Ss).
The Aggregate Supplier Demand Order ASDO(Uu, Rr) in BSC is equal to the
Inventory Supply Plan ISP(Rr, P0r), multiplied by the Explosion Factor EF(Uu). In
MRP/DRP and LRP, the ASDO(Uu, Rr) is the sum of the ISP(Rr, Pr ), from P0 to the last plan
r r
moment Pbr within the scope of Rr+1 + LT, multiplied by the Explosion Factor EF(Uu). The
Individual Supplier Demand Order ISDO(Ss, Uu, Rr) is calculated by multiplication of the
ASDO(Uu, Rr) by the Supplier Allocator SA(Uu, Ss).
3.2.2 Integral inventory management properties

The second part of the integral inventory management design of NIMISs is the explanation
of their properties related to integral inventory management. These properties result from
the integral inventory management model, which describes the position of NIMISs in a
network, the variables that are present in each information system and the equations that
relate those variables. The resulting properties concern functionality for Base Stock
Control (BSC), Material/Distribution Requirements Planning (MRP/DRP) and Line
Requirements Planning (LRP).
3.2.2.1 Base Stock Control
One of the functional requirements for NIMISs is their provision of functionality for Base
Stock Control (BSC). BSC is an integral inventory management algorithm, managing the
integral inventory level of a stock-point. The integral inventory level for a particular stock-
point is the inventory on hand (and on order) at the stock-point, plus the inventory on
hand in and in transit between (on order in) all downstream stock-points. BSC systems
reorder as soon as the integral inventory level drops below the base stock level, which is
the norm for the integral inventory level. In BSC, the NIMISs in a network manage their
integral inventory levels at any review moment instantaneously.
62
Integral inventory level NIMIS S1 at R1 for P0r
Integral inventory level NIMIS X1 at R1 for P0r
Integral inventory level NIMIS C1 at R1 for P0r
NIMIS S1 NIMIS C1
BSC BSC
S1 C1

BSC BSC BSC
S2 X1 C2
NIMIS S3 NIMIS C3
BSC BSC
S3 C3
Information flow Rr = Review moment r
Goods flow Ppr = Plan moment p at review moment r
Figure 3-3 Base Stock Control across a network
In Figure 3-3 the property of Base Stock Control across a network of NIMISs is illustrated.
NIMIS X1 in the middle, deals with three customers and three suppliers. The customers use
63
NIMIS C1, NIMIS C2 and NIMIS C3 to manage their stock-points, while the suppliers use NIMIS
S1, NIMIS S2 and NIMIS S3. NIMIS X1 manages a single SKU stock-point X1, containing
product type X1. Product X1 goes into the products C1, C2 and C3 which are stored by the
customers in their stock-points. Product X1 is composed of products S1, S2 and S3, for
which inventory is kept at the suppliers’ stock-points.
The support of BSC by the NIMISs, is the result of the loose coupling of these
extremely basic information systems. Together, the NIMISs in the network can realise
integral inventory management according to BSC for their stock-points, if all systems in
the network apply BSC. NIMIS X1 receives orders and plans from next downstream
customers. Customer orders specify current and local demand for the single SKU stock-
point X1. NIMIS X1 immediately turns the received customer orders into output process
orders for the operational process. Customer plans contain information about the
downstream integral inventory levels, taking into account downstream inventory norms.
Each customer plan specifies an actual downstream integral inventory balance for product
X1.
At a review moment, NIMIS X1 computes its current integral inventory level with the
help of the actual inventory, the transit inventory plan and the customer plans. The
integral inventory level is used to compute supplier orders, which are sent to suppliers and
forwarded to the operational process as input process orders. At a review moment, NIMIS
X1 also computes supplier plans from the integral inventory level. The supplier plans
specify the downstream integral inventory balance for the suppliers and are forwarded to
the suppliers for their integral inventory management. They perceive the supplier plans
sent by NIMIS X1 as customer plans. So, the other NIMISs in the network can apply the same
principles as NIMIS X1. Due to the possible recurrence of the NIMIS principles at customers
and suppliers, BSC can be realised across a network of supply chains.
The BSC property supported by NIMISs is similar to an (s, Q) BSC system, where s is
the re-order point and Q is a fixed lot size quantity [Magee, 1958] [Clark, 1960] [Silver,
1985]. If the integral inventory level is below the re-order point s at the moment of review,
one or more quantities Q are ordered to raise the integral inventory level up to the re-order
point s.
64
Table 3-11 Base Stock Control in a system
NIMIS Stock- Algorithm Customer Inventory Lot Lead Explosion Supplier

point List Norm Size Time Factor Allocator
List List
NIMIS X1 X1 BSC C1 30 40 — A: 1 A: 1*S1
C2 B: 2 B: 2*S2
C3 C: 3 C: 3*S3
Moment Rr P0r — — — — — —
Time 0 0 — — — — — —
ICDO C1: 2 — — — — — — —
List C2: 3
C3: 5
OPO C1: 2 — — — — — — —
List C2: 3
C3: 5
ACDO 10 — — — — — — —
ICDP C1: — 42 — — — — — —
List C2: –27
C3: 15
ACDP — 30 — — — — — —
AI 10 — — — — — — —
TIP — 40 — — — — — —
EIPP — 20 — — — — — —
ISP — 40 — — — — — —
IIPP — 60 — — — — — —
ASDO X1: 40 — — — — — — —
A: 40
B: 80
C: 120
ISDO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
IPO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
ASDP X1: — –30 — — — — — —
A: –30
B: –60
C: –90
ISDP S1: A: — –30 — — — — — —
List S2: B: –60
S3: C: –90
65
The BSC property of NIMISs is explained with the help of Table 3-11, which represents
information in NIMIS X1. The parameters of NIMIS X1 are specified in the first two rows,
above the double line. NIMIS X1 manages the single SKU stock-point in operational process
X1, in which inventory of product X1 is held. The Customer List includes Customer 1,
Customer 2 and Customer 3. The Inventory Norm (IN) is 30 units and the Lot Size (LS) is
40 units, whereas in BSC the Lead Time (LT) is not applied for time-phasing. According to
the Explosion Factor (EF) List, one product X1 is composed of one product unit A, two B
units and three C units. The Supplier Allocator (SA) List states that all product units A are
supplied by Supplier 1, all units B by Supplier 2 and all units C by Supplier 3. Below the
double-line in Table 3-11 a row named Moment gives a review moment Rr and a plan
moment P0r which are both at clock-time 0. As there is no time-phased management in
BSC, there is typically only one plan moment, which coincides with the review moment.
The Individual Customer Demand Order (ICDO) List states that since the last
review moment, up to and including the current review moment Rr, Customer 1 has
ordered two X1 units, Customer 2 three X1 units and Customer 3 five X1 units. The Output
Process Order (OPO) List gives the same order quantities as in the ICDO List in a format
for the operational process. The Aggregate Customer Demand Order (ACDO) equals 10 X1
units, the sum of the quantities in the ICDO List.
The Individual Customer Demand Plan (ICDP) List gives information on demand
caused by current and downstream integral inventory levels. Each ICDP represents a
balance of a downstream integral inventory level (on hand and ordered) and the total
downstream inventory norm. A positive value in an ICDP indicates a deficit of X1 units in
the downstream supply chains, because the total inventory downstream is less than the
cumulative downstream inventory norms. A negative demand value in the ICDP denotes
that there is more integral inventory available downstream than needed to cover the
downstream integral inventory norm. According to the ICDP List, Customer 1 and
Customer 3 need 42 and 15 X1 units respectively, to cover their inventory norms, whereas
Customer 2 reports a surplus of 27 X1 units. The Aggregate Customer Demand Plan
(ACDP) equals 30 X1 units, the sum of the quantities in the ICDP List. On balance, 30 X1
units are needed to cover the downstream integral inventory norm.
The Actual Inventory (AI) gives the inventory level at the stock-point at the review
moment Rr. The previously ordered quantities in the ICDO List have already been
subtracted from the AI. The Transit Inventory Plan (TIP) indicates that 40 X1 units have
been ordered, but have not been received yet.
The Exclusive Inventory Position Plan (EIPP) for plan moment P0r, is equal to the
AI plus the TIP minus the ACDP, equal to 20 X1 units. Since the EIPP is below the
Inventory Norm (IN) of 30 X1 units, the Inventory Supply Plan (ISP) is 40 X1 units, which
66
is equal to one Lot Size (LS). The EIPP in BSC represents the integral inventory balance
level of stock-point X1, which is not being distorted by lot-sizing rules downstream in the
network of supply chains. The Inclusive Inventory Position Plan (IIPP) is the EIPP plus
the ISP, thus equal to 60 X1 units.
Given the ISP of 40 X1 units, the Aggregate Supplier Demand Order (ASDO)
includes 40 X1 units, exploded with the Explosion Factor (EF) List into 40 A units, 80 B
units and 120 C units. The Supplier Allocator (SA) List indicates that for every product X1,
one product unit A is supplied by Supplier 1, two B units come from Supplier 2 and three
C units are needed from Supplier 3. In the Individual Supplier Demand Order (ISDO) List
and the Input Process Order (IPO) List, quantities of the ASDO are allocated to the
respective suppliers.
The Aggregate Supplier Demand Plan (ASDP) is equal the Inventory Norm (IN)
plus the Aggregate Customer Demand Plan (ACDP), minus the Actual Inventory (AI) and
the Transit Inventory Plan (TIP), minus the Aggregate Supplier Demand Order (ASDO).
So, the ASDP equals –30 X1 units, which is exploded with the Explosion Factor (EF) List
to –30 A units, –60 B units and –90 C units. The ASDP takes into account the integral
inventory level as well as the integral inventory norm in the downstream supply chains.
The Aggregate Supplier Demand Order ASDO of 40 X1 products units, released at the
review moment, results in extra in transit inventory for NIMIS X1 and decreases the ASDP.
In this case, the ASDP contains negative demand for suppliers, thus indicates a surplus of
downstream inventory (on hand and on order).
In the Individual Supplier Demand Plan (ISDP) List, the demand for product units
A, B and C is linked to Supplier 1, Supplier 2 and Supplier 3, with the help of the
Supplier Allocator (SA) List. The ISDP List is forwarded to the suppliers and notifies them
of the product quantities needed downstream in the network of supply chains. In this case,
a downstream inventory surplus is communicated to the suppliers.
3.2.2.2 Material/Distribution Requirements Planning
One of the functional requirements for NIMISs is their provision of functionality for
Material/Distribution Requirements Planning (MRP/DRP). MRP/DRP is an integral inventory
management algorithm, managing time-phased inventory levels of a stock-point,
including current as well as future levels. MRP/DRP systems consist of a set of logically
related procedures, decision rules, and records designed to translate time-phased gross
requirements into net requirements and into the planned orders to cover the net
requirements. In MRP/DRP, the NIMISs in a network manage their local inventory levels at
any review moment in a time-phased manner.
67
Local inventory level NIMIS S1 at R1 for P01, P11, P21, ...
Local inventory level NIMIS X1 at R1 for P01, P11, P21, ...
Local inventory level NIMIS C1 at R1 for P01, P11, P21, ...
NIMIS S1 NIMIS C1
MRP/DRP MRP/DRP
S1 C1

MRP/DRP MRP/DRP MRP/DRP
S2 X1 C2
NIMIS S3 NIMIS C3
MRP/DRP MRP/DRP
S3 C3
Figure 3-4 Material/Distribution Requirements Planning across a network
Figure 3-4 illustrates the property of Material/Distribution Requirements Planning across

a network of NIMISs. This network is similar to the network in Figure 3-3, with NIMIS X1 in
the middle. The support of MRP/DRP by the NIMISs, is the result of the loose coupling of
68
these extremely basic information systems. Together, the NIMISs in the network can realise
integral inventory management according to MRP/DRP for their stock-points, if all systems
in the network apply MRP/DRP. NIMIS X1 receives orders and plans from next downstream
customers. Customer orders specify current and local demand for the single SKU stock-
point X1. NIMIS X1 immediately turns the received customer orders into output process
orders for the operational process. Customer plans give the expected demand for product
X1 at future moments in time.
At a review moment, NIMIS X1 computes its current and future local inventory levels
with the help of the actual inventory, the transit inventory plan and the customer plans.
The time-phased local inventory levels are used to compute supplier orders, which are sent
to suppliers and forwarded to the operational process as input process orders. At a review
moment, NIMIS X1 also computes supplier plans from the time-phased local inventory
levels, which specify the expected local demand for the suppliers. The supplier plans are
given to the suppliers, since they can use the information as customer plans for their
integral inventory management. Because customers and suppliers of a NIMIS can also apply
these principles, MRP/DRP can be realised across a network of supply chains.
The MRP/DRP property supported by NIMISs is similar to the original MRP/DRP
algorithm [Orlicky, 1975] [Martin, 1983] [Martin, 1993]. The Aggregate Customer
Demand Plan (ACDP) is then called Gross Requirements. The Transit Inventory Plan
(TIP) is known as Scheduled Receipts. The Exclusive Inventory Position Plan (EIPP) is
similar to the Available Balance or Projected On Hand. The Inventory Supply Plan (ISP)
relates to Net Requirements and Planned Order Receipts. The Aggregate Supplier Demand
Plan (ASDP) represents the Planned Order Release.
69
Table 3-12 Material/Distribution Requirements Planning in a system

List List
NIMIS X1 X1 MRP C1 30 40 2 A: 1 A: 1*S1
DRP C2 B: 2 B: 2*S2
C3 C: 3 C: 3*S3
Moment Rr P0r P1r P2r P3r P4r P5r P6r
Time 0 0 1 2 3 4 5 6
ICDO C1: 2 — — — — — — —
List C2: 3
C3: 5
OPO C1: 2 — — — — — — —
List C2: 3
C3: 5
ACDO 10 — — — — — — —
ICDP C1: — 0 1 1 1 1 1 1
List C2: 0 3 3 3 3 3 3
C3: 0 6 6 6 6 6 6
ACDP — 0 10 10 10 10 10 10
AI 0 — — — — — — —
TIP — 0 40 0 0 0 0 0
EIPP — 0 30 20 10 0 –10 –20
ISP — 0 0 40 0 0 0 40
IIPP — 0 30 60 50 40 30 60
ASDO X1: 40 — — — — — — —
A: 40
B: 80
C: 120
ISDO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
IPO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
ASDP X1: — 0 0 0 0 40 — —
A: 0 0 0 0 40
B: 0 0 0 0 80
C: 0 0 0 0 120
ISDP S1: A: — 0 0 0 0 40 — —
List S2: B: 0 0 0 0 80
S3: C: 0 0 0 0 120
70
The MRP/DRP property of NIMISs is explained with the help of Table 3-12, which presents
above the double line. They have the same values as in Table 3-11 except for the Lead
Time (LT), which in this case is two time units. Below the double-line in Table 3-12 a row
named Moment gives a review moment Rr and seven plan moments P0r to P6r. The review
moment Rr is at clock-time 0, while the plan moments P0r to P6r are at clock-time 0, 1, 2,
and so on. At the review moment, product quantities for the plan moments are determined.
The Individual Customer Demand Order (ICDO) List and Output Process Order
(OPO) List state that, from the previous review moment up to and including the current
review moment Rr, Customer 1 has ordered two X1 units, Customer 2 has demanded three
X1 units and Customer 3 has requested five X1 units. Hence, the Aggregate Customer
Demand Order (ACDO) equals 10 X1 units, the sum of the ICDO List.
The Individual Customer Demand Plan (ICDP) List specifies the expected future
demand of the customers. The ICDP List for plan moment P0r specifies a demand of zero
X1 units for all customers. For the plan moments P1 and beyond, Customer 1 expects to
r
demand one unit X1, Customer 2 anticipates a demand of three X1 units and Customer 3
foresees a demand of six X1 units per plan moment. The Aggregate Customer Demand
Plan (ACDP) is the sum of the IDCP List, thus equal to ten X1 units for the plan moments
P1r to P6r.
At the review moment Rr, the Actual Inventory (AI) at the stock-point equals zero
X1 unit. The Transit Inventory Plan (TIP) indicates that 40 X1 units have been ordered and
are expected to be received at plan moment P1r. The Exclusive Inventory Position Plan
(EIPP) for P0r and P1r is the AI plus the cumulative TIP minus the cumulative ACDP,
equal to zero and 30 X1 units respectively. The Inventory Supply Plan (ISP) for P0r and P1r
is equal to zero by definition, because the plan moments P0r and P1r are less than the Lead
Time (LT) ahead of the review moment Rr. Thus, the Inclusive Inventory Position Plan
(IIPP) for P0r and P1r is equal to the EIPP. At plan moment P2r, the EIPP drops below the
Inventory Norm (IN) due to the ACDP of 10 X1 units at P2r. Therefore, the ISP at P2r is 40
X1 units, equal to one Lot Size (LS). This upgrades the IIPP to 60 X1 units at P2 . The
r
same logic applies for the calculation of the quantities in the plans at P3r to P6r.
The Aggregate Supplier Demand Order (ASDO) is derived by looking at the Lead
Time (LT) ahead in the Inventory Supply Plan (ISP). Hence, the ASDO at the review
moment Rr is 40 X1 units, equal to the ISP at plan moment P2r, exploded with the
Explosion Factor (EF) List to 40 A units, 80 B units and 120 C units. In the Individual
Supplier Demand Order (ISDO) List and Input Process Order (IPO) List, demand per
product unit is allocated to the respective suppliers with the Supplier Allocator (SA) List.
71
The Aggregate Supplier Demand Plan (ASDP) is determined by off-setting the

Inventory Supply Plan (ISP) over the Lead Time (LT) and using the Explosion Factor (EF)
List to determine the required product units A, B and C. The ASDP at P4r specifies
demand for 40 X1 units, exploded into 40 A units, 80 B units and 120 C units. The ACDP
for the plan moments P5r and P6r is unknown, since the ISP for P7r and P8r is missing. In
the Individual Customer Demand Plan (ICDP) List, the suppliers of the product units have
been added with the help of the Supplier Allocator (SA) List.
3.2.2.3 Line Requirements Planning
One of the functional requirements for NIMISs is their provision of functionality for Line
Requirements Planning. (LRP). LRP is an integral inventory management algorithm
managing time-phased integral inventory levels. LRP combines the integral inventory
levels of BSC with the time-phased inventory levels of MRP/DRP. In addition to the
generation of order suggestions for the current period, a time-series of planned orders is
made. The information exploded by LRP to upstream stock-points is not only based on
expected requirements downstream, but also on downstream inventory in stock-points and
transit processes. In LRP, the NIMISs in a network manage their integral inventory levels at
the any review moment in a time-phased manner.
72
Integral inventory level NIMIS S1 at R1 for P01, P11, P21, ...
Integral inventory level NIMIS X1 at R1 for P01, P11, P21, ...
Integral inventory level NIMIS C1 at R1 for P 01, P11, P21, ...
NIMIS S1 NIMIS C1
LRP LRP
S1 C1

LRP LRP LRP
S2 X1 C2
NIMIS S3 NIMIS C3
LRP LRP
S3 C3
Figure 3-5 Line Requirements Planning across a network
Figure 3-5 illustrates the property of Line Requirements Planning across a network of
NIMISs. This network is similar to the network in Figure 3-3, with NIMIS X1 in the middle.
The support of LRP by the NIMISs, is the result of the loose coupling of these extremely
73
basic information systems. Together, the NIMISs can realise integral inventory
management according to LRP for their stock-points, if all systems in the network apply
LRP. NIMIS X1 receives orders and plans from next downstream customers. Customer
orders specify current and local demand for the single SKU stock-point X1. NIMIS X1
immediately turns the received customer orders into output process orders for the
operational process. Customer plans contain information about current and future
downstream integral inventory levels, taking into account downstream inventory norms.
They specify the actual and expected downstream integral inventory balance for product
X1.
At a review moment, NIMIS X1 computes its current and future integral inventory
levels with the help of the actual inventory, the transit inventory plan and the customer
plans. The time-phased integral inventory levels are used to compute supplier orders,
which are sent to suppliers and forwarded to the operational process as input process
orders. At a review moment, NIMIS X1 also computes supplier plans from the time-phased
integral inventory levels. The supplier plans specify the downstream integral inventory
balance for the suppliers, for the current and for future moments. The supplier plans are
sent to the suppliers, because they can use them as customer plans for their integral
inventory management. Since the relationships of a NIMIS can recur at customers and
suppliers, LRP can be realised across a network of supply chains.
The LRP property supported by NIMISs is similar to the original LRP algorithm
[Donselaar, 1989]. In a NIMIS, the Integral Requirements and Integral Inventory are
combined in the Aggregate Customer Demand Plan (ACDP) together with downstream
inventory norms. Scheduled Receipts are included as Transit Inventory Plan (TIP). The
Available Balance or Projected On Hand are similar to the Exclusive Inventory Position
Plan (EIPP). Net Requirements and Planned Order Receipts are incorporated as the
Inventory Supply Plan (ISP). The Aggregate Supplier Demand Plan (ASDP) in a NIMIS
does not specify Planned Order Releases, but instead the ASDP represents the remaining
current and future demand for suppliers, because this demand has not yet been covered by
the inventory (on hand and on order) at the stock-point of the NIMIS and by the inventory
in downstream stock-points and transit processes.
74
Table 3-13 Line Requirements Planning in a system

List List
NIMIS X1 X1 LRP C1 30 40 2 A: 1 A: 1*S1
C2 B: 2 B: 2*S2
C3 C: 3 C: 3*S3
Moment Rr P0r P1r P2r P3r P4r P5r P6r
Time 0 0 1 2 3 4 5 6
ICDO C1: 2 — — — — — — —
List C2: 3
C3: 5
OPO C1: 2 — — — — — — —
List C2: 3
C3: 5
ACDO 10 — — — — — — —
ICDP C1: — 2 5 5 5 5 5 5
List C2: –7 3 3 3 3 3 3
C3: 15 12 12 12 12 12 12
ACDP — 10 20 20 20 20 20 20
AI 10 — — — — — — —
TIP — 0 40 0 0 0 0 0
EIPP — 0 20 0 –20 –40 –60 –80
ISP — 0 0 40 40 0 40 0
IIPP — 0 20 40 60 40 60 40
ASDO X1: 40 — — — — — — —
A: 40
B: 80
C: 120
ISDO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
IPO S1: A: 40 — — — — — — —
List S2: B: 80
S3: C: 120
ASDP X1: — -10 20 20 20 20 — —
A: -10 20 20 20 20
B: -20 40 40 40 40
C: -30 60 60 60 60
ISDP S1: A: — -10 20 20 20 20 — —
List S2: B: -20 40 40 40 40
S3: C: -30 60 60 60 60
75
The LRP property of NIMISs is explained with the help of Table 3-13, which represents
above the double line. They have the same values as in Table 3-12. Below the double-line
in Table 3-1, a row named Moment gives a review moment Rr and the plan moments P0r
to P6r. The review moment Rr is at clock-time 0, while the plan moments P0r to P6r are at
clock-time 0, 1, 2, and so on. At the review moment, product quantities for the plan
moments are determined.
The Individual Customer Demand Order (ICDO) List and Output Process Order
(OPO) List state that, from the previous review moment up to and including the current
review moment Rr, Customer 1 has ordered two X1 units, Customer 2 three X1 units and
Customer 3 five X1 units. Hence, the Aggregate Customer Demand Order (ACDO) equals
10 X1 units, the sum of the ICDO List.
The Individual Customer Demand Plan (ICDP) List gives information on demand
caused by current and expected future downstream integral inventory levels. The
Individual Customer Demand Plan (ICDP) for plan moment P0r represents a balance of
the downstream integral inventory level (on hand and ordered) and the total downstream
inventory norm. A positive demand value in the ICDP at P0r, indicates a deficit of product
unit X1 in the downstream supply chains, because the total downstream inventory is less
than the cumulative downstream inventory norms. A negative demand value in the ICDP
at P0r, denotes that there is more integral inventory available downstream than is needed
to cover the downstream integral inventory norm. According to the ICDP List for P0r,
Customer 1 needs two X1 units to cover its inventory norm, Customer 3 requires 15 X1
units, whereas Customer 2 reports a surplus of seven X1 units.
The Individual Customer Demand Plan (ICDP) List for the plan moments P1r to
P6r, reflects non-negative future demand for the stock-point, that might be covered by a
negative balance in the IDCP for plan moment P0r. According to the ICDP List for the
plan moments P1r to P6r, Customer 1 expects a demand of five X1 units, Customer 2 needs
three X1 units and Customer 3 asks for 12 X1 units per plan moment. The Aggregate
Customer Demand Plan (ACDP) is the sum of the ICDP List, equal to 10 X1 units for P0r
and equal to 20 X1 units for P1r to P6r.
At the review moment Rr, the Actual Inventory (AI) at the stock-point is 10 X1
units. The Transit Inventory Plan (TIP) indicates that 40 X1 units have been ordered and
are expected to be received at plan moment P1r.
The Exclusive Inventory Position Plan (EIPP) for the plan moments P0r and P1r, is
the Actual Inventory (AI), plus the cumulative Transit Inventory Plan (TIP), minus the
cumulative Aggregate Customer Demand Plan (ACDP), equal to zero and 20 X1 units
respectively. Although the EIPP at P0r and P1r is below the Inventory Norm (IN), the
76
Inventory Supply Plan (ISP) for P0r and P1 is equal to zero by definition, as P0r and P1r are
less than the Lead Time (LT) ahead of the review moment Rr. So, at the plan moments P0r
and P1r, the Inclusive Inventory Position Plan (IIPP) is equal to the EIPP. At plan moment
P2r, the EIPP is still below the Inventory Norm (IN). The ISP at P2r becomes 40 X1 units,
equal to one Lot Size (LS). This upgrades the IIPP to 40 X1 units at P2r. For the
computation of the planned product quantities at P3r to P6r, the same logic applies to. The
EIPP in the case of LRP, represents the integral inventory balance level of stock-point X1,
which is not being distorted by lot-sizing rules downstream in the network of supply
chains.
The Aggregate Supplier Demand Order (ASDO) at the review moment Rr is derived
by looking at the Lead Time (LT) ahead in the Inventory Supply Plan (ISP). Hence, the
ASDO at Rr is 40 X1 units, equal to the ISP at plan moment P2r, multiplied by the
Explosion Factor (EF) List to 40 A units, 80 B units and 120 C units. In the Individual
Supplier Demand Order (ISDO) List and Input Process Order (IPO) List, demand per
product unit is allocated to the respective suppliers with the Supplier Allocator (SA) List.
The Aggregate Supplier Demand Plan (ASDP) at the first plan moment P0r is equal
to the Inventory Norm (IN), plus the cumulative Aggregate Customer Demand Plan
(ACDP) values from the review moment Rr till P2r, which is the Lead Time (LT) ahead of
P0r, minus the Actual Inventory (AI), minus the cumulative Transit Inventory Plan (TIP)
values from the review moment Rr until P2r, multiplied by the Explosion Factor (EF) List,
minus the ASDO which increases the in transit inventory to the stock-point. So, the ASDP
at P0r equals 30 plus 50 minus 10 minus 40 minus 40, which is –10 X1 units, multiplied by
the EF List, resulting in –10 product units A, –20 B units and –30 C units. The ASDP
takes into account the integral inventory level as well as the integral inventory norm in the
downstream supply chains. In this case, the ASDP at P0r contains negative demand for
suppliers, thus indicating a surplus of downstream inventory, because the integral
inventory level for the stock-point exceeds the integral inventory norm.
At plan moments P1r to P4r, the Aggregate Supplier Demand Plan (ASDP) is equal
to the Aggregate Customer Demand Plan (ACDP) at P3r to P6r respectively, which is the
Lead Time (LT) ahead of P1r to P4r. So, the ASDP for P1r to P4r equals 20 X1 units,
exploded with the Explosion Factor (EF) List into 20 product units A, 40 B units and 60 C
units. The ASDP at P1r to P4r forwards the demand for unit X1 at P1r to P4r without
considering the integral inventory level at review moment Rr, because this has already
been taken into account in the ASDP at P0r. In the Individual Supplier Demand Plan
(ISDP) List at P1r to P4r, the product units are linked by the Supplier Allocator (SA) List to
the suppliers. The ASDP at P5r and P6r is unknown, because the ACDP for P7r and P8r is
not yet not known.
77
In the Individual Supplier Demand Plan (ISDP) List, the demand per product unit
is determined by allocation of the demand values from the Aggregate Supplier Demand
Plan (ASDP) to the respective suppliers, with the help of the Supplier Allocator (SA) List.
The ISDP List is forwarded to the suppliers and represents for them the product quantities
needed downstream in the network of supply chains.
3.3 Networked organisation management design

The functional design of the information systems for networked inventory management,
consists partly of a networked organisation management (NOM) design. This design must
be consistent with the integral inventory management (IIM) design, because together they
specify the overall networked inventory management (NIM) design of NIMISs in this study.
To satisfy the functional requirements with respect to networked organisation
management, the information systems must provide functionality for configuration
flexibility, timing flexibility and algorithm flexibility.
3.3.1 Networked organisation management model

With the help of a model of the information systems, it is specified how networked
organisation management is achieved by NIMISs. The networked organisation management
model encompasses a system model that positions the information systems in their
environment of networked organisations. In addition, the model gives the variables that
are used in a NIMIS for networked organisation management. Furthermore, the
relationships between the variables for networked organisation management are specified
in system equations.
3.3.1.1 System model
A major decision in the design of the Networked Inventory Management Information

Systems (NIMISs) is the determination of the system boundaries of one NIMIS. To maximise
flexibility of the information systems, as needed for networked organisation management,
one NIMIS manages the inventory of just one single SKU stock-point (SSS). When several
product types are stored at one location, an equal number of information systems is used.
When a product type is held in stock at various locations, these different single SKU stock-
points need separate NIMISs. A NIMIS is an information system with extremely basic
functionality and an extremely basic architecture. These extremely basic information
systems are loosely coupled to one another in networks, in order to support networked
78
Organisation A Organisation B
BIS BIS
NIMIS S7 NIMIS C7
LRP
NIMIS S4 LRP
NIMIS C4
LRP
NIMIS S1 LRP
NIMIS C1
S7 C7
S4 C4
S1 C1
Location Location
Organisation C Organisation D
BIS BIS
LRP
NIMIS S5 LRP
NIMIS X2 LRP
NIMIS C5
LRP
NIMIS S2 LRP
NIMIS X1 LRP
NIMIS C2
S8 X3 C8
S5 X2 C5
S2 X1 C2
Location Location Location
Organisation E
BIS
NIMIS S9 NIMIS C9
LRP
NIMIS S6 LRP
NIMIS C6
LRP
NIMIS S3 LRP
NIMIS C3
S9 C9
S6 C6
S3 C3
Location Location
Information flow
BIS Business Information System
Goods flow
Operational process including Networked organisation

one single SKU stock-point
Figure 3-6 Network view of networked organisation management
79
In Figure 3-6 a model of the information systems for networked organisation management
is presented from a network viewpoint. A network consists of some networked
organisations that deal with each other in their supply chains. Goods flow through the
supply chains via operational processes that may include single SKU stock-points (SSSs) at
which products are held in stock. A networked organisation can have zero, one or more
locations where SSSs reside. An SSS receives goods from one or more upstream stock-
points in the supply chains and supplies goods to one or more downstream stock-points.
For integral inventory management across networked organisations, every SSS is
managed by one NIMIS. The NIMISs of a networked organisation can work at different
locations. In a network of organisations, the NIMISs exchange information with one
another and with the stock-points they manage. Besides the use of NIMISs for integral
inventory management, a networked organisation normally applies a Business Information
System (BIS), which supports the management of its business processes. Typical functions
of these BISs are the management of sales, production, distribution, purchase, finance,
quality and human resources. A BIS might represent a cluster of various information
systems with specialised functions or could be an Enterprise Resource Planning (ERP)
system with broad functionality. While NIMISs provide very narrow functionality, but
achieve integration across organisations, the BISs normally provide wide functionality, but
lack integration across organisations.
The system model presented in Figure 3-6 might reflect a network of supply chains
in consumer electronics, for example. The networked organisation in the left upper corner
could be an independent supplier of chips which are stored at the single SKU stock-points
S1, S4 and S7. Similarly, the organisation in the left lower corner could be an independent
supplier of casings for which inventory is held at the stock-points S3, S6 and S9. These
independent suppliers supply their chips and casings as components to a manufacturer of
Compact Disc (CD) players. The manufacturer may have an inventory of finished CD
players at the stock-points X1, X2 and X3, but also manages the stock-points S2, S5 and S8,
containing chips that are made in-house. The organisation in the right upper corner is an
independent retailer at one location selling CD players to consumers from the stock-points
C1, C4 and C7. The organisation in the right lower corner is a retail group, which has
outlets at several locations, amongst others one with the stock-points C2, C5 and C8, and
one with the stock-points C3, C6 and C9.
80
Shifting Shifting
boundaries boundaries
Organisation
Co-operation BIS Co-operation
agreement agreement
Strategist
New Solved
Current parameter exception
parameter values Unsolved
values exception
Supplier Customer
plans plans
Supplier Customer
Suppliers orders
NIMIS orders Customers
Actual Actual
supply demand
Input orders Actual inventory Output orders
Location
Goods flow
Information flow
Networked Inventory Management BIS Business Information System

NIMIS Information System

Figure 3-7 System view of networked organisation management
In Figure 3-7 a model of the information systems for networked organisation management
is presented from a system viewpoint. The relevant environment of a NIMIS consists of the
entities with which a NIMIS has relationships. The NIMIS controls an operational process
with one single SKU stock-point (SSS). It further deals with ‘customers’ and ‘suppliers’,
which in this context stand for SSSs, demanding products from and supplying products to
the SSS managed by the NIMIS. Finally, the NIMIS is controlled by a strategist, a human
being who supervises the information system. For setting the parameter values of the
system and for solving exceptions that emerge in the system, the strategist needs consistent
81
information about the relevant environment of the NIMIS. It is assumed that this
information can be obtained from a conceptual database.
A NIMIS operates in the domain of one networked organisation. The boundaries of
the networked organisation might be in between the NIMIS and its customers or suppliers,
or it may be at any other place in the network of NIMISs. Given the possible dynamics of
networked organisations, a NIMIS can cope with shifting boundaries of the networked
organisation. Besides the use of NIMISs for integral inventory management, a networked
organisation has a Business Information System (BIS) for the management of other
business functions. A NIMIS can operate independently of the BIS, so the BIS may change
over time without harming the functionality of the NIMIS.
In the context of networked organisations, the strategists usually make agreements
with customers and suppliers on co-operation between the single SKU stock-points (SSSs) in
the network and the information systems managing these SSSs. The demand for products
from the SSS, as well as the integral inventory management with customers, are based on
some co-operation agreement between the strategist and the customers. At the supply side,
the strategist agrees upon co-operation with suppliers for the supply of goods to the SSS
and the integral inventory management with suppliers. Because of the co-operation, the
strategist can communicate with its customers and suppliers, in order to set the parameter
values of the system and to solve exceptions that emerge in the system.
3.3.1.2 System variables
In the integral inventory management model of NIMISs, a set of variables is identified,

which is also used in the networked organisation management model. To provide
functionality for networked organisation management, some extra system variables in a
NIMIS are identified. All of the supplementary variables in the networked organisation
management model relate to the customers that demand products from the single SKU
stock-point that is managed by the NIMIS.
82
Table 3-14 Supplementary variables for networked organisation management
Variable Description
R rc Time of review moment Rrc

of customer Cc
rc Index to review moment Rrc
of customer Cc
Time of the last review moment Rrc
Rlc of customer Cc
at a review moment time Rr
in the NIMIS
Time of plan moment Ppr
c
P p rc at review moment Rrc

of customer Cc
Index to plan moment Ppr
c
p rc at review moment Rrc
of customer Cc
Number of plan moments Ppr
c
NPrc at review moment Rrc
of customer Cc
ICDO * (Cc , Rrc ) received from customer Cc
at review moment Rrc
ICDP *(Cc , Rrc , Pprc ) received from customer Cc
for plan moment Pprc
The supplementary variables in a NIMIS for networked organisation management are given
in Table 3-14. Review moment Rrcis the r-th moment at which customer Cc reviews its
inventory since the start of the lifetime of the NIMIS. The index r is equal to zero for the
first review moment and is increased by one for all following review moments of customer
Cc. In this way, the review moments Rrc of customers, as perceived by the NIMIS, are
uncoupled from the review moments Rr in the NIMIS. The review moment Rlc is the last
review moment of customer Cc as noticed in the NIMIS at review moment time Rr. At the
last review moment Rlc, customer Cc sent its most recent plan to the NIMIS that reviews its
83
inventory at review moment Rr. Plan moment Ppr is the p-th plan moment in the plans
c
computed by customer Cc at its review moment Rrc. At review moment Rrc, customer Cc
computes expected quantities of products for all its plan moments P0r to PNPr , so the
c c
plans computed at review moment Rrc contain NPrc plus one plan moments.
A NIMIS receives orders and plans from a customer, for which the review moments
and plan moments do not have to be equal to the review moments and plan moments in
the NIMIS. At review moment Rrc of customer Cc, the NIMIS receives an Individual
Customer Demand Order* ICDO*(Cc,Rrc). The quantity of products that customer Cc at its
review moment Rrc, expects to demand at its plan moment Ppr , is specified in the
c
Individual Customer Demand Plan ICDP*(Cc,Rrc,Ppr ). Because customers may use
c
different review moments and plan moments than the moments applied in the receiving
NIMIS, the orders and plans coming from customers need to be translated.
3.3.1.3 System equations
The last part of the networked organisation management model of NIMISs consists of
system equations that relate the system variables for networked organisation management
to the system variables for integral inventory management. These system equations are
used to compute values for the variables in a NIMIS. The supplementary system equations
that are used for networked organisation management all relate to the customers of a
NIMIS.
Table 3-15 Supplementary equations for networked organisation management

Rrc = determined by customers Time of review moment Rrc
at customer Cc
with: rc = 0,1,2,...
as perceived in the NIMIS
Ppr = determined by customers Time of plan moment Pprc
c
with: p rc = 0,1,2,..., NPrc
of customer Cc
as perceived in the NIMIS
Rlc = derived from comparison of Rr and Rrc Time of the last review moment Rlc
of customer Cc
with: Rl c ≤ Rr < Rl +1c
as noticed at review moment Rr
in the NIMIS
84

ICDO * (Cc , Rrc ) = received from customers received from customer Cc
b Individual Customer Demand Order
ICDO( Cc , Rr ) = ∑ ICDO * (Cc , Ri c ) received from customer Cc
i=a
Ra −1c ≤ Rr −1 < Rac ∧
with:
Rbc ≤ Rr < Rb +1c

ICDP * (Cc , Rrc , Ppr ) = received from customers received from customer Cc
c
for plan moment Ppr
c
For BSC: Individual Customer Demand Plan

ICDP(Cc , Rr , P0 r ) = ICDP *(Cc , Rl c , P0 l ) received from customer Cc
c
with: Rl c ≤ Rr < Rl +1 c
for plan moment Ppr
For MRP/DRP and LRP: Individual Customer Demand Plan
b received from customer Cc
ICDP(Cc , Rr , P0 r ) = ∑ ICDP * (Cc , Rlc , Pil )
c computed at review moment Rr
i=0
for plan moment Ppr
Rl c ≤ Rr < Rl +1c ∧
with: when the NIMIS applies
Pbl < P1r ≤ Pb +1l
c c MRP/DRP or LRP
and
b
ICDP(Cc , Rr , Ppr ) = ∑ ICDP *(Cc , Rl c , Pil )
c
i =a
Rl c ≤ Rr < Rl +1c ∧
with: Pa −1l < Ppr ≤ Pal ∧
c c
Pbl < Pp+1r ≤ Pb +1l

c c
for: Ppr > P0 r
In Table 3-15 the supplementary system equations for networked organisation

management are presented. The review moments Rrc are the moments at which customer
85
Cc manages its inventory level. Those review moments, as perceived by the NIMIS, are
determined by customer Cc. The last review moment Rlc of customer Cc, as noticed in the
NIMIS, is found by comparison of the current review moment Rr in the NIMIS to the review
moments of customer Cc. Customer Cc also determines the values for its plan moments
Ppr . These are the moments in plans for which customer Cc computes expected product
c
quantities. The number of plan moments NPrc limits the length of a plan at review
moment Rrc. As in a NIMIS, at customer Cc the plan moments Ppr and the number of plan
c
moments NPrc may differ per review moment Rrc. Normally, the next review moment Rr+1c
of customer Cc will occur at plan moment P1r , as identified in the plans of customer Cc at
c
review moment Rrc.
In the integral inventory management model, it is assumed that a NIMIS gets
Individual Customer Demand Orders ICDO(Cc, Rr) and Individual Customer Demand
Plans ICDP(Cc, Rr, Ppr), for which the review moments and plan moments coincide with
the review moments Rr and plan moments Ppr in the NIMIS. For networked organisation
management, the review moments and plan moments of customers are allowed to differ
from the review moments and plan moments in the NIMIS.
To satisfy networked organisation management, the equation for ICDO(Cc, Rr) as
stated previously in the integral inventory management model, is substituted by an other
equation. A NIMIS receives an Individual Customer Demand Order* ICDO*(Cc, Rrc) from
customer Cc at its review moment Rrc. The ICDO*(Cc, Rrc), as expressed in the review the
moment of the customer, is translated to ICDO(Cc, Rr), which is expressed in the
corresponding review moment of the NIMIS. The Individual Customer Demand Order
ICDO(Cc,Rr) at review moment Rr, is equal to the sum of the orders that have been
received from customer Cc since the previous review moment Rr-1 up until the current
review moment Rr in the NIMIS.
To comply to networked organisation management, the equation for the Individual
Customer Demand Plan ICDP(Cc, Rr, Ppr), as given in the integral inventory management
model, is overruled by an other equation. A NIMIS receives an ICDP*(Cc, Rrc, Ppr ) from
c
customer Cc at its review moment Rrc for its plan moment Ppr . The ICDP*(Cc, Rrc, Ppr ),
c c
as expressed in the review moments and plan moments of the customer, is translated to
ICDP(Cc, Rr, Ppr), which is expressed in the corresponding review moments and plan
moments of the NIMIS. The ICDP(Cc, Rr, Ppr) at review moment Rr, is based on the last
plan that was received from customer Cc at its review moment Rlc.
For BSC, there is only an Individual Customer Demand Plan ICDP(Cc, Rr, P0r) for
plan moment P0r, which is equal to the ICDP*(Cc, Rlc, P0l ) as specified by customer Cc at
c
its last review moment Rlc for plan moment P0l . For MRP/DRP as well as for LRP, the
c
ICDP(Cc, Rr, P0r) at plan moment P0r is equal to the sum of ICDP*(Cc,Rlc,Pi l ) from the
c
86
first plan moment P0l to plan moment Pbl , which is the last plan moment of customer Cc
c c
before the next plan moment P1r in the NIMIS. For plan moments P1r and beyond, the
ICDP(Cc, Rr, Ppr) is calculated by adding the demand specified in ICDP*(Cc, Rlc, Ppl )
c
from plan moment Pal to plan moment Pbl . Pal is the first plan moment of customer Cc,
c c c
coinciding with or some time after plan moment Ppr in the NIMIS. Pbl is the last plan
c
moment of customer Cc before the next plan moment Pp+1r in the NIMIS.
3.3.2 Networked organisation management properties

The second part of the networked organisation management design of NIMISs, is the
explanation of their properties related to networked organisation management. The
properties result from the networked organisation management model, which specifies the
position of the information systems in a network of organisations, the extra variables in
each information system that are needed for networked organisation management and the
equations that relate those supplementary variables. The resulting properties concern
functionality for configuration flexibility, timing flexibility and algorithm flexibility.
3.3.2.1 Configuration flexibility
configuration flexibility. To respect the autonomy of a networked organisation, the
information systems represent separate decision making units that are able to work
independently of other information systems in the network of organisations. Every NIMIS
in a network is an independent decision making unit for the management of its single SKU
stock-point, which could act independently of systems managing other parts of the
network. This decentralisation of decision making units ensures that the information
systems can reflect the structure of networked organisations, which are based on
decentralised management by nature. One aspect of configuration flexibility is that NIMISs
have the ability to constitute a configuration that fits a network of organisations. A second
aspect of configuration flexibility is that NIMISs are able to work independently of other
information systems used by networked organisations.
87
Organisation A Organisation B
BIS BIS
NIMIS S7 NIMIS C7
LRP
NIMIS S4 LRP
NIMIS C4
LRP
NIMIS S1 LRP
NIMIS C1
S7 C7
S4 C4
S1 C1
Location Location
Organisation D
BIS
LRP
NIMIS S5 LRP
NIMIS X2 LRP
NIMIS C5
LRP
NIMIS S2 LRP
NIMIS X1 LRP
NIMIS C2
S8 X3 C8
S5 X2 C5
S2 X1 C2
Organisation E Organisation F
BIS BIS
NIMIS S9 NIMIS C9
LRP
NIMIS S6 LRP
NIMIS C6
LRP
NIMIS S3 LRP
NIMIS C3
S9 C9
S6 C6
S3 C3
Location Location
Information flow
Goods flow

Figure 3-8 Configuration flexibility with respect to other NIMISs
88
Configuration flexibility includes the ability to create a configuration of NIMISs that covers
the integral inventory management across networked organisations. In particular, in a
dynamic network of organisations, a requirement is that a configuration of information
systems can easily be adapted to the frequently changing structure of networked
organisations. To obtain the configuration flexibility, a NIMIS works as an independent
decision making unit for the management of the inventory level for one single SKU stock-
point. As a NIMIS manages only the inventory level of one product type at one location, it
is an information system with extremely basic functionality and an extremely basic
architecture. To provide integral inventory management across networked organisations,
NIMISs co-operate with each other as loosely coupled systems in networks.
With the help of the different networks in Figure 3-6 and Figure 3-8, the property
of configuration flexibility with respect to other NIMISs is explained. The support of
configuration flexibility by the NIMISs, is the result of the loose coupling of these extremely
basic information systems. In both networks, there are seven locations in the domain of
five networked organisations. At each of the locations, three single SKU stock-points
reside. At the location in the middle of the network, stock-point X1 is managed by NIMIS
X1. All five networked organisations apply NIMISs for integral inventory management,
while they each make use of a Business Information System that supports other
management of their business processes.
Due to dynamics in the networked organisations, the network in Figure 3-6 could
change into the network in Figure 3-8. In the first network, NIMIS X1 is in the domain of
organisation C, while in the second network NIMIS X1 belongs to organisation D.
Organisation C in the first network has disappeared in the second network, in which
organisation F has emerged. In the first network, NIMIS X1 deals with three customers and
three suppliers at six different locations, whereas in the second network only one customer
and supplier are left for NIMIS X1. All visible supply chains in the first network go through
stock-point X1, while in the second network there are three independent supply chains,
only one crossing stock-point X1.
As there is no central system in a network of NIMISs, the decentralised systems co-
ordinate themselves by information exchange. The information exchange in a network is
limited to directly adjacent NIMISs. A NIMIS receives information from its immediate
customers and sends information to its immediate suppliers. There is no communication
between a NIMIS and systems further downstream or upstream in a network. Integral
inventory management according to BSC and LRP, is based on integral inventory levels and
final customer demand. Hence, a NIMIS should apparently receive inventory levels from all
downstream systems in the network and final customer demand from all systems dealing
with final customers. Depending on the complexity of network, this could result in
89
countless numbers of links between every NIMIS and all of its downstream systems. Instead
of these explosive numbers of information flows, a NIMIS just receives information from its
direct customers. This reduction in the number of system relations contributes to the
configuration flexibility in a network of NIMISs, since a change in the network structure
affects only a limited number of NIMISs.
The communication between NIMISs is limited to two standard information flows.
Only orders and plans are exchanged between adjacent systems in a network. From the
perspective of a receiving NIMIS, it receives Individual Customer Demand Orders (ICDOs)
and Plans (ICDPs) from its customers. From the perspective of a sending NIMIS, it sends
Individual Supplier Demand Orders (ISDOs) and Plans (ISDPs) to its suppliers. These two
information flows between the systems include all relevant information needed for integral
inventory management according to BSC, MRP/DRP or LRP across networked organisations.
The orders exchanged between NIMISs represent current and local demand, whereas plans
contain all additional information, concerning integral inventory levels for BSC or LRP, as
well as time-phased demand for MRP or LRP. In BSC, the plans reflect current integral
inventory. In MRP/DRP, the plans contain information on future demand. In LRP, the plans
cover combined information on current integral inventory and future demand. The
limitation of the information exchange to two standard flows, supports the configuration
flexibility of NIMISs, since a change of a network relationship affects only a couple of
information flows.
90
Organisation Organisation

LRP
NIMIS S5 LRP
NIMIS X2 LRP
NIMIS C5
LRP
NIMIS S2 LRP
NIMIS X1 LRP
NIMIS C2
BIS BIS
S8 X3 C8
S5 X2 C5
S2 X1 C2
Information flow
Goods flow

Figure 3-9 Configuration flexibility with respect to Business Information Systems
Configuration flexibility includes the ability of NIMISs to work independently of other

information systems used by networked organisations. Those customised legacy systems
and standard application systems undergo frequent changes, due to incremental system
updates or new software releases. The instability of the information systems makes them
unsuitable for integral inventory management across networked organisations. Especially
in a network of organisations, it becomes virtually impossible to develop and maintain
integration across a wide variety of continuously changing information systems. For that
reason, integral inventory management across networked organisations is pursued by
separate, standard and stable information systems. Therefore, NIMISs constitute decision
making units that can work independently of other information systems.
NIMISs work in the domain of networked organisations to achieve networked
inventory management. The information systems applied by a networked organisation for
other functions than networked inventory management, are represented as a Business
Information System (BIS). A BIS supports business functions other than the networked
inventory management, such as the management of purchase, production, distribution,
sales, finance, quality and human resources. The scope of integration of a BIS is limited to
the domain of one networked organisation, because it covers functions for which
91
integration across organisations in supply chains is not of vital importance. So, a BIS
provides very extensive functionality, but does not support integration across networked
organisations. Unlike a BIS, a NIMIS provides very limited functionality, but supports
integration across networks of organisations. In the relevant environment of a NIMIS, there
are customers, suppliers, an operational process and a strategist, but there is no BIS
required. Because of the independent operation of NIMISs and BISs, the integral inventory
management across networked organisations is not vulnerable to changes in the BISs.
In Figure 3-9 configuration flexibility with respect to Business Information Systems
is presented in an alternative way. The network represents supply chains across three
locations in the network of Figure 3-8. The two networked organisations apply NIMISs for
networked inventory management and each have a BIS for the management of other
business functions. Although NIMISs can work independently of BISs, useful relationships
between the systems could be established. A NIMIS needs to get information from the
operational process with the single SKU stock-point being managed, while it also gives
information to the operational process. A NIMIS sends Output Process Orders (OPOs) and
Input Process Orders (IPOs) to its operational process, whereas it receives Actual
Inventory (AI), Actual Demand (AD) and Actual Supply (AS) from the operational
process. Instead of direct information exchange between the NIMISs and the operational
processes, a BIS could be positioned as an intermediate system between the NIMISs and the
operational processes of a networked organisation. Then, the BIS behaves as a system for
information registration that retrieves, stores and forwards OPOs and IPOs from the NIMIS
to the operational processes, and that retrieves, stores and forwards the AI, AD and AS
from the operational processes to the NIMISs. Usually, the core competence of BISs is
registration of information, so NIMISs might well profit from their registration capabilities.
Besides interaction with the operational process, a NIMIS also needs to exchange
information with its strategist, a human being that controls the information system. As
part of the supervision, the strategist monitors and sets the system variables for networked
inventory management. The strategist creates the system and defines its name, which is
equal to the name of the single SKU stock-point. Further, the strategist determines the
parameters for networked inventory management, like the names of suppliers (Ss), the
review moments (Rr), the plan moments (Ppr), the Inventory Norm (IN), the Lot Size (LS),
the Lead Time (LT), the Explosion Factor (EF) List and Supplier Allocator (SA) List. The
BIS of a networked organisation could support the strategist in the management of these
system variables in NIMISs. Much of the information a NIMIS needs from the strategist is
usually registered in the BIS of a networked organisation. Moreover, a BIS is usually
equipped with some database management system that helps to maintain the integrity of
92
the information. So, a BIS can support NIMISs with the registration of correct, complete and
consistent information on system variables.
3.3.2.2 Timing flexibility
One of the functional requirements for NIMISs is their provision of functionality for timing
flexibility. To respect the autonomy of a networked organisation, the information systems
allow the use of own decision timetables, irrespective of decision timetables applied by
other systems in the network of organisations. Every NIMIS is able to use its own decision
timetable to manage its single SKU stock-point, irrespective of the timing principles used
by systems that manage other parts of the network. This decentralisation of decision
timetables relieves information systems in a networked organisation from the obligation of
performing synchronous management with other information systems in a network. One
aspect of timing flexibility is that the review moments in a NIMIS are allowed to differ from
review moments in other systems. A second aspect of timing flexibility is that NIMISs are
able to use plan moments which are different from plan moments encountered in other
systems.
93
BIS BIS
NIMIS S7 NIMIS C7
LRP
NIMIS S4 LRP
NIMIS C4
LRP
NIMIS S1 LRPC1
NIMIS
R r: R r:
2, 10, 18 5, 13, 21
S7 C7
S4 C4
S1 C1
Location Location
BIS BIS
LRP
NIMIS S5 LRP
NIMIS X2 LRP
NIMIS C5
LRP
NIMIS S2 LRP
NIMIS X1 LRP
NIMIS C2
R r: Rr: Rr:
1, 3, 9 10, 20, 30 5, 10, 15
S8 X3 C8
S5 X2 C5
S2 X1 C2
Organisation
BIS
NIMIS S9 NIMIS C9
LRP
NIMIS S6 LRP
NIMIS C6
LRP
NIMIS S3 LRP
NIMIS C3
R r: Rr:
5, 7, 15 7, 37, 67
S9 C9
S6 C6
S3 C3
Location Location
Information flow
Goods flow

Figure 3-10 Timing flexibility in review moments
94
Timing flexibility includes the use of different review moments across NIMISs. Review
moments are the points in time at which a NIMIS reviews the inventory level of its single
SKU stock-point by examination of current variable values and computation of new values.
At a review moment, a NIMIS processes customer plans, evaluates the inventory level, and
generates orders and plans for suppliers. A NIMIS makes use of its own review moments,
which can be determined independently of the review moments applied by systems of
customers and suppliers. The review moments can be set by the strategist as a pre-defined
series of points in time. Alternatively, the review moments could be the points in time at
which events occur that could trigger inventory management. Possible events are changes
in the actual inventory level due to demand or supply, and the receipt of new demand
plans from customers.
In Figure 3-10 the property of timing flexibility with respect to review moments is
presented for the same network as in Figure 3-6. The support of timing flexibility by the
NIMISs, is the result of the loose coupling of these extremely basic information systems.
NIMIS X1 deals with three customers and three suppliers at six different locations. Each of
the five networked organisations applies NIMISs for networked inventory management and
makes use of a Business Information System that supports the management of their
business processes. Because of the autonomy in timing, the review moments in a NIMIS
could differ from review moments in other systems in a network.
For NIMIS X1 in the network, review moment R1 is at time 10, review moment R2 is
at time 20, and so on. NIMIS C1 applies other review moments, with R1 at time 5, R2 at
time 13, and R3 at time 21. Again, other review moments occur at NIMIS C2 and NIMIS C3.
Also NIMIS S1, S2 and S3 have their own specific review moments, different from the
timing in NIMIS X1. In NIMIS C1, C2 and C3, the intervals between the review moments are
constant and equal to 8, 5 and 30 time units respectively. However, in NIMIS S1, S2 and S3,
the intervals between review moments are not constant. In NIMIS S1 and NIMIS S3 they
alternate between 2 and 8 time units, whereas in NIMIS S2 they have other variations.
Due to the autonomy in the timing applied by customers, a NIMIS receives orders
and plans from customers at review moments that may be different from the review
moments of the NIMIS. In addition, the review moments between the customers could be
different. A NIMIS deals with asynchronous review moments by focusing on the last review
moments of its customers as noticed in the NIMIS. In the network, NIMIS C1, C2 and C3 are
customers from the perspective of NIMIS X1. At time 20 (R2), NIMIS X1 reviews its inventory
level with the help of the last plans received from its customers. From NIMIS C1, its last
Individual Customer Demand Order (ICDO) and Plan (ICDP) were received at time 13
(its R2), while NIMIS C2 sent its last ICDO and ICDP at time 20 (its R4) and NIMIS C3 at
time 7 (its R3).
95
The last orders received from the customer systems were processed immediately by
NIMIS X1 at the time of receipt. At time 20 (R2), NIMIS X1 uses the last ICDPs received from
customers to evaluate its inventory level and to compute Individual Supplier Demand
Orders (ISDOs) and Plans (ISDPs). So, NIMIS X1 uses the ICDP received from NIMIS C1 at
time 13, the ICDP received from NIMIS C2 at time 20 and the ICDP received from NIMIS C3
at time 7. The plan received from NIMIS C2 at time 15 was not used, because an updated
plan was received from NIMIS C2 at time 20. The plan received from NIMIS C3 at time 7 will
be used by NIMIS X1 at time 20 (R2) for a second time, as no new plan has been received
since the previous moment R1 at time 10. The plan will even be used by NIMIS X1 for a
third time at time 30 (R3), because NIMIS C3 will not send a new plan before time 37.
96
Table 3-16 Timing flexibility in plan moments
NIMIS Variable Review Time

moment
NIMIS X1 ICDP List R4 40
Customer Review Time

moment
NIMIS C1 R5 37
Plan P05 P15 P25 P35 P45 P55 P65
moment
ICDP* Time 37 45 53 61 69 77 85
Demand 0 1000 2000 3000 4000 3000 2000
Plan P04 P14 P24 P34 P44 P54 P64
moment
ICDP Time 40 50 60 70 80 90 100
Demand 1000 2000 7000 3000 (2000) — —

moment
NIMIS C2 R7 35
Plan P07 P17 P27 P37 P47 P57 P67
moment
ICDP* Time 35 40 45 50 55 60 65
Demand 0 4000 3000 2000 1000 2000 3000
Plan P04 P14 P24 P34 P44 P54 P64
moment
ICDP Time 40 50 60 70 80 90 100
Demand 7000 3000 (5000) — — — —

moment
NIMIS C3 R2 37
Plan P02 P12 P22 P32 P42 P52 P62
moment
ICDP* Time 37 67 97 127 157 187 217
Demand 0 3000 3000 2000 2000 1000 1000
Plan P04 P14 P24 P34 P44 P54 P64
moment
ICDP Time 40 50 60 70 80 90 100
Demand 0 0 3000 0 0 3000 0
Timing flexibility includes the application of different plan moments across NIMISs. Plan
moments are the points in time included in plans to specify expected amounts of products.
At a review moment, for each plan moment the expected values of the corresponding
variables in the plan are computed. Similarly to the review moments, the plan moments in
97
a NIMIS can be set independently of plan moments used in other systems. A NIMIS makes
use of its own plan moments, which can be determined independently of the plan moments
applied by customers and suppliers. For every review moment, the plan moments can be
pre-defined by the strategist as future points in time. Alternatively, the plan moments
could be the points in time at which demand or supply is expected. The events concerning
demand are included in the plans received from customers, while the supply related events
can be derived from the plans sent to suppliers.
In Table 3-16 timing flexibility in plan moments is presented. As indicated in the
first block of the table, the illustration considers an Individual Customer Demand Plan
(ICDP) List in NIMIS X1 as being present at time 40 (R4), containing plans received from
its customers NIMIS C1, NIMIS C2 and NIMIS C3. The second block of the table shows the
original Individual Customer Demand Plan* (ICDP*) received from NIMIS C1 at time 37
(its R5) and the translated Individual Customer Demand Plan (ICDP). The ICDP* and
ICDP contain expected demand values per plan moment. Because of their independence,
the plan moments in the ICDP* from NIMIS C1 are different from the plan moments in the
ICDP as applied by NIMIS X1. Plan moment P15 for NIMIS C1 is at time 45, whereas P14 for
NIMIS X1 is at time 50, and so on. In the third and fourth block of the table, similar
asynchrony in plan moments occurs in the plans received from NIMIS C2 and NIMIS C3 at
times 35 and 37 respectively.
A NIMIS applies allocation of plan moments to deal with the differences between its
own plan moments and the plan moments of customers. The demand values at the plan
moments in the translated ICDPs in a NIMIS are derived by allocation of the demand
values in the original ICDP*s that were most recently received from customers. A NIMIS
using MRP/DRP or LRP allocates the future demand values from an original ICDP*, to plan
moments in the translated ICDP that are equal to or just before the plan moments in the
original ICDP*. The demand value for plan moment P0r in the ICDP, for either BSC,
MRP/DRP or LRP, is further based on the ICDP* for P0 .
r
At review moment R4 (time 40) in NIMIS X1, the ICDP* from NIMIS C1 at P05 (time
37) is allocated to the demand for P04 in the ICDP. Also, the demand for P15 (time 45) in
the ICDP* from NIMIS C1 is allocated to the demand for P04 (time 40) in the ICDP. The
demand for P04 in the ICDP represents a possible negative demand before P04, plus the
expected demand from P04 to P14. Demand for P25 (time 53) in the ICDP* from NIMIS C1 is
allocated to demand for P14 (time 50) in the ICDP, because allocation to P24 (time 60)
would cause late supply. Demand at time 60 in the ICDP is equal to demand at time 61
and 69 in the ICDP*, whereas demand at time 70 is derived from demand at time 77.
Demand at time 80 is estimated to be 2000, derived from demand at time 85. The brackets
in the table denote that the computation is based on incomplete information, since beyond
98
the plan horizon of the ICDP* of NIMIS C1, more demand may occur between time 85 and
90, so the outcome is a preliminary demand value only. Demand values for time 90 and
higher are left empty as no information has yet become available on those plan moments.
The translated ICDPs for NIMIS C2 and NIMIS C3 are completed with the help of
similar logic, using their original ICDP*s as input values. The translated ICDP for NIMIS
C2 at plan moment P0 (time 40) is equal to the demand for P0 to P2 in the ICDP*, since
4 7 7
plan moment P14 in NIMIS X1 is beyond those three plan moments in the ICDP* of NIMIS
C2. The translated ICDP for NIMIS C3 neglects the demand values in the ICDP* at P3
2
(time 127) and higher, because those are beyond the scope of the plan moments in the
ICDP. Although not illustrated, plan moments in NIMISs are allowed to change per review
moment. In addition, the plan horizons are both variable in the number of plan moments
as well as in the time of the last plan moment in a plan.
3.3.2.3 Algorithm flexibility
algorithm flexibility. To respect the autonomy of a networked organisation, the
information systems allow the use of own decision rules, irrespective of decision rules
applied by other systems in the network of organisations. Every NIMIS is allowed to use its
own decision rules to manage its single SKU stock-point, irrespective of the algorithms
used by systems that manage other parts of the network. This decentralisation of decision
rules relieves the information systems in a networked organisation of the obligation to
perform homogeneous management with other information systems in a network. One
aspect of algorithm flexibility is that the NIMISs are able to select either BSC, MRP/DRP or
LRP as their integral inventory management algorithm. A second aspect of algorithm
flexibility is that NIMISs are able to make transitions between any combination of BSC,
MRP/DRP or LRP as used in a network.
99
BIS BIS
NIMIS S7 NIMIS C7
LRP
NIMIS S4 LRP
NIMIS C4
LRP
NIMIS S1 LRP
NIMIS C1
LRP LRP
S7 C7
S4 C4
S1 C1
Location Location
BIS BIS
LRP
NIMIS S5 LRP
NIMIS X2 LRP
NIMIS C5
LRP
NIMIS S2 LRP
NIMIS X1 LRP
NIMIS C2
MRP/DRP LRP MRP/DRP
S8 X3 C8
S5 X2 C5
S2 X1 C2
Organisation
BIS
NIMIS S9 NIMIS C9
LRP
NIMIS S6 LRP
NIMIS C6
LRP
NIMIS S3 LRP
NIMIS C3
LRP BSC
S9 C9
S6 C6
S3 C3
Location Location
Information flow
Goods flow

Figure 3-11 Algorithm flexibility with algorithm selection
100
Algorithm flexibility includes the use of different integral inventory management

algorithms by a NIMIS. For the management of the inventory level of its single SKU stock-
point, a NIMIS can choose between Base Stock Control, Material/Distribution
Requirements Planning and Line Requirements Planning. The integral inventory
management algorithm applied in a NIMIS can be selected by setting the value of a system
parameter. Because BSC, MRP/DRP and LRP are all incorporated in a NIMIS, the inventory
management algorithm can be changed without introducing new information systems.
In Figure 3-11 the property of algorithm flexibility with algorithm selection is
presented for the same network as in Figure 3-6. The support of algorithm flexibility by
the NIMISs, is the result of the loose coupling of these extremely basic information systems.
NIMIS X1 deals with three customers and three suppliers at six different locations. All five
networked organisations apply NIMISs for networked inventory management and make use
of a Business Information System that supports the management of their business
processes. NIMIS X1 in the middle has selected LRP, while its customers and suppliers use
various algorithms for integral inventory management.
NIMIS C1 has selected LRP as its inventory management algorithm. As a
consequence, it sends Individual Customer Demand Orders (ICDOs) to NIMIS X1,
specifying current and local demand, as well as Individual Customer Demand Plans
(ICDPs), containing information on the current integral inventory balance level and
demand for future plan moments. NIMIS C2 makes use of MRP/DRP, thus sends orders and
provides plans with information about expected demand for future plan moments. As
NIMIS C3 uses BSC, besides orders it sends plans to NIMIS X1, specifying the current integral
inventory balance level. NIMIS X1 itself applies LRP, and thus forwards both orders and
plans to its suppliers, the latter revealing integral inventory balance levels and time-
phased demand for future plan moments. At the supplier side of NIMIS X1, NIMIS S1 has
selected LRP, NIMIS S2 applies MRP/DRP, while NIMIS S3 uses LRP.
The selection of algorithms per NIMIS can lead to different inventory management
per location. Each single SKU stock-point (SSS) might be managed by its own algorithm.
Because SSSs can reside at the same location, different inventory management algorithms
can be applied at one location. Also, some supply chains can be managed with a certain
algorithm, whereas another series of related stock-points is managed with a different
algorithm.
The use of different algorithms by different systems in a network, influences the
integral inventory management across the network. The actual scope of integration
achieved by a NIMIS for its single SKU stock-point, depends on the algorithms applied by
the systems downstream in the network. The scope of integration can be divided into
integration over place and integration over time. BSC integrates over place, MRP integrates
101
over time and LRP integrates over both place and time. The scope of integration over place
that can be achieved by a NIMIS in a supply chain ranges from its own stock-point up to
and excluding the first downstream system which does not apply BSC or LRP. The
maximum scope of integration over time for a NIMIS is limited by the first system
downstream not using MRP or LRP.
When a particular NIMIS itself applies LRP and all downstream systems apply LRP,
the NIMIS could realise integration over both time and place in the downstream network,
from final customers to its single SKU stock-point. However, when all systems downstream
apply BSC instead of LRP, no integration over time is established downstream. Hence, the
scope of integration over time, for the particular LRP NIMIS, is limited to its own stock-
point. However, the scope of integration over place in the LRP NIMIS ranges from the final
customers to its own stock-point. Similarly, when all downstream systems apply MRP, no
integration over place is realised downstream. Then, the LRP NIMIS can only integrate over
place for its own stock-point. Nevertheless, the scope of integration over time in the LRP
NIMIS can extend from final customers to its own stock-point.
102
Table 3-17 Algorithm flexibility with algorithm transition
Customer
(NIMIS C1, NIMIS C2, NIMIS C3)
Algorithm SIC BSC MRP/DRP LRP
Addition Translation Translation Translation

of plan value of plan value of plan value of plan value
BSC for P0r for P0r for P0r for P0r
+ +
Removal Removal
of plan values of plan values
after P0r after P0r
of plan values of plan value of plan values of plan values
NIMIS MRP/DRP for all for P0r
plan moments +
(NIMIS X1) Addition
of plan
values after P0r
of plan values of plan value of plan values of plan values
LRP for all for P0r
plan moments +
Addition
of plan values
after P0r
Algorithm flexibility includes the transitions between any combination of BSC, MRP/DRP
and LRP by a NIMIS. A NIMIS uses algorithm transition to cope with systems using
algorithms for integral inventory management that differ from its own algorithm. The
algorithm transition involves adaptation of information received by a NIMIS from other
systems. A NIMIS receives Individual Customer Demand Orders* (ICDO*s) and Plans*
(ICDP*s) from its customer. Irrespective of the algorithm used by the customers, the
103
ICDO*s can directly be used in a NIMIS without transition, because all orders provide
basically the same information on current and local demand. Algorithm transition is
needed for the ICDP*s received from customers, because the information in the plans is
dependent on the algorithms used by the customers.
Algorithm transition in a NIMIS represents the adaptation of information in the
original ICDP*s from customers, to information in translated ICDPs that can be processed
by the algorithm applied in the NIMIS. A NIMIS uses algorithm transition to make
transitions between either BSC, MRP/DRP, LRP or Statistical Inventory Control (SIC) as
applied by its customers, and the algorithm applied by the NIMIS itself. SIC is included
because some customers might apply non-integral inventory management. Algorithm
transition works on the ICDP*s received from customers and includes the translation of
relevant information, the removal of unnecessary information, the addition of missing
information and the manipulation of inaccurate information. The translation and removal
of information can be accomplished by a NIMIS automatically. The addition and
manipulation of information in a NIMIS needs to be done manually by the strategist
supervising the NIMIS.
The property of algorithm flexibility with algorithm transition is presented in Table
3-17. The possible integral inventory management algorithms of a NIMIS, are shown in the
two left most columns: BSC, MRP/DRP or LRP. The algorithms that may be applied by the
customers of a NIMIS, are shown in the first two rows: SIC, BSC, MRP/DRP or LRP. The other
cells in the table represent transitions between algorithms in a NIMIS. In the case of a
transition between similar algorithms, only translation of plan values is needed. In
transition from BSC to BSC, from MRP/DRP to MRP/DRP and from LRP to LRP, the Individual
Customer Demand Plans* (ICDP*s) received from the customers are of the same type as
the ICDPs applied in the NIMIS, except for their specific review moments and plan
moments.
Transition from SIC to BSC requires the addition of the expected integral inventory
balance at the one and only plan moment P0r in BSC. Transition from SIC to MRP/DRP
requires the addition of expected demand for all future plan moments applied in MRP/DRP.
Transition from SIC to LRP also requires the addition of expected demand for all plan
moments applied in LRP, where the demand value at plan moment P0r represents the
estimated integral inventory balance.
Transition from BSC to MRP/DRP requires translation of the demand value at plan
moment P0r as well as the addition of expected demand values for plan moment P1r and
beyond. When the demand value for plan moment P0r obtained from BSC is negative, more
inventory is available downstream than needed. Transition from BSC to LRP is similar to
transition from BSC to MRP/DRP. In the translation from the original ICDP* of BSC to the
104
ICDP for LRP, a negative demand value at plan moment P0r increases the inventory
position.
Transition from MRP/DRP to BSC is based on translation of the demand value in the
ICDP* at plan moment P0r to a demand value at plan moment P0r in the ICDP. The
demand for plan moment P0r in MRP/DRP is equal to zero by definition, and is interpreted
by BSC as a neutral integral inventory balance level. Further, the transition from MRP/DRP
to BSC involves removal of the demand values from MRP/DRP which are beyond plan
moment P0r. Besides translation of plan values, the transition from MRP/DRP to LRP does
not require further manipulation. The demand for plan moment P0r in MRP/DRP is equal to
zero by definition, and is interpreted by LRP as a neutral integral inventory balance level.
Transition from LRP to BSC encompasses translation of the LRP demand value in the
ICDP* at plan moment P0r to the BSC demand value for plan moment P0r in the ICDP. In
the transition from LRP to BSC, demand values in the ICDP* beyond plan moment P0r are
removed. Transition from LRP to MRP/DRP requires the translation of plan values. The
demand value at plan moment P0r in the ICDP for MRP/DRP, is equal to the demand value
at P0r in the ICDP* of LRP, plus the demand values in the ICDP* of LRP for which the plan
moment is before P1r in the ICDP of MRP/DRP. In this way, the ICDP for MRP/DRP can
compensate for extra demand or for a downstream inventory surplus at plan moment P0r.
3.4 Conclusion
The networked inventory management design constitutes the functional design NIMISs.
The functional design consists of an integral inventory management design and a
networked organisation management design.
The integral inventory management design is based on one NIMIS per single SKU
(Stock Keeping Unit) stock-point, holding inventory for one product type at one location.
Thus, a NIMIS is an information system with extremely basic functionality and an
extremely basic architecture. These extremely basic information systems are loosely
coupled to one another in networks, in order to support integral inventory management.
Every system is equipped with system variables and equations, reflecting related
information on a strategist supervising the system, customers, suppliers, the operational
process including the stock-point, and the inventory itself.
The integral inventory management design satisfies the functional requirements of
Base Stock Control (BSC), Material/Distribution Requirements Planning (MRP/DRP) and
Line Requirements Planning (LRP). With the help of the system variables and system
equations in a network of NIMISs, integral inventory management can be accomplished
according to one of these algorithms. These properties comprise integration in the time
105
dimension as well as in the place dimension, by using extra information on time-phased

demand or integral inventory. The integration, as required for integral inventory
management, and as provided by NIMISs, is the result of loose coupling of extremely basic
information systems.
In the networked organisation management design, the scope of a NIMIS is equated
to the system scope in the integral inventory management design. A NIMIS manages just
one single SKU stock-point in the domain of a networked organisation, which uses a
Business Information System for business functions other than networked inventory
management. These extremely basic information systems are loosely coupled to one
another in networks, in order to support networked organisation management. For
achieving networked organisation management, some supplementary system variables and
equations are included in the NIMISs.
The networked organisation management design satisfies the functional
requirements of configuration flexibility, timing flexibility and algorithm flexibility.
Configuration flexibility is based on creating different networks of NIMISs, which can
operate independently of Business Information Systems. Timing flexibility is achieved by
coping with different review moments and plan moments in NIMISs. Algorithm flexibility
encompasses algorithm selection in a NIMIS and algorithm transition across NIMISs. These
properties allow autonomy of networked organisations with respect to the place of
management, the timing of management and the type of management. The flexibility, as
required for networked organisation management, and as provided by NIMISs, is just like
the integration the result of loose coupling of extremely basic information systems.
106
Chapter 4 Case study implementation
4. Case study implementation
4.1 Introduction
In this chapter, a functional implementation of the information systems in a particular
environment of logistics management is explained. The inputs for the case study
implementation are the networked inventory management design (Chapter 3), and
implicitly the prototype system implementation (Chapter 7). The outputs of the case study
implementation are a description of a functional system environment and a demonstration
of the application of the information systems in the particular environment of logistics
management.
In section 4.2, the logistics management in a real-life network of supply chains is
described. Both the current situation and a future scenario of the case are addressed.
Section 4.3 is devoted to the application of NIMISs for networked inventory management in
the case. After an explanation of the application of the systems in supply chains, the
possible relationship of NIMISs to existing Business Information Systems is discussed.
4.2 Logistics management

A case study has been conducted in order to show how the networked inventory
management design of the information systems fits into a particular environment of
logistics management. The case study concerns a network of supply chains for cordless
telephones and has been carried out in two projects. One addressed the improvement of
supply chain management [Rijen, 1994] [Verwijmeren, 1994a] and the other one focused
on the application of NIMISs [Grinsven, 1997].
107
Case study implementation Chapter 4
Initially, the logistics management in the current situation is discussed. Attention is

paid to the physical processes and the organisations in the supply chains. The currently
applied inventory management and information systems are also taken into account.
Secondly, a future scenario of the case is given, describing how the supply chains will
probably be like in a few years time. The future scenario is based on currently observed
trends that influence the organisations and processes in the supply chains.
4.2.1 Current situation

The case study concerns a network of supply chains in the manufacturing and distribution
of cordless telephones from component acquisition to points of sales. A cordless telephone
set consists of a hand-held device and a base station. The base station is connected to a
fixed telephone line in a building, while the hand-held device is used to make wireless
phone calls in and around a house, an office or other premises. Typical components of a
cordless telephone are: sender and receiver units, plastic casings, antennas, a microphone,
a speaker, a battery and a power adapter.
The product family of cordless telephones under study, consists of about 13 product
groups. Common characteristics of a product group are shape, functionality, frequency
(low or high) and signalling (analogous or digital) of the cordless telephones. Within each
product group there are several product types. A shared characteristic of a product type is
its colour. Altogether, there are about 40 types of cordless telephones (CTs), here called CT
1 to CT 40. The total volume of cordless telephones through the studied supply chains is
some hundred thousands of products a year. Selling prices for final customers range from
about 80 to 250 Euro per cordless telephone. The average product life-cycle of a product
type is about 18 months.
108
Manufacturer 1 KPN Telecom
Suppliers
Customers
Components Finished products
in Hong Kong in Hong Kong Consumer outlet 1
in The Netherlands
Warehouse in
Suppliers The Netherlands

in France in France
Customers
Manufacturer 2
Consumer outlet m
in The Netherlands
Distribution
Suppliers centre in
The Netherlands
in Hong Kong in Hong Kong
Manufacturer 3 Customers
Telesales outlet
Suppliers in The Netherlands

in Japan in Japan
Manufacturer 4
Customers
Suppliers
Business outlet 1
in The Netherlands
in Germany in Germany
Manufacturer 5
Suppliers Customers
Components Finished products Business outlet n

in Germany in Germany in The Netherlands
Goods flow Single SKU stock-point Organisation
Figure 4-1 Supply chains for cordless telephones in the current situation
In Figure 4-1 the supply chains for the cordless telephones are shown as they are in the
current situation. Six organisations participate in the supply chains for the manufacturing
and distribution of the cordless telephones. KPN Telecom is a telecommunications service
provider that has its home market in The Netherlands. The company not only provides
services, but is also a retailer of telecommunications related equipment in both consumer
and business markets. KPN Telecom distributes cordless telephones and sells the products
through several types of sales outlets in The Netherlands. There are over 110 sales outlets
for serving the consumer market and over 25 outlets for sales to the business market.
Customers buy their products in the sales outlets off the shelf. Besides the consumer
outlets and the business outlets, KPN Telecom operates a telesales outlet for distant
109
ordering by customers and delivery to their addresses. For the supply to the sales outlets,
KPN Telecom makes use of a distribution centre, also based in The Netherlands.
The cordless telephones are supplied to KPN Telecom by five manufacturers. These
suppliers make final products for KPN Telecom and other distributors. The manufacturers
assemble cordless telephones from components, which they acquire from component
suppliers. Manufacturer 1 produces both in Hong Kong and in France. This company
distributes its cordless telephones to KPN Telecom via a warehouse in The Netherlands.
Manufacturer 2, located in Hong Kong, is the major supplier for KPN Telecom, both in
number and value of the products supplied. Sales to KPN Telecom form roughly a quarter
of the turnover of Manufacturer 2, while KPN Telecom buys more than half of its sales
volume in cordless telephones from Manufacturer 2. Manufacturer 3 is located in Japan,
whereas both Manufacturer 4 and 5 produce cordless telephones in Germany.
The supply chains for cordless telephones consists of many single SKU stock-points
(SSSs). In the supply chains, an SSS occurs for every product type stored at the different
locations where inventory is held. For example, product type CT1 at the manufacturing
location of Manufacturer 1 represents one SSS, whereas product type CT1 in consumer
outlet 37 is another SSS. The manufacturers have stock-points for their components and
finished products. For distribution to customers, Manufacturer 1 makes use of stock-points
in a warehouse in The Netherlands, where products made in Hong Kong or France come
together. In KPN Telecom’s distribution centre, there are about 40 stock-points that hold
inventory for the 40 types of cordless telephones. Also, every consumer outlet and business
outlet has stock-points for CT1 to CT 40. Moreover, their is a separate location with stock-
points for the telesales channel. Within the organisational boundaries of KPN Telecom
alone, there are more than five thousand single SKU stock-points for cordless telephones,
spread out over more than one hundred locations.
110
KPN Telecom
Forecasts
WinBes CM
‘SIC’
Orders
Orders
Master Customers
plans Central
WinBes CM Consumer outlet 1
in The Netherlands
Orders
Spreadsheet Orders WinBes CM

‘DRP’ ‘SIC’
Orders
Framework
contract
Customers
Consumer outlet m
Manufacturer 2 in The Netherlands
Orders
GBS UNAS TSA
Orders BIS ‘SIC’ ‘SIC’
Orders Orders Orders
Suppliers Customers
Components Finished products Distribution centre Telesales outlet

in Hong Kong in Hong Kong in The Netherlands in The Netherlands
Orders WinBes BM
‘SIC’
Orders
Orders
Customers
Central
WinBes BM Business outlet 1
in The Netherlands
Orders
WinBes BM
‘SIC’
Orders
Customers
Human interface
Business outlet n
in The Netherlands
Information flow
Goods flow BIS Business Information System Organisation
Figure 4-2 Logistics management in the current situation
In Figure 4-2 the logistics management in the current situation is presented. The
illustration is limited to the supply chains for product types supplied by Manufacturer 2
and sold by KPN Telecom, although the principles also apply to the other supply chains.
For the inventory management in the supply chains for cordless telephones, various types
of systems are applied. In the consumer outlets, the inventory is managed with the help of
111
WinBes CM systems. Every outlet registers its sales, inventory and replenishment orders in
its local WinBes CM system. The inventory management algorithm is a type of Statistical
Inventory Control (SIC). Depending on the size of a consumer outlet, the inventory level at
the stock-points is reviewed once or twice a week. When the inventory level at a review
moment is below its re-order level, a replenishment order is generated. In the afternoon of
a review day, orders are forwarded in batches from the consumer outlets to the Central
WinBes CM system. During the night, this central system sends the collected orders from
the different consumer outlets to the GBS system. If sufficient inventory is available in KPN
Telecom’s distribution centre, the ordered products arrive in the consumer outlets two
working days after the review moment.
The inventory management in the business outlets is done in a similar way. They
make use of slightly different WinBes BM systems, which are connected to a Central
WinBes BM. The review frequency in the SIC based systems of the business outlets is twice
weekly. Orders are uploaded in batches from the local WinBes BM systems to the Central
WinBes BM, that forwards the orders from different business outlets to the GBS system. The
lead time for orders from the business outlets is also two working days.
In the telesales outlet, the TSA system and UNAS system are used for inventory
management. Telephone operators in call centres take customer orders and put them in the
TSA system. Five times a day, customer orders are forwarded from the TSA system, via a
conversion database, to the UNAS system. The received customer orders are used for
picking the products from the stock-points. The ordered products are delivered to the
customers one or two days after the ordering. The UNAS system manages the inventory in
the telesales channel according to SIC based decision rules. Inventory replenishment orders
are read from the UNAS system by a system operator and manually keyed in to the GBS
system.
The GBS system is used for the operational inventory management in KPN Telecom’s
distribution centre. The GBS system receives replenishment orders from the Central
WinBes CM system, the Central WinBes BM system and the UNAS system. The orders are
picked the day after they were received and are shipped to the consumer outlets, business
outlets and telesales channel the next day. In the GBS system, the inventory levels of the
stock-points in the central distribution centre are registered. Based on SIC, suggestions for
purchase orders are generated to replenish the inventory in the distribution centre. The
purchase orders are manually sent to the manufacturers of the cordless telephones. The
actual purchase orders must be within the restrictions of framework contracts that are
agreed upon with suppliers. For this purpose the GBS system receives planning information
112
from a spreadsheet system. The lead times for the purchase orders is two to three months
for most product types.
The GBS system is a central and procedural information system that was introduced
at KPN Telecom in 1985 for integral logistics management within its distribution network
[Weegen, 1989]. At that time, the network also consisted of regional distribution centres
between the central distribution centre and sales outlets. Originally, the GBS system was
meant for integral inventory management according to DRP in the entire distribution
network. However, in the current situation its most important function is registration of
distribution orders, inventories and purchase orders in KPN Telecom’s remaining central
distribution centre. The inventory management by the GBS system is now limited to SIC
based control of the stock-points in the distribution centre. Reasons not to use DRP were
the elimination of the regional distribution centres and the homogeneity of the distribution
channels, both reducing the complexity of inventory management. Other arguments were
the difficulties to forecast demand per individual SKU, in combination with the presence of
rather centralised commercial units which could forecast demand at an aggregate level.
For the inventory management at a tactical level, KPN Telecom uses a spreadsheet
system. In the spreadsheets, decision rules similar to DRP are implemented to manage the
stock-points in the distribution centre in a time-phased manner. A commercial product
manager discusses with a logistics planner the sales forecasts per product group per
month. The discussion of the forecasts leads to master plans that contain monthly demand
per product group. The master plans, as well as the available inventory in the distribution
centre, are inputs for the spreadsheet system. With the help of the spreadsheet system, a
planner makes a framework contract, specifying the expected monthly demand for every
product group for the coming months. The first months in the framework contract specify
a quantity that can no longer be changed anymore. For the next months, there is some
flexibility, expressed in an allowed percentage change, whereas the quantities in the last
months can be adjusted without limitations. Every month, an updated framework contract
is faxed by the planner to the manufacturers. With the help of the spreadsheet system, the
planner makes also a weekly planning per product type. This planning is used in the GBS
system to generate purchase orders that are consistent with the framework contracts.
The manufacturers have a diversity of own systems in place for inventory management. At
KPN Telecom, little is known about the decision rules and information systems used by its
suppliers. For logistics management, Manufacturer 2 makes use of a its own particular
Business Information System. Manufacturer 2 receives a framework contract from KPN
Telecom every month. This time-phased information per product group is used, amongst
others, for the ordering of crystal components at a supplier in Japan and for the purchase
113
of plastic materials. The in-house moulding of plastic casings and the assembly of
components into final products is also guided by the framework contact. Shipment of
cordless telephones from the stock-points in Hong Kong is based on purchase orders from
KPN Telecom that specify demand per product type. The different product types are
grouped into full container loads. Containers from Manufacturer 2 to KPN Telecom’s
distribution centre are transported by sea, taking approximately one month. The other
manufacturers have their own methods of logistics management and their own systems for
inventory management.
4.2.2 Future scenario

The current situation of the supply chains for cordless telephones is being influenced by
developments in the business. Based on the currently observed trends, a future scenario of
the case is described. The future scenario shows what the supply chains will probably be
like within a few years, as a result of the expected changes. KPN Telecom operates in a
telecommunications market which is more and more open to global competition. In the
sales of telecommunications equipment to residential and business customers, fierce
competition is being experienced and still more is anticipated.
Customers will require a better price-quality ratio of cordless telephones from KPN
Telecom, as well as a more dynamic product assortment. If these requirements are not
completely satisfied, to the level required by the customers, those customers will probably
choose other suppliers of cordless telephones who offer better deals. To consolidate its
market share under these circumstances, KPN Telecom wants to further improve its
business performance. This requires an increase of the productivity by reducing costs and
improving quality. In addition, the flexibility needs to be increased, which includes the
offering of a more frequently changing assortment of cordless telephones. Supply chain
management is regarded as one of the directions to achieve higher productivity and greater
flexibility. In particular, networked inventory management could have a positive impact
on the performance of the supply chains.
114
Networked inventory management
Manufacturer 1 KPN Telecom
Suppliers
Customers
in Hong Kong in Hong Kong Consumer outlet 1
in The Netherlands
Warehouse in The
Suppliers Netherlands

in France in France
Customers
Manufacturer 2 Consumer outlet m

in The Netherlands
Distribution
Suppliers centre in
The Netherlands
in Hong Kong in Hong Kong
Manufacturer 3 Customers
Telesales outlet
Suppliers in The Netherlands

in Japan in Japan
Manufacturer 4
Customers
Suppliers
Business outlet 1
in The Netherlands
in Germany in Germany
Manufacturer 5
Suppliers Customers
Components Finished products Business outlet n

in Germany in Germany in The Netherlands
Manufacturer 101 Dealer 1001
Suppliers Customers
Components Finished products Consumer outlet

in The Netherlands in The Netherlands in Europe
Suppliers Customers
Components Finished products Business outlet

in the USA in the USA in Europe
Goods flow Single SKU stock-point Networked organisation
Figure 4-3 Supply chains for cordless telephones in a future scenario
115
In Figure 4-3 the supply chains for cordless telephones in a future scenario are presented.
When compared to the current situation, it is expected that new organisations will
participate in the supply chains, both at the side of manufacturers and at the side of sales
outlets. Given the customers’ need to choose from a more dynamic product assortment, it
is expected that KPN Telecom will update its portfolio of cordless telephones more
frequently. It is likely that for this new portfolio, more manufacturers will be needed, each
specialised in a limited number of product types that represent the state of the art.
Moreover, KPN Telecom will not be able to serve all targeted customers through its own
sales outlets. Therefore, new dealers will enter the supply chains that sell cordless
telephones under the label of KPN Telecom. Those new dealers will not buy all their
products exclusively from KPN Telecom, but will also directly acquire products from
manufacturers. This means that new relationships with new players in the network will
arise.
Networked organisation management is becoming increasingly important in the
supply chains of KPN Telecom, its suppliers and its dealers, because the network of
customers and suppliers is expected to change more frequently, due to shorter product life-
cycles for a more dynamic product assortment. It is likely that the organisations will grow
towards networked organisations in order to achieve the required flexibility. Networked
organisations are organisations with their own strategic control units, that co-operate with
other organisations to gain mutual benefits. These type of organisations are able to create a
network of organisations with customers and suppliers, at low cost and in a short time. For
the organisations in the supply chains, operating as networked organisations is a way to
increase the ability to adapt to changing circumstances, without concessions to
productivity. Supply chains through these networks emerge for the marketing,
development, manufacturing and distribution of a product type. After the lifetime of the
product type, the network disappears and will soon be replaced by new supply chains for
new product types. Because networked organisation management can improve the
flexibility of the supply chains, it will be a key competence in the future scenario.
When compared to the current situation, it is also expected that the supply chains for
cordless telephones will be managed in a more integral way. Given the need of customers
to buy products with the best price-quality ratio available in the market, logistics
performance will have to be excellent. The required quality with respect to logistics is
customer service, expressed as the availability of cordless telephones off the shelf. The
availability of products will have to be almost a hundred percent, meaning that inventory
shortage will be virtually prohibited. The allowed prices of products relate to logistics
costs, which are partly due to holding inventory. The costs of holding temporarily excess
116
inventory and having permanently obsolete inventory will have to become negligible. The
foreseen supply chain management will have a scope of integration from sales outlets back
to manufacturers and beyond. To improve the logistics performance in the supply chains,
further integration of the logistics management across the organisations is needed.
Integral inventory management will become a policy issue in the supply chains for
cordless telephones, since the performance of the supply chains has to increase to satisfy
customers who require high quality for the lowest price possible. Integral inventory
management concerns the co-ordinated planning, control and monitoring of inventory
levels in stock-points throughout supply chains. It is likely that the organisations in the
supply chains will further improve the integration of their inventory management systems
to cope with productivity requirements. The required productivity improvement comes
from customers, and is propagated by KPN Telecom and other dealers to the upstream
distribution and manufacturing stages in the supply chains. For the organisations in the
supply chains, integral inventory management is a way to reduce costs related to holding
excess inventory and to increase revenues related to having products available for
customer service. Integral inventory management is based on reduction of uncertainties in
decision making processes, so that besides so-called desired and required inventory, less
extra inventory will be needed to compensate for uncertainties. Uncertainties are reduced
by exchange of information between the links of the supply chains. Because integral
inventory management can improve productivity, it will be a key competence in the future
scenario, together with networked organisation management.
4.3 System application

In order to show how the networked inventory management design fits into a particular
environment of logistics management, the application of NIMISs in the future scenario of
the case is demonstrated. First, the application of NIMISs for achieving networked
inventory management in the supply chains of cordless telephones is shown. The
information systems have not actually been implemented in the real-life situation, so the
case study only addresses the possible application of the systems. Next, the application of
the NIMISs in relation to currently used Business Information Systems in the supply chains
is discussed. NIMISs can co-operate with existing information systems in the organisations
to arrive at integral inventory management across the networked organisations.
117
4.3.1 Application of NIMISs

From the observed developments in the supply chains of cordless telephones, it is deduced
that in the future scenario, both networked organisation management and integral
inventory management are desirable for improving the productivity and flexibility of the
supply chains. This requires the availability of information systems which support integral
inventory management across networked organisations. However, the information systems
in the supply chains that are currently used for logistics management, are not geared to
provide functionality for networked inventory management.
Most systems in the supply chains of cordless telephones are not sufficiently
suitable for integral inventory management, because they do not support management of
time-phased inventory levels as needed for MRP/DRP or LRP. Moreover, none of the systems
has facilities to manage integral inventory levels as needed for BSC and LRP. It would take
quite a development effort to include the required functionality for integral inventory
management in all of the systems in the supply chains. Because of the heterogeneity of the
available information systems, every type of system would need customised adjustments to
add functionality for BSC, MRP/DRP and LRP. Even when all information systems internally
had the required functionality, it would be an enormous job to establish relationships
between these heterogeneous systems. For every relationship between two particular
system types, a dedicated interface would need to be developed.
The systems in the supply chains of cordless telephones do not have special
facilities for networked organisation management, as they mostly miss configuration
flexibility, timing flexibility and algorithm flexibility. To cover integral inventory
management across the networks of organisations with changing system configurations,
with different timing principles and with various algorithms, a prohibitive number of
dedicated interfaces between the heterogeneous systems would be needed. As the network
of organisations often changes, dedicated interfaces would need to be developed endlessly
to cope with systems in new networks. Even in a temporarily static network of
organisations, the dedicated interfaces would require intensive maintenance, because the
information systems face frequent changes due to incremental system updates and new
software releases. The dynamics of the networked organisations and the instability of their
information systems make it practically unfeasible to develop and maintain networked
inventory management using the existing systems in the supply chains.
118

KPN Telecom
NIMIS
Customers
Consumer outlet 1
in The Netherlands
NIMIS
Customers
Consumer outlet m
in The Netherlands
Manufacturer 2
NIMIS NIMIS NIMIS NIMIS
Suppliers Customers

NIMIS
Customers
Business outlet 1
in The Netherlands
NIMIS
Customers
Business outlet n
in The Netherlands
NIMIS NIMIS NIMIS
Suppliers Customers
Components Finished products Business outlet

in the USA in the USA in Europe
Goods flow Information flow Networked organisation
Figure 4-4 Networked inventory management by NIMISs
119
For the future scenario of the supply chains for cordless telephones, integral inventory
management across the networked organisations can hardly be achieved by the systems
currently applied for logistics management. Therefore, networked inventory management
in the supply chains is pursued by the application of NIMISs. In Figure 4-4 the possible
application of NIMISs for networked inventory management is presented for a limited
number of supply chains, although the principles also apply to the other supply chains.
The network includes the product types which are supplied by Manufacturer 2 in
Hongkong and Manufacturer 102, and which are sold by KPN Telecom and Dealer 1002.
For the purpose of networked inventory management in the supply chains, a NIMIS
is applied for every single SKU stock-point that holds inventory for cordless telephones. A
NIMIS manages only the inventory level of one product type at one location, so it is an
Loose coupling of these extremely basic information systems enables them to support
integral inventory management and, at the same time, networked organisation
management. Thus, by co-operation in a network, NIMISs can provide networked inventory
management.
The application of NIMISs in the supply chains provides functionality for integral inventory
management according to Base Stock Control (BSC), Material/Distribution Requirements
Planning (DRP/MRP) and Line Requirements Planning (LRP). These properties comprise
integration in the time dimension as well as in the place dimension, by using extra
information on time-phased demand or integral inventory. The integration, as required for
integral inventory management, and as provided by NIMISs, is the result of loose coupling
of extremely basic information systems. When every single SKU stock-point in the supply
chains is equipped with a NIMIS, the information systems together can manage the
inventory levels of the stock-points according to one of the available algorithms. The
condition for the overall achievement of integral inventory management, according to
either BSC, MRP/DRP or LRP, is that all NIMISs in the network apply the same type of
algorithm.
When BSC is selected in all NIMISs, information on current final customer demand
and downstream inventory is used at all single SKU stock-points to manage their integral
inventory levels in an instantaneous way. The integral inventory level for a particular
stock-point is the inventory on hand and on order at the stock-point, plus the inventory on
hand in and in transit between all downstream stock-points. When MRP/DRP is selected in
all systems, information on expected demand is used to manage the local inventory levels
of the stock-points in a time-phased manner. By selection of LRP in all systems,
information on expected final customer demand and current downstream inventory is used
120
to manage the integral inventory levels of the stock-points in a time-phased way. The
expected final customer demand represents the estimated demand for future plan moments
in the sales outlets.
Every NIMIS in the supply chains is controlled by a strategist, who sets and monitors
system variables. For integral inventory management according to BSC, MRP/DRP or LRP,
the strategists have to select the same algorithm. The NIMISs achieve co-ordinated
planning, control and monitoring of the inventory levels of the single SKU stock-points by
exchange of information across the systems, combined with information exchange between
the NIMISs and the stock-points. Individual Customer Demand Orders (ICDOs) and Plans
(ICDPs) go from downstream NIMISs in the supply chains to adjacent upstream
information systems. Actual Inventory (AI), Actual Demand (AD) and Actual Supply (AS)
go from the stock-points to the NIMISs, while Input Process Orders (IPOs) and Output
Process Orders (OPOs) are outputs of NIMISs that are forwarded to the operational
processes, each including a single SKU stock-point.
The application of NIMISs in the supply chains for cordless telephones provides
functionality for networked organisation management, including configuration flexibility,
timing flexibility and algorithm flexibility. These properties allow autonomy of networked
organisations with respect to the place of management, the time of management and the
type of management. The flexibility, as required for networked organisation management,
and as provided by NIMISs, is the result of loose coupling of extremely basic information
systems.
Configuration flexibility means that the NIMISs represent separate decision making
units that are able to work independently of other information systems in the network of
organisations. Because a NIMIS manages just the inventory level of one single SKU stock-
point, a fitting configuration of NIMISs can be created for any particular network of
organisations. For every single SKU stock-point belonging to KPN Telecom, Dealer 1002,
Manufacturer 2 and Manufacturer 102, a NIMIS is installed to cover the supply chains. The
decentralised systems co-ordinate themselves by exchange of information, without the help
of a central system for the whole network. The NIMISs can work independently of other
information systems in the supply chains for cordless telephones. This makes them less
vulnerable to frequent changes in the available systems for logistics management. The
systems such as WinBes CM, WinBes BM, UNAS and GBS can change without harming the
integral inventory management across the networked organisations.
The application of NIMISs also provides timing flexibility in the supply chains of
cordless telephones, which implies that the information systems are allowed to use their
own decision timetables, irrespective of the decision timetables applied by other systems in
121
the network of organisations. The review moments and plan moments applied by a NIMIS
may differ from the review moments and plan moments applied by other systems in the
network of supply chains. The review interval in KPN Telecom’s consumer outlets can be
one hour, while in the business outlets, the review interval could be two hours and in the
telesales outlet, it might be four hours. The NIMISs in KPN Telecom’s distribution centre
might manage on a daily basis. Manufacturer 2 could apply daily review of its inventory
level of finished products, whereas crystal components are reviewed every week and
plastic components once a month. Similarly to the review moments, the plan moments in
the NIMISs are allowed to differ per system in the network.
The application of NIMISs provides algorithm flexibility in the supply chains, which
indicates that NIMISs can make use of their own decision rules, irrespective of decision
rules applied by other systems in the network of organisations. The integral inventory
management algorithm applied by a NIMIS may differ from algorithms applied elsewhere
in the network. The strategist controlling a NIMIS can select either to BSC, MRP/DRP or LRP
as the integral inventory management algorithm for the single SKU stock-point being
managed. NIMISs in the supply chains for cordless telephones are able to make transitions
between any combination of BSC, MRP/DRP or LRP. For algorithm transition, information is
translated and removed automatically by the system, and information is added and
manipulated manually by the strategist. In the sales outlets, BSC could be applied, while
LRP may be used in the KPN Telecom’s distribution centre. Manufacturer 2 might manage
its finished products according to LRP and use MRP for its components. Because the LRP
NIMIS in KPN Telecom’s distribution centre needs information on time-phased demand,
the strategist of the LRP NIMIS has to add demand forecasts to the plans received from the
BSC NIMISs in the sales outlets.
4.3.2 NIMISs and Business Information Systems

In the future scenario of the case study, NIMISs could achieve networked inventory
management in coexistence with the Business Information Systems (BISs) currently
applied in the supply chains for cordless telephones. A BIS represents the cluster of
existing information systems used by a networked organisation for functions other than
networked inventory management. KPN Telecom’s BIS consists, amongst others, of the
WinBes CM, WinBes BM, TSA, UNAS and GBS system. The heterogeneity and instability of
the BISs makes them unsuitable for integral inventory management across networked
organisations. Because the NIMISs are separate, standard and stable systems, they can
provide the integration and flexibility needed for networked inventory management in the
supply chains. The NIMISs in the supply chains for cordless telephones may not be
hindered by the BISs at the manufacturers, KPN Telecom and the dealers. Therefore, the
122
NIMISs can work independently of the BISs of the networked organisations. However, useful
relationships can be created between the BISs and NIMISs, without threatening the
integration and flexibility of the information systems for networked inventory
management.
123

KPN Telecom
NIMIS
WinBes CM
Orders
Customers
Consumer outlet 1
in The Netherlands
NIMIS
WinBes CM
Orders
Customers
Consumer outlet m
in The Netherlands
Manufacturer 2
NIMIS NIMIS NIMIS NIMIS
BIS GBS UNAS TSA

Orders
Suppliers Customers

NIMIS
WinBes BM
Orders
Customers
Business outlet 1
in The Netherlands
NIMIS
WinBes BM
Manufacturer 102 Orders
NIMIS NIMIS Customers
Business outlet n
BIS in The Netherlands
Dealer 1002
Suppliers
NIMIS
in the USA in the USA
Point of sale system
Orders
Human interface
Customers
Information flow BIS Business Information System
Business outlet
Goods flow Networked organisation in Europe
Figure 4-5 NIMISs and Business Information Systems
124
In Figure 4-5 it is shown how NIMISs could achieve networked inventory management in
the supply chains of cordless telephones, in coexistence with the Business Information
Systems. NIMISs can profit from loose coupling to the currently applied BISs without
sacrificing the integration and flexibility needed for networked inventory management.
The NIMISs in the supply chains of cordless telephones can be considered as a layer of
information systems for integral inventory management across the networked
organisations, which is conceptually abstracted from the Business Information Systems. A
NIMIS needs to exchange information with its operational process and its strategist. Instead
of direct interaction with the strategist and the operational process, a NIMIS can use the BIS
of the networked organisation as an intermediate. The functionality for integral inventory
management and networked organisation management is concentrated in the NIMISs,
whereas the BIS facilitates the information exchange with the operational process and the
strategist.
To support networked inventory management by NIMISs, the Business Information
Systems can be used for information registration and data management. The available BISs
in the supply chains for cordless telephones all have capabilities to register the inventory,
demand, supply and orders for operational processes. At a review moment, a NIMIS needs
information on the status of the single SKU stock-point being managed. A BIS registers the
Actual Inventory (AI), Actual Demand (AD) and Actual Supply (AS) of the stock-points of
a networked organisation. So, a NIMIS can retrieve this information from the BIS instead of
the operational process. A NIMIS needs to communicate Input Process Orders (IPOs) and
Output Process Orders (OPOs) to its operational process. Instead of direct interaction, this
information can be forwarded to the Business Information System of the networked
organisation. Then, an operational process receives the orders for its stock-point from the
BIS.
A Business Information System can also support a NIMIS in its interaction with the
strategist, who sets and monitors the systems values of the NIMIS. The strategist creates a
NIMIS, defines its name and sets the parameters for networked inventory management.
These parameters include the names of suppliers (Ss), the review moments (Rr), the plan
moments (Ppr), the Inventory Norm (IN), the Lot Size (LS), the Lead Time (LT), the
Explosion Factor (EF) List and Supplier Allocator (SA) List. Much of this information is
registered in the BISs, so the strategist could retrieve this information from the BIS and put
it into the NIMIS. Most of the BISs in the supply chains of cordless telephones have built-in
database management systems. So, a BIS not only supports NIMISs by basic registration of
information, but it can also help to maintain the integrity of the data used by the NIMISs in
a networked organisation.
125
4.4 Conclusion
The case study implementation shows how the networked inventory management design of
NIMISs fits into a particular environment of logistics management.
Logistics management in the case study concerns a network of supply chains for
manufacturing and distribution of cordless telephones. In the current situation, five
manufacturers in various countries supply KPN Telecom with cordless telephones. KPN
Telecom sells the products through more than one hundred sales outlets in The
Netherlands to customers in the consumer market and in the business market.
A future scenario shows what the supply chains for cordless telephones will
probably be like within a few years, as a result of expected changes. To consolidate market
share at a time of fierce competition, KPN Telecom wants to further improve its business
performance. It is expected that the network of organisations in the supply chains will
expand and change more frequently, while at the same time the supply chains will be
managed in a more integral way.
With the help of networked organisation management the flexibility of the supply
chains can be increased, while integral inventory management can improve the
productivity. However, it is practically unfeasible to develop and maintain the desirable
networked inventory management with the existing information systems in the supply
chains for cordless telephones. The heterogeneity and instability of the currently applied
systems would require a prohibitive number of dedicated interfaces.
Networked inventory management can be achieved by application of a NIMIS for
every single SKU stock-point that holds inventory for cordless telephones. Loose coupling
enables these extremely basic information systems to support integral inventory
management and, at the same time, networked organisation management. By co-operation
in a network, NIMISs can provide BSC, MRP/DRP and LRP, in combination with
configuration flexibility, timing flexibility and algorithm flexibility.
NIMISs could achieve networked inventory management in coexistence with the
Business Information Systems currently applied in the supply chains for cordless
telephones. To support networked inventory management by NIMISs, the existing Business
Information Systems can be used for information registration and data management.
126
Chapter 5 Computer network technology analysis
5. Computer network technology analysis
5.1 Introduction
In this chapter, computer network technology and related issues are analysed. The inputs
for the computer network technology analysis are the research objective and method
(Chapter 1), while implicit input comes from the supply chain management analysis
(Chapter 2). The outputs of the computer network technology analysis are observations in
the technical system environment and technical requirements for the information systems
studied.
In section 5.2, issues in computer network technology are analysed. After a
discussion on computer network technology, distributed system technology and object-
oriented system technology are explained. In section 5.3, technical system requirements
for the information systems are specified. The requirements related to distributed system
technology are followed by the requirements related to object-oriented system technology.
5.2 Issues in computer network technology

Information technology is a very broad technology and research area, in which computer
network technology covers the part that focuses on computer systems that are
interconnected through communication networks. Currently, much attention is paid to
computer network technology, because co-operation of computer systems through
communication networks offers opportunities to further increase technical capabilities
after stand-alone computers have been exploited.
127
Computer network technology analysis Chapter 5
One of the promising fields for improvement of system capabilities is distributed

system technology. The co-operation of computer systems at different locations, as
encountered in distributed systems, can increase the quality and flexibility of information
processing. In addition, object-oriented system technology is an important driver for better
capabilities of information systems. Object-oriented systems are based on self-contained
components that reflect real-world entities, which enables them to cope rather easily with
the growing dynamics in information processing.
The issues in computer network technology that are studied further, are illustrated
in Figure 5-1, with references to the sections where they are discussed. Computer network
technology (CNT) encompasses aspects of distributed system technology (DST) and object-
oriented system technology (OST). Distributed object technology (DOT) is a concept at the
intersection of distributed system technology and object-oriented system technology.
Information technology
Computer network technology

5.2.1
DST: DOT: OST:

Distributed Distributed Object-orien-
system object ted system
technology technology technology
(5.2.2) (5.3) (5.2.3)
Figure 5-1 Issues in computer network technology
5.2.1 Computer network technology

Computer systems which are interconnected through communication networks make up
computer networks. Computer network technology concerns the integration of computers
and telecommunication infrastructures, creating a world-wide web of computer networks
[Harasim, 1993]. Computer networks can range from local area networks at one site to
128
wide area networks that span local area networks at different sites. Figure 5-2 illustrates
world-wide computer networks that are made up, amongst others, of desk-top computers,
servers, databases and communication networks. Conceptually, the computer networks are
built of system components for transformation, storage and transportation of information.
129
Figure 5-2 World-wide computer networks
In this era, an unprecedented progress in computer network technology is being made.

Due to fundamental innovations in electronics in the past decades, the power of computer
components has increased dramatically. The information transformation capacity of
microprocessors shows exponential growth, as the number of transistors per chip doubles
approximately every eighteen months [Clemens, 1997]. This phenomenon is known as
Moore’s Law, and it is likely to hold true for at least the coming decade [Yu, 1996]. In
addition, the information storage capacity of memory chips has increased from a few kilo
bits, to many mega bits in today’s memory chips [Rowe, 1995]. Moreover, the information
transportation capacity of communication networks is increasing fast. The bandwidth of
copper based networks of two decades ago, ranged from several kilo bits to several mega
bits per second, while nowadays fibre based local and wide area networks can provide a
bandwidth up to giga bits per second using Asynchronous Transfer Mode (ATM)
[Klovning, 1997].
The availability of powerful computer components and their integration in
computer networks, have resulted in computer networks with high performance
computing, high capacity storage and high bandwidth communication. Components with
growing capabilities are integrated in computers, so a system can accomplish more
complex functions or provide functions at higher performance. Moreover, those evolving
computers are becoming more and more integrated into networks that can be extended
almost endlessly to obtain the required capabilities. Computers are integrated over
130
communications networks, which themselves are largely built of dedicated computer

components for switching, multiplexing and transmission.
During the evolution of computer network technology several architectures have
been dominant for some time. Computer networking began with the connection of
terminals to a mainframe computer [Halsall, 1992]. In such a host-terminal network, a
single system image is preserved [Ovum, 1995]. Thereafter, stand-alone computers
became integrated in local area networks, interconnecting computers at one location. In
the following integration stage, local computer networks at different sites were integrated
in wide area networks. Nowadays, millions of dispersed computers have access to one
another through Internet, leading to a situation in which the network can be considered as
a giant computer. Ultimately, the integration of computers in networks could evolve into a
virtual mainframe, in which the integrated computer components provide a single system
image again, like in the traditional mainframe environment.
The advances in computer network technology give rise to new opportunities for
information processing. Due to the integration of advanced components in computers and
advanced computers in networks, there are less restrictions for information processing
with respect to available capacity. Because computing, storage and transmission capacity
is continuously making progress, the optimisation of information processing can shift from
technical efficiency towards functional effectiveness. In the first generations of computer
network technology, applications were designed in such a way that the information
processing required minimum technical resources. Desired functionality had to be
sacrificed to optimise the efficiency of applications. In the recent history, the programming
of years in four digits was regarded as a waste of capacity. As a result, society is now
suffering from the so-called millennium problem.
In advanced computer network technology, applications can be designed to fully
meet the desired functionality, since ample capacity is, or could be made, available to
achieve optimal effectiveness of the applications. From the perspective of an almost
unlimited information processing capacity, advanced applications heavily consume
processor time, memory space and bandwidth. Because computer network technology is
growing beyond traditional technical limitations, the major challenge becomes the creation
of useful applications. In the long run, the functionality and performance of the world-
wide web of computer networks seems mainly to be limited by the creativity of mankind in
conceiving new applications, and the willingness of people to heavily invest in computer
network technology [Rowe, 1995].
New applications of computer networks may emerge in areas where it was
previously not justifiable, feasible or imaginable. Applications launched in the last decade
131
are: video conferencing, remote gaming, home shopping, virtual reality, concurrent
engineering, tracking & tracing, point-of-sale systems and all other types of Internet
applications. The electronic highway is no longer an abstract vision, since nowadays
millions of people and organisations use modern information and communication
technology, utilise multimedia services, surf the World Wide Web (WWW), install
corporate Intranets, interconnect their systems via Electronic Data Interchange (EDI) and
regulate their processes through Work Flow Management (WFM) systems. The current
Internet is a long way from being the ultimate electronic highway, but it is the closest
approximation there is today [Gates, 1995].
New computer network technology has a significant impact on the way business is
organised. Computer networks become the nervous systems of companies, by which they
reach customers, employees, suppliers and other stakeholders. Computer network
technology makes it possible to achieve co-ordination and autonomy at the same time
[Ericsson, 1995]. Large organisations can decentralise their decision making and
distribute their activities over the world, while small organisations can establish co-
operative relations to offer customers composite products or services. So, the application of
computer networks supports the rise of networked organisations which are linked by an
electronic network. Advanced technology enables organisations to operate flexibly as a
unit, regardless of their locations, exchanging information between dissimilar computer
systems, amongst others about inventory levels and delivery schedules [Upton, 1996].
The business reconfiguration induced by computer network technology is an
evolutionary process, which can divided in five stages: localised exploitation, internal
integration, business process redesign, business network redesign and business scope
redefinition [Scott Morton, 1991] [Venkatraman, 1994]. Each stage represents a further
degree of business transformation and offers a greater range of potential benefits. Supply
chain management is an application area of computer network technology in the stage of
business network redesign, which is concerned with the reconfiguration of the business
network involved in the creation and delivery of products and services. This stage requires
electronic integration of activities, both within and across organisations involved in a
business network. Electronic integration enables a quasi-hierarchy or quasi-market
mechanism for co-ordination of activities in a business network by exchange of
information. The information exchange in electronic integration may reflect transactions,
inventory status, process details and eventually expertise [Scott Morton, 1991]
[Venkatraman, 1994].
132
5.2.2 Distributed system technology

One of the areas in computer network technology that drives the improvement of
information processing is distributed system technology. A distributed system is a group of
autonomous computers, each consisting of processing and storage elements, which are
interconnected through a communication network in order to provide integrated functions
[Umar, 1993] [Khanna, 1994] [Simon, 1996]. They consist of independent, interacting
and geographically distributed functional entities for processing and storage of
information [Weger, 1994]. The technical information processes that are needed for the
integrated functions of a distributed system, run on several independent Central
Processing Units (CPUs) [Mullender, 1989]. These processors do not share main memory,
so that the information can not be transferred through global variables, but only through
messages over networks [Umar, 1993]. Because an application of a distributed system is
based on multiple processors, they have to work together reliably and coherently [Khanna,
1994].
Distributed systems have several characteristics in common: remoteness,
concurrency, lack of global state, partial failures and asynchrony [ITU/ISO, 1996].
Remoteness denotes that the components of a distributed system may be spread across a
space and that interactions may be either local or remote. Concurrency says that each
component of a distributed system can execute in parallel with other components. Lack of
global state means that the overall state of a distributed system can not be determined
precisely. Partial failures imply that any component of a distributed system may fail
independently of other components. Asynchrony indicates that communication and
processing activities are not driven by a single global clock and that related changes in a
distributed system can not be assumed to take place at a single instant.
For co-operative processing of information in distributed systems there are some

prototypical architectures: master-slave, client-server and peer-to-peer [Khanna, 1994]. In
a master-slave architecture, users interact with terminals which are connected to a central
mainframe system. These terminals do not have intelligence for information processing,
because the presentation logic, application logic and data management logic are fully
concentrated in the mainframe. In a client-server architecture, client systems are
connected to servers, which provide functionality to the clients on demand. Clients run at
least the presentation logic, and servers take care of at least the data management logic.
The application logic resides at the clients, or at the servers, or at both. In a peer-to-peer
architecture, all systems co-operate at an equal level of authority and change roles
depending on their needs. In a client role, a system can interact with a peer to ask for
functionality not available on its own system. In a server role, the same system may
133
provide functionality to the same peer if the peer lacks this functionality. Presentation
logic, application logic and data management logic can run on any system in varying
proportions.
Irrespective of the architecture of a distributed system, many reliable system
components at different locations, have to work together coherently to provide integrated
functions. Data communication networks and object-oriented computing are two main
enablers of distributed systems [Khanna, 1994]. During the last decades, the performance
and reliability of data communication networks has improved significantly. Data
communication networks have become a commonly available and reliable utility for
organisations. Object-oriented computing refers to engineering information systems in
self-contained and interacting components. Robust objects and high-level interfaces
between them can reduce the complexity of distributed systems.
Distributed system technology gives opportunities to extend capabilities of computer

networks. In particular, it could provide higher quality and efficiency in information
processing, as well as better control of the computing resources [Hordeski, 1989]. Given
the functionality required by users, distributed systems often can achieve integrated
information processing with a better quality, when compared to fully concentrated
computing in one monolithic system. Quality advantages of distributed systems, as they
may be perceived by users, address improvements in: performance, reliability, availability,
scalability, modularity and expandability [Coulouris, 1988] [Mullender, 1989]
[Nieuwenhuis, 1991] [Ang, 1994] [Franken, 1996] [Simon, 1996].
Distributed systems make it possible to achieve higher information processing
performance, because applications can be executed in parallel by different system parts.
Reliability is a measure of the continuous delivery of a proper service from an initial point
of time [Nieuwenhuis, 1991]. Reliability can be increased by applying redundancy in
system components, so if a fault occurs, no improper service is delivered. Availability is a
measure of the delivery of a proper service with respect to alternation of delivery of proper
and improper service [Nieuwenhuis, 1991]. Distributed systems can improve availability,
as redundancy in system components can secure that a fault in a component does not lead
to failure of the systems. Scalability means that a distributed system is prepared for
increase or decrease of the system size by adding or removing system components.
Distributed systems have a high degree of modularity, because they consist of independent
system components that interact through precisely specified interfaces. Expandability
refers to the ability of distributed systems to show incremental growth of capabilities, by
implementing new hardware or software components, step by step.
134
Besides the quality advantages of distributed systems, they could also offer a
possibility to decrease costs of information processing [Berson, 1992] [Khanna, 1994]. In
contrast to a central mainframe system, distributed systems are largely built of general
purpose workstations and personal computers. Focusing on procurement costs,
microprocessors in distributed systems usually offer a better price-performance ratio than
processors in mainframes. Although cost reductions can be expected in the procurement of
hardware, the costs of exploitation of distributed systems might exceed the exploitation
costs of central systems, because the management of distributed systems is more complex.
The total costs of ownership for distributed systems as compared to central mainframe
systems is still open to discussion.
From an application viewpoint, distributed system technology enables organisations to

innovate their way of conducting business, because it fulfils the need to achieve integrated
information processing as well as the need to have autonomy over local information.
Distributed system technology can support the integration of systems that are distributed
by nature, without taking away the autonomy of the local systems. In this way, distributed
system technology can contribute to the alignment between the structure of information
systems and the structure of organisations [Henderson, 1991] [Henderson, 1993] [Khanna,
1994].
Users of information systems are geographically distributed by nature, as is
information itself, since it belongs to processes at different locations [Mullender, 1989]
[Franken, 1996]. When compared to a central and monolithic system, a distributed system
can provide integration, while largely maintaining the autonomy of local systems and
users. Local information systems that process local information, give better control of
computing resources to local organisations and users [Hordeski, 1989] [Mullender, 1989].
Where a central system would replace local systems, distributed systems are built of local
systems, mainly under the control of local people and organisational units. By organising
their own information processing in their own local systems, organisations and users
become less dependent on information systems that are beyond their scope of control.
The need for integrated information processing across locations is increasing.
Organisations and people that previously operated in near isolation, start co-operating in
organisational networks, while hierarchical organisations are decentralising and become
loosely coupled entities. The sharing of information is particularly needed to improve co-
ordination in co-operating organisations which put emphasis on communication,
collaboration, and decentralised decision making [Mullender, 1989] [Khanna, 1994]
[ITU/ISO, 1996]. With the help of distributed system technology, local information systems
135
can be interconnected, so that information can be shared among users and organisational
units without threatening their autonomy [Coulouris, 1988] [Ang, 1994].
Given that organisations have local information systems by nature, and want them
for autonomy, interconnection of their autonomous computers through a communication
network can yield integrated functions by sharing information. So, distributed systems
often evolve from existing local information systems, when organisations want to integrate
the islands of information through communication networks [Mullender, 1989] [Weger,
1994]. The resulting distributed systems can be tightly coupled organisation-wide
information systems based on one computer platform, or can be loosely coupled inter-
organisational information systems based on Electronic Data Interchange (EDI) [Weger,
1994].
5.2.3 Object-oriented system technology

Object-oriented system technology is another area that drives the advances in computer
network technology. Object-oriented system technology is a relatively new way of
designing and implementing information systems [Meyer, 1988] [Coad, 1990] [Taylor,
1990] [Rumbaugh, 1991] [Martin, 1992] [Rohloff, 1993] [Booch, 1994] [Carmichael,
1994] [Taylor, 1995]. Instead of a procedural system that runs through a program from
begin to end and accesses common data, an object-oriented system is split up in separate
objects that invoke each other. Each object has its own explicit behaviour and its own set
of data, in contrast with conventional system engineering in which data structure and
behaviour are only loosely connected [Taylor, 1995]. The structuring of systems in self-
contained objects leads to flexible and maintainable systems, especially when the systems
are modelled around real-world entities. Each physical or logical real-world entity can be
represented by an object [Rumbaugh, 1991]. An information system then consists of a
collection of objects, representing concepts in the real-world which are relevant to the
system objective.
A generic definition of similar objects is called an object class, while a particular
occurrence of a single object is called an object instance [Rumbaugh, 1991]. With the help
of an object class, new instances can be created, which have structure and behaviour as
specified in the object class. The structure of objects is specified in its attributes, in which
data values can be stored. Those data stores are similar to variables in procedural systems,
except that they can contain references to other objects [Taylor, 1995]. The behaviour of
an object is captured in its operations, that allow an object to carry out actions. These
instructions are similar to procedures in procedural systems, except that they are defined
in the context of a specific class.
136
Whereas the operations and attributes of an object instance are defined by its object
class, the values of attributes are contained in object instances [Taylor, 1995]. Object
instances show behaviour by executing operations in response to received messages. An
objects instance can invoke an operation on itself or on another object instance by sending
a message. The message specifies the receiving object, names the desired operations and
adds any parameter values that may be required for the receiving object to fulfil the
request. The invoked object instance executes some operation as a reaction to the request
and may return a response to the sending object instance.
Often mentioned characteristics of object-oriented system technology are: abstraction,

identity, classification, inheritance and polymorphism [Rumbaugh, 1991] [Coad, 1990].
Abstraction refers to focusing on aspects of the system which are essential to its purpose
and ignoring its accidental properties. Identity indicates that all object instances can be
uniquely identified, even when some object instances have equal values for the same
attributes. Classification means that objects with the same structure and behaviour are
grouped into a class, describing a possibly infinite set of objects instances. Inheritance is
the sharing of structure and behaviour among classes based on an hierarchical
relationship, in which a subclass inherits all properties of its superclass and adds its own
unique properties. Encapsulation refers to information hiding by separating the external
aspects of an object, which are accessible to other objects, from the internal
implementation details of the object, which are hidden from other objects. Polymorphism
means that the same operation name may behave differently on different classes, as the
implementation of an operation is defined per class.
Construction of an object-oriented system consists of identifying the essential
objects and then connecting them through three types of relationships: specialisation,
collaboration and composition [Taylor, 1995]. Specialisation is the relationship between
superclasses and subclasses. A subclass inherits all of the operations and attributes of its
superclass. The layering of superclasses and subclasses, with the help of the specialisation
relationship, results in a class hierarchy. Collaboration is the relationship that represents
the interaction between objects due to invocation of operations. Objects invoke operations
on other objects by sending messages. Composition is the relationship between composite
objects and component objects. A composite objects contains several other objects, called
component objects.
Object-oriented system technology gives opportunities to enhance the capabilities of

computer networks. In particular, it may have advantages with respect to the development,
operation and maintenance of information systems [Taylor, 1990] [Carmichael, 1994]
137
[Meyer, 1995]. Given the required functionality of an information system, the potential
advantages of object-oriented system technology, when compared to conventional system
engineering, include shorter development times, better quality and less costs. Due to
proper modelling of real-world entities as objects, one object model can be used in all
system life-cycle stages and can be used to communicate between all parties involved. By
this means, the sequential development in conventional approaches can be replaced by
faster iterative system development, also known as rapid prototyping [Taylor, 1990].
Instead of passing all development phases once in a fixed order, the cyclic approach
includes a series of visits to the phases and so profits from early feedback from the parties
involved [Meyer, 1995].
The modelling of systems in objects that represent real-world entities, also
stimulates the creation of standard objects that can be reused [Meyer, 1995]. The speed of
system development can be increased by building a new system out of existing standard
objects. Due to natural modularization of object-oriented systems, the interactions among
components are reduced. The clear identification of objects as manageable parts supports
the handling of complexity in information systems. Because of this effective way of
organising information systems, it is easier to verify that components function correctly
[Taylor, 1990]. The faster development due to reuse, and the higher quality through
modularization, can both contribute to reduced costs of information systems that are based
on object-oriented system technology.
When compared to procedural system engineering, object-oriented system technology

provides opportunities to increase the flexibility of information systems. Flexibility
concerns the ability of systems to easily adjust their functionality to changing requirements
imposed by their environment. In functional decomposition, the primary conventional
system engineering approach, specific functions are obtained by breaking a problem down
into successively smaller units of functionality, until the level is reached where the
remaining tasks can be carried out by relatively short segments of instructions for the
computer [Taylor, 1995]. Functional decomposition ensures that unstable specific
functions are woven into the architecture of an information system, so it is very difficult to
change its functionality without completely restructuring the system [Taylor, 1995].
Hence, functional decomposition can not adequately cope with rapidly changing
requirements.
As opposed to conventional system engineering, in object-oriented system
technology the architecture of an information system is based on a stable model of the
domain which is supported by the system. By building a system around objects rather than
around functionality, the system is more resilient to change [Taylor, 1990] [Rumbaugh,
138
1991]. The objects in a system correspond to relatively stable real-world entities, while
also data and functions that logically belong together are concentrated in one object. When
new functions are required from an object-oriented system in a particular domain, the
system architecture is unlikely to become obsolete. A change of functionality usually just
requires the adaptation of some operations and attributes of existing objects. So, the
functionality of object-oriented information systems can be changed by local system
adjustments, without rebuilding the entire system [Taylor, 1990].
5.3 Distributed object technology requirements

When compared to central and procedural information systems, distributed object
technology provides opportunities to increase integration and flexibility of computer
networks. The analysis of distributed system technology indicates that it could extend the
integration of computer networks. Given that organisations have local information systems
by nature, and want them for autonomy, integrated functions can be obtained by
interconnecting local computers through a communication network. The analysis of
object-oriented system technology shows that it could improve the flexibility of computer
networks. By organising information processing in self-contained objects that reflect real-
world entities, information systems can more easily be adjusted to changes in their
environment.
Thus, distributed system technology and object-oriented system technology are two
supplementary directions for the improvement of information processing in computer
networks. Ideally, both issues in computer network technology should be exploited by
information systems for supply chain management. The combination of distributed system
technology (DST) and object-oriented system technology (OST) is called distributed object
technology (DOT) [EURESCOM, 1996] [Verwijmeren, 1997]. In Figure 5-3 the concurrent
exploitation of distributed system technology and object-oriented system technology is
illustrated.
139
Location I Location II
System C System Z
System B System Y
System A System X
Object a1 Object a1
Object a1 Object a1
Object a1 Object x1
Communication network
Figure 5-3 Distributed object technology
Central and procedural information systems can not simultaneously support the
integration as well as the flexibility of information processing, which is needed for supply
chain management in general, and for networked inventory management in particular. In
central systems, information processing can be integrated across locations in supply
chains, but then the different organisations do not have autonomy over their own
functionality and data. Procedural systems can provide integrated functions, but they lack
the flexibility to easily adapt functionality and data to changing conditions in supply
chains.
As opposed to central and procedural systems, distributed and object-oriented
information systems could provide integration and flexibility of information processing as
it is needed for supply chain management in general, and for networked inventory
management in particular. By interconnection of local systems in supply chains, integrated
functions may be achieved without sacrificing the autonomy of the organisational units in
supply chains. The organisation of information systems around objects, rather than around
functionality, can make the systems more resilient to changes in supply chains.
Currently, for supply chain management or networked inventory management, no

information systems appear to be available that fully exploit distributed object technology.
EDI based inter-organisational systems, which emerged from coupling local systems, as
well as commercially available Enterprise Resource Planning (ERP) systems, are still not
completely built of distributed objects.
140
Distributed system technology is to some extent, used by most ERP systems and EDI
based inter-organisational systems, as they consist of autonomous systems that are
interconnected through a communication network in order to provide integrated functions.
Multi-site ERP systems provide integrated functions, however, they miss full distribution
because parts of the functionality and data reside on a central server. EDI based inter-
organisational systems, which emerged from coupling local systems, may be fully
distributed, but they do not provide consistent logic for integrated functions. Because of
the integration possibilities in combination with to autonomy advantages, system vendors
have the intention to further incorporate distributed system technology in future systems
[Andersen, 1995] [Lierop, 1996] [Giesbers, 1997] [Ovum, 1997] [Coopers, 1998]
[Verwijmeren, 1998].
So far, object-oriented system technology has hardly been incorporated in
information systems for supply chain management. There still appear to be no systems for
supply chain management commercially available that totally consist of objects that invoke
operations on each other by sending messages. The design of existing systems is mainly
based on functional decomposition, while the implementation of most systems still heavily
relies on procedural programming. However, because of the flexibility advantages, system
vendors are increasingly incorporating object-oriented system technology in the design
and implementation of the next generation of systems [Andersen, 1995] [Lierop, 1996]
[Giesbers, 1997] [Ovum, 1997] [Coopers, 1998] [Verwijmeren, 1998].
141
Computer network technology
DST: DOT: OST:

Distributed Distributed Object-orien-
system object ted system
technology technology technology
Distributed object technology requirements
Distributed system technology: Object-oriented system technology:

• Local computing • Object classification
• Heterogeneous computing • Attribute encapsulation
• Transparent computing • Operation invocation
NIMIS
Figure 5-4 Distributed object technology requirements
Information systems for networked inventory management that fully exploit distributed
object technology are not yet commonly available, while those systems provide
opportunities to increase the integration and flexibility of information processing in supply
chains. Therefore, the feasibility of information systems for networked inventory
management using distributed object technology is studied. As shown in Figure 5-4,
distributed object technology (DOT) imposes technical requirements on the information
systems for networked inventory management which are being studied. Some technical
requirements for NIMISs relate to distributed system technology (DST), while the others
stem from object-oriented system technology (OST). The technical requirements for the
information systems are explained below.
142
5.3.1 Distributed system technology requirements

Conforming to the research objective, NIMISs need to exploit distributed object technology
(DOT), so the information systems have to include distributed system technology (DST). To
show the technical feasibility of distributed system technology in information systems for
networked inventory management, three relevant technical requirements related to
distributed system technology are imposed on the systems to be designed. These technical
requirements for NIMISs support their functionality for networked inventory management.
The NIMISs should include technology with:
1. Local computing
2. Heterogeneous computing
3. Transparent computing
Because of practical research limitations, these technical requirements do not represent an

exhaustive list of possible characteristics of distributed system technology. However, when
compared to central system technology, the requirements include major aspects of
distributed system technology, as they address integration and autonomy with respect to
locations, techniques and management of distributed information systems. Therefore,
these requirements might also provide insight into the feasibility of related characteristics
of distributed systems.
5.3.1.1 Local computing
Given the research objective to exploit distributed system technology, a first technical
requirement for the information systems is that they should use technology with local
computing. Local computing implies that information processing which is needed to
provide a particular function that logically belongs to a certain location, can physically be
executed by computer resources at the same location. So, functions for local purposes can
be accomplished by local resources, while functions performed for different locations can
be distributed over different computers.
Distributed systems consist of groups of autonomous computers, in which each
computer is a set of resources at one location for processing information to perform certain
functions. The information processing in a computer incorporates transformation of
information through one or more processors as well as storage of information in one or
more memories. Local computing can be done by standard computers which basically
provide local storage and transformation of information. A communication network can
interconnect the local computers which are involved in performing integrated functions.
143
Local computing can be useful for information systems providing functionality for
networked inventory management. Networked inventory management addresses the
management of inventory levels for stock-points at different locations and across different
organisations. Local computing allows this functionality to be achieved with the help of
local systems, that may each reside at the location of a stock-point or at any location in an
organisation. Local computing is a means for networked organisations to have autonomy
over their own functionality and data, while achieving integration for integral inventory
management across networked organisations by information exchange across local
systems.
5.3.1.2 Heterogeneous computing
Given the research objective to exploit distributed system technology, a second technical
requirement for the information systems is that they should use technology with
heterogeneous computing. Heterogeneous computing implies that information processing
can be executed at computers that are based on different types of techniques, with respect
to programming languages, operating systems and hardware components. So, one
computer in a distributed system can consist of a particular combination of techniques,
while another computer in the network can be built of a different set of techniques.
Every computer in a distributed system is equipped with a programming language,
an operating system and hardware components. The information processing in a computer
is dependent on its specific techniques, which need to co-operate with techniques of other
computers to provide integrated functions. Heterogeneous computing can be accomplished
by conversion between programming languages, operating systems and hardware of
different computers. Standard interface components can map techniques in one type of
system to the techniques in another type of system.
Heterogeneous computing can be useful for information systems providing
functionality for networked inventory management. Networked inventory management
concerns computers at different locations in different organisations. Using heterogeneous
computing, the systems at the different locations and organisations are allowed to use their
own combination of techniques. Heterogeneous computing is a means for the networked
organisations to have autonomy over their own techniques, while achieving integral
inventory management across networked organisations by standard interface components
bridging different techniques.
5.3.1.3 Transparent computing
Given the research objective to exploit distributed system technology, a third technical
requirement for the information systems is that they should use technology with
144
transparent computing. Transparent computing implies that technical complexities, due to

distribution of system components, are hidden from the application specific components in
distributed systems. This hiding of complexities concerns several types of transparencies,
amongst others, location transparency, transaction transparency and persistence
transparency [ITU/ISO, 1995] [ITU/ISO, 1996] [Leydekkers, 1997]. Location transparency
for example, means that system components can be addressed by functional and logical
names instead of their technical and physical locations.
Distributed systems are technically complex, as the system components of different
computers have to work together seamlessly to provide an integrated function. The co-
operation between the components requires the management of technical complexities
with respect to locations, transactions, persistence, and so on. Transparent computing can
be realised with the help of standard management components that are dedicated to the
management of technical complexities of distributed systems, so that these complexities
can be hidden from application specific components. For example, location transparency
can be accomplished by management components which are able to find the physical
location of a system component by its logical name.
Transparent computing can be useful for information systems providing
involves systems for integral inventory management, in different organisations and at
different locations. Due to transparent computing, networked organisations do not have to
be aware of the technical complexities in these distributed systems. Transparent
computing is a means for the networked organisations to have autonomy over their own
system management, while achieving integral inventory management across networked
organisations by standard management components managing technical complexities.
5.3.2 Object-oriented system technology requirements

Conforming to the research objective, NIMISs should exploit distributed object technology
(DOT), so the information systems have to include object-oriented system technology (OST).
To show the technical feasibility of object-oriented system technology in information
systems for networked inventory management, three relevant technical requirements
related to object-oriented system technology are imposed on the systems to be designed.
These technical requirements for NIMISs support their functionality for networked
inventory management. The NIMISs should include technology with:
1. Object classification
2. Attribute encapsulation
3. Operation invocation
145
Because of practical research limitations, these technical requirements do not represent an

exhaustive list of possible characteristics of object-oriented system technology.
However, when compared to procedural system technology, the requirements include the
most important aspects of object system technology, as they address flexibility with respect
to structure, data and functions of object-oriented information systems. Therefore, these
requirements might also provide insight into the feasibility of related characteristics of
object-oriented systems.
5.3.2.1 Object classification
Given the research objective to exploit object-oriented system technology, a fourth

technical requirement for the information systems is that they should use technology with
object classification. Object classification implies that an information system consists of
related objects which preferably represent real-world entities, and further implies that
objects in a system with similar structure and behaviour are defined in a class. So, a
system is organised around objects that each contain both data and functions of the object,
while a system executes by interaction between objects.
A class is an abstract definition of a set of particular object occurrences, having
structure and behaviour as described in the class. From a class, object instances can be
created, which represent particular object occurrences with the specific description of their
structure and behaviour. Object classification stands for abstraction of similar object
instances into an object class, whereas object instantiation is the creation of instances from
classes. For object classification, the components of the information systems need to have
abstract definitions described in object classes and specific descriptions in object instances.
Object classification can be useful for information systems providing functionality
for networked inventory management. Networked inventory management addresses the
organisations. Object classification allows this functionality to be achieved with the help of
self-contained components, that include functions together with the accompanying data.
Object classification is a means for networked organisations to remain flexible, because
the architecture of information systems can naturally reflect the structure of the networked
organisations and their integral inventory management.
5.3.2.2 Attribute encapsulation
Given the research objective to exploit object-oriented system technology, a fifth technical
requirement for the information systems is that they should use technology with attribute
encapsulation. Attribute encapsulation implies that the objects in an information system
146
each contain attributes that specify the data of the object, and further implies that the
attributes of an object are normally hidden from other objects. So, data values are stored in
the attributes of an object and the attributes are only accessible through explicitly allowed
behaviour for reading and writing attributes.
Object-oriented systems are organised around objects which have attributes that
contain the data belonging to the object. The names of the attributes are defined in object
classes, while the actual values of the attributes are stored in object instances. Attribute
encapsulation makes the data in an attribute private to the object owning the attribute,
while access is arranged by operations in the object. For attribute encapsulation, the
components of the information systems need to have a data structure which is specified in
attributes of object classes and data values which are stored in the derived attributes of
object instances.
Attribute encapsulation can be useful for information systems providing
addresses the management of inventory levels for stock-points at different locations and
across different organisations. Attribute encapsulation allows data about a stock-point or
organisation to be included in objects which also provide the functions for that stock-point
or organisation, so that system components can manage their own data in relation to their
functions. Attribute encapsulation is a means for networked organisations to remain
flexible, because the attributes in the information systems can naturally reflect the data in
networked organisations and their integral inventory management.
5.3.2.3 Operation invocation
Given the research objective to exploit object-oriented system technology, a sixth technical
requirement for the information systems is that they should use technology with operation
invocation. Operation invocation implies that the objects in an information system each
contain operations that specify the functions of the object, and further implies that the
operations of an object are invoked by itself or by other objects. So, functions are
performed by the operations of an object, and an operation is executed in response to a
message received from an object requiring the operation to be executed.
Object-oriented systems are organised around objects which have operations that
specify the functions belonging to the object. An operation enables an object to perform a
function through execution of instructions, in response to a message. The instructions of
an operation are specified in the object class, while object instances just include the names
of operations. Operation invocation makes the function of an operation public to other
objects, which can invoke the operation by sending a message to the object containing the
147
operation. In response to the receipt of a message, an object executes the instructions

belonging to the invoked operation.
Operation invocation can be useful for information systems providing functionality
for networked inventory management. Networked inventory management addresses the
organisations. Operation invocation allows functions for a stock-point or organisation to
be included in objects which also contain the data of that stock-point or organisation, so
that system components can manage their own functions in relation to their data.
Operation invocation is a means for networked organisations to remain flexible, because
the operations in the information systems can naturally reflect the functions in networked
5.4 Conclusion
Computer network technology concerns the integration of computers and
telecommunication networks, creating a world-wide web of computer networks. This
enables new ways of information processing and of organising business, as optimisation
can shift towards functional effectiveness, and business networks can be reconfigured with
the help of electronic integration. Important issues in computer network technology are
distributed system technology and object-oriented system technology.
Distributed system technology regards technology for groups of autonomous
computers, each consisting of processing and storage elements, which are interconnected
through a communication network in order to provide integrated functions. Distributed
system technology is a means to achieve integration across locations while respecting the
need of organisations to have autonomy over their own information processing.
Object-oriented system technology is about designing and implementing
information systems as a set of objects that invoke each other. An object represents a real-
world entity and contains functions as well as associated data. Object-oriented system
technology can increase the flexibility of information systems. As systems are based on
stable real-world entities, instead of unstable functions, their functionality can be changed
by local adjustments.
The combination of distributed system technology and object-oriented system
technology is called distributed object technology. Currently, no information systems for
supply chain management appear to be available that fully exploit distributed and object-
oriented system technology. This induces technical requirements for new information
systems for networked inventory management (NIMISs).
148
Technical requirements related to distributed system technology are the use of

technology with: local computing, heterogeneous computing and transparent computing.
The information processing may be executed by computers at different locations, the
computers might be equipped with different techniques and the technical complexities of a
distributed system are hidden from the application specific components. These
requirements allow networked organisations to achieve integration across locations, while
preserving autonomy over their own functions and data, the techniques of their systems
and the management of technical complexities.
Technical requirements related to object-oriented system technology are the use of:
object classification, attribute encapsulation and operation invocation. The information
systems consist of objects, which include both functions and associated data. Data is stored
in attributes which are hidden from other objects, and functions are performed by
operations, in response to the receipt of messages. These requirements allow the
information systems to naturally reflect the structure, data and functions of networked
149
Chapter 6 Distributed object technology design
6. Distributed object technology design
6.1 Introduction
In this chapter, a technical design of the information systems for networked inventory
management is specified, in which distributed object technology is exploited. The inputs
for the distributed object technology design are the technical requirements from the
computer network technology analysis (Chapter 5), and implicitly the networked inventory
management design (Chapter 3). The outputs of the distributed object technology design
are a model that specifies NIMISs and an explanation of the technical properties of the
In section 6.2, the object-oriented system technology design of the information
systems is specified, representing one part of the distributed object technology design. The
object-oriented system technology design includes a model of NIMISs as well as an
explanation of their properties related to object-oriented system technology. The
distributed system technology design of the information systems, the other part of the
distributed object technology design, is specified in section 6.3. There, the distributed
system technology of the information systems is modelled and their properties related to
distributed system technology are explained.
6.2 Object-oriented system technology design

As part of the technical design of the information systems for networked inventory
management, using distributed object technology, an object-oriented system technology
design is specified. The object-oriented system technology (OST) design must be consistent
151
Distributed object technology design Chapter 6
with the distributed system technology (DST) design. Together, these two designs specify
the overall distributed object technology (DOT) design of NIMISs in this study. To conform
to the technical requirements with respect to object-oriented system technology, the
information systems must use technology with object classification, attribute encapsulation
and operation invocation.
The object-oriented system technology design does not specify all technical details
of NIMISs. Instead, it mainly specifies the information systems from the information
viewpoint, as distinguished in the reference model for Open Distributed Processing (ODP)
[ITU/ISO, 1995] [ITU/ISO, 1996] [Leydekkers, 1997]. For specification of distributed and
object-oriented systems, the ODP reference model identifies five viewpoints, ranging from
extremely functional to extremely technical: enterprise, information, computational,
engineering and technology viewpoint. Roughly speaking, the enterprise viewpoint, which
is concerned with the business activities, is captured in the networked inventory
management design. The information viewpoint, concerned with the information being
processed, dominates in the object-oriented system technology design. The computational
viewpoint, which is concerned with the interfacing of distributed components, is dealt with
in the distributed system technology design. The engineering viewpoint, concerned with
the distribution mechanisms, and the technology viewpoint, concerned with the
implementation details, are hardly addressed in the distributed object technology design.
6.2.1 Object Modelling Technique

For the specification of the object-oriented system technology design, the Object Modelling
Technique (OMT) is applied [Rumbaugh, 1991] [Kerr, 1995]. OMT is one of the widely
known design methods for object-oriented information systems, from which many
fundamentals have been incorporated in the currently popular Unified Modelling
Language (UML) [Rational, 1997]. In OMT, three models are used to describe a system: an
object model, a dynamic model and a functional model. As shown in Figure 6-1, the
models of OMT specify a system from three viewpoints. Together, the models capture the
objects in a system, the interaction between the objects and the transformation of
information by the objects. Various Computer Aided Software Engineering (CASE) tools
exist for the specification of the OMT models in a system design.
152
Dynamic model
Functional model
Object model
Figure 6-1 Object Modelling Technique
An object model in OMT describes the static structure of a system by showing the objects in
the system, the relationships between the objects, and the attributes and operations that
characterise each class of objects [Rumbaugh, 1991]. When compared to the other two
kind of models, the object model is the core of a design, because it shows the objects of a
system, their contents and their relationships. The object model captures the state of a
system, particularly for those elements that must be monitored from moment to moment.
Objects are the central entities in the object model. An object class describes a
group of objects with common attributes, common operations and common relationships.
An object instance is a particular object in an object class. An attribute is a data value held
by the objects in a class. An operation is a function that can be provided by objects in a
class.
There are several types of relationships that connect objects to one another:
association, aggregation and generalisation. An association denotes structural interaction
between object classes. An association describes a group of links with a common structure
and common semantics. All the links in an association connect objects from the same
classes. A link is an instance of an association, so it represents a physical or logical
connection between object instances. Multiplicity constrains the number of related objects,
because it defines how many instances of one class may relate to a single instance of an
associated class. An aggregation denotes that an object consists of, or is a part of, other
objects. In an aggregation relationship, components of an object are related to the object
representing the entire assembly. A generalisation denotes that a class has either one or
153
more generic versions or either one or more specific versions. The class being generalised
is the superclass in the relationship, and the class being specialised is the subclass.
Specialisation refers to the fact that subclasses refine or specialise the superclass.
An object model in OMT is specified graphically in class diagrams and instance
diagrams. A class diagram shows all possible instances of objects, whereas an instance
diagram shows how a particular set of objects relate. A class diagram shows the structure
of object classes and their attributes, operations and relationships. An instance diagrams
shows the structure of unique object occurrences. As many diagrams as needed may be
used to specify the object model of a system.
In OMT, a dynamic model describes the interactions among objects in a system and covers
those system aspects that are concerned with time and changes [Rumbaugh, 1991]. A
dynamic model gives allowable sequences of changes to objects identified in the object
model. It specifies the temporal evolution of the objects in a system, in terms of the
changes they undergo in response to interactions with other objects.
The main entities in the dynamic model are events and states. An event is
something that happens at a point in time, having no duration. Events function as an
external stimulus to objects and relate to operations in the object model. An event is a one
way transmission of a stimulus from one object to some other object. An object generating
an event for another object may expect a reply, but the reply itself is a separate event under
control of the second object, which can choose to send it or not. A scenario is a sequence
of events that occurs during a particular execution of a system. Depending on the scope of
a scenario, it may include all events in the system, or it may include those events
generated by or influencing certain objects in the system.
The other type of entities in a dynamic model are states, which represent values of
objects at a certain moment. A state is an abstraction of the attribute values of an object.
According to the attribute values that have major impact on the behaviour of the object,
sets of values are grouped together into a state. Thus, a state represents a range of attribute
values for an object. Transitions of the state of an object are caused by events that
influence the attribute values of the object. Operations of objects can be executed within
states, but they can also be related to state transitions.
A dynamic model in OMT is specified graphically in multiple state diagrams and
event trace diagrams. A state diagram is a graph whose nodes represent states and whose
arcs are transitions that are labelled by events names. It describes all or part of the
behaviour of one object of a given class. A state diagram includes the events generated by
the object and the events by which the object is influenced. In particular, it shows the
possible ways in which the object responds to events from other objects. Besides state
154
diagrams, event trace diagrams are used to show the sequence of events in a scenario,
together with the way they propagate across the objects involved. Every scenario or event
trace corresponds to a path through the state diagrams. A scenario that is captured in an
event trace diagram, can be a historical record of executing a system or a thought
experiment of executing a proposed system.
A functional model in OMT describes the transformation of information by the system,

showing how output values in a computation are derived from input values without regard
for the order in which the values are computed [Rumbaugh, 1991]. The transformations in
the functional model can be mapped onto operations in the object model and the events or
states in the dynamic model. In the design of object-oriented systems, the functional model
is constructed within the perspective of the object model and dynamic model.
Entities in the functional model are processes, data flows, data stores and actors.
Processes transform input values into output values. Data flows represent value streams
that correspond to attribute values in the object model. In data stores, values can be stored
before they are used again. Actors are entities just producing or consuming data flows. The
elementary processes in a functional model can be implemented as operations in the object
model, so they relate to events or states in the dynamic model.
The graphic notation of the functional model in OMT consists of one or more data
flow diagrams, which can be supplemented with pseudo code or formulae. A data flow
diagram is a graph that shows the functional relationships of the values computed by a
system. It contains processes that transform data, data flows that move data, actors that
produce and consume data, and data stores that store data. Data flow diagrams are the
primary modelling concepts in a number of traditional system technologies, whereas in
object-oriented system technology they represent only a minor part of a system design.
Besides data flow diagrams, pseudo code or formulae can be used to specify the internal
detail of processes. In some way, algorithms for the processes have to be stated, so that
they can be executed in the operations of objects.
6.2.1.1 Object model
The object model specifies the objects of the information systems being designed. To be
consistent with the networked inventory management design, one NIMIS is considered as
an extremely basic information system providing networked inventory management for
just one single SKU stock-point (SSS). The design is created from a local system viewpoint,
instead of designing from a global network viewpoint. As a consequence, the object model
covers only one NIMIS and its environment. The environment of the NIMIS may in turn
contain other NIMISs. This recursion makes it possible to specify a network of NIMISs. The
155
object model of a NIMIS consists of multiple class diagrams and instance diagrams, which
specify the identity, relationships, attributes and operations of the objects in the
information system.
156
A class diagram shows the structure of object classes in an information system. In

particular, class diagrams show the generic components of an information system and
their relationships. The object model of the information systems includes class diagrams
for the:
• Basic system
• Environment composition
• System composition
• System associations
• Component associations
• Inventory Manager
• Customer Manager
• Supplier Manager
• Operational Manager
• Strategic Manager
• Customer
• Supplier
• Operational Process
• Strategist
NIMIS
Interacts with
Environment
Object class Relation
Figure 6-2 Basic system class diagram
In Figure 6-2, a class diagram for the basic system is presented, making a distinction
between on the one hand a NIMIS, and on the other hand the environment in which the
system operates. From the viewpoint of a NIMIS, there is one unique environment which
includes all relevant entities outside a NIMIS.
157
Environment
Operational Customer
Supplier Process Strategist
Figure 6-3 Environment composition class diagram
In Figure 6-3 a class diagram is given that specifies the composition of the environment
relevant to a NIMIS. In the environment, there is one Operational Process, including one
single SKU stock-point (SSS) which is managed by the information system. Furthermore,
the environment includes one or more Customers that demand goods from the stock-point.
Also, there are one or more Suppliers that supply goods to the stock-point. Finally, the
environment contains a Strategist who supervises the system.
NIMIS
Supplier Operational Inventory Strategic Customer

Manager Manager Manager Manager Manager
Figure 6-4 System composition class diagram
In Figure 6-4 a class diagram is presented that specifies the composition of the system.
The entities in an information system for supply chain management can be built of
components that represent real-world entities in the supply chain [Harink, 1993]
[Verwijmeren, 1996b]. So, the objects of a NIMIS represent concepts in the real-world of
158
networked organisations and integral inventory management. For the identification of

robust objects in a system, the objects need to represent durable elements in the
environment of the system. Forthcoming objects have data and functions that naturally
belong together. Within such an object there is strong interdependence between data and
functions, while interdependence between the objects is rather weak.
The system composition class diagram specifies that a NIMIS consist of five object
classes: a Customer Manager, a Supplier Manager, an Operational Manager, a Strategic
Manager and an Inventory Manager. Reasoning from lasting entities in the real-world,
these five object classes with cohesive functions and data are identified. An object class
represents a cohesive cluster of functions and data that can be mapped onto corresponding
entities in the real world. Each object class is responsible for providing its own functions
and maintaining its own data.
Strategist
Controls
Supplier Deals with NIMIS Deals with Customer
Controls
Operational
Process
Figure 6-5 System associations class diagram
In Figure 6-5 a class diagram is given for the associations of a system to its environment.
From the viewpoint of one NIMIS, the class diagram specifies that a NIMIS has associations
with four object classes in its environment. The NIMIS itself is considered to be an object
class that manages the inventory level of one single SKU stock-point (SSS). In the
159
environment of the system there is an Operational Process, a Strategist and one or more
Customers and Suppliers. An Operational Process is an object class that represents an SSS,
together with the process supplying products to the stock-point and the process demanding
products from the stock-point.
A Customer is an object class which represents an actor that demands products
from the Operational Process controlled by the NIMIS. A NIMIS deals with Customers for
the management of the inventory level at the single SKU stock-point (SSS) of the
Operational Process. A Supplier is an object class which represents an actor that supplies
products to the Operational Process controlled by the NIMIS. For managing the inventory
level at the SSS, a NIMIS also deals with Suppliers. A Strategist is an object class
representing a human manager who is responsible for the inventory management of the
SSS in the Operational Process. A NIMIS is controlled by the Strategist, so that the
inventory can be managed according to the insight of the human manager. Customers and
Suppliers can be equipped with NIMISs, but they may also use other information systems or
no system at all. If a Customer or a Supplier also makes use of a NIMIS, the same system
associations apply from the viewpoint of the Customer or the Supplier.
Strategist
Controls NIMIS
Strategic
Manager
Controls Controls Controls
Controls
Supplier Inventory Customer

Supplier Deals with Manager Deals with Manager Deals with Manager Deals with Customer
Controls Controls Controls
Operational
Manager
Controls
Operational
Process
Figure 6-6 Component associations class diagram
160
In Figure 6-6 a class diagram is shown with the associations of the system components.
Again, the four object classes in the NIMIS environment are included. A Customer
Manager is an object class that is responsible for the functions and data related to the
Customers of the NIMIS. To that end, the Customer Manager deals with Customers, deals
with the Inventory Manager, controls the Operational Process and is controlled by the
Strategic Manager. A Supplier Manager is an object class that is responsible for the
functions and data related to the Suppliers of the NIMIS. For this aim, the Supplier
Manager deals with Suppliers, but also deals with the Inventory Manager, controls the
Operational Process and is controlled by the Strategic Manager.
An Operational Manager is an object class that is responsible for the functions and
data related to the Operational Process containing a single SKU stock-point. For that
purpose, the Operational Manager controls the Operational Process and is controlled by
the Customer Manager, Supplier Manager, Inventory Manager and Strategic Manager. A
Strategic Manager is an object class that is responsible for the functions and data related to
the Strategist controlling the NIMIS. For this aim, the Strategic Manager is controlled by
the Strategist and controls the Customer Manager, Supplier Manager, Operational
Manager and Inventory Manager.
An Inventory Manager is an object class that is responsible for the functions and
data related to the inventory in the single SKU stock-point which is controlled by the NIMIS.
To do this, the Inventory Manager deals with the Customer Manager and Supplier
Manager, controls the Operational Process and is controlled by the Strategic Manager.
The object classes in a NIMIS are equipped with attributes and operations which enable
them to perform in accordance with their targets. The operations of an object class give the
ability to provide its functions, while the attributes give the ability to maintain its data.
The information being transformed by the operations comes from or goes to the attributes.
In all object classes, the operations are divided into operations to get, compute, give, write
and read information. A ‘get-operation’ in an object gets information from an other object,
while a ‘give-operation’ gives information to an other object. A ‘compute-operation’
computes new values of attributes in an object, without being involved in information
exchange with other objects. A ‘write-operation’ in an object writes parameters or an
exception to an other object, while a ‘read-operation’ reads new values for parameters or a
solution for an exception from an other object. Get-operations, give-operations and
compute-operations are executed on a regular basis, as opposed to write-operations and
read-operations, which are used only in the occasion of parameter setting or exception
handling.
161
Inventory Manager
-Inventory Norm
-Lot Size
-Lead Time
-Explosion Factor List
-Transit Inventory Plan
-Exclusive Inventory Position Plan
-Inventory Supply Plan
-lnclusive Inventory Position Plan
-Exception
+Get Aggregate Customer Demand Plan
+Get Actual Inventory
+Compute Transit Inventory Plan
+Compute Exclusive Inventory Position Plan
+Compute Inventory Supply Plan
+Compute Inclusive Inventory Position Plan
+Compute Aggregate Supplier Demand Plan
+Compute Aggregate Supplier Demand Order
+Give Aggregate Supplier Demand Plan
+Give Aggregate Supplier Demand Order
+Write Parameters
+Read Parameters Object
+Write Exception Attributes
+Read Exception Operations
Figure 6-7 Inventory Manager class diagram
In Figure 6-7 an object class diagram for the Inventory Manager (IM) is presented. The
Inventory Norm (IN) is the attribute containing a value for the desired and required
inventory level of the single SKU stock-point (SSS). The Lot Size (LS) gives the number of
products that have to be ordered together in one batch. The Lead Time (LT) specifies the
time that elapses between the moment of ordering products for replenishment of the stock-
point and the moment of receiving the products at the SSS. The Explosion Factor (EF) List
is an attribute that specifies a one level product structure (bill of materials) or distribution
structure, that gives the type and number of product units going into each product held at
the SSS. The Transit Inventory Plan (TIP) contains a plan with products that have been
ordered, but that have not yet been received at the SSS. The Exclusive Inventory Position
Plan (EIPP) is a plan giving the expected inventory level at the SSS if no new supply is
planned. The Inventory Supply Plan (ISP) is a plan that denotes the new supply to the SSS
which is needed to prevent from inventory shortage. The Inclusive Inventory Position Plan
(IIPP) is a plan which specifies the expected inventory level at the SSS, taking into account
162
the new supply. The Exception is an attribute that can contain all types of messages which
are needed for unforeseen circumstances.
The Inventory Manager incorporates operations to transform information. One get-
operation is included to get an Aggregate Customer Demand Plan (ACDP) from the
Customer Manager. Another get-operation gets the Actual Inventory (AI) from the
Operational Manager. Five compute-operations are present to compute new values for the
Transit Inventory Plan (TIP), Exclusive Inventory Position Plan (EIPP), the Inventory
Supply Plan (ISP), the Inclusive Inventory Position Plan (IIPP), the Aggregate Supplier
Demand Plan (ASDP) and the Aggregate Supplier Demand Order (ASDO). One give-
operation is included to give the Aggregate Supplier Demand Plan (ASDP) to the Supplier
Manager. Another give-operation enables the Inventory Manager to give the Aggregate
Supplier Demand Order (ASDO) to the Supplier Manager. Finally, the Inventory Manager
is equipped with write-operations to forward the values of Parameters or any Exception to
the Strategic Manager. The Parameters represent the attributes in the Inventory Manager
for which the values can be set by the Strategist. The read-operations are used to receive
new values for Parameters or the solution for an Exception from the Strategic Manager.
163
Customer Manager
-Customer List
-Individual Customer Demand Order List
-Individual Customer Demand Plan List
-Aggregate Customer Demand Order
-Aggregate Customer Demand Plan
-Exception
+Get Individual Customer Demand Order
+Get Individual Customer Demand Plan
+Compute Individual Customer Demand Order List
+Compute Individual Customer Demand Plan List
+Compute Aggregate Customer Demand Order
+Compute Aggregate Customer Demand Plan
+Give Individual Customer Demand Order
+Give Individual Customer Demand Plan
+Give Aggregate Customer Demand Order
+Give Aggrate Customer Demand Plan
+Write Parameters
Figure 6-8 Customer Manager class diagram
In Figure 6-8 an object class diagram for the Customer Manager (CM) is presented.
Customer List is the attribute that holds a list of Customers for the NIMIS. The Individual
Customer Demand Order (ICDO) List contains actual and local demand from customers,
while the Aggregate Customer Demand Order (ACDO) registers total demand from
customers between two consecutive review moments. The Individual Customer Demand
Plan (ICDP) List provides the NIMIS with extra information from customers concerning
future demand and integral inventory. The list includes both the original plans, as received
from Customers as well as translated plans, in which customer demand has been allocated
to review and plan moments used by the NIMIS. The Aggregate Customer Demand Plan
(ACDP) contains the aggregated values from the ICDP List. Unforeseen circumstances are
reported in an Exception.
The Customer Manager possesses operations to get information needed in compute-
operations, and to give information resulting from compute-operations. Four compute-
operations are included, for the computation of new values of the Individual Customer
Demand Order (ICDO) and Plan (ICDP) Lists, and for the Aggregate Customer Demand
Order (ACDO) and Plan (ACDP). For the setting of Parameters and the handling of an
Exception, the Customer Manager is equipped with read-operations and write-operations.
164
165
Supplier Manager
-Supplier List
-Supplier Allocator List
-Aggregate Supplier Demand Order
-Aggregate Supplier Demand Plan
-Individual Supplier Demand Order List
-Individual Supplier Demand Plan List
-Exception
+Get Aggregate Supplier Demand Order
+Get Aggregate Supplier Demand Plan
+Compute Individual Supplier Demand Order List
+Compute Individual Supplier Demand Plan List
+Give Individual Supplier Demand Order
+Give Individual Supplier Demand Plan
+Write Parameters
Figure 6-9 Supplier Manager class diagram
A class diagram for the Supplier Manager (SM) is given in Figure 6-9. Supplier List is the
attribute containing a list of Suppliers for the NIMIS. The Supplier Allocator (SA) List
indicates the respective suppliers for each of the product units. The Aggregate Supplier
Demand Order (ASDO) registers total supply required from all suppliers at a review
moment, while the Individual Supplier Demand Order (ISDO) List contains actual and
local supply required from the individual suppliers. The Aggregate Supplier Demand Plan
(ASDP) represents total future demand and integral inventory per product unit for all
suppliers. The Individual Supplier Demand Plan (ISDP) List contains the future demand
and integral inventory per product unit and per supplier. Unforeseen circumstances are
reported in an Exception.
The Supplier Manager has operations available to get information needed in
compute-operations, and to give information resulting from compute-operations. For the
computation of new values of the Individual Supplier Demand Order (ISDO) and Plan
(ISDP) Lists two compute-operations are included. For parameter setting and exception
handling, read-operations and write-operations are available in the Supplier Manager.
166
Operational Manager
-Output Process Order List

-Input Process Order List
-Actual Inventory
-Actual Demand
-Actual Supply
-Exception
+Compute Output Process Order List
+Give Output Process Order
+Get Individual Supplier Demand Order
+Compute Input Process Order List
+Give Input Process Order
+Write Parameters
Figure 6-10 Operational Manager class diagram
In Figure 6-10 an object class diagram for the Operational Manager (OM) is presented.
The Output Process Order (OPO) List specifies the orders going to the Operational
Process to supply products to customers, in response to Individual Customer Demand
Orders (ICDOs) that have been received from customers. The Input Process Order (IPO)
List contains orders for the Operational Process to receive products from suppliers,
corresponding to Individual Supplier Demand Orders (ISDOs) which are sent to Suppliers.
The Actual Inventory (AI) registers the inventory at a review moment, while Actual
Demand (AD) and Actual Supply (AS) respectively store the total demand from, and
supply to, the single SKU stock-point (SSS) between two consecutive review moments. The
Exception takes care of system anomalies.
The Operational Manager possesses operations to get information needed in
compute-operations, and to give information resulting from compute-operations. The
Operational Manager has two compute-operations available, to calculate new values for
the Input (IPO) and Output Order (OPO) Lists. For the setting of Parameters and the
handling of an Exceptions, the Operational Manager is equipped with read-operations and
write-operations.
167
Strategic Manager
-Time
-Review Moment List
-Plan Moment List
-Exception
-Parameter List
-Exception List
+Give Individual Customer Demand Order
+Give Individual Supplier Demand Order
+Get Individual Supplier Demand Plan
+Write Parameters
Figure 6-11 Strategic Manager class diagram
A class diagram for the Strategic Manager (STM) is given in Figure 6-11. The Strategic
Manager stores the series of review moments applied by the NIMIS in the Review Moment
List, while the series of plan moments per review moment is held in a Plan Moment List.
Any exception occurring in the Strategic Manager itself is stored in the attribute
Exception. The Strategic Manager contains a Parameter List that refers to all Parameters
of all component objects in a NIMIS. The Parameters represent all attributes in the system
for which the values can be set by the Strategist. The Exception List collects all Exceptions
occurring in the component objects of a NIMIS.
The Strategic Manager has get-operations available to get regularly changing
information from component objects or from the Strategist, while give-operations give this
dynamic information to the Strategist or to component objects. The Strategic Manager gets
from component objects Individual Customer Demand Orders (ICDOs) and Plans
(ICDPs), as well as Individual Supplier Demand Orders (ISDOs) and Plans (ISDPs). This
information is given to the Strategist to monitor and check their values. After the
Strategist has checked the information, the Strategic Manager receives the information,
which may or may not have been adjusted, from the Strategist and feeds it back to the
Customer Manager or Supplier Manager.
168
For the object classes in the environment of a NIMIS, attributes and operations are also
identified. The operations of an object class in the environment, state what functions need
to be covered by the external entities to interface with a NIMIS. The attributes of the object
classes in the environment, represent the data that need to be available in the external
entities for proper interfacing with a NIMIS.
Customer
-Individual Supplier Demand Order

-Individual Supplier Demand Plan Object
+Give Individual Supplier Demand Order Attributes
+Give Individual Supplier Demand Plan Operations
Figure 6-12 Customer class diagram
In Figure 6-12 a class diagram is presented for a Customer (C) in the environment of a
NIMIS. It specifies that for interfacing with a NIMIS, a Customer must maintain its own
Individual Supplier Demand Orders (ISDOs) and Plans (ISDPs), which are given to the
NIMIS that manages the supplying stock-point for the customer. A NIMIS receives this
information from its local viewpoint as Individual Customer Demand Orders (ICDOs) and
Plans (ICDPs).
Supplier
-Individual Customer Demand Order

-Individual Customer Demand Plan Object
+Get Individual Customer Demand Order Attributes
+Get Individual Customer Demand Plan Operations
Figure 6-13 Supplier class diagram
The class diagram for a Supplier (S) in the environment of a NIMIS is given in Figure 6-13.
For interfacing with a NIMIS, a Supplier must be able to get and store Individual Customer
Demand Orders (ICDOs) and Plans (ICDPs). From its local viewpoint, a NIMIS sends this
information to the Supplier as Individual Supplier Demand Orders (ISDOs) and Plans
(ISDPs).
169
Operational Process
-Actual Inventory
-Actual Demand
-Actual Supply
-Output Process Order List
-Input Process Order List
+Give Actual Inventory
+Give Actual Demand
+Give Actual Supply Object
+Get Output Process Order Attributes
+Get Input Process Order Operations
Figure 6-14 Operational Process class diagram
In Figure 6-14 a class diagram is presented for the Operational Process (OP). This object
class in the environment of a NIMIS must be able to get and register an Output Process
Order (OPO) List and an Input Process Order (IPO) List. It also needs to register the
Actual Inventory (AI), Actual Demand (AD) and Actual Supply (AS), and must be able to
give this information to the NIMIS.
170
Strategist
-Parameter List
-Exception List
-Individual Customer Demand Order List
-Individual Customer Demand Plan List
-Individual Supplier Demand Order List
-Individual Supplier Demand Plan List
+Check Individual Customer Demand Plan
+Get Indvidual Supplier Demand Plan
+Check Individual Supplier Demand Plan
+Read Parameters
+Set Parameters
+Write Parameters
Object
+Read Exception
+Handle Exception Attributes
+Write Exception Operations
Figure 6-15 Strategist class diagram
In Figure 6-15 a class diagram is presented for the Strategist (STR) who controls a NIMIS.
A Strategist must be able to get Individual Customer Demand Orders (ICDOs) and
Individual Supplier Demand Orders (ISDOs) for monitoring purposes. Moreover, the
Strategist needs to get, check and give Individual Customer Demand Plans (ICDPs) and
Individual Supplier Demand Plans (ISDPs). Further, the Strategist must be able to read, to
set and to write the Parameter List. Finally, the Strategist needs to have the ability to read,
to handle and to write the Exception List.
Besides class diagrams, the object model of a NIMIS is specified with instance diagrams,
which show the structure of unique object occurrences. For a particular network of supply
chains, managed with the help of NIMISs, a specific instance diagram can be created.
Supply chains can be managed by a network of NIMISs, because NIMISs are allowed to have
mutual relationships. As many instance diagrams can be created as needed to sufficiently
specify a particular situation. The instance diagrams which are presented in the object
model of NIMISs, are based on an imaginary situation.
171
Supplier S11 NIMIS S1 NIMIS C1 Customer C11
Supplier S21 Customer C21
Supplier S22 Customer C22
Supplier S31 NIMIS S3 NIMIS C3 Customer C31
Object instance Relation
Figure 6-16 NIMIS network instance diagram
In Figure 6-16 an instance diagram for a particular network of NIMISs is presented. The
network of NIMISs for this imaginary situation, fulfils integral inventory management
across networked organisations. The NIMIS network contains seven instances of the NIMIS
object class, four instances of the Customer object class and four instances of the Supplier
object class. All object instances in the network are created by instantiation of the
corresponding object classes as specified in the class diagrams. The seven NIMISs deal with
each other, as well as with actors that are outside the scope of attention in this situation.
Those peripheral actors are represented as customers and suppliers.
NIMIS X1 in the middle of the network deals with convergent incoming product
flows and divergent outgoing product flows. NIMIS C1, NIMIS C2 and NIMIS C3 demand
products from NIMIS X1, while NIMIS X1 orders supply at NIMIS S1, NIMIS S2 and NIMIS S3.
NIMIS C1 and NIMIS C3 each have one customer, while NIMIS C2 supplies to two customers.
Those Customers are actors for which it is not known whether or not they apply a NIMIS.
At the supply side of NIMIS X1, there are similar types of demand and supply relationships
between suppliers and NIMISs. Although not shown in the instance diagram for the
particular NIMIS network, each NIMIS controls one Operational Process including a single
SKU stock-point (SSS), and is controlled by a Strategist.
172
Strategist X1
Customer Supplier
Manager S1 Manager C1
NIMIS X1
Strategic
Manager X1
Customer Supplier Inventory Customer Supplier

Manager S2 Manager X1 Manager X1 Manager X1 Manager C2
Operational
Manager X1
Customer Supplier
Manager S3 Manager C3
Operational
Process X1
Object instance Relation
Figure 6-17 NIMIS instance diagram
An instance diagram for a particular NIMIS in the network is shown in Figure 6-17. The
instance diagram specifies the object instances that are part of NIMIS X1 in Figure 6-16, as
well as their relationships to external objects in the particular NIMIS network. NIMIS X1
consists of five object instances: Customer Manager X1, Supplier Manager X1, Operational
Manager X1, Strategic Manager X1 and Inventory Manager X1. With respect to external
links of NIMIS X1, Customer Manager X1 deals with Supplier Manager C1 of NIMIS C1,
Supplier Manager C2 of NIMIS C2 and Supplier Manager C3 of NIMIS C3. Internally,
Customer Manager X1 controls Operational Process X1, deals with Inventory Manager X1
and is controlled by Strategic Manager X1.
Supplier Manager X1 has external relationships with Customer Manager S1 of NIMIS
S1,Customer Manager S2 of NIMIS S2 and Customer Manager S3 of NIMIS S3. Internally,
Supplier Manager X1 controls Operational Process X1, deals with Inventory Manager X1
and is controlled by Strategic Manager X1. Operational Manager X1 controls Operational
Process X1 and is controlled by the other object instances of NIMIS X1. Inventory Manager
X1deals with Customer Manager X1 and Supplier Manager X1, controls Operational
Manager X1 and is controlled by Strategic Manager X1. Strategic Manager X1 controls all
other object instances in NIMIS X1 and is controlled by Strategist X1. All objects in the
173
instance diagrams maintain data by storing specific values in their attributes and provide
functions with their operations as specified in the object classes.
6.2.1.2 Dynamic model
The dynamic model of NIMISs specifies the dynamic behaviour of the information systems
being designed. In terms of events, the dynamic model specifies the interaction of objects
in a NIMIS over time. It also includes the possible states of the objects in a NIMIS and the
state transitions due to events. The NIMIS dynamic model consists of multiple event trace
diagrams and state diagrams.
An event trace diagram shows a sequence of events and the objects which generate the
events, or are influenced by them. In particular, the event trace diagrams illustrate
scenarios for executing a NIMIS. The dynamic model of a NIMIS includes event trace
diagrams for:
• Regular Management
• Occasional Management
174
Give/Get ICDO
1.
Give/Get ICDO
Give/Get OPO
Give/Get ICDO
Give/Get ICDO
Give/Get ICDP
Give/Get ICDP
Give/Get ICDP
Give/Get ICDP
Give/Get ICDP
Give/Get ACDP
Get/Give AI
Get/Give AD
Get/Give AS
Give/Get AD
Give/Get AD
Give/Get AS
Give/Get AI
Give/Get ASDO
Give/Get ASDP
Give/Get ISDO
Give/Get ISDO
Give/Get IPO
Give/Get ISDO
Give/Get ISDO
Give/Get ISDP
Give/Get ISDP
Give/Get ISDP
Give/Get ISDP
Give/Get ISDP
Supplier Supplier Operational Operational Inventory Strategist Strategic Customer Customer

Manager Process Manager Manager manager Manager
Object Event
Figure 6-18 Event trace diagram for Regular Management
In Figure 6-18 an event trace diagram is presented for the scenario that a NIMIS executes
Regular Management. Regular Management by a NIMIS concerns management of the
inventory level in the single SKU stock-point (SSS), encompassing a set of events occurring
on a regular basis. The vertical lines in the event trace diagram represent object instances
and the horizontal arrows denote events. The object instances involved in Regular
Management are the five objects making up a NIMIS: Customer Manager, Supplier
Manager, Operational Manager, Strategic Manager and Inventory Manager. The other
175
object instances stand for objects in the environment of the NIMIS: Operational Process,
Strategist, one or more Customers and one or more Suppliers.
Customers send their Individual Customer Demand Orders (ICDOs) to the
Customer Manager. The ICDOs are forwarded to both the Operational Manager and the
Strategic Manager. The Operational Manager translates the received information to
Output Process Orders (OPOs), which are then transferred to the Operational Process. The
ICDOs are sent by the Strategic Manager to the Strategist for monitoring the system.
Customers can also send Individual Customer Demand Plans (ICDPs) to the
Customer Manager, which contain information on future demand or integral inventory. At
a review moment, the ICDPs are sent via the Strategic Manager to the Strategist, who
checks the plans and returns the approved plans, via the Strategic Manager, to the
Customer Manager. The Customer Manager computes the Aggregate Customer Demand
Plan (ACDP) and forwards this to the Inventory Manager. The Inventory Manager asks
the Operational Manager to retrieve the Actual Inventory (AI) at a review moment. The
Operational Manager gets the AI, as well as the Actual Demand (AD) and Actual Supply
(AS) from the Operational Process, and passes the AI to the Inventory Manager. The
Inventory Manager then starts computing the Exclusive Inventory Position Plan (EIPP),
the Inventory Supply Plan (ISP), the Inclusive Inventory Position Plan (IIPP) and the
Transit Inventory Plan (TIP). Eventually, this results in an Aggregate Supplier Demand
Order (ASDO) and an Aggregate Supplier Demand Plan (ASDP), which are handed over
to the Supplier Manager.
The Supplier Manager computes the Individual Supplier Demand Orders (ISDOs)
as well as the Individual Supplier Demand Plans (ISDPs). The ISDOs are directly sent to
the suppliers. In addition, the ISDOs are given to the Strategic Manager which
communicates the orders to the Strategist for monitoring purpose. Also, the Operational
Manager receives the ISDOs and transfers the information as Input Process Orders (IPOs)
to the Operational Process. The ISDPs go from the Supplier Manager, via the Strategic
Manager, to the Strategist. The Strategist checks the plans and sends the approved plans
back, via the Strategic Manager, to the Supplier Manager, Finally, the ISDPs are sent to
the respective suppliers.
176
Read/Write Parameters
Write/Read Parameters
Write/Read Exception
Supplier Supplier Operational Operational Inventory Strategist Strategic Customer Customer

Manager Process Manager Manager manager Manager
Object Event
Figure 6-19 Event trace diagram for Occasional Management
In Figure 6-19 an event trace diagram is given for the scenario that a NIMIS executes
Occasional Management. Occasional Management by a NIMIS concerns the setting of
parameters and the handling of exceptions, two functions accomplished on an occasional
basis. The same object instances are included as in the event trace diagram of Figure 6-18.
The Strategist can read and write Parameters of the component objects in a NIMIS.
Therefore, the Strategist sends a request to read the Parameters to the Strategic Manager.
As a reaction, the Strategic Manager sends requests to read the Parameters to the
177
Customer Manager, the Supplier Manager, the Inventory Manager, the Operational
Manager and the Strategic Manager itself. They all respond to the requests by writing
their Parameters to the Strategic Manager. The values of the Parameters received from the
objects are bundled in a Parameter List and forwarded to the Strategist. The Strategist may
set new values for one or more Parameters. The updated values of the Parameters are
returned to the Strategist, who then writes the refreshed Parameters to the corresponding
object instances.
The Strategist also handles possible Exceptions emerging in a NIMIS. In any
component object, an Exception may occur, which is then transmitted to the Strategic
Manager. The Strategic Manager groups Exceptions in the Exception List and forwards
this information to the Strategist. The Strategist handles the Exceptions by suggesting
solutions. The handled Exceptions are sent back to the Strategic Manager, which forwards
the Exceptions, now including the proposed solutions, to the respective component objects
in the NIMIS. If the solution is not adequate for a component object, it generates a new
Exception, and so on.
The events in the event trace diagrams can be mapped onto the operations of the objects in
a NIMIS. The give/get events and get/give events in the event trace diagram for Regular
Management correspond to get-operations and give-operations, whereas the write-events
and read-events in the scenario for Occasional Management relate to write-operations and
read-operations of the objects. The compute-operations of the objects are carried out
without direct interaction with other object instances. Therefore, these compute-operations
do not create events that are visible in the event trace diagrams.
A state diagram describes states, state transitions and related events for an object class. In
particular, a state diagram specifies the main states of an object class, the possible state
transitions due to events and the operations executed when being in a state. The dynamic
model of a NIMIS includes state diagrams for each of the object classes in a NIMIS:
• Customer Manager
• Supplier Manager
• Operational Manager
• Strategic Manager
• Inventory Manager
178
CM Occasional Management
CM Parameters CM Parameters CM Exception CM Exception

to be written to be read to be written to be read
STM reads STM writes Exception STM writes

Parameters Parameters occurs Exception
from CM to CM in CM to CM
Write Read Write Read
Parameters Parameters Exception Exception
to STM from STM to STM from STM
CM Neutral
Get ICDO Give ICDO to Get ICDP Give ICDP Get ICDP Give ACDP
from C OM and STM from C to STM from STM to IM
to OP
ICDO got from C ICDP got from C ICDP got from STM
+Compute ICDO List +Compute ICDP List +Compute ACDO

+Compute ACDP
CM Regular Management
State Event
Figure 6-20 Customer Manager state diagram
In Figure 6-20 a state diagram for the Customer Manager (CM) is presented. This object
class has three main states: Neutral, Occasional Management and Regular Management.
The Neutral state is the state in which the Customer Manager is not busy and is waiting
for new events. When the Customer Manager becomes involved in Occasional
Management or Regular Management, the Neutral state is left, but is entered again when a
series of operations has been completed.
179
The Occasional Management state is entered through transitions caused by

incidental events for setting Parameters or handling Exceptions. ‘CM Parameters to be
written’ is the state starting as soon as the Strategic Manager (STM) sends a request to read
the Customer Manager’s Parameters. The state ends when the Customer Manager writes
its Parameters to the Strategic Manager. The state ‘CM Parameters to be read’ is entered
when the Strategic Manager writes updated values for the Parameters to the Customer
Manager, and is left when the Customer Manager reads these updated values. When an
Exception occurs in the Customer Manager, the state ‘CM Exception to be written’ is
entered, which is left when the Customer Manager writes the Exception to the Strategic
Manager. The state ‘CM Exception to be read’ is entered when the Strategic Manager
sends a solution for the Exception and is left when the Customer reads the solved
Exception.
Due to regular events, a transition takes place from the Neutral state to the Regular
Management state. ‘ICDO got from Customer’ is the state after the receipt of an
Individual Customer Demand Order (ICDO) from a Customer (C) and before forwarding
the ICDOs to the Operational Manager and Strategic Manager. In this state an updated
ICDO List is computed. The state ‘ICDP got from C’ is reached as soon as a Customer
sends an Individual Customer Demand Plan (ICDP) with its expected demand or integral
inventory. In this state an updated ICDP List is computed. The state is left when the ICDP
is forwarded to the Strategic Manager (STM) for monitoring and checking by the
Strategist. ‘ICDP got from STM’ starts when the Strategic Manager returns the plans,
after the Strategist has checked the plans. After the Aggregate Customer Demand Order
(ACDO) and Aggregate Customer Demand Plan (ACDP) have been computed, the
Customer Manager sends the ACDP to the Inventory Manager (IM) and returns to its
Neutral state.
180
IM Occasional Management
IM Parameters IM Parameters IM Exception IM Exception


from IM to IM in IM to IM
IM Neutral
Get ACDP from CM Give ASDP to SM
ACDP got ASDO given

from CM to SM
Get AI from OM Give ASDO to SM

AI got from OM
+Compute EIPP
+Compute ISP
+Compute IIPP
+Compute ASDO
+Compute ASDP
+Compute TIP
IM Regular Management
State Event
Figure 6-21 Inventory Manager state diagram
A state diagram for the Inventory Manager (IM) is presented in Figure 6-21. Again, the
object class has three main states: Neutral, Occasional Management and Regular
Management. The Neutral state is the base state occupied by the Inventory Manager as
long as no operations have to be carried out. The Occasional Management state is entered
either for the setting of Parameters or the handling of Exceptions.
Regular Management is the state that starts when an Aggregate Customer Demand
Plan (ACDP) is received from the Customer Manager (CM). The transition from the state
181
‘ACDP got from CM’ to the state ‘AI got from OM’ happens as soon as the Actual
Inventory (AI) is retrieved from the Operational Manager (OM). In the entered state, the
Inventory Manager executes several compute-operations to compute new values for the:
Exclusive Inventory Position Plan (EIPP), Inventory Supply Plan (ISP), Inclusive
Inventory Position Plan (IIPP), Aggregate Supplier Demand Plan (ASDP), Aggregate
Supplier Demand Order (ASDO) and Transit Inventory Plan (TIP). After finishing the
computations, the next state is reached by sending the ASDO to the Supplier Manager.
The state ‘ASDO given to SM’ is left immediately thereafter, when the Inventory Manager
gives the ASDP to the Supplier Manager (SM). With this transition, the Inventory Manager
returns in the Neutral state.
182
SM Occasional Management
SM Parameters SM Parameters SM Exception SM Exception


from SM to SM in SM to SM

SM Neutral
Get ASDO from IM Give ISDP to S
ASDO got ISDP got

from IM from STM
Get ASDP from IM

Get ISDP from STM
ASDP got from IM

+Compute ISDO List ISDP given
+Compute ISDP List to STM
Give ISDO to S, OM and STM Give ISDP to STM
ISDO given to
S, OM and STM
SM Regular Management
State Event
Figure 6-22 Supplier Manager state diagram
In Figure 6-22 a state diagram for the Supplier Manager (SM) is given. The object class
has three main states: Neutral, Occasional Management and Regular Management. As
long as no operations are carried out, the Supplier Manager is in the Neutral state, while
the Occasional Management state is entered for the setting of Parameters or the handling
of Exceptions.
Due to regular events, a transition takes place from the Neutral state to the Regular
Management state. Soon after the Supplier Manager receives an Aggregate Supplier
183
Demand Order (ASDO) from the Inventory Manager (IM), an Aggregate Supplier Demand
Plan (ASDP) is also received. From this information, the Supplier Manager computes an
Individual Supplier Demand Order (ISDO) List and an Individual Supplier Demand Plan
(ISDP) List. The ISDOs are forwarded to the Suppliers (S), the Operational Manager (OM)
and the Strategic Manager (STM). The ISDPs are sent to the Strategic Manager and later
on, a checked version of the plans is received. Then, the ISDPs are forwarded to the
Suppliers and the Supplier Manager returns to its Neutral state.
OM Occasional Management
OM Parameters OM Parameters OM Exception OM Exception


from OM to OM in OM to OM
OM Neutral
Get ICDO Give OPO Get ISDO Give IPO

Get AI from OP
from CM to OP from SM to OP
ICDO got from CM AI got from OP ISDO got from SM
+Compute OPO List +Compute IPO List

Get AD from OP
AD got from OP
Get AS from OP
Give AI to IM
AS got from OP
OM Regular Management
State Event
Figure 6-23 Operational Manager state diagram
184
A state diagram for the Operational Manager (OM) is presented in Figure 6-23. Like the
other objects in a NIMIS, the object class has three main states: Neutral, Occasional
Management and Regular Management. As long as no operations are carried out, the
Operational Manager remains in the Neutral state, while the Occasional Management
state is entered for the setting of Parameters or the handling of Exceptions.
The Regular Management state is reached when the Operational Manager receives
Individual Customer Demand Orders (ICDOs) from the Customer Manager (CM) or
Individual Supplier Demand Orders (ISDOs) from the Supplier Manager (SM). The
Operational Manager turns this information into Output Process Orders (OPOs) or Input
Process Order (IPOs). As soon as the OPOs or IPOs have been sent to the Operational
Process (OP), the Regular Management state is left. The Operational Manager (OM) also
goes into the Regular Management state at a review moment, when it gets the Actual
Inventory (AI), Actual Demand (AD) and Actual Supply (AS) from the Operational
Process. By sending the retrieved information to the Inventory Manager (IM), the
Operational Manager returns to the Neutral state.
185
STM Occasional Management
Parameters Exception being

being set by STR handled by STR
Write Parameters Read Parameters Write Exception Read Exception

to STR from STR to STR from STR
Parameters of Exception of
Managers read Managers read
Read Parameters Write Parameters Read Exception Write Exception

from Managers to Managers from Managers to Managers
STM Neutral
Get Get Get Get Get Get

ICDO ICDP ICDP ISDO ISDP ISDP
from from from from from from
CM Give CM STR SM SM STR Give
ICDO ISDP
to STR to SM
Give Give
ICDO got from CM ICDP ISDP ISDP got from STR
Give Give
to STR to STR
ICDP ISDO
to CM to STR
ICDP got from CM ISDP got from SM
ICDP got from STR ISDO got from SM
STM Regular Management
State Event
Figure 6-24 Strategic Manager state diagram
A state diagram for the Strategic Manager (STM) is presented in Figure 6-24. Again, the
object class has three main states: Neutral, Occasional Management and Regular
Management. As long as no operations are carried out, the Strategic Manager is in the
Neutral state. The Occasional Management state is entered for the setting of Parameters or
the handling of Exceptions. After the Strategic Manager has read the Parameters from the
five component objects (Managers) in a NIMIS, those Parameters are sent to the Strategist
186
(STR). When the updated Parameters are later received from the Strategist, the Parameters
in the component objects are updated and the Strategic Manager returns to the Neutral
state. The Strategic Manager receives Exceptions when anomalies emerge in any of the
component objects (Managers). These Exceptions are forwarded to the Strategist who
returns possible solutions with the Exceptions. The Strategic Manager sends the
Exceptions, including their solutions, to the corresponding component objects (Managers).
The Regular Management state is entered when an Individual Customer Demand
Order (ICDO) or an Individual Supplier Demand Order (ISDO) is received from the
Customer Manager (CM) or Supplier Manager (SM), which are immediately forwarded to
the Strategist (STR) for notification. The Strategic Manager also reaches the Regular
Management state when an Individual Customer Demand Plan (ICDP) or an Individual
Supplier Demand Plan (ISDP) is received from the Customer Manager or the Supplier
Manager. When a checked version of this plan comes back from the Strategist, the
Strategic Manager enters the Regular Management state, and returns to the Neutral state
when the checked ICDPs or ISDPs are sent back to the Customer Manager or the Supplier
Manager.
The state diagrams for all component objects of a NIMIS have the same three main states:
Neutral, Occasional Management and Regular Management. The state transitions for
Occasional Management all have similar patterns. However, the state transitions for
Regular Management are different for each object class. The events in the state diagrams
correspond to the events shown in the event trace diagrams. The state transitions in the
state diagrams reflect operations in the objects. Get and give transitions coincide with get-
operations and give-operations, while write and read transitions relate to write-operations
and read-operations. Some states in the state diagrams include compute-operations which
compute new values of attributes.
187
6.2.1.3 Functional model
The functional model of NIMISs specifies the information transformations in the

information systems being studied. It shows how output values in a computation are
derived from input values, without regard for the order in which the values are computed.
The NIMIS functional model consists of a data flow diagram and computation formulae.
ISDP List ASDP IIPP EIPP ACDP ICDP List
ISDP List ASDP ASDP IIPP EIPP EIPP EIPP ACDP ACDP ICDP List ICDP List
Compute Compute Compute Compute Compute Compute

ISDP List ASDP IIPP ISP EIPP ACDP ICDP List
ISDP SA List LT EF List ISP ISP ISP LS IN TIP AI ICDP
Supplier SA List LT EF List ISP LS IN TIP AS AI AD Customer
ISDO SA List LT EF List ISP

ICDO
Compute Compute Compute ACDO

ISDO List ASDO TIP
AS AI AP Compute
ACDO ICDO List
ASDO ASDO ASDO
Compute
ISDO List ASDO IPO List OPO List ACDP
ICDO List
IPO List OPO List ICDO List
Compute Operational Compute

ISDO List ISDO List IPO OPO ICDO List ICDO List
IPO List Process OPO List
Data flow Process Data store Actor
Figure 6-25 Data flow diagram for a NIMIS
In Figure 6-25 the data flow diagram for a NIMIS is presented. A data flow diagram is a
graph that shows the functional relationships of the values computed by a system. In
particular, a data flow diagram gives the data flows between processes, data stores and
actors. Actors in the data flow diagram are Customers, Suppliers and the Operational
Process, which represent objects in the environment of a NIMIS. The data stores in the data
flow diagram correspond to attributes in the NIMIS object model. The data stores keep the
values of the attributes available for later use. The processes in the data flow diagram
reflect compute-operations in the Regular Management scenario. There are no processes
for Occasional Management in the data flow diagram, because in that scenario no values
are computed by the system.
188
Roughly speaking, the data flows in the diagram go from the right to the left when
executing the computations in the Regular Management scenario. Customers send
Individual Customer Demand Orders (ICDOs) and Plans (ICDPs) to a NIMIS, which
computes the ICDO List and ICDP List. These are inputs for the computation of the
Aggregate Customer Demand Order (ACDO) and Plan (ACDP) respectively. The ICDO
List is used to compute the Output Process Order (OPO) List, from which the orders go to
the Operational Process.
The Exclusive Inventory Position Plan (EIPP) is computed by combining the
Actual Inventory (AI), the Aggregate Customer Demand Plan (ACDP) and the Transit
Inventory Plan (TIP). The AI is retrieved from the Operational Process, while the TIP is
computed from Aggregate Supplier Demand Orders (ASDOs) released previously. The
EIPP is used together with the Lot size (LS) and Inventory Norm (IN) to compute the
Inventory Supply Plan (ISP). Given the ISP and the EIPP, the IIPP is computed.
From the Inventory Supply Plan (ISP), the Explosion Factor (EF) List and the Lead
Time (LT), the Aggregate Supplier Demand Order (ASDO) and Aggregate Supplier
Demand Plan (ASDP) for MRP are determined. Although not shown, in BSC and LRP, the
ASDP is related to the Aggregate Customer Demand Plan (ACDP) instead of the ISP. The
ASDO is used to update the TIP. With the help of the Supplier Allocator (SA) List, an
Individual Supplier Demand Order (ISDO) List and Individual Supplier Demand Plan
(ISDP) List are generated. The ISDOs and ISDPs are inputs for the respective suppliers.
The ISDO List is the input for the calculation of the Input Process Order (IPO) List, from
which the orders go to the Operational Process.
All processes in the data flow diagram represent compute-operations of the objects
in a NIMIS. The get-operations, give-operations, write-operations and read-operations do
not represent processes in which new values are computed. As a consequence, these
operations are not visible in the data flow diagram. The actors in the data flow diagram
also have processes in which new values for their attributes are computed. Because those
actors are beyond the scope of a NIMIS, their internal data flows, data stores and processes
are not revealed in the data flow diagram.
Computation formulae describe the functional relationships between the input values and
the output values of a process. In particular, computation formulae specify the algorithms
within the processes in a mathematical way. The functional model of a NIMIS includes
computation formulae for the following attributes:
• Individual Customer Demand Order List

• Aggregate Customer Demand Order
• Individual Customer Demand Plan List
189
• Aggregate Customer Demand Plan

• Output Process Order List
• Transit Inventory Plan
• Exclusive Inventory Position plan
• Inventory Supply Plan
• Inclusive Inventory Position Plan
• Aggregate Supplier Demand Plan
• Aggregate Supplier Demand Order
• Individual Supplier Demand Order List
• Individual Supplier Demand Plan List
• Input Process Order List
In the networked inventory management design (Chapter 3), system equations are given
for the variables in a NIMIS. These system equations also represent the computation
formulae in the functional model of a NIMIS. The computation formulae specify how
operations of the objects compute new values for attributes of the objects. Because the
computation formulae are given in the networked inventory management design, these
system equations are not specified here again.
6.2.2 Object-oriented system properties

In the second part of the object-oriented system technology design of NIMISs, their
properties related to object-oriented system technology are explained. These properties
result from the object-oriented system technology model, which describes NIMISs from
three viewpoints. The object model specifies the objects together with their relationships,
attributes and operations. In the dynamic model, event traces for scenarios are given as
well as state diagrams for the objects in a NIMIS. Finally, the functional model specifies the
data flows between processes and refers to the computation formulae that relate inputs to
outputs. The resulting properties concern the use of technology with object classification,
attribute encapsulation and operation invocation.
6.2.2.1 Object classification
One of the technical requirements for the NIMISs is their use of technology with object
classification. Object classification implies that an information system consists of related
objects which preferably represent real-world entities, and further implies that objects in a
system with similar structure and behaviour are defined in a class. So, a system is
190
organised around objects that each contain both data and functions of the object, while the
system is executed by interaction between objects.
Object classes NIMIS

Class
Strategic Operational Inventory Supplier Customer

Manager Manager Manager Manager Manager
Class Class Class Class Class
Classification Instantiation
Object instances
STM STM STM
SM IM CM SM IM CM SM IM CM
OM OM OM
OM OM OM OM
SM IM CM SM IM CM SM IM CM SM IM CM
STM STM STM STM
NIMIS S3 NIMIS S2 NIMIS C2 NIMIS C3
Figure 6-26 Object classes and instances for object classification
The object classification property of the information systems is explained with the help of
the network of NIMISs as shown in Figure 6-26. The network represents the configuration
of NIMISs as presented earlier in the NIMIS network instance diagram of Figure 6-16. From
the perspective of NIMIS X1, the customers use NIMIS C1, NIMIS C2 and NIMIS C3, while its
suppliers use NIMIS S1, NIMIS S2 and NIMIS S3. In the network, the seven NIMISs run on
191
seven computers that are linked together by a communication network. Object

classification is arranged with the help of object classes and object instances. Every system
in the network is equipped with object classes and instances. The object classes in the
upper half of Figure 6-26 represent abstract definitions of the NIMISs. The object instances
in the lower half are unique object occurrences generated from the object classes.
The transitions between object classes and object instances are called classification
and instantiation. Classification is the abstraction of similar object instances into an object
class, whereas object instantiation is the creation of instances from of classes.
Classification relates instances to classes, while instantiation relates a class to its
instances. A class describes a certain category of objects, whereas an instance of that class
is just one specific representative of that category. In an object class, the attributes and
operations of an object are defined. Each instance possesses attributes and operations as
defined in the class. All systems in the network are objects themselves for which the
definition is specified in the object class NIMIS. The NIMIS class is composed of five
different object classes: Inventory Manager, Customer Manager, Supplier Manager,
Operational Manager and Strategist.
A network of NIMISs is a particular configuration of object instances, which are
created by instantiation of the object classes. The network of Figure 6-26 is built by
multiple instantiation of the object class NIMIS, generating the object instances NIMIS X1,
NIMIS C1, NIMIS S1, and so on. Each of the NIMIS instances consists of its five components,
also representing object instances. By using object classification, creating a new NIMIS is
just making another instance of the NIMIS class. Instantiation of the NIMIS class
automatically creates instances for all its components. Because each NIMIS contains it own
objects, attributes and operations, it can operate as an autonomous information system.
6.2.2.2 Attribute encapsulation
One of the technical requirements for the NIMISs is their use of technology with attribute
encapsulation. Attribute encapsulation implies that the objects in an information system
each contain attributes that specify the data of the object, and further implies that the
attributes of an object are normally hidden from other objects. So, data values are stored in
the attributes of an object and the attributes are only accessible through explicitly allowed
behaviour for reading and writing attributes.
192
Attributes Attributes Attributes
Operations Operations Operations
Operations Operations Operations Operations
Attributes Attributes Attributes Attributes
Figure 6-27 Attributes and encapsulation for attribute encapsulation
The attribute encapsulation property of the information systems is explained with the help
of the network of NIMISs as shown in Figure 6-27, representing a part of the NIMIS network
instance diagram of Figure 6-16. Attribute encapsulation is arranged by including
attributes in objects and by encapsulation of those attributes. The attributes of the objects
in the network are not visible to other objects in the network. Object classes define the
names of the attributes, while the object instances store their values. The names and values
of attributes of all objects in a NIMIS are hidden from other objects. Access to attributes can
only be realised through operations in an object. The operations represent the interface of
an object to other objects. The attributes of an object in a NIMIS are not only hidden from
the objects in other NIMISs, but also from the objects in the NIMIS itself.
Components of NIMIS X1 and NIMIS S1 are Supplier Manager X1 and Customer
Manager S1 respectively. Supplier Manager X1 specifies its Individual Supplier Demand
Orders (ISDOs) for Customer Manager S1, but is not capable of directly accessing the
Individual Customer Demand Order (ICDO) List of Customer Manager S1, the attribute
where the order information has to be stored. Instead, Supplier Manager X1 invokes the
operation ‘get Individual Customer Demand Order’ at Customer Manager S1. This
operation provides explicit access to the ICDO List in Customer Manager S1. In a NIMIS,
all attributes are indirectly accessible through the read-operations and write-operations,
used by the Strategist for monitoring and setting attribute values.
The objects have attributes to maintain their own data. Every object in a NIMIS is
equipped with an Exception to store data on unforeseen circumstances. Further, each
193
object has its specific attributes which are used by the operations of the object. The
Supplier Manager X1 of NIMIS X1, for example, has the attribute Supplier Allocator (SA)
List, which specifies that NIMIS S1, NIMIS S2 and NIMIS S3 are the suppliers of product units
for NIMIS X1. The SA List is used by Supplier Manager X1 to compute the Individual
Supplier Demand Order (ISDO) and Plan (ISDP) Lists from the Aggregate Supplier
Demand Order (ASDO) and Plan (ASDP). All the inputs and outputs of this computation
are attributes of Supplier Manager X1.
6.2.2.3 Operation invocation
One of the technical properties of NIMISs is their exploitation of technology with operation
invocation. Operation invocation implies that the objects in an information system each
contain operations that specify the functions of the object, and further implies that the
operations of an object are invoked by itself or other objects. So, functions are performed
by the operations of an object, and an operation is executed in response to a message
received from an object requiring the operation to be executed.
Attributes Attributes Attributes
Operations Operations Operations
Operations Operations Operations Operations
Attributes Attributes Attributes Attributes
Figure 6-28 Operations and invocation for operation invocation
The operation invocation property of the information systems is explained with the help of
the network of NIMISs as shown in Figure 6-28, representing a part of the NIMIS network
instance diagram of Figure 6-16. Operation invocation is arranged by including operations
in objects and by letting objects invoke these operations. As soon as an object in NIMIS
194
sends a message, an operation in the receiving object is carried out, and a result may be
fed back or another operation may be triggered by a new message. Objects within a NIMIS
invoke operations with each other, but also invoke operations on other NIMISs in the
network.
For invocation of operations on an object in a remote system, a NIMIS sends
messages over the communication network. NIMIS C1, NIMIS C2 and NIMIS C3 invoke
operations of objects within NIMIS X1, whereas NIMIS X1 invokes operations on NIMIS S1,
NIMIS S2 and NIMIS S3. A component of NIMIS X1 is Supplier Manager X1, while Customer
Manager S1 is a component of NIMIS S1. At a review moment, the Supplier Manager X1
executes the operation ‘compute Individual Supplier Demand Order (ISDO) List’. At the
end of the computation, the operation ‘give Individual Supplier Demand Order (ISDO)’ is
invoked on Supplier Manager X1. This operation invokes the operation ‘get Individual
Customer Demand Order (ICDO)’ on the remote object Customer Manager S1 of NIMIS S1.
Within Customer Manager S1, the operation ‘compute Individual Customer Demand
Order (ICDO) List’ is then invoked, which again triggers an operation, and so on.
The objects are equipped with several types of operations to perform their
functions. Get-operations are used to retrieve dynamic information from other objects and
to manage control during Regular Management. Give-operations provide regularly
changing values of attributes to other objects and also manage control during Regular
Management. Compute-operations are applied during Regular Management, to compute
new values for attributes without direct interaction with other objects, as this is done using
get-operations and give-operations. Write-operations and read-operations are included to
transfer Parameters or Exceptions to the Strategist during Occasional Management, and to
change the values of Parameters or to solve Exceptions as indicated by the Strategist.
6.3 Distributed system technology design

The technical design of the information systems for networked inventory management
consists for the other part of a distributed system technology (DST) design. This design
must be consistent with the object-oriented system technology (OST) design, because
together they specify the overall distributed object technology (DOT) design of NIMISs in
this study. The information systems must satisfy the technical requirements with respect to
distributed system technology. This means that they must use technology with local
computing, heterogeneous computing and transparent computing.
The distributed system technology design does not specify all technical details of
NIMISs. When mapped on the five viewpoints as distinguished in the reference model for
Open Distributed Processing (ODP), the distributed system technology design specifies
195
NIMISs mainly from the computational viewpoint [ITU/ISO, 1995] [ITU/ISO, 1996]
[Leydekkers, 1997]. Roughly speaking, the enterprise viewpoint of NIMISs is captured in
the networked inventory management design, whereas the information viewpoint is dealt
with in the object-oriented system technology design. The computational viewpoint, which
is concerned with the interfacing of distributed components, dominates in the distributed
system technology design. Further technical details, emerging in the engineering and
technology viewpoints, are hardly addressed in the distributed object technology design.
6.3.1 Common Object Request Broker Architecture

For the specification of the distributed system technology design, the Common Object
Request Broker Architecture (CORBA) is applied. CORBA itself is a specification of
standardised distributed system technology [Ben-Natan, 1995] [Mowbray, 1995] [Orfali,
1996] [Schill, 1996] [Siegel, 1996] [Baker, 1997] [OMG, 1998]. CORBA facilitates
seamless information processing in heterogeneous computer networks, which consist of
computers at different locations, and which may apply different hardware components,
operating systems and programming languages. CORBA specifies ‘middle-ware’ that
creates a transparent information processing platform, to which interacting system
components can be linked and can then communicate with each other through the middle-
ware. With the help of CORBA, the location of a component, its technology and distribution
complexities can be hidden from other components.
CORBA has been, and is being, developed by the Object Management Group (OMG),
an international organisation supported by hundreds of members, including hardware
vendors, software developers, user organisations and academic institutions. The goal of
OMG is to make standard specifications for distributed object technology, using a consensus
based approach. New specifications can only be adopted as standard if a product
implementation conforming to the specification is commercially available.
196
Computer Computer
Objects Objects
Operation
invocation
Application CORBA CORBA Application CORBA CORBA
objects Facilities Services objects Facilities Services
IDL interfaces IDL interfaces
IDL IDL IDL IDL

Stubs Skeletons Stubs Skeletons
ORB GIOP ORB

Core Core
Object Request Broker Object Request Broker
Figure 6-29 Common Object Request Broker Architecture
In Figure 6-29 an overview of CORBA is presented. Besides computers and a

communication network, there are three segments in the architecture: Object Request
Brokers (ORBs), Interface Definition Language (IDL) interfaces and objects. Objects
communicate with remote objects in IDL and via mediation by ORBs. In the segment of
ORBs, there is a distinction between ORB cores, non-core components and an inter-ORB
protocol. The IDL interfaces in CORBA consist of IDL Stubs and IDL Skeletons. Objects can
be categorised by their level of functionality in application objects, CORBA Facilities and
CORBA Services.
6.3.1.1 Object Request Brokers
Object Request Brokers (ORBs) are system components in CORBA that facilitate interaction
of objects that are distributed over systems [Ben-Natan, 1995] [Mowbray, 1995] [Blair,
1996] [Schill, 1996] [Siegel, 1996] [Baker, 1997]. In the CORBA object model, an object is
described as an identifiable, encapsulated entity that provides one or more services that
can be requested by a client. Objects in CORBA are described by the interfaces they present
to other objects. The interfaces are defined in the technology-independent Interface
197
Definition Language (IDL). The interfaces specify the services an object is prepared to
provide, the parameters they require, and any exceptions that might be generated.
A client object can request a service from (invoke an operation on) a remote server
object without having a notion of the location of the server object, its programming
language, or any other implementation detail. Client and server roles may change over
time, so an object can be both a client and a server. In order to access a service, a client
object issues a request that consists of the target object, required operation name and
optional parameters. A request from a client object to a remote server object is intercepted
by an ORB that supports the client object. The ORB determines the location of the server
object and forwards the request to the ORB that supports the server object. This ORB
prepares the server object to receive and process the request. Optionally, a result is
returned from the server object to the client object through the ORBs.
An ORB assigns an object reference to every CORBA object in a system, at the time of
object creation, that remains valid until the object is explicitly deleted. For the invocation
of a remote object, its object reference is used. The ORBs involved in the invocation
understand the object reference, and use it to find out the address of the object. The ORBs
keep track of the object references and their network and memory addresses. The object
reference of an object remains valid during its lifetime, even when it is moved across the
network.
An ORB consists of several components, amongst others: an Interface Repository, an

Implementation Repository, Object Adapters, an ORB Interface, an ORB Core, a Dynamic
Invocation Interface, Dynamic Skeleton Interfaces and the General Inter-ORB Protocol.
The Interface Repository is a persistent store of object interface definitions, specified in
IDL. The Implementation Repository maintains information needed by the ORB to locate
and start up the object implementations necessary to fulfil a request. Object Adapters
provide interfaces between the ORB and objects, allowing the ORB to prepare the objects to
receive a request, and allowing the objects to notify the ORB that they are ready to process
requests. The ORB Interface supports initialisation by providing client and server objects
with references to its ORB, Naming Service and Interface Repository, and by providing
access to the Implementation Repository.
The Dynamic Invocation Interface enables client objects to discover objects newly
added to the system at run-time, retrieve their interface definitions and invoke operations
on those objects. The Dynamic Skeleton Interface creates local interfaces on the ORB, for
objects whose implementation is on another ORB. An invocation of the remote object is
passed through the Dynamic Skeleton Interface to the ORB of the server object. The ORB
Core provides the basic communication of requests to the various components.
198
Communication between ORBs is arranged by the General Inter-ORB Protocol (GIOP). The
Internet Inter-ORB Protocol (IIOP) is an implementation of the GIOP over the Internet
communication standard TCP/IP (Transmission Control Protocol / Internet Protocol).
6.3.1.2 Interface Definition Language interfaces
Interface Definition Language (IDL) interfaces are system components that facilitate
interaction of objects that are programmed in different languages [Ben-Natan, 1995]
[Mowbray, 1995] [Blair, 1996] [Schill, 1996] [Siegel, 1996] [Baker, 1997]. The interfaces
that CORBA uses to describe objects are defined in the Interface Definition Language. The
interfaces specify the services an object is prepared to provide, the parameters they require,
and any exceptions that might be generated. IDL is a technology independent language
with mappings to programming languages such as C++, Smalltalk and Java.
IDL Stubs are the linking pins of client objects to an ORB, whereas IDL Skeletons
represent the connectors between server objects and an ORB. IDL Stubs and IDL Skeletons
are created by compiling the IDL source code that specifies the object interfaces. Client
objects generate requests in their native programming language, and server objects receive
the requests in their local language too. A client object sends a request to its IDL Stub,
whereas the server object gets the request through its IDL Skeleton. IDL Stubs and IDL
Skeletons translate at run-time the local language of the client and server objects to IDL
and vice versa.
The Interface Definition Language (IDL) is the common interface language in CORBA,
bridging the implementation specific programming languages in which client and server
objects are programmed. IDL is not a full programming language, but rather an external
specification language, as it incorporates syntax for declarations but lacks algorithmic
structures. IDL is a language in which every variable is declared to be a particular type.
An IDL interface definition is composed of a header and a body. The IDL interface
header names the interface and specifies an optional inheritance structure. The IDL
interface body contains declarations of data types, constants, operations, attributes and
exceptions. An operation is built of its name, return type of the operation, and a list of
parameters. A parameter declaration consists of the parameter name, a type declaration
and a variable denoting its direction as incoming or outgoing. In IDL, an attribute declares
functions that allow client objects to set and retrieve the value of the attribute. Declared
exceptions can be raised by operations in the IDL interface, in case of difficulties.
A language mapping defines one-to-one correspondences from IDL constructs to
programming language constructs. A language mapping has to express all of the
constructs of IDL. All mappings provide means to express IDL data types, constants,
199
operations, attributes and exceptions. They also must provide access to the functionality of
ORBs and must fix responsibility for memory allocation and freeing. Instead of making
programming language code fit to the IDL specifications, there is also the possibility to
automatically generate IDL from the source code of the client and server objects.
6.3.1.3 Services and Facilities
CORBA Services and CORBA Facilities are two special object categories included in CORBA,
which further support the development and application of distributed systems [Ben-Natan,
1995] [Mowbray, 1995] [Blair, 1996] [Schill, 1996] [Siegel, 1996] [Baker, 1997]. While
the CORBA Facilities give support to issues at the application level, the CORBA Services
support implementation issues at the infrastructure level. CORBA Services are low-level
services, which provide standard functionality for the management of technical
complexities in distributed systems, such as identification, transactions, security and
storage. The CORBA Services are useful in most applications and are accessible from every
client object.
One of the CORBA Services is the Object Lifecycle Service, which defines services
and conventions for creating, deleting, copying or moving objects. The Relationship
Service manages relationships between objects, characterising the relationships by type,
roles, degree, cardinality and semantics. The Persistent Object Service standardises the
storage and retrieval of the persistent state of an object, to guarantee that every object state
remains unchanged from one invocation to the next. The Externalisation Server defines
interfaces, protocols and conventions for recording and playing back a state of an object as
a standardised stream of data, that can either be captured on a recording medium or sent
over a network.
The Naming Service provides client objects with the service to get references to
objects elsewhere on the system. As soon as a client connects to the ORB, it can invoke a
standard call to retrieve the object reference for the Naming Service itself. From that
reference, a client object can get references to other server objects which are connected to
the ORBs in a network, and it can request their services. Clients use the Naming Service to
find server objects and use an IDL Skeleton to access them. The Trader Service is a service
which can find objects and services that comply to specified constraints. Besides the object
references, the Trader Service has extra information on services, such as costs per service,
the location it runs at, or syntax details. Client objects can invoke the Trader Service to
detect new server objects which become accessible for the client object at run-time via the
Dynamic Invocation Interface.
The Event Service provides communication semantics to notify objects of events
which take place in other objects. The Transaction Service gives transaction semantics
200
which define the conditions guaranteeing that, for a sequence of operations, the result
always meets the requirements of atomicity, consistency, isolation and durability. The
Concurrency Service is a facility to manage the locking of objects, to restrict concurrent
access to objects.
The Property Service gives client objects the ability to create and delete properties
from objects, and to get and set their values. The Query Service unifies CORBA objects,
object-oriented databases, relational databases and files into a single query target. The
Security Service provides functionality for identification, authentication, authorisation and
auditing. The Licensing Service offers a generic set of interfaces that can be used to
provide access to software using licenses.
CORBA Facilities provide helpful services at the application level. The CORBA Facilities are
divided into horizontal and vertical facilities [Siegel, 1996] [Baker, 1997]. Horizontal
facilities are independent of the application domain, whereas vertical facilities are
specialised for an application domain.
Horizontal CORBA Facilities are divided into four categories. The User Interface
Facility makes information accessible to its users and responsive to their needs. The
Information Management Facility supports modelling, defining, storing, retrieving,
managing and interchanging information. The Systems Management Facility provides
functions to manage complex information systems. The Task Management Facility
automates work flows, including both user and system processes.
Vertical CORBA Facilities are under development for some application domains.
The application domains currently addressed are: health care, telecommunications,
financial services, manufacturing, transport and electronic commerce. The Vertical CORBA
Facilities define services that helps the development of domain specific applications.
6.3.2 Distributed system technology properties

The second part of the distributed system technology design of NIMIS is the explanation of
their properties related to distributed system technology. These properties result from the
distributed system technology model, which specified the distributed system technology in
the information systems. Within the Common Object Request Broker Architecture, Object
Request Brokers arrange messaging across distributed objects. Interface Definition
Language interfaces can link components which make use of different types of technology.
CORBA Services and CORBA Facilities further support the development and application of
distributed information systems. The resulting properties concern the use of technology
with local computing, heterogeneous computing and transparent computing.
201
6.3.2.1 Local computing
One of the technical requirements for NIMISs is their use of technology with local
computing. Local computing implies that information processing which is needed to
provide a particular function that logically belongs to a certain location, can physically be
executed by computer resources at that location. So, functions for local purposes can be
accomplished by local resources, while functions performed for different locations can be
distributed over different computers.
202
Local Local Local

processor processor processor
Local Local Local

memory memory memory
Local Local Local Local

memory memory memory memory
Local Local Local Local

processor processor processor processor
NIMIS S3
S1 NIMIS S2 NIMIS C2 NIMIS C3
Figure 6-30 Local processors and memories for local computing
The local computing property of the information systems is explained with the help of a
network of NIMISs, as presented in Figure 6-30. The network represents the configuration
of NIMISs as presented earlier in the NIMIS network instance diagram of Figure 6-16. The
seven NIMISs in the configuration run on seven computers that are linked together by a
communication network. Each of these computers is a set of resources at one location, for
processing information to perform certain functions in the NIMISs. Information processes
carried out by each computer are transformation of information through a processor and
storage of information in a memory. The transport of information across the NIMISs is
arranged through sending and receiving messages between the computers over the
communication network.
The core functionality of a NIMIS is networked inventory management, comprising
a set of local functions that address the management of the inventory level of a single SKU
stock-point (SSS) at a particular location. In conformance with the local computing
property, these local functions can be provided by a computer that resides at the same
location as the SSS for which the inventory level is managed. When there are several SSSs
at one location, their networked inventory management is accomplished by an equal
number of NIMISs. For local computing, each single NIMIS could run on a separate local
computer, so having its own physical resources for information processing. Alternatively,
the NIMISs at one location can make use of one and the same local computer, thus
physically sharing the computer resources.
203
The information processing of a NIMIS can be executed by a local computer, which

is built of a local processor and a local memory. The transformation of information in a
NIMIS, for the networked inventory management of a single SKU stock-point, can be carried
out by the local processor, whereas the information storage can be arranged by the local
memory. The information transformation in a NIMIS concerns the computation of new
values of attributes, as well as the management of retrieval and storage of information. To
do this, the local processor performs compute-operations, as well as get-operations, give-
operations, write-operations and read-operations. The storage of information in a NIMIS
includes the registration of information coming in from external systems, generated
internally and going to external systems. The local memory preserves the attributes in a
NIMIS and contains the program code needed by the processor to perform its operations.
6.3.2.2 Heterogeneous computing
One of the technical requirements for NIMISs is their use of technology with heterogeneous
computing. Heterogeneous computing implies that information processing can be executed
by computers that are based on different types of techniques, with respect to programming
languages, operating systems and hardware components. So, one computer in a distributed
system can consist of a particular combination of techniques, while another computer in
the network can be built of a different set of techniques.
IDL IDL IDL

interfaces interfaces interfaces
Virtual Virtual Virtual

machine machine machine
Virtual
Local Virtual Virtual Virtual
machine
memory machine machine machine
Local
IDL IDL IDL IDL
processor
interfaces interfaces interfaces interfaces
NIMIS S3
Figure 6-31 IDL interfaces and virtual machines for heterogeneous computing
204
The heterogeneous computing property of the information systems is explained with the
help of a network of NIMIS as presented in Figure 6-31, representing a part of the NIMIS
network instance diagram of Figure 6-16. The NIMISs can run on computers at different
locations. In conformance with the heterogeneous computing property, these computers
can be built of different types of techniques. Heterogeneous computing in a network of
NIMISs is arranged with the help of IDL interfaces and virtual machines at all computers in
the network of NIMISs.
The Interface Definition Language (IDL) interfaces make it possible to apply
different programming languages in different systems. For every object in a local system
that interacts with remote objects, an IDL interface is specified that translates the
implementation specific programming language to the implementation neutral Interface
Definition Language. When an object at a local system sends a message to invoke an
operation on an object at a remote system, the message is translated at the local system
from its specific programming language to IDL, then it is transferred to the remote system,
where it is translated again from IDL to the programming language of the remote system.
For heterogeneous computing with the help of IDL interfaces, mappings between the
programming languages and IDL are used.
Virtual machines make it possible to have NIMISs running at computers that are
built of different hardware components and different operating systems. The NIMISs in a
network each have a virtual machine that can connect the application specific software to
the particular operating system and hardware components of the local computer. A virtual
machine is a piece of software consisting of machine code, conceptually working on top of
the hardware and operating system. The virtual machine provides an homogeneous
information platform to the application specific software, irrespective of the underlying
hardware and operating system. Virtual machines themselves are specific to hardware
components, operating systems and programming languages.
6.3.2.3 Transparent computing
One of the technical requirement for NIMISs is their use of technology with transparent
computing. Transparent computing implies that technical complexities due to distribution
of system components are hidden from the application specific components in distributed
systems. This hiding of complexities concerns several types of transparencies, amongst
others, location transparency, transaction transparency and persistence transparency
[ITU/ISO, 1995] [ITU/ISO, 1996] [Leydekkers, 1997]. Location transparency for example,
ensures that system components can be addressed by functional and logical names instead
of their technical and physical locations.
205
CORBA CORBA CORBA

Services Services Services
ORB ORB ORB
Local
ORB ORB ORB ORB
memory
CORBA
Local CORBA CORBA CORBA
processor
Services Services Services Services
NIMIS S3
Figure 6-32 ORBs and CORBA Services for transparent computing
The transparent computing property of the information systems is explained with the help
of a network of NIMIS as given in Figure 6-32, representing a part of the NIMIS network
instance diagram of Figure 6-16. The NIMISs can run on computers at different locations.
In conformance with the transparent computing property, the application specific objects
do not have to manage the technical complexities in distributed systems. Transparent
computing is arranged with the help of Object Request Brokers (ORBs) and CORBA Services
at all computers in the network of NIMISs.
The ORBs in the computers make it possible to exchange information between local
and remote system components, irrespective of their locations. An ORB manages object
references and uses them to exchange information across distributed system components.
To every component of a NIMIS which is involved in remote information exchange, the
ORB of the local computer assigns an object reference, at the time of creation of the
component. For the interaction between remote system components, their object references
are used. The ORBs involved in the interaction understand the object references and use
them to find out the address of the components. The ORBs keep track of the object
references and their network and memory addresses. The object reference of a NIMIS
component remains valid during its lifetime, even when it is moved across the network.
The CORBA Services together with ORBs can provide, amongst others, location
transparency, transaction transparency and persistence transparency. Location
206
transparency hides the distribution in space of system components. For location

transparency, the Naming Service of CORBA arranges that the application specific
components in a NIMIS do not have to maintain the technical addresses of the objects over
the network. Instead they can exchange information with a remote system component by
specification of its logical name, irrespective of its physical location. The Naming Service
registers the names of system components and connects them to object references. A local
system component can invoke a remote component by its name, because the Naming
Service relates the name to the object reference of the remote system component. The local
component invokes the Naming Service, which sends the object reference of the remote
component to the local component. The local component then uses the object reference to
address the remote component. The object reference is used by the ORBs to locate the
remote component.
Besides location transparency, the CORBA Services can also arrange transaction
transparency and persistence transparency. Transaction transparency hides the co-
ordination of activities among a configuration of objects, to achieve consistency. The
Transaction Service defines the conditions guaranteeing that, for a sequence of operations,
the result always meets the requirements of atomicity, consistency, isolation and
durability. The Transaction Service manages the commitment and abortion of transactions
with a two-phase commit protocol between the objects involved. Persistence transparency
hides the de-activation or re-activation of an object from other objects. The Persistent
Object Service standardises the storage and retrieval of the persistent object state of an
object to guarantee that every object state remains unchanged from one invocation to the
other. The Persistent Object Service defines how an object must communicate with a
database in order to store the object into the database and to restore the object from the
database.
6.4 Conclusion
The distributed object technology design constitutes the technical design of NIMISs. The
technical design consists of a distributed system technology design and an object-oriented
system technology design.
The object-oriented system technology design is created with the help of the Object
Modelling Technique (OMT). Hence, NIMISs are specified in an object model, a dynamic
model and a functional model. In the object model five core objects are identified. The
dynamic model includes state diagrams for the core objects as well as event trace diagrams
for two scenarios. In the functional model, the processes that compute new values are
207
specified in a data flow diagram, while computation formulae are specified as system
equations in the functional design.
The object-oriented system design satisfies the technical requirements of object
classification, attribute encapsulation and operation invocation. Object classification is
accomplished by specifying a NIMIS as a set of interacting object classes and instances.
Attribute encapsulation is based on storage of data in attributes, which can only be
accessed through access operations. Operation invocation is arranged by performing
functions in operations, which are executed in response to the receipt of messages.
Because of these properties, the information systems can naturally reflect the structure,
data and functions of networked organisations and their integral inventory management.
The distributed system technology design is created with the Common Object
Request Broker Architecture (CORBA), which includes Object Request Brokers (ORBs),
Interface Definition Language (IDL) interfaces and several types of objects. ORBs are
system components that facilitate interaction of objects that are distributed over systems.
IDL interfaces enable interaction of objects that are programmed in different languages.
CORBA Services and CORBA Facilities offer additional support for the development and
application of systems built of distributed objects.
The distributed system technology design satisfies the technical requirements of
local computing, heterogeneous computing and transparent computing. Local computing
is accomplished by using a local processor and a local memory, for one or more NIMISs at a
location. Heterogeneous computing is realised using IDL interfaces and virtual machines,
that allow interaction across different programming languages, hardware components and
operating systems. Transparent computing is arranged using ORBs and CORBA Services,
which hide technical complexities related to, amongst others, locations, transactions and
persistence. Because of these properties, networked organisations can achieve integration
across locations, while preserving autonomy over their own functions and data, the
techniques of their systems and the management of technical complexities.
208
Chapter 7 Prototype system implementation
7. Prototype system implementation
7.1 Introduction
In this chapter, a technical implementation of the information systems in a particular
environment of information technology is explained. The inputs for the prototype system
implementation are the distributed object technology design (Chapter 6), and implicitly
the case study implementation (Chapter 4). The outputs of the prototype system
implementation are a description of a technical system environment and a demonstration
of the operation of the information systems in the particular environment of information
technology.
In section 7.2, the information technology in a real-life network of computers is
described. Both the applied prototype tools and the specific prototype objects are
addressed. Section 7.3 is dedicated to the operation of the prototype NIMISs in a network by
exploiting distributed object technology. After an explanation of the installation of the
prototype systems in a computer network, the use of the prototype NIMISs is discussed.
7.2 Information technology

A prototype system has been constructed in order to show how the distributed object
technology design of the information systems fits into a particular environment of
information technology. The implementation of the prototype NIMIS has been carried out in
two projects. The first project focused on exploration of available tools and a rough
implementation of system components [Toia, 1997]. In the second project, the details of
209
Prototype system implementation Chapter 7
the systems were implemented and the components were integrated into a running system
[Hof, 1997].
In the prototype NIMISs, distributed object technology is exploited for networked
inventory management. First, the information technology in the prototype systems is
discussed. Attention is paid to the tools for building and running the systems in computer
networks. Secondly, the objects that are specific to the prototype systems are explained.
These prototype objects concern user-interfaces and technical implementation details.
7.2.1 Prototype tools

With the help of distributed object technology, a prototype NIMIS has been implemented.
For the implementation of the prototype system, three interrelated tools are used:
Smalltalk, Visual Works and Distributed Smalltalk. In Figure 7-1 the tools for the
implementation of a network of prototype NIMISs are illustrated.
Smalltalk is a programming language and programming environment that is fully
object-oriented. Visual Works is an extension of Smalltalk, with standard object classes for
user-interfaces and with facilities to construct applications. Distributed Smalltalk is an
extension of Visual Works with CORBA technology, facilitating interaction of distributed
objects. Both the tools and the resulting information systems make use of a computer
platform, consisting of computers that are interconnected via a communication network.
Computer X Computer Y
Visual Works Visual Works
Smalltalk Smalltalk
Distributed Smalltalk Distributed Smalltalk
Figure 7-1 Tools for a network of prototype NIMISs
210
Smalltalk is an object-oriented programming language, in addition to being an interactive

programming environment, including a library of object classes [Goldberg, 1985]
[Rumbaugh, 1991] [Hopkins, 1995]. The Smalltalk language is uniformly object-oriented,
as objects are employed to represent everything in Smalltalk, including all the
conventional data types that may be found in any programming language, such as integers,
booleans, floating-point numbers, characters, strings and arrays. In addition, objects are
used to represent display items such as buttons, menus and windows. The language, the
class library and even the programming environment itself, consist of objects.
In Smalltalk, attributes are called variables, operations are represented as methods
associated with classes, and invoking operations is known as sending messages. Objects in
Smalltalk interact by sending messages that consist of the name of the method to be
executed together with a list of argument values. A new object instance is created by
sending a message to an object class, an object that describes the class itself. All variables
in Smalltalk are objects, including the pseudo-variable ‘self’, which is used in Smalltalk to
refer to the receiver of a message.
The Smalltalk class library contains hundreds of classes and thousands of methods,
all available on-line in source code. The available classes, together with the inheritance
principle, can be used to construct new classes. The library includes classes for numbers,
data structures, text, font, colour and geometric representations.
The Smalltalk programming environment consists of programming tools for:
editing source code, compilation, debugging, system integration, testing and change
management [Hopkins, 1995] [Goldberg, 1985]. The System Browser class allows class
descriptions in the system to be viewed and edited. The Workspace class is a tool for
testing Smalltalk code before building it into the code library. The Notifier class is used to
provide a simple description of the process at the time an error occurs. The Debugger class
is the tool that gives a more detailed view of an error, and provides the ability to change
the state of a suspended process before resuming it. The Inspector class provides a view of
the attributes of an object.
Technically, the Smalltalk system consists of two parts: a virtual image and a
virtual machine. The virtual image contains all classes in the system, whereas the virtual
machine consists of machine code routines to give dynamics to the objects in the image.
This technique is used to ensure portability of the virtual image. A virtual image is
executable on any virtual machine, because the image is isolated from the implementation
of the virtual machine. Almost all of the functionality is in the virtual image, so the virtual
machine is relatively lean. Because the complete working environment is saved in an
image, Smalltalk also acts as a persistent object store. This allows the creation of new
classes and instances, which can be kept between working sessions.
211
Visual Works is an extension of Smalltalk, with standard object classes for user-interfaces
and with facilities to construct applications [ParcPlace, 1994] [ParcPlace, 1996]. The
capabilities of Visual Works are implemented in the Smalltalk programming language, so
Visual Works is also fully object-oriented. A pre-defined application framework is
available in Visual Works, which can be adapted to create new applications.
In Visual Works, applications can be conceptually divided into two layers. One
layer contains domain objects, which define and manipulate data structures. Domain
objects simulate the state and behaviour of real-world objects in the application domain,
which is the area being supported by the information system. The other layer consists of
user-interface objects, which present data from the domain objects and enable users to
interact with this data. User-interface object are the objects that make up a display screen,
consisting of windows and so-called ‘widgets’. Widgets are control elements such as input
fields, action buttons and scrollable lists.
The layering of domain and user-interface objects promotes the re-use of existing
domain objects in different systems. It also facilitates maintenance because domain objects
tend to be relatively stable, whereas user-interface objects may require considerable
revision from one release to the next.
The creation of a graphical user-interface in Visual Works starts with opening a
canvas, a window under construction that is configured until it complies to the
requirements for the application. A canvas tool is available to tune the appearance of the
canvas and to invoke additional canvas preparation tools. A palette of standard widgets is
offered to fill in the canvas with control elements. For each widget, properties such as font,
colours, borders and data types can be set.
Installation of the canvas creates an interface specification through which the user-
interface objects can be connected to domain objects. Whereas a canvas is a graphical
depiction of the contents and layout of a window, an interface specification is a symbolic
representation that domain objects can interpret. Each interface specification is a formula
for generating an operational window that contains particular widgets.
The graphical user-interface is further programmed by linking widgets in the
windows to domain objects, to either display a particular piece of information or to
perform a particular action. Action widgets send messages to domain objects requesting
that an operation be carried out. Data widgets display data of domain objects or collect
data from users.
Distributed Smalltalk is an extension of Visual Works with CORBA technology, to facilitate

interaction of distributed objects [Keremitsis, 1995] [ParcPlace, 1996] [Siegel, 1996].
212
Distributed Smalltalk is a combined programming and run-time environment for

development and deployment of distributed applications. To facilitate distributed
applications, the object classes provided by Smalltalk and Visual Works are supplemented
with object classes for CORBA. By building applications with Distributed Smalltalk,
systems that run on different hardware components and operating systems are allowed to
co-operate. An application running in Distributed Smalltalk may be distributed over
several systems, because the distributed objects can interact seamlessly across their
locations.
The Distributed Smalltalk version that is used for the prototype NIMISs is an
implementation of CORBA version 2.0, a standard issued by the Object Management
Group. The Object Request Broker (ORB) in Distributed Smalltalk provides inter-
operability between different ORBs from different vendors, written in different languages
and running on different platforms. Distributed Smalltalk comprises CORBA Services for
Initialisation, Naming, Lifecycle, Event Notification, Concurrency Control and
Transaction. Extra services include Compound Lifecycle, Relationships and Properties.
For communication to other ORBs, Distributed Smalltalk includes the Internet Inter-ORB
Protocol (IIOP), which enables objects to inter-operate over a communication network with
other applications using CORBA.
An application written in Distributed Smalltalk is able to process service requests
with remote systems [Keremitsis, 1995] [ParcPlace, 1996] [Siegel, 1996]. Objects for
which an IDL interface has been defined, can be accessed transparently by other objects
that have an IDL interface. These CORBA objects can communicate with CORBA objects that
may be in the same local image, or in any other image running either locally or remotely.
Remote objects that request services from the system need not be written in Distributed
Smalltalk, as long as they are in a system that makes use of CORBA.
A message that is sent by a local client object to a remote server object, is translated
by the IDL Stub of the client object from the Smalltalk language to the Interface Definition
Language. The translated message is intercepted by the ORB, which uses CORBA Services to
locate the remote object. The ORB supporting the client object then forwards the request to
the ORB that supports the remote server object. The IDL Skeleton of the server object
translates the request from IDL to the programming language of the server object. To
complete the request, the server object may send a return value to the client object via the
involved IDL Skeleton, the ORBs and the IDL Stub.
In Distributed Smalltalk, distributed applications are usually created in steps. First,
a complete local application is built and tested in one image. Then, an IDL generator is
used to generate IDL interfaces for the objects that need to communicate with remote
objects. The IDL interfaces are registered in an Interface Repository. Thereafter, the parts
213
of the application that have to run at other locations are moved to images at those
locations. Finally, the Interface Repositories of the local images are updated. The
application can then run in the distributed environment. For delivery of the final version,
the images can be stripped, that is, all objects and tools which are no longer needed, are
removed from the image, without alteration of the constructed application.
214
7.2.2 Prototype objects

The prototype NIMIS consists partly of application objects, that are specific to the
application of the information systems. The other system components, like the ORBs, IDL
interfaces and CORBA Services are generic to all types of applications. In Figure 7-2 the
types of application objects in the prototype NIMIS are shown, including the surrounding
systems in the environment of the prototype NIMIS.
The application objects of the prototype NIMIS can be categorised into user-interface
objects and domain objects. Application objects occur in the prototype NIMIS itself, but also
in systems representing the environment of the prototype NIMIS: the customer system, the
operational process and the supplier system. The prototype NIMIS is controlled by a
strategist, while the operational process is maintained by an operator. In the prototype
implementation, customer strategists and supplier strategists control the customer systems
and supplier systems respectively. The strategists and operators represent human beings,
so they are not implemented as objects in an information system.
Strategist
Supplier Customer
strategist strategist
NIMIS
User-interface
Supplier objects Customer
system system
Domain
objects
Operational
process
Operator
Figure 7-2 Application objects in the prototype NIMIS
Domain objects are the objects of a system in which its core functionality and information
resides. The main domain objects of the prototype NIMIS are specified in the networked
inventory management design and include: Customer Manager, Supplier Manager,
215
Operational Manager, Strategic Manager and Inventory Manager. For each single SKU
stock-point managed by a prototype NIMIS, there is one instance of each of those classes.
Those five domain objects conform to the attributes, operations and relationships as
specified in the design.
In addition to the five major domain objects, there are several types of minor
domain objects, which are needed for the specific prototype implementation. Examples of
those implementation specific domain objects, are the attributes of the five main domain
objects in the networked inventory management design. Because the prototype NIMIS is
implemented in Distributed Smalltalk, all these attributes are objects themselves. Other
implementation specific domain objects are orders and plans that are implemented to
capture the data structure of many attributes of the main domain objects.
In addition to the operations specified in the design, extra operations are included
in the prototype NIMIS for object creation, instance initialisation and CORBA invocation.
Extra attributes are implemented to link domain objects to user-interface objects. In
Distributed Smalltalk, the programming code of an object starts with the name of the
object class and the name of the class from which it inherits attributes and operations.
Then, the attributes of the object are given, followed by the code for its methods.
Objects within one prototype NIMIS mutually interact in a direct way, that is,
messages invoking an operation go directly from the sending domain object to the
receiving domain object. For communication with the strategist, the domain objects
interact via user-interface objects. For the interaction with remote objects, the domain
objects communicate via ORBs. IDL interfaces are implemented for the domain objects that
invoke, or are invoked by, remote objects.
Customer Manager and Supplier Manager are domain objects with IDL interfaces,
which are registered in the Interface Repository of the ORB, and used to generate IDL Stubs
and IDL Skeletons. IDL interfaces are also defined for the parameters that are included in
remote operation invocation. In the prototype implementation, those parameters are orders
and plans. The Supplier Manager of a prototype NIMIS sends its Individual Supplier
Demand Order (ISDO) or Plan (ISDP) to the Customer Manager of another prototype
NIMIS. The Supplier Manager is a client object that invokes the operation ‘get Individual
Customer Demand Order’ or ‘get Individual Customer Demand Plan’ at the Customer
Manager of another NIMIS, which acts as a server object.
When a server object is remote, the message is sent by the client object to an object
reference that is provided by the Naming Service. The object reference acts as a publicly
available surrogate for the remote object. Since the surrogate object can not implement the
invoked operation, the ORB of Distributed Smalltalk uses dedicated mechanisms to locate
and communicate with the remote object.
216
User-interface objects are the objects facilitating interaction between a user and the
domain objects of an information system. The user-interface objects of the prototype NIMIS
enable the strategist to control the system. Instead of direct access to domain objects, the
strategist interacts with the domain objects via user-interface objects, including windows,
menus, buttons and fields. Because the prototype NIMIS is implemented in Distributed
Smalltalk, all elements in the user-interface of system are objects, which together make up
the user-interface. To enable a strategist to control the prototype NIMIS, the user-interface
translates actions undertaken by the strategist to operation invocations in the domain
objects. On request of the strategist, the user-interface presents information from the
domain objects in the user-interface.
The user-interface objects of the prototype NIMIS have not been defined in the
design, as they can be devised independently during implementation. Although the syntax
of the user-interface objects is equal to the syntax of domain objects, the code is generated
in a different way. Instead of typing in code lines, the user-interface program code is for
the main part, created with the help of a graphical programming tool that is part of Visual
Works. The user-interface objects are partly programmed by pointing and clicking
windows and controls. The tool also assists in the connection of the user-interface objects
to the domain objects, so that the correct operations are invoked and the correct attributes
are used.
The user-interface of the prototype NIMIS consists of three core windows: a Main
window, a window for Occasional Management and a window for Regular Management.
The Main window of the prototype NIMIS is automatically opened after starting the system
and offers the possibilities to continue with Regular or Occasional Management, or to shut
down the system. The Main window contains three action buttons, to select a management
mode or to quit the system. Pressing an action button invokes an operation in an object.
The window for Occasional Management supports the setting of parameters and the
handling of exceptions. It is built of scrollable lists to show the status of the Customer
Manager, Supplier Manager, Operational Manager, Inventory Manager and Strategic
Manager. The lists show the names and values of the parameters of these domain objects.
Action buttons are available to set new values for the parameters.
The window for Regular Management shows the regular activities in the system
and provides options for intervention in the system operation. The window for Regular
Management consists of two scrollable lists for Individual Customer Demand Orders
(ICDOs) and Plans (ICDPs), as well as two lists for Individual Supplier Demand Orders
(ISDOs) and Plans (ISDPs). The window contains also action buttons to check and
approve the plans.
217
Environment objects are the objects in the prototype implementation that occur in the
environment of the prototype NIMIS. The environment objects for the prototype NIMISs
represent other types of systems to which the prototype NIMISs can be related. Those
objects simulate the environment of the prototype NIMISs. The main environment objects in
the prototype implementation are the operational process, customer systems and supplier
systems.
The operational process in the prototype implementation is regarded as an
independent system that is maintained by an operator. The operational process registers
the Actual Inventory (AI), Actual Demand (AD) and Actual Supply (AS), and gives these
values to a prototype NIMIS on request. The operational process also processes Output
Process Orders (OPOs) as well as Input Process Orders (IPOs) that come from the
prototype NIMIS. The functionality is provided by domain objects of the operational
process. User-interface objects in the operational process enable the operator to execute
Regular or Occasional Management. Regular Management by the operator involves the
monitoring of the process, while Occasional Management concerns the manual change of
attribute values in the operational process and the handling of exceptions.
Customer systems and supplier systems are included in the prototype
implementation to simulate incoming demand from customers and outgoing demand to
suppliers. Customers and suppliers are implemented as customer systems or supplier
systems, either when it is known that they do not make use of NIMISs or when they are
outside the scope of the network. A customer system or supplier system is regarded as an
independent system that is controlled by a strategist. A customer system generates orders
or plans and sends this information to a prototype NIMIS, whereas a supplier system
absorbs orders and plans coming from a prototype NIMIS.
The functionality of the customer systems and supplier systems is provided by their
domain objects. A strategist interacts with the domain objects of its customer system or its
supplier system via user-interface objects. Again, the user-interface includes a Main
window, a window for Occasional Management and a window for Regular Management.
In the Occasional Management window, parameters can be set and exceptions can be
handled, while in the Regular Management window, the regular process can be monitored
and manipulated.
218
7.3 System operation

In order to show how the distributed object technology design fits into a particular
environment of information technology, the operation of NIMISs using the prototype tools
and prototype objects is demonstrated. First, the installation of prototype NIMISs in
computer networks is explained. Using a network of prototype NIMISs, single SKU stock-
points from different organisations in supply chains can be covered. In addition, the use of
the prototype NIMISs in a real-life computer network is discussed. The operation of the
prototype NIMISs is presented from the user’s point of view, showing the interaction
between the strategist and the system, through the user-interface.
7.3.1 Prototype installation

A network of prototype NIMISs is needed to achieve networked inventory management with
the help of the information systems. For integral inventory management across the
networked organisations in particular supply chains, a prototype NIMIS is installed for
every single SKU stock-point (SSS) that needs to be managed. In this way, a network of
prototype NIMISs can be installed that exactly reflects the configuration of SSSs as
encountered in the supply chains. The use of distributed and object-oriented system
technology allows that the prototype NIMISs are extremely basic and loosely coupled
information systems, which provide the integration and flexibility as required for
networked inventory management.
Installation of the prototype NIMISs encompasses the preparation of the computer
hardware, operating system, communication network and software before actually running
the systems. The prototype NIMISs, as well as the systems simulating the environment, run
on Personal Computers (PCs) that are equipped with Pentium-processors and have
Windows NT as their operating system. The PCs are interconnected through a
communication network based on the Internet communication standard TCP/IP
(Transmission Control Protocol/ Internet Protocol). TCP is a connection-oriented protocol,
at the transport layer (layer 4) of the OSI reference model. TCP makes use of IP, a
connectionless protocol, at the network layer (layer 3) of the OSI reference model [Jong,
1997].
The software for the prototype implementation is provided to the user in two files,
one containing an image and the other a virtual machine. The image contains all objects
of a prototype NIMIS, as well as an operational process, a customer system and a supplier
system, which can be used for simulation of the environment of the prototype NIMIS. The
objects include user-interface objects, domain objects and CORBA related objects. The
virtual machine contains the machine code that is needed to run the image on the specific
219
computer platform. The type of hardware and the type of operating system determine what
type of virtual machine is needed. Smalltalk virtual machines are available for all major
hardware and operating systems. The files with the image and the virtual machine are
stored on the computer where a system has to operate.
A user can then open the image together with the virtual machine. From the open
image, a user starts up the Object Request Broker (ORB) for that computer, and
synchronises the ORB with the ORBs of other computers in the network. In the image, the
user then starts one or more prototype systems that have to run on the computer. Multiple
NIMISs, operational processes, customer systems and supplier systems could be installed on
the same computer.
Strategist Strategist
S1 C1
NIMIS S1 NIMIS C1
S11 C11
Supplier Operational Operational Customer

system S11 Process S1 Process C1 system C11
S11 S11
Operator Operator
S1 C1
S21 Strategist Strategist Strategist C21
S2 X1 C2
Supplier Customer
system S21 system C21
Operational Operational Operational

Strategist Process S2 Process X1 Process C2 Strategist
S22 S11 S11 S11 C22
Operator Operator Operator
Supplier S2 X1 C2 Customer
system S22 system C22
S3 C3
NIMIS S3 NIMIS C3
S31 C31
Supplier Operational Operational Customer

system S31 Process S3 Process C3 system C31
S11 S11
Operator Operator
S3 C3
Figure 7-3 Network of prototype systems in imaginary supply chains
220
In Figure 7-3 a network of prototype systems is shown for some imaginary supply chains.
The network reflects the configuration of systems as presented in the NIMIS network
instance diagram of Figure 6-16. The overall network is composed of prototype NIMISs and
systems in their environment, including operational processes, customer systems and
supplier systems. The systems can be installed anywhere on a network of PCs that are
interconnected through an Internet based communication network. The seven NIMISs,
controlled by strategists, manage the inventory of the single SKU stock-points in the
operational processes. The operational processes are systems that simulate the physical
processes, while the strategists represent the users supervising the NIMISs. Four customer
systems and four supplier systems are at the boundaries of the network. The customer
systems and supplier systems simulate the sources and sinks of demand respectively. Like
the prototype NIMISs, each customer system and supplier system is controlled by a
strategist.
221
Intranet
PC
Prototype
Internet NIMIS
Customers
Consumer outlet 1
in The Netherlands
PC
Prototype
NIMIS
Intranet
Customers
PC
Consumer outlet m
Prototype in The Netherlands
NIMIS
PC PC PC
Suppliers
Prototype Prototype Prototype
NIMIS NIMIS NIMIS
Crystal components
in Hong Kong
Customers
PC
Finished products Distribution centre Telesales outlet
Prototype in Hong Kong in The Netherlands in The Netherlands
NIMIS
PC
Suppliers
Prototype
NIMIS
Plastic components
in Hong Kong
Customers
Business outlet 1
in The Netherlands
PC
Prototype
NIMIS
Customers
Business outlet n
in The Netherlands
KPN Telecom
Goods flow Information flow Networked organisation
Figure 7-4 Network of prototype NIMISs in supply chains for cordless telephones
In Figure 7-4 a network of prototype NIMISs in the supply chains for cordless telephones is
presented. Integral inventory management across the networked organisations can be
achieved in the real-life supply chains by multiple installation of the prototype NIMISs on
PCs that are linked together by an Internet based communication networks. A copy of the
prototype NIMIS is installed for every single SKU stock-point in the network. For providing
networked inventory management in the supply chains for cordless telephones, the
information systems exploit distributed system technology. The prototype NIMISs make use
222
of local computing, heterogeneous computing and transparent computing, as well as object

classification, attribute encapsulation and operation invocation.
7.3.2 Prototype use

The prototype NIMISs can provide functionality for networked inventory management by
their exploitation of distributed object technology. A network of prototype NIMISs can be
used for integral management of the inventory levels of single SKU stock-points across
networked organisations in supply chains. The actual users who operate the prototype
NIMISs are the strategists who supervise the systems. Therefore, the use of a prototype
NIMIS is explained from the viewpoint of its strategist. Main modes of operation in the
prototype system are Occasional Management and Regular Management.
Figure 7-5 Main window in a NIMIS
As soon as a user starts a prototype NIMIS, the Main window as shown in Figure 7-5, is
displayed to the user. In the text line at the top of the window, the type of window and the
unique name of the prototype NIMIS are revealed. From the Main window, the user can
proceed with Occasional Management or Regular Management, or can shut down the
system, by clicking one of the action buttons. At the start of the system operation,
223
Occasional Management is needed to connect the prototype NIMIS to other systems in the
network and to set the parameters of the system. The use of prototype NIMISs for
Occasional Management and Regular Management is explained below. Operational
processes, customer systems and supplier systems are operated in a similar way.
Figure 7-6 Window for Occasional Management
Occasional Management is one of the two main modes of operation in a prototype NIMIS. It
includes the setting of new values for parameters of application objects in the prototype
NIMIS, as well as the handling of exceptions generated by the application objects.
Occasional means that this function is not executed on a regular basis by definition, but
only at the instruction of the strategist or when exceptions occur. When running a
prototype NIMIS, the user can choose for Occasional Management at any time.
As soon as the user selects Occasional Management from the Main window, or in
the window for Regular Management, a window for Occasional Management as shown in
Figure 7-6, is presented to the user. The top line gives the type of window as well as the
name of the prototype NIMIS. In the left, upper corner there are three fields: Last Review,
224
Time and Next Review. They respectively indicate the last review moment at which the
inventory level was reviewed, the current clock-time in the system and the time at which
the next review will take place.
As shown in Figure 7-6, five scrollable lists display the parameters for the five
main application objects in the prototype NIMIS. The position of the application objects in
the window reflects the logical position of these domain objects in the distributed object
technology design of NIMISs. Below the parameter lists, the Exceptions field presents any
occurring exceptions. At the bottom of the window, buttons are provided to go to the Main
window, the Regular Management window, to close the window or to ask for help.
Figure 7-7 Window for setting the Explosion Factor List
Examples of parameters that can be set by the user are the lead time, the inventory norm,
the lot size, and the moments at which the prototype NIMIS reviews and plans the inventory
level of the single SKU stock-point (SSS). To set a new value for a parameter, the user
selects the corresponding parameter in one of the lists in the window for Occasional
Management. By clicking on the Set button at the bottom of the list, a window for setting
the value of the parameter is presented to the user. In Figure 7-7 a window for setting the
Explosion Factor List is presented, allowing the user to specify the type and number of
product units that are needed for one product in the single SKU stock-point. The window
gives the current value of the parameter and offers the user the possibility to set new
values. The user may either just view the value and press the Cancel button, or can change
the value by pressing the OK button after entering the new value. After leaving the
225
window for setting a parameter value, the window for Occasional Management is once
again displayed.
Figure 7-8 Window for Regular Management
Regular Management is the other main mode of operation in a prototype NIMIS. Regular
Management concerns the monitoring of orders and plans processed by the prototype
NIMIS, as well as the checking of plans coming in from customers and plans going out to
suppliers. Regular means that this function is executed on a regular basis, at every moment
the prototype NIMIS reviews the inventory level at the stock-point, but also in-between the
226
review moments, to process orders and to check plans. While running a prototype NIMIS,
the user can choose for Regular Management at any time.
By selecting Regular Management from the Main window, or in the window for
Occasional Management, a window for Regular Management is displayed, as presented in
Figure 7-8. Again, the top line gives the type of window and the name of the prototype
NIMIS. As in the window for Occasional Management, the last review moment, the current
time and next review moment are indicated in the left, upper corner. At the bottom of the
window, buttons are provided to go to the Main window, the Occasional Management
window, to close the window or to ask for help.
The two lists on the right hand side of the Regular Management window represent
orders and plans coming from customers. The lower list contains Individual Customer
Demand Orders (ICDOs) that have been received since the last review moment and have
already been forwarded to the operational process. The upper list shows Individual
Customer Demand Plans (ICDPs) that have been received from customers since the last
review moment. The user can either check the plans first or can approve them
immediately, without further investigation. Instead of manual checking and approval of
plans, a user can choose for automatic approval by marking the Auto-approve field.
The left hand side of the Regular Management window includes two lists for the
orders and plans that go to suppliers. The lower list represents Individual Supplier
Demand Orders (ISDOs) that were sent by the prototype NIMIS to suppliers at the last
review moment. At a review moment, the upper list contains Individual Supplier Demand
Plans (ISDPs) that are generated by the NIMIS. The user can check and approve the plans
before they are sent to the suppliers and removed from the window. The Auto-approve
field can be marked to send the plans to suppliers without user intervention.
When the Auto-approve field is not marked, the user of a NIMIS has the possibility
to check the plans coming from customers or going to suppliers. From a list of plans in the
window for Regular Management, the user can select the plan to be checked. By clicking
the Check button, the user is provided with a window for checking the plan. As soon as
the current time equals a review moment, messages are displayed in the window for
Regular Management, urging the user to check and approve the customer plans and
supplier plans immediately.
227
Figure 7-9 Window for checking a plan
In Figure 7-9 a window for checking an Individual Customer Demand Plan (ICDP) is
presented. The fields above the two lists give the name of the customer, the name of the
prototype NIMIS which received the plan, an order identification name as well as a plan
interval and a receive time. On the left hand side, the window contains a list with the
original plan as it was received from a customer. On the right hand side, a translated plan
is included that has been computed by the prototype NIMIS. The original plan contains
expected demand for plan moments as applied by the customers. For each plan moment, a
quantity of products is stated, which represents the expected demand for that plan
moment.
In the translated plan, the expected demand from the customer has been allocated
to the plan moments that are used in the prototype NIMIS. The user is allowed to change
values in the translated plan, so the user can manually take into account considerations
which are not automatically supported by the prototype NIMIS. With the buttons at the
bottom of the window, the user can confirm the changes and go back to the window for
Regular Management. The values in the original plan can not be changed by the user.
The Regular Management window instructs the user to check and approve the
supplier plans as soon as they are available after a review moment. For the checking and
228
approval of an Individual Supplier Demand Plan (ISDP), a similar window is available,

although that window does not contain a translated plan. For each plan moment applied in
the prototype NIMIS, the expected demand for suppliers is stated. The supplier plans that
are computed by the prototype NIMIS, can be changed by the user, so that the user can
manually cope with issues not dealt with by the prototype NIMIS automatically.
7.4 Conclusion
The prototype system implementation shows how the distributed object technology design
of NIMISs fits into a particular environment of information technology.
Information technology in the prototype NIMIS encompasses the tools for
development and application of distributed and object-oriented information systems.
Suitable tools for the implementation of NIMISs are the Smalltalk programming language,
the user-interface objects of Visual Works and the CORBA implementation of Distributed
Smalltalk.
Besides the objects specified in the distributed object technology design, a network
of prototype NIMISs includes extra implementation specific objects. In addition to the five
core objects, there are extra domain objects for the implementation of technical system
details. Further, user-interface objects are added to implement the user-interface. The
prototype implementation also includes environment objects to simulate systems in the
environment of the prototype NIMISs.
For achieving networked inventory management in particular supply chains, a
prototype NIMIS is installed for every single SKU stock-point that needs to be managed. By
exploiting distributed object technology, a network of prototype NIMISs can be installed
that exactly reflects the single SKU stock-point in the supply chains. The prototype NIMISs
make use of technology with object classification, attribute encapsulation and operation
invocation, as well as technology with local computing, heterogeneous computing and
transparent computing.
Occasional Management and Regular Management are the two main operating
modes in the use of the prototype NIMISs. Occasional Management includes the setting of
new values for parameters and the handling of possible exceptions. Regular Management
concerns the monitoring and checking of orders and plans coming in from customers and
going out to suppliers.
229
Chapter 8 Conclusion
8. Conclusion
8.1 Outcomes of the research

The main objective of the research was to show the functional and technical feasibility of
information systems for integral inventory management across networked organisations,
using distributed and object-oriented system technology. These systems were called
Networked Inventory Management Information Systems (NIMISs).
From the results of this study, it can be concluded that NIMISs are functionally and
technically feasible. All six research stages in this study resulted in supportive evidence for
the feasibility of networked inventory management by distributed object technology. The
claim of functional feasibility is supported by the outcomes of the supply chain
management analysis, the networked inventory management design and the case study
implementation. The claim of technical feasibility is supported by the outcomes of the
computer network technology analysis, the distributed object technology design and the
prototype system implementation. Although several aspects of the information systems
have not yet been studied, no outcomes are foreseen that seriously undermine the
functional and technical feasibility of NIMISs.
Up to now, in a vast majority of supply chains the scope of integral inventory
management has been limited to one organisation, due to opposition between
organisations in the supply chains. In a small minority of supply chains, integral inventory
management has a scope of several organisations, due to the domination of one
organisation over other organisations in the supply chains. For these current types of
supply chain management, a central and procedural information system is usually applied
that generates mandatory instructions with fixed routines for all managed stock-points.
231
Conclusion Chapter 8
In the near future, a newer type of supply chain management may come into being,
in which integral inventory management is realised across networked organisations, by co-
operation between organisations in supply chains. The central and procedural information
systems currently applied in supply chains, are not suitable for integral inventory
management across networked organisations. They can not simultaneously support both
the integration required for integral inventory management and the flexibility required for
networked organisations.
The Networked Inventory Management Information Systems introduced in this
study can achieve integral inventory management across networked organisations, by
exploiting distributed and object-oriented system technology. These extremely basic
information systems are loosely coupled to one another in networks. As a result, NIMISs are
able to provide the integration required for integral inventory management, as well as the
flexibility required for networked organisations.
Given supply chain management as a trend in logistics management and computer
network technology as a trend in information technology, it was suggested that supply
chain management could be enhanced with the help of computer network technology.
Overall, the research proved potential synergy between supply chain management and
computer network technology. The outcomes of the research are given below, for each of
the six research stages.
8.1.1 Supply chain management analysis

Supply chain management was analysed because it is a major trend in logistics
management. It concerns the inter-organisational management of goods flows between
independent organisations. Supply chain management is an integrative approach to
planning, control and monitoring of total material flows from suppliers to end users,
aiming at improved customer service at reduced overall costs. It was argued that supply
chain management is a means for organisations to improve their business performance, in
particular to achieve higher productivity and greater flexibility. This is needed to respond
to customers who require products with a better price-quality ratio and a more dynamic
product assortment. Important issues in supply chain management are integral inventory
management and networked organisation management.
It was mentioned that integral inventory management, instead of non-integral
inventory management, could contribute to productivity improvements. Integral inventory
management focuses on the co-ordinated planning, control and monitoring of inventory
levels at stock-points throughout supply chains, in order to maximise overall supply chain
performance. It was argued that besides purposely desired inventory and necessarily
required inventory, there would ideally be no extra inventory in supply chains. Existing
232
inventory excesses and shortages can be reduced with the help of integral inventory
management.
It was explained that networked organisation management, instead of hierarchical
organisation management, is a means to achieve greater flexibility. A networked
organisation is an organisation (actor, company or business unit) with its own strategic
control unit, that co-operates with other organisations at a tactical and operational level,
within its strategic constraints, in order to gain mutual benefits. Using a co-ordination
mechanism in between markets and hierarchies, networked organisations can make up
stable, internal or dynamic networks. Dynamic networks of organisations are particularly
suited for flexibility improvements, because the participating networked organisations link
network.
Integral inventory management and networked organisation management were found to be

supplementary directions for improvement of business performance in supply chains. The
combination of integral inventory management and networked organisation management
was called networked inventory management. It was argued that currently no information
systems for supply chain management appear to be available, that give adequate support
for both integral inventory management and networked organisation management. The
productivity and flexibility opportunities of networked inventory management, related to
the perceived shortcomings of ERP systems and EDI based inter-organisational systems,
induced functional requirements for new information systems for networked inventory
management, these requirements comprise integration in the time dimension as well as
integration in the place dimension, by using extra information on time-phased demand or
integral inventory.
allow the use of own decision timetables and that can cope with different decision rules.
233
management and the type of management.
8.1.2 Networked inventory management design

The networked inventory management design constitutes the functional design of NIMISs.
The integral inventory management design was based on one NIMIS per single SKU
stock-point, holding inventory for one product type at one location. Thus, a NIMIS is an
in order to support integral inventory management. Many of these systems have to be
present in supply chains to provide integral inventory management across networked
organisations. A NIMIS processes information for the management of its stock-point and
exchanges information with other systems. Every system is equipped with system variables
and equations, reflecting related information on a strategist supervising the system,
customers, suppliers, the operational process including the stock-point, and the inventory
itself.
It was explained how the properties of NIMISs satisfy the functional requirements
related to integral inventory management. With the help of the system variables and
system equations in a network of NIMISs, integral inventory management can be
accomplished according to the algorithms of Base Stock Control (BSC),
Material/Distribution Requirements Planning (MRP/DRP) and Line Requirements Planning
(LRP). These properties comprise integration in the time dimension as well as integration
in the place dimension, by using extra information on time-phased demand or integral
inventory. The integration, as required for integral inventory management, and as
provided by NIMISs, is the result of loose coupling of extremely basic information systems.
In the networked organisation management design, the scope of a NIMIS was equated to the
system scope in the integral inventory management design. A NIMIS manages just one
single SKU stock-point in the domain of a networked organisation, which uses a Business
Information System for business functions other than networked inventory management.
in order to support networked organisation management. Information is processed within
a NIMIS and is exchanged across systems in a network. For achieving networked
organisation management, some supplementary system variables and system equations
were included, which all relate to the customers of a NIMIS.
234
It was explained how the properties of NIMISs satisfy the functional requirements
related to networked organisation management. Configuration flexibility was based on
creating different networks of NIMISs, which can operate independently of Business
Information Systems. Timing flexibility was achieved by coping with different review
moments and plan moments in NIMISs. Algorithm flexibility encompassed algorithm
selection in a NIMIS and algorithm transition across NIMISs. These properties allow
management and the type of management. The flexibility, as required for networked
organisation management, and as provided by NIMISs, is just like the integration the result
of loose coupling of extremely basic information systems.
8.1.3 Case study implementation

The case study implementation showed how the networked inventory management design
of NIMISs fits into a particular environment of logistics management.
manufacturing and distribution of cordless telephones, as encountered in a real-life
situation. In the current situation, five manufacturers in various countries supply KPN
Telecom with cordless telephones. KPN Telecom sells the products through more than one
hundred sales outlets in The Netherlands to customers in the consumer market and in the
business market. The supply chains include stock-points at manufacturers for components
and finished products, as well as stock-points at the distributor, in a distribution centre and
in the sales outlets. For the inventory management in the supply chains, various types of
systems are applied.
A future scenario showed what the supply chains for cordless telephones will
managed in a more integral way. Supply chain management in general, and networked
inventory management in particular, is a means to achieve higher productivity and greater
flexibility in the supply chains. Networked organisation management can increase the
flexibility of the supply chains, as the network of customers and suppliers will expand and
change more frequently to offer a more dynamic product assortment. Integral inventory
management is a means to improve the productivity, including reduction of costs related to
holding inventory and increase of revenues related to product availability for customer
service.
235
It was argued that it is practically unfeasible to develop and maintain the desirable
It was shown that networked inventory management can be achieved by application
of a NIMIS for every single SKU stock-point that holds inventory for cordless telephones.
Loose coupling in networks enables these extremely basic information systems to support
integral inventory management and, at the same time, networked organisation
management. By co-operation in a network, NIMISs can provide BSC, MRP/DRP and LRP, in
combination with configuration flexibility, timing flexibility and algorithm flexibility. For
integral inventory management according to one of the algorithms, all systems in the
network need to apply the same algorithm. For networked organisation management, a
NIMIS can work separately from other systems, may use its own review and plan moments,
and is allowed to apply its own algorithm.
It was indicated that NIMISs could achieve networked inventory management in
coexistence with the Business Information Systems currently applied in the supply chains
for cordless telephones. NIMISs can profit from loose coupling to the existing Business
Information Systems, without sacrificing the integration and flexibility needed for
networked inventory management. Instead of direct interaction with its strategist and
operational process, a NIMIS can use the Business Information System of a networked
organisation as an intermediate. To support networked inventory management by NIMISs,
the existing Business Information Systems can be used for information registration and
data management.
Although the case study implementation addressed just one environment of
logistics management, it is expected that the information systems can be applied in many
other situations. Because the case represents issues which are encountered in an increasing
number of supply chains, it is argued that the systems could also be implemented in
situations with similar logistics management.
8.1.4 Computer network technology analysis

Computer network technology was analysed because it is a major trend in information
technology. It concerns the integration of computers and telecommunication networks,
creating a world-wide web of computer networks. Computer network technology was
identified as an enabler for new ways of information processing and new ways of
organising business. Due to advances in technology, the optimisation of information
processing can shift from technical efficiency towards functional effectiveness. With the
help of electronic integration, business networks can be reconfigured. Important issues in
236
computer network technology are distributed system technology and object-oriented system
technology.
through a communication network in order to provide integrated functions. It was found
that distributed system technology is a means to achieve integration across locations while
respecting the need of organisations to have autonomy over their own information
processing.
world entity and contains functions as well as associated data. It emerged that object-
oriented system technology can increase the flexibility of information systems. As systems
are based on stable real-world entities, instead of unstable functions, their functionality
can be changed by local adjustments.
Distributed system technology and object-oriented system technology were found to be

supplementary directions for improvement of information processing in computer
networks. The combination of distributed system technology and object-oriented system
technology was called distributed object technology. It was stated that currently no
information systems for supply chain management appear to be available that fully exploit
distributed and object-oriented system technology. The integration and flexibility
opportunities of distributed object technology, related to the perceived shortcomings of ERP
systems and EDI based inter-organisational systems, induced technical requirements for
new information systems for networked inventory management (NIMISs).
Technical requirements related to object-oriented system technology are the use of
technology with: object classification, attribute encapsulation and operation invocation.
The information systems consist of objects, which include both functions and associated
data. Data is stored in attributes, which are hidden from other objects, and functions are
performed by operations, in response to the receipt of messages. These requirements allow
237
the information systems to naturally reflect the structure, data and functions of networked
8.1.5 Distributed object technology design

The object-oriented system technology design was created with the help of the
Object Modelling Technique (OMT). Hence, NIMISs are specified in an object model, a
dynamic model and a functional model. In the object model, five core objects were
identified: Customer Manager, Supplier Manager, Operational Manager, Strategic
Manager and Inventory Manager. The dynamic model of a NIMIS includes state diagrams
for the core objects as well as event trace diagrams for Regular Management and
Occasional Management. In the functional model, the processes that compute new values
together with their inputs and outputs, were specified in a data flow diagram, while
computation formulae were specified as system equations in the functional design. It
emerged that the object-oriented system technology design of NIMISs can be specified with
the help of OMT.
It was explained how the properties of NIMISs satisfy the technical requirements
related to object-oriented system technology. Object classification was accomplished by
specifying a NIMIS as a set of interacting object classes and instances. Attribute
encapsulation was based on storage of data in attributes, which can only be accessed
through access operations. Operation invocation was arranged by performing functions in
operations, which are executed in response to the receipt of messages. Because of these
properties, the information systems can naturally reflect the structure, data and functions
of networked organisations and their integral inventory management.
The distributed system technology design was created with the Common Object Request
Broker Architecture (CORBA), which includes Object Request Brokers (ORBs), Interface
Definition Language (IDL) interfaces and several types of objects. ORBs are system
components that facilitate interaction of objects that are distributed over systems. IDL
interfaces enable interaction of objects that are programmed in different languages. CORBA
Services and CORBA Facilities offer additional support for the development and application
of systems built of distributed objects. It emerged that the distributed system technology
design of NIMISs can be specified with the help of CORBA.
It was explained how the properties of NIMISs satisfy the technical requirements
related to distributed system technology. Local computing was accomplished by using a
238
local processor and a local memory, for one or more NIMISs at a location. Heterogeneous
computing was realised using IDL interfaces and virtual machines, that allow interaction
across different programming languages, hardware components and operating systems.
Transparent computing was arranged using ORBs and CORBA Services, which hide
technical complexities related to, amongst others, locations, transactions and persistence.
Because of these properties, networked organisations can achieve integration across
locations, while preserving autonomy over their own functions and data, the techniques of
their systems and the management of technical complexities.
8.1.6 Prototype system implementation

The prototype system implementation showed how the distributed object technology
design of NIMISs fits into a particular environment of information technology.
Information technology in the prototype NIMIS encompasses the tools used for
development and application of distributed and object-oriented information systems. It
emerged that tools are available which are suitable for the implementation of NIMISs. The
Smalltalk programming language and development environment assured that the
prototype NIMIS is fully object-oriented and corresponds to the objects, attributes and
operations as specified in the object-oriented system technology design. Visual Works
added a library with user-interface objects to Smalltalk, and enabled the interaction with
users. Distributed Smalltalk extended Smalltalk and Visual Works with an
implementation of CORBA, and facilitated the interaction of distributed objects.
It was indicated that, besides the objects that were specified in the distributed object
technology design, a network of prototype NIMISs includes extra implementation specific
objects. Domain objects take care of the core functionality and information of the systems.
In addition to the five core objects in the object model, there are extra domain objects for
the implementation of technical system details. Further, user-interface objects are added to
the prototype NIMIS to implement the user-interface. The prototype implementation also
includes environment objects to simulate systems in the environment of the prototype
NIMISs, like operational processes, customer systems and supplier systems.
It was shown that for achieving networked inventory management in particular supply
chains, a prototype NIMIS is installed for every single SKU stock-point that needs to be
managed. System installation encompasses the start up of one system per single SKU stock-
point on computers that are interconnected through an Internet based communication
network. By exploiting distributed object technology, a network of prototype NIMISs can be
installed that exactly reflects the single SKU stock-point in the supply chains. The
prototype NIMISs make use of technology with object classification, attribute encapsulation
239
and operation invocation, as well as technology with local computing, heterogeneous

computing and transparent computing.
It was revealed that Occasional Management and Regular Management are the two
main operating modes in the use of the prototype NIMISs. Occasional management includes
the setting of new values for parameters related to networked inventory management, as
well as the handling of possible exceptions. Regular Management concerns the monitoring
of orders and plans processed by a NIMIS, as well as the checking of plans coming in from
customers and going out to suppliers.
Although the prototype system implementation addressed just one particular
environment of information technology, it is expected that the information systems can be
operated with many other tools. Because the prototype system exploits features that are
becoming available in a growing number of computer networks, it is argued that the
systems can also be implemented in tools with similar information technology.
8.2 Issues for further research

Many issues related to Networked Inventory Management Information Systems have not
been dealt with in this study, due to practical limitations in the availability of manpower,
funding and time for research. To get a deeper understanding of supply chain management
by computer network technology, in particular of networked inventory management by
distributed object technology, it is recommended that the most significant remaining
questions be studied in new research projects. Issues for further research have been
identified for each of the six research stages.
8.2.1 Supply chain management analysis

Concerning the supply chain management analysis, a first issue for further research is the
relationship between NIMISs and managerial concepts for supply chain management. The
way the information systems fit into concepts like Efficient Consumer Response (ECR),
Vendor Managed Inventory (VMI) and Quick Response (QR), should be studied.
A second issue for further research is the relationship between NIMISs and other
candidate areas for integral management in supply chains. The way in which the
principles of the information systems could be applied for integral management of
functions other than inventory management, such as production, transportation and
capacity management, should be studied.
A third issue for further research is the relationship between NIMISs and
organisational forms encountered in practice. An area that should be studied is, how the
240
information systems could be applied in organisations which are not purely networked
organisations, but have similar features, such as autonomous work cells, co-makership and
strategic alliances.
8.2.2 Networked inventory management design

Concerning the networked inventory management design, a first issue for further research
is the relationship between NIMISs and possible feed back loops in networked inventory
management. Information systems should be studied for which the design includes
functionality for available-to-promise reasoning, capacity restrictions and negotiations.
functionality for integral inventory management. Information systems should be studied
for which the design includes algorithms for management according to Just-In-Time (JIT),
Optimised Production Technology (OPT) and Advanced Planning Systems (APS).
A third issue for further research is the relationship between NIMISs and other
functionality for networked organisations. Information systems should be studied for
which the design includes facilities for network configuration management, product data
management and optimal parameter setting across networked organisations.
8.2.3 Case study implementation

Concerning the case study implementation, a first issue for further research is the
relationship between NIMISs and their possible application in various situations. The
applicability of the information systems should be studied for situations with different
characteristics, such as multi-sourcing, differentiated lead times, make-to-order and cross-
docking.
A second issue for further research is the relationship between NIMISs and
quantitative performance effects of networked inventory management. Performance effects
in supply chains due to the application of NIMISs, such as inventory reduction or customer
service increase, should be studied with the help of analytical models and simulation tools.
A third issue for further research is the relationship between NIMISs and methods to
introduce and apply the systems in real-life supply chains. Introduction and application
guidelines should be studied, which support migration to networked inventory
management, as well as the ongoing operation of networked inventory management.
241
8.2.4 Computer network technology analysis

Concerning the computer network technology analysis, a first issue for further research is
the relationship between NIMISs and information technology for decision support in
computer networks. The way in which the information systems could use technology like
artificial intelligence, virtual reality and On-Line Analytical Processing (OLAP), should be
studied.
A second issue for further research is the relationship between NIMISs and
information technology for data management in computer networks. The possibilities of
the information systems exploiting technology such as Product Data Management (PDM)
systems, federated databases and On-Line Transaction Processing (OLTP), should be
studied.
A third issue for research is the relationship between NIMISs and information
technology for information exchange in computer networks. The ways in which the
information systems could profit from technology like Electronic Data Interchange (EDI),
Work Flow Management systems (WFM) and electronic commerce, should be studied.
8.2.5 Distributed object technology design

Concerning the distributed object technology design, a first issue for further research is the
relationship between NIMISs and intelligent agents. Information systems should be studied
in which the design includes technology for intelligent agents, which can travel
independently through computer networks to complete their mission.
distributed system technology. Information systems should be studied in which the design
includes technology like the Distributed Common Object Model (DCOM), instead of
CORBA, and Open Distributed Processing (ODP), to extend the transparency of distributed
systems.
A third issue for further research is the relationship between NIMISs and other
object-oriented system technology. Information systems should be studied in which the
design includes technology like the Unified Modelling Language (UML), instead of OMT,
and object-oriented databases, for persistent information storage.
8.2.6 Prototype system implementation

Concerning the prototype system implementation, a first issue for further research is the
relationship between NIMISs and technical system management. For the implementation of
242
the information systems the incorporation of technical management fields, like security
management, fault management and configuration management, should be studied.
A second issue for further research is the relationship between NIMISs and technical
performance of the information processing. The technical performance, like response
times and error rates, should be studied for large scale implementations of the information
systems, in real-life situations with complex supply chains and computer networks.
A third issue for further research is the relationship between NIMISs and alternative
implementation technology. The construction of the information systems using other tools
than Distributed Smalltalk, like programming languages as Java, and other Graphical
User Interface (GUI) builders, such as Delphi, should be studied.
243
References
References
[Aken, 1998] Aken, J.E. van, Hop, L. & Post, G.J.J., The Virtual Organization: a
special mode of strong inter-organizational co-operation, In: Hitt, M.A.,
Ricart, J.E. & Nixon, R.D. (eds.), Managing Strategically in an
Interconnected World, John Wiley & Sons, Chichester (England), 1998.
[Andersen, 1995] Andersen Consulting, Logistics Software 1995 Edition, Andersen
Consulting, New York (USA), 1995.
[Ang, 1994] Ang, J., Distributed environments: A conceptual framework using
objects, Data & Knowledge Engineer, Vol. 14, 1994, pp. 191-202.
[Axsäter, 1994] Axsäter, S. & Rosling, K., Multi-level production-inventory control:
Material requirements planning or reorder point policies, European
Journal of Operational Research, Vol. 75, 1994, pp. 405-412.
[Baker, 1997] Baker, S., CORBA Distributed Objects: Using Orbix, Addison-Wesley,
Harlow (England), 1997.
[Barekat, 1989] Barekat, M.M., Aspects of the Design and Operation of Production
Control Systems in Manufacturing Industry, PhD thesis, University of
Aston in Birmingham, Birmingham (England), 1989.
[Bemelmans, 1987] Bemelmans, T.M.A., Bestuurlijke informatiesystemen en automatisering
(Administrative information systems and automation, in Dutch), Stenfert
Kroese, Leiden (The Netherlands), 1987.
[Ben-Natan, 1995] Ben-Natan, R., CORBA: A guide to Common Object Request Broker
Architecture, McGraw-Hill, New York (USA), 1995.
[Berenschot, 1997] Berenschot, Software Disk 97-98 Inkoop & Logistiek (Software Disc 97-
98 Purchase & Logistics, in Dutch), Kluwer, Deventer (The
Netherlands), 1997.
[Berson, 1992] Berson, A., Client/Server Architecture, McGraw-Hill, New York (USA),
1992.
[Bertrand, 1990] Bertrand, J.W.M., Wortmann, J.C. & Wijngaard, J., Production Control:
A Structural and Design Oriented Approach, Elsevier, Amsterdam (The
Netherlands), 1990.
[Blair, 1996] Blair, G., Coulson, G. & Davies, N., Standards and platforms for open
distributed processing, Electronics & Communication Journal, Vol. 8,
No. 3, June 1996, pp. 123-133.
[Booch, 1994] Booch, G., Object Oriented Design and Analysis: with Applications,
Benjamin/Cummings, Redwood City (USA), 1994.
[Browne, 1995] Browne, J., Sackett, P.J. & Wortmann, J.C., Future manufacturing
systems: Towards the extended enterprise, Computers in Industry, Vol.
25, 1995, pp. 235-254.
245
References
[Buzacott, 1997] Buzacott, J.A., Continuous time distributed decentralized MRP,

Production Planning & Control, Vol. 8, No. 1, 1997, pp. 62-71.
[Carmichael, 1994] Carmichael, A., Object development methods, SIGS Books, New York
(USA), 1994.
[Ching, 1996] Ching, C., Holsapple, C.W. & Whinston, A.B., Toward IT support for
co-ordination in network organizations, Information & Management,
Vol. 30, 1996, pp. 179-199.
[Christopher, 1994] Christopher, M., Logistics and Supply Chain Management, Financial
Times, London (England), 1994.
[Clark, 1960] Clark, A.J. & Scarf, H., Optimal policies for a multi-echelon inventory
problem, Management Science, Vol. 6, 1960, pp. 475-490.
[Clemens, 1997] Clemens, J.T., Silicon Microelectronics Technology, Bell Labs Technical
Journal, Autumn 1997, pp. 76-102.
[CLM, 1991] Council of Logistics Management (CLM), Improving Quality and
Productivity in the Logistics Process: Achieving Customer Satisfaction
Breakthroughs, Council of Logistics Management, Oak Brook (USA),
1991.
[Coad, 1990] Coad, P. & Yourdon, E., Object-Oriented Analysis, Yourdon Press,
Prentice-Hall, Englewood Cliffs (USA), 1990.
[Coopers, 1998] Coopers&Lybrand & Logiplan, Standaard Software voor Handel &
Industrie: Inclusief detailplanning (Standard Software for Trade &
Industry: Including detail planning, in Dutch), Coopers&Lybrand &
Logiplan, Utrecht (The Netherlands), 1998.
[Coulouris, 1988] Coulouris, G.F., Dollimore, J., Distributed Systems: Concepts and
Design, Addison-Wesley, Wokingham (England), 1988.
[Davidow, 1992] Davidow, W.H., Malone, S.M., The Virtual Corporation: Structuring
and Revitalizing the Corporation for the 21st century, Harper Business,
New York (USA), 1992.
[Davis, 1993] Davis, T., Effective Supply Chain Management, Sloan Management
Review, Summer 1993, pp. 35-46.
[Diks, 1996] Diks, E.B., Kok, A.G. de & Lagodimos, A.G., Multi-echelon systems: A
service measure perspective, European Journal of Operational Research,
Vol. 95, 1996, pp. 241-263.
[Donselaar, 1987] Donselaar, K. van, Jenniskens, F. & Timmer, J., Line Requirements
Planning alternatief voor MRP? (I) (Line Requirements Planning
alternative for MRP? (I), in Dutch), Tijdschrift voor Inkoop & Logistiek,
Vol. 3, No. 11, 1987, pp. 21-25.
[Donselaar, 1989] Donselaar, K.H. van, Material coordination under uncertainty, PhD
thesis, Eindhoven University of Technology, Eindhoven (The
Netherlands), 1989.
246
References
[Donselaar, 1990] Donselaar, K.H. van, Integral stock norms in divergent systems with lot-
sizes, European Journal of Operational Research, Vol. 45, 1990, pp. 70-
84.
[Ellram, 1989] Ellram, L.M., La Londe, B.J. & Weber, M.M., Retail Logistics,
International Journal of Physical Distribution & Materials
Management, Vol. 19, No. 12, 1989, pp. 29-39.
[Ellram, 1991] Ellram, L.M., Supply Chain Management: The Industrial Organization
Perspective, International Journal of Physical Distribution & Logistics
[Ericsson, 1995] Ericsson, D., Harvey-Jones, J., Keen, P.G.W., Saffo, P. & Scott-Morgan,
P., Virtual Integration: Information Technology - the enabler in
globalization, Unisource, Stockholm (Sweden), 1995.
[EURESCOM, 1996] EURESCOM Project 517, Foresight Study on Distributed Object-
Oriented Computing: Report on Distributed Object-Oriented
Technologies, EURESCOM, Heidelberg (Germany), 1996.
[Fogarty, 1991] Fogarty, D.W., Blackstone, J.H. & Hoffman, T.R., Production &
inventory management, South-Western Publishing, Cincinnati (USA),
1991.
[Forrester, 1961] Forrester, J.W., Industrial Dynamics, MIT Press, Cambridge (USA),
1961.
[Franken, 1996] Franken, L.J.N., Quality of Service Management: a Model-Based
Approach, PhD thesis, University of Twente, KPN Research, Groningen
(The Netherlands), 1996.
[Gates, 1995] Gates, W.H., The Road Ahead, Viking Penguin, London (England),
1995.
[Giesbers, 1997] Giesbers, M.J.H., Pijl, G.J. van der & Vroenhoven, E.P.R. van, IT-trends
en ERP-pakketwaarde (IT trends and ERP package value, in Dutch),
Compact, No. 3, 1997, pp. 10-17.
[Goldberg, 1985] Goldberg, A. & Robson, D., Smalltalk-80: The Language and its
Implementation, Addison-Wesley, Reading (USA), 1985.
[Graves, 1988] Graves, S.C., Safety Stocks in Manufacturing Systems, Journal of
Manufacturing & Operations Management, Vol. 1, 1988, pp. 67-101.
[Graves, 1993] Graves, S.C., Rinnooy Kan, A.H.G. & Zipkin, P.H. (eds.), Handbooks in
Operations Research and Management Science Volume 4: Logistics of
Production and Inventory, Elsevier Science Publishers, Amsterdam (The
Netherlands), 1993.
[Gray, 1989] Gray, C.D. & Landvater, D.V., MRP II Standard System: A Handbook
for Manufacturing Software Survival, Oliver Wight, Essex Junction
(USA), 1989.
[Grinsven,1997] Grinsven, R.J.W. van, Case-studie onderzoek bij PTT Telecom naar
Networked Inventory Management Information Systems (Case study
247
References
research at PTT Telecom into Networked Inventory Management

Information Systems, in Dutch), KPN Research, Groningen (The
Netherlands), 1997.
[Halsall, 1992] Halsall, F., Data communications, computer networks and open systems,
Addison-Wesley, Wokingham (England), 1992.
[Hammer, 1993] Hammer, M. & Champy, J., Reengineering the Corporation: A Manifesto
for Business Revolution, Harper Collins, London (England), 1993.
[Harasim, 1993] Harasim, L.M., Global Networks: Computers and International
Communication, MIT Press, Cambridge (USA), 1993.
[Harink, 1993] Harink, J.H.A., Duursma, K.M., Raad, P. van & Verwijmeren,
M.A.A.P., Architectuur voor besturing van logistieke ketens
(Architecture for management of supply chains, in Dutch), PTT
Research, Groningen (The Netherlands), 1993.
[Hausman, 1994] Hausman, W.H. & Erkip, N.K., Multi-echelon vs. Single-echelon
Inventory Control Policies for Low-demand Items, Management Science,
Vol. 40, No. 5, May 1994, pp. 597-602.
[Henderson, 1991] Henderson, J.C. & Venkatraman, N., Understanding Strategic
Alignment, Business Quarterly, Winter 1991, pp. 72-78.
[Henderson, 1993] Henderson, J.C. & Venkatraman, N., Strategic alignment: Leveraging
information technology for transforming organizations, IBM Systems
Journal, Vol. 32, No. 1, 1993, pp. 4-16.
[Hoekstra, 1987] Hoekstra, S. & Romme, J.H.J.M., Op weg naar integrale logistieke
structuren (Towards integral logistics structures, in Dutch), Kluwer,
Deventer (The Netherlands), 1987.
[Hof, 1997] Hof, E. van het, Networked Inventory Management Information Systems:
Ontwerp en Implementatie (Networked Inventory Management
Information Systems: Design and Implementation, in Dutch), KPN
Research, Leidschendam (The Netherlands), 1997.
[Hopkins, 1995] Hopkins, T. & Horan, B., Smalltalk: An introduction to application
development using Visual Works, Prentice-Hall, Englewood Cliffs
(USA), 1995.
[Hordeski, 1989] Hordeski, M.F., Communications Networks, TAB Books, Blue Ridge
Summit (USA), 1989.
[Houtum, 1996] Houtum, G.J. van, Inderfurth, K. & Zijm, W.H.M., Materials
coordination in stochastic multi-echelon systems, European Journal of
Operational Research, Vol. 9, 1996, pp. 1-23.
[ITU/ISO, 1995] ITU/ISO, Open Distributed Processing Reference Model: Part 3
Architecture, ITU-T Recommendation X.903, International Standard
ISO/IEC 10746-3, ITU/ISO, 1995.
248
References
[ITU/ISO, 1996] ITU/ISO, Open Distributed Processing Reference Model: Part 1

Overview, ITU-T Recommendation X.901, International Standard
ISO/IEC 10746-1, ITU/ISO, 1996.
[Johnston, 1988] Johnston, R. & Lawrence, P.R., Beyond Vertical Integration: the Rise of
the Value-Adding Partnership, Harvard Business Review, July-August
1988, pp. 94-101.
[Jones, 1985] Jones, T.C. & Riley, D.W., Using Inventory for Competitive Advantage
through Supply Chain Management, International Journal of Physical
Distribution & Materials Management, Vol. 15, No. 5, 1985, pp. 16-26.
[Jong, 1997] Jong, C. de, Michiels, E.F., Nijhof, J.A.M. & Vlist, P. van der (eds.),
Telematica (Telematics, in Dutch), Samson, Alphen aan den Rijn (The
Netherlands), 1997.
[Keremitsis, 1995] Keremitsis, E. & Fuller, I.J., Distributed Smalltalk: A Tool for
Developing Distributed Applications, Hewlett-Packard Journal, April
1995, pp. 85-92.
[Kerr, 1995] Kerr, K.W., Applying OMT: A Practical Step-by-Step Guide to Using the
Object Modelling Technique, SIGS Books, New York (USA), 1995.
[Khanna, 1994] Khanna, R., Distributed Computing: Implementation and Management
Strategies, Prentice-Hall, Englewood Cliffs (USA), 1994.
[Kloving, 1997] Kloving, E. & Bryhni, H., High speed networking in Internet and
corporate Intranets, Telektronikk, No.2, 1997, pp. 46-54.
[Kurt, 1993] Kurt Salmon Associates, ECR: Enhancing Consumer Value in the
Grocery Industry, Food Marketing Institute, Washington DC (USA),
1993.
[Lee, 1992] Lee, H.L. & Billington, C., Managing Supply Chain Inventory: Pitfalls
and Opportunities, Sloan Management Review, Spring 1992, pp. 65-73.
[Lee, 1993] Lee, H.L. & Billington, C., Material Management in Decentralized
Supply Chains, Operations Research, Vol. 41, No. 5, September-October
1993, pp. 835-847.
[Leeuw, 1990] Leeuw, A.C.J. de, Bedrijfskundige methodologie: management van
onderzoek (Methodology of management science : management of
research, in Dutch), Van Gorcum, Assen (The Netherlands), 1990.
[Leeuw, 1996] Leeuw, S.L.J.M. de, The selection of distribution control techniques in a
contingency perspective, PhD thesis, Eindhoven University of
Technology, Eindhoven (The Netherlands), 1996.
[Leydekkers, 1997] Leydekkers, P., Multimedia Services in Open Distributed
Telecommunication Environments, PhD thesis, University of Twente,
KPN Research, Groningen (The Netherlands), 1997.
[Lierop, 1996] Lierop, F.L.G. van & Vanmaele, H. (eds.), Multi-site Business
Information Systems, DELWEL, Den Haag (The Netherlands), 1996.
249
References
[Love, 1989] Love, D. & Barekat, M.M., Decentralized, distributed MRP: solving
control problems in cellular manufacturing, Production & Inventory
Management Journal, Vol. 3, No. 30, 1989, pp. 78-84.
[Magee, 1958] Magee, J.F., Production Planning and Inventory Control, McGraw-Hill,
New York (USA), 1958.
[Martin, 1983] Martin, A.J., DRP: Distribution Resources Planning, Oliver Wight,
Essex Junction (USA), 1983.
[Martin, 1992] Martin, J. & Odell, J.J., Object-Oriented Analysis and Design, Prentice-
Hall, Englewood Cliffs (USA), 1992.
[Martin, 1993] Martin, A.J., Distribution Resource Planning: the Gateway to True
Quick Response and Continuous Replenishment, Oliver Wight, Essex
Junction (USA), 1993.
[Meal, 1984] Meal, H.C., Putting production decisions where they belong, Harvard
Business Review, No. 62, 1984, pp. 102-110.
[Meyer, 1988] Meyer, B., Object-oriented Software Construction, Prentice-Hall,
Englewood Cliffs (USA), 1988.
[Meyer, 1995] Meyer, B., Object Success: A Manager’s Guide to Object Orientation, its
Impact on the Corporation, and its Use for Reengineering the Software
Process, Prentice-Hall, Englewood Cliffs (USA), 1995.
[Miles, 1986] Miles, R.E. & Snow, C.C., Organizations: New Concepts for New
Forms, California Management Review, Vol. XXVIII, No. 3, Spring
1986, pp. 62-73.
[Miles, 1992] Miles, R.E. & Snow, C.C., Causes of Failure in Network Organizations,
California Management Review, Summer 1992, pp. 53-72.
[Mintzberg, 1983] Mintzberg, H., Structure in Fives: Designing Effective Organizations,
Prentice-Hall, Englewood-Cliffs (USA), 1983.
[Monhemius, 1989] Monhemius, W. & Durlinger, P.P.J., Logistiek Management (Logistics
Management, in Dutch), Kluwer, Deventer (The Netherlands), 1989.
[Mowbray, 1995] Mowbray, T.J. & Zahavi, R., The Essential CORBA: Systems Integration
Using Distributed Objects, John Wiley & Sons, New York (USA), 1995.
[Mullender, 1989] Mullender, S., Distributed Systems, ACM Press, New York (USA),
1989.
[Mustakim, 1990] Mustakim, M., Computerised Control of Cellular Manufacturing
Systems, PhD thesis, University of Aston in Birmingham, Birmingham
(England), 1990.
[Nieuwenhuis, 1991] Nieuwenhuis, L.J.M., Fault Tolerance through Program
Transformation, PhD thesis, University of Twente, PTT Research,
Leidschendam (The Netherlands), 1991.
[OMG, 1998] Object Management Group (OMG), The Common Object Request
Broker: Architecture and Specification CORBA v2.2, Object
Management Group, Framingham (USA), February 1998.
250
References
[Orfali, 1996] Orfali, R., Harkey, D. & Edwards, J., The Essential Distributed Objects
Survival Guide, John Wiley & Sons, New York (USA), 1996.
[Orlicky, 1975] Orlicky, J., Material Requirements Planning, McGraw-Hill, New York
(USA), 1975.
[Ovum, 1995] Ovum, Distributed Objects: Creating the Virtual Mainframe, Ovum,
London (England), 1995.
[Ovum, 1997] Ovum, ERP for Manufacturers, Ovum, London (England), 1997.
[Palmer, 1995] Palmer, J.W., The Performance Impact of Quick Response and
Strategy/IT Alignment in Specialty Retailing, PhD thesis, Clarement
Graduate School, Claremont (USA), 1995.
[ParcPlace, 1994] ParcPlace Systems, Visual Works: Tutorial, ParcPlace Systems,
Sunnyvale (USA), 1994.
[ParcPlace, 1996] ParcPlace-Digitalk, Visual Works: Distributed Smalltalk User’s Guide,
ParcPlace-Digitalk, Sunnyvale (USA), 1996.
[Pine, 1992] Pine II, B.J., Mass Customization: the new frontier in business
competition, Harvard Business School Press, Boston (USA), 1992.
[Powell, 1990] Powell, W.W., Neither Market nor Hierarchy: Network Forms of
Organization, Research in Organizational Behaviour, Vol. 12, 1990, pp.
295-336.
[Rijen, 1994] Rijen, L.B.P., Herontwerp van een logistieke keten met behulp van
simulatie (Redesign of a supply chain with the help of simulation, in
Dutch), PTT Research, Groningen (The Netherlands), 1994.
[Rogers, 1994] Rogers, D.S. & Sherman, R.J., Efficient Consumer Response: Impact on
Intermodal Transportation, In: Proceedings of the Intermodal
Distribution Education Academy, University of Nevada, 1994.
[Rohloff, 1993] Rohloff, M., Decentralized production planning and design of a
production management system based on an object-oriented architecture,
International Journal of Production Economics, Vol. 30-31, 1993, pp.
365-383.
[Rowe, 1995] Rowe II, S.H., Telecommunications for Managers, Prentice-Hall,
Englewood Cliffs (USA), 1995.
[Rational, 1997] Rational Software, UML Summary v1.1, Rational Software, Cupertino
(USA), September 1997.
[Rumbaugh, 1991] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. & Lorensen, W.,
Object-Oriented Modelling and Design, Prentice-Hall, Englewood Cliffs
(USA), 1991.
[Schill, 1996] Schill, A., Mittasch C., Spaniol, O. & Popien, C. (eds.), Distributed
Platforms, Chopman & Hall, London (England), 1996.
[Scott Morton, 1991] Scott Morton, M.S. (ed.), The corporation of the 1990s: Information
Technology and Organizational Transformation, Oxford University
Press, New York (USA), 1991.
251
References
[Scott, 1991] Scott, C. & Westbrook, R., New Strategic Tools for Supply Chain
Management, International Journal of Physical Distribution & Logistics
[Sheombar, 1995] Sheombar, H.S., Understanding logistics co-ordination: A foundation
for using EDI in operational (re)design of dyadical Value Adding
Partnerships, PhD thesis, Katholieke Universiteit Brabant, Tilburg (The
Netherlands), 1995.
[Siegel, 1996] Siegel, J., CORBA: Fundamentals and Programming, John Wiley &
Sons, New York (USA), 1996.
[Silver, 1985] Silver, E.A. & Peterson, R, Decision Systems for Inventory Management
and Production Planning, John Wiley & Sons, New York (USA), 1985.
[Simon, 1996] Simon, E., Distributed Information Systems: From client/server to
distributed multimedia, McGraw-Hill, New York (USA), 1996.
[Snow, 1992] Snow, C.C., Miles, R.E. & Coleman, H.J., Managing 21st Century
Network Organizations, Organizational Dynamics, Vol. 20, No. 3,
Winter 1992, pp. 5-20.
[Stenger, 1996] Stenger, A.J., Reducing inventories in a multi-echelon manufacturing
firm: A case study, International Journal of Production Economics, Vol.
45, 1996, pp. 239-249.
[Stevens, 1989] Stevens, J., Integrating the supply chain, International Journal of
Physical Distribution & Materials Management, Vol. 19, No.8, 1989,
pp. 3-8.
[Suomi, 1992] Suomi, R., On the concept of inter-organizational information systems,
Journal of Strategic Information Systems, Vol. 1, No. 2, March 1992,
pp. 93-100.
[Taylor, 1990] Taylor, D.A., Object-Oriented Technology: A Manager’s Guide,
Addison-Wesley, Reading (USA), 1990.
[Taylor, 1995] Taylor, D.A., Business Engineering with Object Technology, John Wiley
& Sons, New York (USA), 1995.
[Thorelli, 1986] Thorelli, H.B., Networks: Between Markets and Hierarchies, Strategic
Management Journal, Vol. 7, No. 1, 1986, pp. 37-51.
[Ten Hagen, 1997] Ten Hagen & Stam, Automatiserings Gids: Almanak en Elektronisch
Archief 1994-1997 (Automation Guide: Almanac and Electronic
Archives 1994-1997, in Dutch), Ten Hagen & Stam, Den Haag, 1997.
[Timmermans, 1993] Timmermans, P., Modular Design of Information Systems for Shop
Floor Control, PhD thesis, Eindhoven University of Technology,
Eindhoven (The Netherlands), 1993.
[Toia, 1997] Toia, L.F., Prototyping Networked inventory management Information
Systems, KPN Research, Groningen (The Netherlands), 1997.
[Towill, 1996] Towill, D.R., Time compression and supply chain management: a guided
tour, Logistics Information Management, Vol. 9, No. 6, 1996, pp. 41-53.
252
References
[Umar, 1993] Umar, A., Distributed Computing: A Practical Synthesis, Prentice-Hall,

Englewood Cliffs, USA (NJ), 1993.
[Upton, 1996] Upton, D.M., McAfee, A., The Real Virtual Factory, Harvard Business
Review, July-August 1996, pp. 123-133.
[Venkatraman, 1994] Venkatraman, N., IT-Enabled Transformation: From Automation to
Business Scope Redefinition, Sloan Management Review, Winter 1994,
pp.73-87.
[Vermunt, 1993] Vermunt, A.J.M., Wegen naar logistieke dienstverlening (Ways to
logistics service providing, in Dutch), PhD thesis, Katholieke
Universiteit Brabant, Tilburg (The Netherlands), 1993.
[Verwijmeren, 1994a] Verwijmeren, M.A.A.P., Business process design: simulation of logistics
chains, In: Yearbook Research & Development Activities 1993, PTT
Research, Leidschendam, 1994, pp. 96-99.
[Verwijmeren, 1994b] Verwijmeren, M.A.A.P., Ketenbesturing in theorie: besturing, systemen
en toepassingen (Chain management in theory: management, systems
and applications, in Dutch), PTT Research, Groningen (The
Netherlands), 1994.
[Verwijmeren, 1995] Verwijmeren, M.A.A.P. & Harink, J.H.A., Een architectuur voor
specificatie van een opslagbesturingssysteem (An architecture for
specification of a storage management system, in Dutch), Tijdschrift voor
Inkoop & Logistiek, Vol. 11, No. 10, 1995, pp. 30-34.
[Verwijmeren, 1996a] Verwijmeren, M.A.A.P., Vlist, P. v.d. & Donselaar, K. v., Networked
Inventory Management Information Systems: Materializing Supply Chain
Management, International Journal of Physical Distribution & Logistics
[Verwijmeren, 1996b] Verwijmeren, M.A.A.P., Object-oriented specification of integral
distribution services, KPN Research, Groningen (The Netherlands),
1996.
[Verwijmeren, 1997] Verwijmeren, M.A.A.P., Towards networked inventory management
through distributed object technology, IFORS Conference on Information
Systems in Logistics and Transportation, Gothenburg (Sweden), 1997.
[Verwijmeren, 1998] Verwijmeren, M.A.A.P. & Eijkman, D., ERP Introductie (ERP
Introduction, in Dutch), KPN Research, Leidschendam (The
Netherlands), 1998.
[Vlist, 1991] Vlist, P. van der, Jong, W.J. de, Kolff, A.E., Net, D.J. van der, Overbeek,
A. van & Siebbeles, A.T.C. (eds.), EDI in de Handel (EDI in Trade, in
Dutch), Samsom, Alphen aan den Rijn (The Netherlands), 1991.
A. van & Siebbeles, A.T.C. (eds.), EDI in de Industrie (EDI in Industry,
in Dutch), Samsom, Alphen aan den Rijn (The Netherlands), 1992.
253
References
A. van & Siebbeles, A.T.C. (eds.), EDI in de Transportsector (EDI in
the Transport Sector, in Dutch), Samsom, Alphen aan den Rijn (The
Netherlands), 1994.
[Vries, 1985] Vries, G. de, De ontwikkeling van wetenschap: een inleiding in de
wetenschapsfilosofie (The development of science: an introduction in the
philosophy of science, in Dutch), Wolters-Noordhoff, Groningen (The
Netherlands), 1985.
[Walker, 1994] Walker, M., Supplier-Retailer Collaboration in European Grocery
Distribution, Logistics Information Management, Vol. 7, No. 6, 1994,
pp. 23-27.
[Webster, 1992] Webster, F.E., The changing role of marketing in the corporation,
Journal of Marketing, Vol. 56, October 1992, pp.1-17.
[Weegen, 1989] Weegen, E.M. van der, Logistieke besturing van fysieke distributie
(Logistics management of physical distribution, in Dutch), PhD thesis,
Eindhoven University of Technology, Samsom, Alphen aan den Rijn
(The Netherlands), 1989.
[Weger, 1994] Weger, M.K. & Vissers, C.A., Issues in design methodologies for
distributed systems, In: IFIP Transactions 1994, 1994, pp. 195-208.
[Wesley, 1982] Wesley, P., Elementaire wetenschapsleer (Elementary epistemology, in
Dutch), Boom, Meppel (The Netherlands), 1982.
[Whiteoak, 1993] Whiteoak, P., The Realities of Quick Response in the Grocery Sector: A
Supplier Viewpoint, International Journal of Retail & Distribution
Management, Vol. 21., No. 8, 1993, pp. 3-10.
[Whitin, 1957] Whitin, T.M., The Theory of Inventory Management, Princeton
University Press, Princeton (USA), 1957.
[Wierda, 1991] Wierda, F.W., Developing interorganizational information systems, PhD
thesis, Delft University of Technology, Delft (The Netherlands), 1991.
[Wijngaard, 1985] Wijngaard, J. & Wortmann, J.C., MRP and inventories, European
Journal of Operational Research, Vol. 20, 1985, pp. 281-193.
[Williamson, 1975] Williamson, O.E., Markets and Hierarchies: analysis and anti-trust
implications: a study in the economics of internal organization, Free
Press, New York (USA), 1975.
[Williamson, 1981] Williamson, O.E., The Economics of Organization: The Transaction Cost
Approach, American Journal of Sociology, Vol. 87, No. 3, 1981, pp.
548-577.
[Womack, 1994] Womack, J.P. & Jones, D.J., From Lean Production to the Lean
Enterprise, Harvard Business Review, March-April 1994, pp. 93-103.
[Yu, 1996] Yu, A.Y.C., The Future of Microprocessors, IEEE Micro, December
1996, pp. 46-53.
254
References
[Zijm, 1992] Zijm, W.H.M., Hierarchical production planning and multi-echelon

inventory management, International Journal of Production Economics,
Vol. 26, 1992, pp. 257-264.
255
Abbreviations
Abbreviations
ACDO Aggregate Customer Demand Order
ACDP Aggregate Customer Demand Plan
AD Actual Demand
AI Actual Inventory
APS Advanced Planning Systems
AS Actual Supply
ASDO Aggregate Supplier Demand Order
ASDP Aggregate Supplier Demand Plan
BSC Base Stock Control
C Customer
CASE Computer Aided Software Engineering
CD Compact Disc
CM Customer Manager
CNT Computer Network Technology
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit
CR Continuous Replenishment
CT Cordless Telephone
DCOM Distributed Common Object Model
DOT Distributed Object Technology
DRP Distribution Requirements Planning
DST Distributed System Technology
ECR Efficient Consumer Response
EDI Electronic Data Interchange
EF Explosion Factor
EIPP Exclusive Inventory Position Plan
ERP Enterprise Resource Planning
GIOP General Inter-ORB Protocol
GUI Graphical User Interface
ICDO Individual Customer Demand Order
ICDP Individual Customer Demand Plan
IDL Interface Definition Language
IEC International Electrotechnical Commission
IIM Integral Inventory Management
257
Abbreviations
IIOP Internet Inter-ORB Protocol

IIPP Inclusive Inventory Position Plan
IM Inventory Manager
IN Inventory Norm
IP Internet Protocol
IPO Input Process Order
ISDO Individual Supplier Demand Order
ISDP Individual Supplier Demand Plan
ISO International Standardisation Organisation
ISP Inventory Supply Plan
ITU International Telecommunication Union
JIT Just In Time
LRP Line Requirements Planning
LS Lot Size
LT Lead Time
MRP Material Requirements Planning
NIM Networked Inventory Management
NIMIS Networked Inventory Management Information System
NOM Networked Organisation Management
ODP Open Distributed Processing
OLAP On-Line Analytical Processing
OLTP On-Line Transaction Processing
OM Operational Manager
OMG Object Management Group
OMT Object Modelling Technique
OP Operational Process
OPO Output Process Order
OPT Optimised Production Technology
ORB Object Request Broker
OSI Open System Interconnection
OST Object-oriented System Technology
PC Personal Computer
PDM Product Data Management
QR Quick Response
S Supplier
SA Supplier Allocator
SCM Supply Chain Management
258
Abbreviations
SIC Statistical Inventory Control

SKU Stock Keeping Unit
SM Supplier Manager
SSS Single SKU Stock-point
STM Strategic Manager
STR Strategist
TCP Transmission Control Protocol
TIP Transit Inventory Plan
UML Unified Modelling Language
VMI Vendor Managed Inventory
WFM Work Flow Management
WWW World Wide Web
259
Summary
Summary
Supply chain management is a trend in logistics management, whereas computer
network technology is a trend in information technology. Supply chain management,
particularly integral inventory management across networked organisations, requires
new information systems that provide both integration and flexibility. Computer
network technology, particularly distributed and object-oriented system technology,
allows new information systems to be made up of self-contained components that
operate at different locations. This research shows the functional and technical
feasibility of information systems that can achieve integral inventory management
across networked organisations, by exploiting distributed and object-oriented system
technology. These so-called Networked Inventory Management Information Systems
(NIMISs) are extremely basic information systems that are loosely coupled to one
another in networks. As a result, NIMISs are able to provide the integration required
for integral inventory management, as well as the flexibility required for networked
organisations.
Introduction
Most supply chains still do not profit from supply chain management from natural
resources to final customers. Instead, the supply chains struggle with non-integral
inventory management due to opposition between organisations. However, supply chain
management, in particular integral inventory management across networked
organisations, is becoming a vital issue for improving the productivity and flexibility in
supply chains.
The central and procedural information systems currently applied in supply chains,
are not suitable for integral inventory management across networked organisations. These
systems can not simultaneously support the integration required for integral inventory
management as well as the flexibility required for networked organisations. However,
computer network technology, in particular distributed and object-oriented system
technology, is becoming mature. This technology might better satisfy the requirements of
supply chain management.
The main objective of the research is to show the functional and technical
feasibility of information systems for integral inventory management across networked
organisations, using distributed and object-oriented system technology. The study of these
NIMISs consists of six stages, which are summarised below. The first three research stages
successively address analysis, design and implementation of the systems from a functional
261
Summary
viewpoint, while the last three stages are devoted to analysis, design and implementation
from a technical viewpoint.
Supply chain management analysis

Supply chain management is an integrative approach to planning, control and monitoring
of total materials flow from suppliers to end users, aiming at improved customer service at
reduced overall costs. This approach is a means for organisations to improve their
performance, in particular to achieve higher productivity and greater flexibility. This is
needed to respond to customers who require products with a better price-quality ratio and a
more dynamic product assortment. Important issues in supply chain management are
integral inventory management and networked organisation management.
Integral inventory management, instead of non-integral inventory management,
can contribute to higher productivity in supply chains. Integral inventory management
focuses on the co-ordinated planning, control and monitoring of inventory levels at stock-
points throughout supply chains, in order to maximise overall supply chain performance.
Besides purposely desired inventory and necessarily required inventory, there would
ideally be no extra inventory in supply chains. Existing inventory excesses and shortages
can be reduced with the help of integral inventory management.
Networked organisation management, instead of hierarchical organisation
management, is a means to achieve greater flexibility in supply chains. A networked
organisation is an organisation with its own strategic control unit, that co-operates with
other organisations at a tactical and operational level, within its strategic constraints, in
order to gain mutual benefits. Dynamic networks of organisations are particularly suited
for flexibility improvements, because the participating networked organisations link
network.
The combination of integral inventory management and networked organisation
management is called networked inventory management. Currently, no information
systems for supply chain management appear to be available that give adequate support for
both integral inventory management and networked organisation management. This
induces functional requirements for new information systems for networked inventory
262
Summary
management, these requirements comprise integration in the time dimension and in the
place dimension, by using extra information on time-phased demand or integral inventory.
allow the use of own decision timetables, and that can cope with different decision rules.
autonomy of networked organisations with respect to the place, the time and the type of
management.
Networked inventory management design

The networked inventory management design constitutes the functional design NIMISs.
The integral inventory management design is based on one NIMIS per single SKU
(Stock Keeping Unit) stock-point, holding inventory for one product type at one location.
Thus, a NIMIS is an information system with extremely basic functionality and an
extremely basic architecture. These systems are loosely coupled to one another in
networks. Every system is equipped with system variables and equations, reflecting related
information on a strategist supervising the system, customers, suppliers, the operational
process including the stock-point, and the inventory itself.
The integral inventory management design satisfies the functional requirements of
BSC, MRP/DRP en LRP. With the help of the system variables and equations in a network of
NIMISs, integral inventory management can be accomplished according to one of these
algorithms. The integration, as required for integral inventory management, and as
provided by NIMISs, is the result of loose coupling of extremely basic information systems.
In the networked organisation management design, the scope of a NIMIS is equated
to the system scope in the integral inventory management design. A NIMIS manages just
one single SKU stock-point in the domain of a networked organisation, which uses a
business information system for business functions other than networked inventory
management. For achieving networked organisation management, some supplementary
system variables and equations are included in the NIMISs.
The networked organisation management design satisfies the functional
requirements of configuration flexibility, timing flexibility and algorithm flexibility.
Configuration flexibility is based on creating different networks of NIMISs, operating
independently of business information systems. Timing flexibility is achieved by coping
with different review moments and plan moments in NIMISs. Algorithm flexibility
encompasses algorithm selection in a NIMIS and algorithm transition across NIMISs. The
263
Summary
flexibility, as required for networked organisation management, and as provided by

NIMISs, is just like the integration the result of loose coupling of extremely basic
264
Summary
Case study implementation

A case study implementation shows how the networked inventory management design of
NIMISs fits into a particular environment of logistics management.
manufacturing and distribution of cordless telephones. In the current situation, five
manufacturers in various countries supply KPN Telecom with cordless telephones. KPN
Telecom sells the products through more than one hundred sales outlets in The
Netherlands to customers in the consumer market and in the business market.
A future scenario shows what the supply chains for cordless telephones will
managed in a more integral way.
With the help of networked organisation management the flexibility of the supply
chains can be increased, while integral inventory management can improve the
productivity. However, it is practically unfeasible to develop and maintain the desirable
Networked inventory management can be achieved by application of a NIMIS for
every single SKU stock-point that holds inventory for cordless telephones. Loose coupling
in networks enables the extremely basic information systems to support integral inventory
management and, at the same time, networked organisation management.
NIMISs could achieve networked inventory management in coexistence with the
business information systems currently applied in the supply chains for cordless
telephones. To support networked inventory management by NIMISs, the existing business
information systems can be used for information registration and data management.
Computer network technology analysis

Computer network technology concerns the integration of computers and
telecommunication networks, creating a world-wide web of computer networks. This
enables new ways of information processing and of organising business, as optimisation
can shift towards functional effectiveness, and business networks can be reconfigured with
the help of electronic integration. Important issues in computer network technology are
distributed system technology and object-oriented system technology.
265
Summary

through a communication network in order to provide integrated functions. Distributed
system technology is a means to achieve integration across locations while respecting the
need of organisations to have autonomy over their own information processing.
world entity and contains functions as well as associated data. Object-oriented system
technology can increase the flexibility of information systems. As systems are based on
stable real-world entities, instead of unstable functions, their functionality can be changed
by local adjustments.
The combination of distributed system technology and object-oriented system
technology is called distributed object technology. Currently, no information systems for
supply chain management appear to be available that fully exploit distributed and object-
oriented system technology. This induces technical requirements for new information
systems for networked inventory management (NIMISs).
Technical requirements related to object-oriented system technology are the use of
technology with: object classification, attribute encapsulation and operation invocation.
The information systems consist of objects, which include both functions and associated
data. Data is stored in attributes which are hidden from other objects, and functions are
performed by operations, in response to the receipt of messages. Because of these
requirements, information systems can naturally reflect the structure, data and functions of
networked organisations and their integral inventory management.
Distributed object technology design

The object-oriented system technology design is created with the help of the Object
Modelling Technique (OMT). Hence, NIMISs are specified in an object model, a dynamic
266
Summary
model and a functional model. In the object model five core objects are identified. The
dynamic model includes state diagrams for the core objects as well as event trace diagrams
for two scenarios. In the functional model, the processes that compute new values are
specified in a data flow diagram, while computation formulae are specified as system
equations in the functional design.
The object-oriented system design satisfies the technical requirements of object
classification, attribute encapsulation and operation invocation. Object classification is
accomplished by specifying a NIMIS as a set of interacting object classes and instances.
Attribute encapsulation is based on storage of data in attributes, which can only be
accessed through access operations. Operation invocation is arranged by performing
functions in operations, which are executed in response to the receipt of messages.
The distributed system technology design is created with the Common Object
Request Broker Architecture (CORBA), which includes Object Request Brokers (ORBs),
Interface Definition Language (IDL) interfaces and several types of objects. ORBs are
system components that facilitate interaction of objects that are distributed over systems.
IDL interfaces enable interaction of objects that are programmed in different languages.
CORBA Services and CORBA Facilities offer additional support for the development and
application of systems built of distributed objects.
The distributed system technology design satisfies the technical requirements of
local computing, heterogeneous computing and transparent computing. Local computing
is accomplished by using a local processor and a local memory, for one or more NIMISs at a
location. Heterogeneous computing is realised using IDL interfaces and virtual machines,
that allow interaction across different programming languages, hardware components and
operating systems. Transparent computing is arranged using ORBs and CORBA Services,
which hide technical complexities related to, amongst others, locations, transactions and
persistence.
Prototype system implementation

The prototype system implementation shows how the distributed object technology design
of NIMISs fits into a particular environment of information technology.
Information technology in the prototype NIMIS encompasses the tools for
development and application of distributed and object-oriented information systems.
Suitable tools for the implementation of NIMISs are the Smalltalk programming language,
the user-interface objects of Visual Works and the CORBA implementation of Distributed
Smalltalk.
Besides the objects specified in the distributed object technology design, a network
of prototype NIMISs includes extra implementation specific objects. In addition to the five
core objects, there are extra domain objects for the implementation of technical system
267
Summary
details. Further, user-interface objects are added to implement the user-interface. The
prototype implementation also includes environment objects to simulate systems in the
environment of the prototype NIMISs.
For achieving networked inventory management in particular supply chains, a
prototype NIMIS is installed for every single SKU stock-point that needs to be managed. By
exploiting distributed object technology, a network of prototype NIMISs can be installed
that exactly reflects the single SKU stock-point in the supply chains.
Occasional management and regular management are the two main operating
modes in the use of the prototype NIMISs. Occasional management includes the setting of
new values for parameters and the handling of possible exceptions. Regular management
concerns the monitoring and checking of orders and plans coming in from customers and
going out to suppliers.
Conclusion
From the results of this study, it can be concluded that NIMISs are functionally and
technically feasible. The claim of functional feasibility is supported by the outcomes of the
supply chain management analysis, the networked inventory management design and the
case study implementation. The claim of technical feasibility is supported by the outcomes
of the computer network technology analysis, the distributed object technology design and
the prototype system implementation.
In the near future, a newer type of supply chain management may come into being,
in which integral inventory management is realised across networked organisations, by co-
operation between organisations in supply chains. The NIMISs introduced in this study can
achieve integral inventory management across networked organisations, by exploiting
distributed and object-oriented system technology. These extremely basic information
systems are loosely coupled to one another in networks. As a result, NIMISs are able to
provide the integration required for integral inventory management, as well as the
flexibility required for networked organisations.
268
Samenvatting
Samenvatting
Logistieke ketenbesturing is een trend in logistiek management, terwijl computer-
netwerktechnologie een trend is in informatietechnologie. Voor logistieke
ketenbesturing, met name voor integrale voorraadbesturing over
netwerkorganisaties, zijn nieuwe informatiesystemen nodig die zowel integratie als
flexibiliteit verschaffen. Computer-netwerktechnologie, met name gedistribueerde en
object-georiënteerde systeemtechnologie, maakt het mogelijk dat nieuwe
informatiesystemen opgebouwd worden uit zelfstandige componenten die op
verschillende lokaties werken. Dit onderzoek toont de functionele en technische
haalbaarheid van informatiesystemen die integrale voorraadbesturing over
netwerkorganisaties tot stand kunnen brengen, door gebruik te maken van
gedistribueerde en object-georiënteerde systeemtechnologie. Deze zogenaamde
Networked Inventory Management Information Systems (NIMISs) zijn uiterst
elementaire systemen die op een losse manier aan elkaar gekoppeld zijn in
netwerken. Hierdoor zijn de NIMISs in staat om zowel de benodigde integratie voor
integrale voorraadbesturing als de benodigde flexibiliteit voor netwerkorganisaties te
verschaffen.
Inleiding
De meeste logistieke ketens profiteren nog steeds niet van logistieke ketenbesturing vanaf
natuurlijke hulpbronnen tot aan uiteindelijke klanten. In plaats daarvan kampen de
logistieke ketens met niet-integrale voorraadbesturing vanwege tegenstand tussen
organisaties. Logistieke ketenbesturing, in het bijzonder integrale voorraadbesturing over
netwerkorganisaties, wordt echter een cruciaal aandachtspunt voor de verbetering van de
productiviteit en flexibiliteit van logistieke ketens.
De centrale en procedurele informatiesystemen die nu gebruikt worden in logistieke
ketens, zijn niet geschikt voor integrale voorraadbesturing over netwerkorganisaties. Deze
systemen kunnen niet gelijktijdig de benodigde integratie voor integrale voorraadbesturing
en de benodigde flexibiliteit voor netwerkorganisaties ondersteunen. Computer-
netwerktechnologie, in het bijzonder gedistribueerde en object-georiënteerde
systeemtechnologie, is echter volwassen aan het worden. Deze technologie zou wellicht
beter aan de eisen van logistieke ketenbesturing kunnen voldoen.
Het doel van het onderzoek is het aantonen van de functionele en technische
haalbaarheid van informatiesystemen voor integrale voorraadbesturing over
netwerkorganisaties, die gebruik maken van gedistribueerde en object-georiënteerde
systeemtechnologie. Het onderzoek naar deze NIMISs bestaat uit zes fasen, die hieronder
269
Samenvatting
worden samengevat. De eerste drie onderzoeksfasen behandelen achtereenvolgens analyse,

ontwerp en implementatie van de systemen vanuit functioneel perspectief, terwijl de
laatste drie fasen gewijd zijn aan analyse, ontwerp en implementatie vanuit technisch
perspectief.
Analyse van logistieke ketenbesturing

Logistieke ketenbesturing (‘supply chain management’) is een integrale benadering van de
planning, aansturing en bewaking van de totale goederenstromen vanaf leveranciers tot
aan eindgebruikers, die gericht is op betere bediening van klanten tegen lagere totale
kosten. Deze benadering is voor organisaties een middel om hun prestatie te verbeteren, in
het bijzonder om een hogere productiviteit en een grotere flexibiliteit te bereiken. Dit is
nodig om te reageren op klanten die producten met een betere prijs/kwaliteit-verhouding
en een dynamischer productassortiment eisen. Belangrijke aandachtspunten in logistieke
ketenbesturing zijn integrale voorraadbesturing en netwerk-organisatiebesturing.
Integrale voorraadbesturing (‘integral inventory management’), in plaats van niet-
integrale voorraadbesturing, kan bijdragen aan een hogere productiviteit in logistieke
ketens. Integrale voorraadbesturing is gericht op de gecoördineerde planning, aansturing
en bewaking van voorraadniveaus van voorraadpunten in logistieke ketens om de totale
prestatie van de logistieke ketens te maximaliseren. Naast doelbewust gewenste voorraad
en noodzakelijkerwijs vereiste voorraad zou er idealiter geen extra voorraad in logistieke
ketens aanwezig zijn. Aanwezige voorraadoverschotten of -tekorten kunnen verminderd
worden met behulp van integrale voorraadbesturing.
Netwerk-organisatiebesturing (‘networked organisation management’), in plaats
van hiërarchische organisatiebesturing, is een manier om grotere flexibiliteit in logistieke
ketens te verkrijgen. Een netwerkorganisatie is een organisatie met een eigen strategische
besturingseenheid, die binnen zijn strategische randvoorwaarden op tactisch en
operationeel niveau samenwerkt met andere organisaties om wederzijds voordeel te
bereiken. Met name dynamische netwerken van organisaties zijn geschikt om de
flexibiliteit te verbeteren, omdat de betrokken netwerkorganisaties zich verbinden voor
tijdelijke productie en daarna weer ontbinden om onderdeel te worden van een ander
netwerk.
De combinatie van integrale voorraadbesturing en netwerk-organisatiebesturing
wordt netwerk-voorraadbesturing (‘networked inventory management’) genoemd. Op dit
moment blijken er geen informatiesystemen voor logistieke ketenbesturing beschikbaar te
zijn die voldoende ondersteuning bieden voor zowel integrale voorraadbesturing als
netwerk-organisatiebesturing. Dit induceert functionele eisen aan nieuwe
informatiesystemen voor netwerk-voorraadbesturing (NIMISs).
270
Samenvatting
Functionele eisen met betrekking tot integrale voorraadbesturing zijn het

verschaffen van functionaliteit voor Base Stock Control (BSC), Material/Distribution
Requirements Planning (MRP/DRP) en Line Requirements Planning (LRP). De
informatiesystemen moeten functionaliteit verschaffen om voorraad integraal te besturen
volgens deze drie algoritmen. Vergeleken met niet-integrale voorraadbesturing omvatten
deze eisen integratie in de tijdsdimensie en in de plaatsdimensie, door gebruik te maken
van extra informatie over tijdgefaseerde vraag of integrale voorraad.
Functionele eisen met betrekking tot netwerk-organisatiebesturing zijn het
verschaffen van functionaliteit voor configuratie-flexibiliteit, timing-flexibiliteit en
algoritme-flexibiliteit. De informatiesystemen moeten aparte besluitvormingseenheden
representeren, die het gebruik van eigen tijdschema’s toestaan en om kunnen gaan met
verschillende beslissingsregels. Vergeleken met hiërarchische organisatiebesturing zorgen
deze eisen voor autonomie van netwerkorganisaties met betrekking tot de plaats, de tijd en
de soort van besturing.
Ontwerp voor netwerk-voorraadbesturing

Het ontwerp voor netwerk-voorraadbesturing vormt het functioneel ontwerp van NIMISs.
Het functioneel ontwerp bestaat uit een ontwerp voor integrale voorraadbesturing en een
ontwerp voor netwerk-organisatiebesturing.
Het ontwerp voor integrale voorraadbesturing is gebaseerd op één NIMIS per
enkelvoudig SKU (‘Stock Keeping Unit’) voorraadpunt, dat voorraad bevat voor één
productsoort op één lokatie. Een NIMIS is dus een informatiesysteem met uiterst
elementaire functionaliteit en een uiterst elementaire architectuur. Deze systemen zijn op
een losse manier aan elkaar gekoppeld in netwerken. Ieder systeem is uitgerust met
systeemvariabelen en -vergelijkingen, die samenhangende informatie weerspiegelen van
een strateeg die toezicht houdt op het systeem, klanten, leveranciers, het operationeel
proces inclusief het voorraadpunt, en de voorraad zelf.
Het ontwerp voor integrale voorraadbesturing voldoet aan de functionele eisen van
BSC, MRP/DRP en LRP. Met behulp van de systeemvariabelen en -vergelijkingen in een
netwerk van NIMISs kan integrale voorraadbesturing volgens een van deze algoritmen
gerealiseerd worden. De integratie, zoals vereist voor integrale voorraadbesturing en zoals
verschaft door NIMISs, is het resultaat van losse koppeling van uiterst elementaire
informatiesystemen.
In het ontwerp voor netwerk-organisatiebesturing wordt de reikwijdte van een
NIMIS gelijk gesteld aan de reikwijdte van de systemen in het ontwerp voor integrale
voorraadbesturing. Een NIMIS bestuurt slechts één enkelvoudig SKU voorraadpunt in het
domein van een netwerkorganisatie, die een bedrijfsinformatiesysteem gebruikt voor
bedrijfsfuncties anders dan netwerk-voorraadbesturing. Om netwerk-organisatiebesturing
271
Samenvatting
te bereiken, worden enkele aanvullende systeemvariabelen en -vergelijkingen aan de

NIMISs toegevoegd.
Het ontwerp voor netwerk-organisatiebesturing voldoet aan de functionele eisen
van configuratie-flexibiliteit, timing-flexibiliteit en algoritme-flexibiliteit. Configuratie-
flexibiliteit is gebaseerd op het creëren van verschillende netwerken van NIMISs, die
onafhankelijk van bedrijfsinformatiesystemen kunnen werken. Timing-flexibiliteit wordt
bereikt door om te kunnen gaan met verschillende bestel- en planmomenten in NIMISs.
Algoritme-flexibiliteit omvat de selectie van een algoritme in een NIMIS en de transitie van
algoritmen tussen NIMISs. De flexibiliteit, zoals vereist voor netwerk-organisatiebesturing
en zoals geboden door NIMISs, is net zoals de integratie het resultaat van losse koppeling
van uiterst elementaire informatiesystemen.
Implementatie in een case-study

Een implementatie in een case-study toont hoe het ontwerp van NIMISs voor netwerk-
voorraadbesturing past in een specifieke omgeving van logistiek management.
Logistiek management in de case-study betreft een netwerk van logistieke ketens
voor de productie en distributie van draadloze telefoons. In de huidige situatie zijn er vijf
producenten in diverse landen die aan KPN Telecom draadloze telefoons leveren. KPN
Telecom verkoopt de producten via meer dan honderd verkoopkanalen in Nederland aan
klanten in de consumentenmarkt en in de zakelijke markt.
Een toekomstscenario laat zien hoe de logistieke ketens voor draadloze telefoons er
waarschijnlijk over een paar jaar uit zullen zien ten gevolge van verwachte veranderingen.
Om het marktaandeel in een tijd van heftige concurrentie te consolideren wil KPN
Telecom zijn bedrijfsprestatie verder verbeteren. De verwachting is dat het netwerk van
organisaties in de logistieke ketens groter wordt en vaker zal wijzigen, terwijl de logistieke
ketens tegelijkertijd integraler bestuurd zullen gaan worden.
Met behulp van netwerk-organisatiebesturing kan de flexibiliteit van de logistieke
ketens vergroot worden, terwijl integrale voorraadbesturing de productiviteit kan
verbeteren. Praktisch bezien is het echter onhaalbaar om de wenselijke netwerk-
voorraadbesturing te ontwikkelen en te onderhouden met de bestaande informatiesystemen
in de logistieke ketens voor draadloze telefoons. De heterogeniteit en instabiliteit van de
systemen die momenteel gebruikt worden, zouden een onbeheersbaar aantal
gespecialiseerde interfaces vereisen.
Netwerk-voorraadbesturing kan bereikt worden door toepassing van een NIMIS voor
ieder enkelvoudig SKU voorraadpunt waar draadloze telefoons op voorraad worden
gehouden. Losse koppeling in netwerken stelt de uiterst elementaire informatiesystemen in
staat om tegelijkertijd integrale voorraadbesturing en netwerk-organisatiebesturing te
ondersteunen.
272
Samenvatting
NIMISs zouden netwerk-voorraadbesturing kunnen bereiken in coëxistentie met de

bedrijfsinformatiesystemen die momenteel gebruikt worden in de logistieke ketens voor
draadloze telefoons. Om netwerk-voorraadbesturing door NIMISs te ondersteunen, kunnen
de bestaande informatiesystemen gebruikt worden voor registratie van informatie en
beheer van gegevens.
Analyse van computer-netwerktechnologie

Computer-netwerktechnologie (‘computer network technology’) betreft de integratie van
computers en telecommunicatienetwerken, waardoor een wereldwijd web van
computernetwerken ontstaat. Dit maakt nieuwe manieren van informatieverwerking en
bedrijfsinrichting mogelijk, omdat de optimalisatie kan verschuiven van technische
efficiëntie naar functionele effectiviteit en bedrijfsnetwerken met behulp van elektronische
integratie andere configuraties kunnen krijgen. Belangrijke aandachtspunten in computer-
netwerktechnologie zijn gedistribueerde systeemtechnologie en object-georiënteerde
systeemtechnologie.
Gedistribueerde systeemtechnologie (‘distributed system technology’) heeft
betrekking op technologie voor groepen van autonome computers, elk bestaande uit
verwerkings- en opslagelementen, die onderling verbonden zijn via een
communicatienetwerk om geïntegreerde functies te verschaffen. Gedistribueerde
systeemtechnologie is een middel om integratie tussen lokaties te bereiken, met
inachtneming van de behoefte van organisaties om autonomie over hun eigen
informatieverwerking te hebben.
Object-georiënteerde systeemtechnologie (‘object-oriented system technology’) gaat
over het ontwerpen en implementeren van informatiesystemen als een verzameling
objecten die elkaar aanroepen. Een object bevat zowel functies als de daarbij behorende
gegevens en representeert een entiteit uit de reële wereld. Object-georiënteerde
systeemtechnologie kan de flexibiliteit van informatiesystemen vergroten. Omdat systemen
gebaseerd worden op stabiele entiteiten uit de reële wereld in plaats van instabiele
functies, kan hun functionaliteit gewijzigd worden door lokale aanpassingen.
De combinatie van gedistribueerde systeemtechnologie en object-georiënteerde
systeemtechnologie wordt gedistribueerde objecttechnologie (‘distributed object
technology’) genoemd. Op dit moment blijken er geen informatiesystemen voor logistieke
ketenbesturing beschikbaar te zijn die gedistribueerde en object-georiënteerde
systeemtechnologie volledig benutten. Dit induceert technische eisen aan nieuwe
informatiesystemen voor voorraadbesturing in netwerken (NIMISs).
Technische eisen met betrekking tot gedistribueerde systeemtechnologie zijn
het gebruik van technologie met lokale verwerking, heterogene verwerking en
transparante verwerking. De informatieverwerking mag uitgevoerd worden door
273
Samenvatting
computers op verschillende lokaties, de computers mogen uitgerust zijn met verschillende

technieken en de technische complexiteit van een gedistribueerd systeem blijft verborgen
voor de toepassingsspecifieke componenten. Deze eisen zorgen ervoor dat
netwerkorganisaties integratie over lokaties kunnen bereiken, met behoud van autonomie
over hun eigen functies en gegevens, de technieken van hun systemen en het beheer van
technische complexiteit.
Technische eisen met betrekking tot object-georiënteerde systeemtechnologie zijn
het gebruik van technologie met object-classificatie, attribuut-inkapseling en operatie-
aanroeping. De informatiesystemen bestaan uit objecten die zowel functies als de
bijbehorende gegevens bevatten. Gegevens zijn opgeslagen in attributen die verborgen zijn
voor andere objecten en functies worden vervuld door operaties in reactie op de ontvangst
van berichten. Door deze eisen kunnen de informatiesystemen op een natuurlijke wijze de
structuur, gegevens en functies van netwerkorganisaties en hun integrale
voorraadbesturing kunnen weerspiegelen.
Ontwerp voor gedistribueerde objecttechnologie

Het ontwerp voor gedistribueerde objecttechnologie vormt het technisch ontwerp van
NIMISs. Het technisch ontwerp bestaat uit een ontwerp voor gedistribueerde
systeemtechnologie en een ontwerp voor object-georiënteerde systeemtechnologie.
Het ontwerp voor object-georiënteerde systeemtechnologie wordt gecreëerd met
behulp van de Object Modelling Technique (OMT). Daarmee worden NIMISs gespecificeerd
in een objectmodel, een dynamisch model en een functioneel model. In het objectmodel
worden vijf kernobjecten geïdentificeerd. Het dynamisch model omvat zowel
toestandsdiagrammen voor de kernobjecten als diagrammen met sporen van
gebeurtenissen voor twee scenario’s. In het functioneel model worden processen die
nieuwe waarden berekenen gespecificeerd in een gegevensstroomdiagram, terwijl
berekeningsformules gespecificeerd worden als systeemvergelijkingen in het functioneel
ontwerp.
Het ontwerp voor object-georiënteerde systeemtechnologie voldoet aan de
technische eisen van object-classificatie, attribuut-inkapseling en operatie-aanroeping.
Object-classificatie wordt bereikt door een NIMIS te specificeren als een verzameling
interactieve objectklassen en -instanties. Attribuut-inkapseling is gebaseerd op de opslag
van gegevens in attributen die alleen toegankelijk zijn via toegangsoperaties. Operatie-
aanroeping wordt gerealiseerd door functies te verschaffen met behulp van operaties die
uitgevoerd worden in reactie op de ontvangst van berichten.
Het ontwerp voor gedistribueerde systeemtechnologie wordt gecreëerd met behulp
van de Common Object Request Broker Architecture (CORBA), die bestaat uit Object
Request Brokers (ORBs), Interface Definition Language (IDL) interfaces en enkele soorten
274
Samenvatting
objecten. ORBs zijn systeemcomponenten die interactie faciliteren tussen objecten die
gedistribueerd zijn over systemen. IDL interfaces maken interactie mogelijk tussen
objecten die geprogrammeerd zijn in verschillende talen. CORBA Services en CORBA
Facilities bieden aanvullende ondersteuning voor de ontwikkeling en toepassing van
systemen die opgebouwd zijn uit gedistribueerde objecten.
Het ontwerp voor gedistribueerde systeemtechnologie voldoet aan de technische
eisen van lokale verwerking, heterogene verwerking en transparante verwerking. Lokale
verwerking wordt gerealiseerd door het gebruik van een lokale processor en een lokaal
geheugen voor één of meer NIMISs op een lokatie. Heterogene verwerking wordt bereikt
met IDL interfaces en ‘virtual machines’, die interactie mogelijk maken tussen
verschillende programmeertalen, hardware-componenten en operating-systems.
Transparante verwerking wordt geregeld door ORBs and CORBA Services, die de technische
complexiteit met betrekking tot onder andere lokaties, transacties en persistentie
verbergen.
Implementatie in een prototype-systeem

Een implementatie in een prototype-systeem toont hoe het ontwerp van NIMISs voor
gedistribueerde objecttechnologie past in een specifieke omgeving van
informatietechnologie.
De informatietechnologie in het prototype-NIMIS omvat de middelen voor de
ontwikkeling en toepassing van gedistribueerde en object-georiënteerde
informatiesystemen. Geschikte middelen voor de implementatie van NIMISs zijn de
programmeertaal Smalltalk, de gebruikersinterface-objecten van Visual Works en de
CORBA-implementatie van Distributed Smalltalk.
Behalve de objecten die gespecificeerd zijn in het ontwerp voor gedistribueerde
objecttechnologie, omvat een netwerk van prototype-NIMISs extra implementatie-specifieke
objecten. Naast de vijf kernobjecten zijn er extra domeinobjecten voor de implementatie
van technische systeemdetails. Verder worden er gebruikersinterface-objecten toegevoegd
om de gebruikersinterface te implementeren. De prototype-implementatie omvat ook
omgevingsobjecten om systemen in de omgeving van de prototype-NIMISs te simuleren.
Om netwerk-voorraadbesturing in bepaalde logistieke ketens te bereiken, wordt
voor ieder enkelvoudig SKU voorraadpunt dat bestuurd moet worden een prototype-NIMIS
geïnstalleerd. Door benutting van gedistribueerde objecttechnologie kan een netwerk van
prototype-NIMISs worden geïnstalleerd dat precies de enkelvoudige SKU voorraadpunten in
de logistieke ketens weerspiegelt.
Incidentele besturing en regelmatige besturing zijn de twee belangrijkste
werkwijzen in het gebruik van de prototype-NIMISs. Incidentele besturing omvat het
instellen van parameters met nieuwe waarden en de afhandeling van mogelijke
275
Samenvatting
uitzonderingen. Regelmatige besturing betreft het bewaken en controleren van orders en

plannen die binnenkomen van klanten en uitgaan naar leveranciers.
Conclusie
Uit de resultaten van dit onderzoek kan geconcludeerd worden dat NIMISs functioneel en
technisch haalbaar zijn. De claim van de functionele haalbaarheid wordt ondersteund door
de uitkomsten van de analyse van logistieke ketenbesturing, het ontwerp voor netwerk-
voorraadbesturing en de implementatie in de case-study. De claim van de technische
haalbaarheid wordt ondersteund door de uitkomsten van de analyse van computer-
netwerktechnologie, het ontwerp voor gedistribueerde objecttechnologie en de
implementatie in het prototype-systeem.
In de nabije toekomst kan een nieuwe vorm van logistieke ketenbesturing ontstaan,
waarin integrale voorraadbesturing gerealiseerd wordt over netwerkorganisaties door
samenwerking tussen organisaties in logistieke ketens. De NIMISs die geïntroduceerd zijn
in dit onderzoek kunnen integrale voorraadbesturing over netwerkorganisaties tot stand
brengen, door gebruik te maken van gedistribueerde en object-georiënteerde
systeemtechnologie. Deze uiterst elementaire systemen zijn op een losse manier aan elkaar
gekoppeld in netwerken. Hierdoor zijn de NIMISs is staat om zowel de benodigde integratie
voor integrale voorraadbesturing als de benodigde flexibiliteit voor netwerkorganisaties te
verschaffen.
276
Curriculum vitae
Curriculum vitae
Martin Verwijmeren was born in Breda (The Netherlands) on May 30th 1969. In 1991 he
graduated ‘cum laude’ in Industrial Engineering & Management Science at the Eindhoven
University of Technology. At Canon in Japan he studied inventory management in laser
printer assembly, while at KLM (Royal Dutch Airlines) he did research into air cargo
scheduling.
For the last six years, he has been a project manager, consultant and scientist, in
the area of logistics management and information technology at KPN Research, the
corporate R&D institute of KPN, also doing contract research for TPG (TNT Post Groep).
KPN provides global telecommunications services, while TPG provides logistics services
to customers world-wide. He participated in a variety of projects on logistics management
and information technology, advised in several business development projects, and was
manager of a program on information technology in traffic and transport.
At KPN Research, he studied the design of information systems for integral
inventory management across networked organisations, which make use of distributed and
object-oriented system technology. This research was carried out in a PhD study at the
Eindhoven University of Technology and resulted in this dissertation. Besides many
internal publications at KPN, he has published in logistics journals in The Netherlands, in
the European Journal of Operational Research and in the International Journal of Physical
Distribution & Logistics Management.
He grew up in Prinsenbeek, has been resident in Eindhoven and Groningen, and
nowadays lives in Rotterdam, together with his beloved Marieke. He enjoys doing leisure
activities with a group of dear friends, met at university and regularly meeting ever since.
Playing his trombone for fun in a carnival band is for Martin a favourite way to relax.
277

9802717

Î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

9802717

Încărcat de

Drepturi de autor:

Formate disponibile

Networked Inventory Management

Networked Inventory Management by Distributed Object Technology /

Keywords: logistics management, information technology, supply chain management, inventory

NUGI 687 / 855

Cover picture by Marieke Kavelaars

 1998 Koninklijke KPN NV, KPN Research, Leidschendam, The Netherlands

ter verkrijging van de graad van doctor

Martinus Antonius Adrianus Petrus Verwijmeren

prof.ir. P. van der Vlist

prof.dr.ir. A.J.M. Vermunt

Martin Verwijmeren, July 1998

2. Supply chain management analysis 15

3. Networked inventory management design 43

3.2.1.3 System equations 54

4. Case study implementation 107

5. Computer network technology analysis 127

5.3.2 Object-oriented system technology requirements 145

6. Distributed object technology design 151

7. Prototype system implementation 209

Curriculum vitae 277

1.1 Research problem

Logistics management has been performed since the beginning of civilisation.

The current trend in information technology is computer network technology,

Natural Material Component Product Final

Integration Integration Integration Integration Integration

Material Material Component Component Product Central Regional Local

Central and procedural

Figure 1-1 Non-integral inventory management by opposition between organisations,

Natural Material Component Product Final

Central and procedural

Natural Material Component Product Final

Material Material Component Component Product Central Regional Local

Distributed and object-oriented

Figure 1-3 Integral inventory management by co-operation across networked

show the functional and technical feasibility of information systems

management, the focus is on alternative information processing in already known

1.2 Research method

system in a particular system environment is deduced. The system implementation tests

Logistics management Information technology

Supply chain management Computer network technology

Networked inventory management Distributed object technology

Case study Prototype system

Figure 1-4 Research framework

management. Chapter 4 is dedicated to the case study implementation of the information

2. Supply chain management analysis

2.2 Issues in supply chain management

markets, the flexibility of organisations could be improved by co-operation with other

SCM: Supply chain management

IIM: NIM: NOM:

Figure 2-1 Issues in supply chain management

2.2.1 Supply chain management

A supply chain typically crosses several organisational boundaries as the materials

Figure 2-2 World-wide supply chains

Due to increasing competition, companies are required to improve their business

constraints imposed by their respective strategic management units, aiming at an optimal

Supply chain management is a concept for organisations to achieve higher productivity

2.2.2 Integral inventory management

Natural Material Component Product Final

Material Material Component Component Product Central Regional Local

Figure 2-3 Inventory categories in supply chains

Integral inventory management concerns the co-ordinated planning, control and

2.2.3 Networked organisation management

Market Networked organisations Hierarchy

Loose relationships Semi-stable relationships Fixed relationships