Networked Inventory Management by Distributed Object Technology

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.

Networked Inventory Management

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

I

PrefaceHuman 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.

Preface

II

Martin Verwijmeren, July 1998

Contents

III

Contents

1. Introduction 11.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 152.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 433.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

Contents

IV

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 1074.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 1275.1 Introduction 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

Contents

V

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 1516.1 Introduction 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 2097.1 Introduction 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

Contents

VI

8. Conclusion 2318.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

Chapter 1 Introduction

1

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].

Introduction Chapter 1

2

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.


3

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.


4

Integration Integration Integration IntegrationIntegration

Central and proceduralinformation systemStock-pointOpposition Goods Information

Componentmanufacturer

Materialwinner

Productmanufacturer Wholesaler Retailer

Finalcustomers

Naturalresources

Componentstock

Materialstock

Materialstock

Productstock

Componentstock

Regionalstock

Centralstock

Localstock

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.


5

Central and proceduralinformation systemStock-point

Integration

Domination Goods Information


Materialwinner


Finalcustomers

Naturalresources

Componentstock

Materialstock

Materialstock

Productstock

Componentstock

Regionalstock

Centralstock

Localstock

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.


6

Distributed and object-orientedinformation systemStock-pointCo-operation

Integration

Goods Information


Materialwinner


Finalcustomers

Naturalresources

Componentstock

Materialstock

Materialstock

Productstock

Componentstock

Regionalstock

Centralstock

Localstock

Figure 1-3 Integral inventory management by co-operation across networkedorganisations, 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


7

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


8

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


9

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


10

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

the fit of the system design in the particular system environment.


11

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.


12

Information technologyLogistics management

Networked inventory managementdesign (3)

Distributed object technologydesign (6)

Supply chain managementanalysis (2)

Computer network technologyanalysis (5)

Case studyimplementation (4)

Prototype systemimplementation (7)

Introduction (1)

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


13

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


14

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.

Chapter 2 Supply chain management analysis

15

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

Supply chain management analysis Chapter 2

16

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.

SCM: Supply chain management(2.2.1)

Logistics management

NIM:

Networkedinventory

management

(2.3)

NOM:

Networkedorganisationmanagement

(2.2.3)

IIM:

Integralinventory

management

(2.2.2)

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.


17

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


18

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


19

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


20

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


21

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.


Materialwinner


Finalcustomers

Naturalresources

Inventory

Excess

Desired

Required

Shortage

Componentstock

Materialstock

Materialstock

Productstock

Componentstock

Regionalstock

Centralstock

Localstock

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,


22

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


23

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


24

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


25

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.

HierarchyNetworked organisationsMarket

Organisation

Fixed relationshipsSemi-stable relationshipsLoose relationships

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


26

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


27

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


28

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.


29

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.

Integral inventory managementSuppliers

Networkedorganisation

Customers



Operational processincluding a stock-pointGoods flow Information flow

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


30

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.


31

SCM: Supply chain management

Integral inventory management:

• Base Stock Control

• Material/Distribution Requirements Planning

• Line Requirements Planning

Networked organisation management:

• Configuration flexibility

• Timing flexibility

• Algorithm flexibility

Networked inventory management requirements

NIMIS

NIM:

Networkedinventory

management

NOM:

Networkedorganisationmanagement

IIM:

Integralinventory

management

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


32

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


33

time-phased management represents integration in the time dimension of inventory

management.

MRP LRP

SIC BSC

Time focus

Place focus

Time-phasedmanagement

Instantaneousmanagement

Localinventory

Integralinventory

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].


34

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


35

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].


36

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.


37

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


38

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].


39

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


40

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


41

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.

Chapter 3 Networked inventory management design

43

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

Networked inventory management design Chapter 3

44

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.


45

NIMIS Networked Inventory ManagementInformation System

Operational process including onesingle SKU stock-point

Information flow

Goods flow

S3

NIMIS S3

C3

NIMIS C3

X1

NIMIS X1

S2

NIMIS S2

C2

NIMIS C2

S1

NIMIS S1

C1

NIMIS C1

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.


46

Strategist

NIMIS

Newparametervalues Unsolved

exception

SolvedexceptionCurrent

parametervalues

Co-operationagreement


Supplierplans

Customerplans

Supplierorders

Customerorders

Actualsupply

Output ordersInput orders

Actualdemand

CustomersSuppliers

Goods flow

Information flow

Networked Inventory ManagementInformation System

Operational process includingone single SKU stock-point

NIMIS

Actual inventory

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


47

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.


48

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

PprTime 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.


49

Table 3-2 Customer related variables


Cc Name of customer Cc

c Index to customer Cc

NC Number of customers Cc

ICDO(Cc, Rr)

Individual Customer Demand Order

received from customer Cc

at review moment Rr

ACDO(Rr) Aggregate Customer Demand Order

computed at review moment Rr

ICDP(Cc, Rr, Ppr)

Individual Customer Demand Plan


at review moment Rr

for plan moment Ppr

ACDP(Rr, Ppr)

Aggregate Customer Demand Plan


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.


50

Table 3-3 Operational process related variables


AI(Rr)

Actual Inventory

at review moment Rr

after Actual Supply and Demand

at review moment Rr

AD(Rr)

Actual Demand

at review moment Rr

after Actual Supply

at review moment Rr

AS(Rr)

Actual Supply

at review moment Rr

before Actual Demand

at review moment Rr

OPO(Cc, Rr)

Output Process Order

related to customer Cc

at order moment Rr

IPO(Ss, Uu, Rr)

Input Process Order

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.


51

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

TIP(Rr, Ppr)

Transit Inventory Plan

at review moment Rr

for plan moment Ppr

EIPP(Rr, Ppr)

Exclusive Inventory Position Plan

at review moment Rr

for plan moment Ppr

ISP(Rr, Ppr)

Inventory Supply Plan

at review moment Rr

for plan moment Ppr

IIPP(Rr, Ppr)

Inclusive Inventory Position Plan

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


52

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).


53

Table 3-5 Supplier related variables


Ss Name of supplier Ss

s Index to supplier Ss

NS Number of suppliers Ss

SA(Uu, Ss)

Supplier Allocator

for product unit Uu

from supplier Ss

ASDP(Uu, Rr, Ppr–LT)

Aggregate Supplier Demand Plan

for product unit Uu

at review moment Rr

for plan moment Ppr–LT

ISDP(Ss, Uu, Rr, Ppr–LT)

Individual Supplier Demand Plan

sent to supplier Ss

for product unit Uu

at review moment Rr

for plan moment Ppr–LT

ASDO(Uu, Rr)

Aggregate Supplier Demand Order

for product unit Uu

at review moment Rr

ISDO(Ss, Uu, Rr)

Individual Supplier Demand Order

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


54

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

derived from events

with: r = 0 1, ,2,...

Review moment Rr

in the NIMIS

Ppr= set by the strategist or

derived from events

with:p NP

P Rr r

rr

= ∧

=

0 1

0

, ,2, . . . ,

Plan moment Ppr

at review moment Rr

in the NIMIS

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


55

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

with: c NC= 1,2, . . . ,

Name of customer Cc

ICDO C Rc r( , ) = received from customer Cc Individual Customer Demand Order


at review moment Rr

ACDO R ICDO C Rr c rc

NC

( ) ( , )==

∑1

Aggregate Customer Demand Order


ICDP C R Pc r pr( , , ) = received from customer Cc Individual Customer Demand Plan


at review moment Rr

for plan moment Ppr

ACDP R P ICDP C R Pr p c r pc

NC

r r( , ) ( , , )=

=∑

1

Aggregate Customer Demand Plan


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.


56

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


AI Rr( ) = received from the operational process

Actual Inventory

at review moment Rr

after Actual Supply and Demand

at review moment Rr

AD Rr( ) = received from the operational process

Actual Demand

at review moment Rr

after Actual Supply

at review moment Rr

AS Rr( ) = received from the operational process

Actual Supply

at review moment Rr

before Actual Demand

at review moment Rr

OPO C R ICDO C Rc r c r( , ) ( , )=

Output Process Order

related to customer Cc

at review moment Rr

IPO S U R ISDO S U Rs u r s u r( , , ) ( , , )=

Input Process Order

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


57

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

with: u NU= 1,2,.. .,

Name of product unit type Uu

EF Uu( )= set by the strategist Explosion Factor

for product unit type Uu

For BSC:

TIP R PASDO U R

EF Uru i

ui a

b

r( , )

( , )

( )0 ==∑

with:R P LT R

R P R

a a

b b

r

r

−

+

≤ − < ∧

< ≤1 0

0 1


at review moment Rr

for plan moment P0r

when the NIMIS applies BSC

For MRP/DRP and LRP:

TIP R PASDO U R

EF Ur pu i

ui a

b

r( , )

( , )

( )=

=∑

with:R P LT R

R P LT R

a p a

b p b

r

r

− −

+

≤ − < ∧

≤ − <1 1

1

for: R P R LTr p rr< < +

and

TIP R Pr pr( , ) = 0

for: P R P R LTp r p rr r= ∨ ≥ +


at review moment Rr

for plan moment Ppr

when the NIMIS applies

MRP/DRP or LRP

EIPP R P

AI R TIP R P ACDP R P

r p

r r ii

p

r ii

pr

r r

( , )

( ) ( , ) ( , )

=

+ −= =∑ ∑

0 0

Exclusive Inventory Position Plan

at review moment Rr

for plan moment Ppr


58


For BSC:

ISP R P

roundupIN EIPP R P

LSLS

r

r

r

r

( , )

max ,( , )

0

00

=

−

⋅


at review moment Rr

for plan moment P0r



( )ISP R Pr pr, = 0

for: P R LTp rr< +

and

ISP R P

roundup

IN EIPP R P ISP R P

LSLS

r p

r p r ii

p

r

r r

( , )

max ,

( , ) ( , )

=

− −

⋅

=

−∑

0 0

1

for: P R L Tp rr≥ +


at review moment Rr

for plan moment Ppr


MRP/DRP or LRP

IIPP R P EIPP R P ISP R Pr p r p r ii

p

r r r( , ) ( , ) ( , )= +

=∑

0

Inclusive Inventory Position Plan

at review moment Rr

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


59

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, Ppr) states, at review

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, Ppr) is forced to be zero for plan moments Ppr

which are less than the Lead

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

SA U Su s( , ) = set by the strategist

Supplier Allocator

for product unit Uu

from supplier Ss

For BSC:

[ ]ASDP U R P

IN ACDP R P AI R TIP R P

EF U ASDO U R

u r

r r r

u u r

r( , , )

( , ) ( ) ( , )

( ) ( , )

0

0 0

=

+ − −

⋅ −


for product unit Uu

at review moment Rr

for plan moment P0r



60


For MRP/DRP:

ASDP U R Pu r r( , , )0 0=

and

ASDP U R P LT

ISP R P EF U

u r p

r p u

r

r

( , , )

( , ) ( )

− =

⋅

for: P P LTpr r> +0


for product unit Uu

at review moment Rr

for plan moment P0r and Ppr

–LT

when the NIMIS applies MRP/DRP

For LRP:

ASDP U R P

IN ACDP R P AI R TIP R P

EF U ASDO U R

u r

r ii

b

r r ii

b

u u r

r

r r

( , , )

( , ) ( ) ( , )

( ) ( , )

0

0 0

=

+ − −

⋅ −= =∑ ∑

with: P P LT Pb r br r≤ + < +0 1

and

ASDP U R P LT

ACDP R P EF U

u r p

r p u

r

r

( , , )

( , ) ( )

− =

⋅

for: P P LTpr r> +0


for product unit Uu

at review moment Rr


–LT

when the NIMIS applies LRP

For BSC:

ISDP S U R P

ASDP U R P SA U S

s u r

u r u s

r

r

( , , , )

( , , ) ( , )

0

0

=

⋅


sent to supplier Ss

for product unit Uu

at review moment Rr

for plan moment P0r



ISDP S U R P

ASDP U R P SA U S

s u r

u r u s

r

r

( , , , )

( , , ) ( , )

0

0

=

⋅

and

ISDP S U R P LT

ASDP U R P LT SA U S

s u r p

u r p u s

r

r

( , , , )

( , , ) ( , )

− =

− ⋅

for: P P LTpr r> +0


sent to supplier Ss

for product unit Uu

at review moment Rr


–LT


MRP/DRP or LRP


61


For BSC:

ASDO U R ISP R P EF Uu r r ur( , ) ( , ) ( )= ⋅0


for product unit Uu

at review moment Rr



ASDO U R ISP R P EF Uu r r ii

b

ur( , ) ( , ) ( )= ⋅

=∑

0

with: P R LT Pb r br r< + ≤+ +1 1


for product unit Uu

at review moment Rr


MRP/DRP or LRP

ISDO S U R ASDO U R SA U Ss u r u r u s( , , ) ( , ) ( , )= ⋅

Individual Supplier Demand Order

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


62

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, P0r) multiplied by the

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, Prr), from P0r

to the last plan

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.


63

Information flow

Goods flow

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



Rr = Review moment r

Ppr = Plan moment p at review moment r

S3

NIMIS S3BSC

C3

NIMIS C3BSC

X1

NIMIS X1BSC

S2

NIMIS S2BSC

C2

NIMIS C2BSC

S1

NIMIS S1BSC

C1

NIMIS C1BSC

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


64

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.


65

Table 3-11 Base Stock Control in a system

NIMIS Stock-

point

Algorithm Customer

List

Inventory

Norm

Lot

Size

Lead

Time

Explosion

Factor

List

Supplier

Allocator

List

NIMIS X1 X1 BSC C1

C2

C3

30 40 — A: 1

B: 2

C: 3

A: 1*S1

B: 2*S2

C: 3*S3

Moment Rr P0r

— — — — — —

Time 0 0 — — — — — —

ICDO C1:

List C2:

C3:

2

3

5

— — — — — — —

OPO C1:

List C2:

C3:

2

3

5

— — — — — — —

ACDO 10 — — — — — — —

ICDP C1:

List C2:

C3:

— 42

–27

15

— — — — — —

ACDP — 30 — — — — — —

AI 10 — — — — — — —

TIP — 40 — — — — — —

EIPP — 20 — — — — — —

ISP — 40 — — — — — —

IIPP — 60 — — — — — —

ASDO X1:

A:

B:

C:

40

40

80

120

— — — — — — —

ISDO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

IPO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

ASDP X1:

A:

B:

C:

— –30

–30

–60

–90

— — — — — —

ISDP S1: A:

List S2: B:

S3: C:

— –30

–60

–90

— — — — — —


66

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


67

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.


68

S1

NIMIS S1MRP/DRP

Information flow

Goods flow

Local inventory level NIMIS C1 at R1 for P01, P11

, P21, ...




, P21, ...


, P21, ...

Local inventory level NIMIS X1 at R1 for P01, P11

, P21, ...

Local inventory level NIMIS S3 at R1 for P01, P11

, P21, ...


, P21, ...


, P21, ...

S2

NIMIS S2MRP/DRP

S3

NIMIS S3MRP/DRP

X1

NIMIS X1MRP/DRP

C1

NIMIS C1MRP/DRP

C2

NIMIS C2MRP/DRP

C3

NIMIS C3MRP/DRP

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


69

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.


70

Table 3-12 Material/Distribution Requirements Planning in a system

NIMIS Stock-

point

Algorithm Customer

List

Inventory

Norm

Lot

Size

Lead

Time

Explosion

Factor

List

Supplier

Allocator

List

NIMIS X1 X1 MRP

DRP

C1

C2

C3

30 40 2 A: 1

B: 2

C: 3

A: 1*S1

B: 2*S2

C: 3*S3

Moment Rr P0r

P1r

P2r

P3r

P4r

P5r

P6r

Time 0 0 1 2 3 4 5 6

ICDO C1:

List C2:

C3:

2

3

5

— — — — — — —

OPO C1:

List C2:

C3:

2

3

5

— — — — — — —

ACDO 10 — — — — — — —

ICDP C1:

List C2:

C3:

— 0

0

0

1

3

6

1

3

6

1

3

6

1

3

6

1

3

6

1

3

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:

A:

B:

C:

40

40

80

120

— — — — — — —

ISDO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

IPO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

ASDP X1:

A:

B:

C:

— 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

40

40

80

120

— —

ISDP S1: A:

List S2: B:

S3: C:

— 0

0

0

0

0

0

0

0

0

0

0

0

40

80

120

— —


71

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 P1r and beyond, Customer 1 expects to

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 P2r. The

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.


72

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.


73

Information flow

Goods flow

Integral inventory level NIMIS S1 at R1 for P01, P11

, P21, ...


, P21, ...


, P21, ...

Integral inventory level NIMIS X1 at R1 for P01, P11

, P21, ...

Integral inventory level NIMIS C1 at R1 for P01, P11

, P21, ...


, P21, ...


, P21, ...



S3

NIMIS S3LRP

C3

NIMIS C3LRP

X1

NIMIS X1LRP

S2

NIMIS S2LRP

C2

NIMIS C2LRP

S1

NIMIS S1LRP

C1

NIMIS C1LRP

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


74

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.


75

Table 3-13 Line Requirements Planning in a system

NIMIS Stock-

point

Algorithm Customer

List

Inventory

Norm

Lot

Size

Lead

Time

Explosion

Factor

List

Supplier

Allocator

List

NIMIS X1 X1 LRP C1

C2

C3

30 40 2 A: 1

B: 2

C: 3

A: 1*S1

B: 2*S2

C: 3*S3

Moment Rr P0r

P1r

P2r

P3r

P4r

P5r

P6r

Time 0 0 1 2 3 4 5 6

ICDO C1:

List C2:

C3:

2

3

5

— — — — — — —

OPO C1:

List C2:

C3:

2

3

5

— — — — — — —

ACDO 10 — — — — — — —

ICDP C1:

List C2:

C3:

— 2

–7

15

5

3

12

5

3

12

5

3

12

5

3

12

5

3

12

5

3

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:

A:

B:

C:

40

40

80

120

— — — — — — —

ISDO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

IPO S1: A:

List S2: B:

S3: C:

40

80

120

— — — — — — —

ASDP X1:

A:

B:

C:

— -10

-10

-20

-30

20

20

40

60

20

20

40

60

20

20

40

60

20

20

40

60

— —

ISDP S1: A:

List S2: B:

S3: C:

— -10

-20

-30

20

40

60

20

40

60

20

40

60

20

40

60

— —


76

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


77

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.


78

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



79

Information flow

Goods flow

S7S4

NIMIS S7LRPNIMIS S4

LRP

Location

BISOrganisation A

NIMIS S1

C7C4

NIMIS C7LRPNIMIS C4

LRP

Location

BISOrganisation B

C1

NIMIS C1

S8S5

NIMIS S8LRPNIMIS S5

LRP

Location

BISOrganisation C

S2

NIMIS S2

X3X2

NIMIS X3LRPNIMIS X2

LRP

Location

NIMIS X1

C8C5

NIMIS C8LRPNIMIS C5

LRP

Location

BISOrganisation D

C2

NIMIS C2

S9S6

NIMIS S9LRPNIMIS S6

LRP

Location

BISOrganisation E

S3

NIMIS S3

C9C6

NIMIS C9LRPNIMIS C6

LRP

Location

C3

NIMIS C3

BIS


Business Information System

Networked organisation

S1

X1

Figure 3-6 Network view of networked organisation management


80

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.


81

NIMIS

Newparametervalues Unsolved

exception

SolvedexceptionCurrent

parametervalues



Supplierplans

Customerplans

Supplierorders

Customerorders CustomersSuppliers

Goods flow

Information flow

Networked Inventory ManagementInformation System


NIMIS Business Information System


BIS

BIS

Organisation

Location

Shiftingboundaries

Shiftingboundaries

Strategist

Actualsupply

Output ordersInput orders

Actualdemand

Actual inventory

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


82

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.


83

Table 3-14 Supplementary variables for networked organisation management

Variable Description

RrcTime of review moment Rrc

of customer Cc

rc Index to review moment Rrc

of customer Cc

Rlc

Time of the last review moment Rrc

of customer Cc

at a review moment time Rr

in the NIMIS

Pp rc

Time of plan moment Pprc

at review moment Rrc

of customer Cc

p rc

Index to plan moment Pprc


of customer Cc

NPrc

Number of plan moments Pprc


of customer Cc

ICDO C Rc rc* ( , )




ICDP C R Pc r pc rc*( , , )




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


84

inventory at review moment Rr. Plan moment Pprc is the p-th plan moment in the plans

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 P0rc to PNPrc

, so the

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 Pprc

, is specified in the

Individual Customer Demand Plan ICDP*(Cc,Rrc,Pprc

). Because customers may use

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

with: rc = 0 1, ,2,...

Time of review moment Rrc

at customer Cc

as perceived in the NIMIS

Pprc= determined by customers

with: p NPr rc c= 0 1, ,2, . .. ,

Time of plan moment Pprc


of customer Cc

as perceived in the NIMIS

Rlc = derived from comparison of Rr and Rrc

with: R R Rlc r l c≤ < +1

Time of the last review moment Rlc

of customer Cc

as noticed at review moment Rr

in the NIMIS


85


ICDO C Rc rc* ( , ) = received from customers




ICDO C R ICDO C Rc r c ici a

b( , ) * ( , )=

=∑

with:R R R

R R Ra c r ac

b r b cc

− −

+

≤ < ∧

≤ <1 1

1




ICDP C R Pc r pc rc* ( , , ) = received from customers




for plan moment Pprc

For BSC:

ICDP C R P ICDP C R Pc r c lcr lc( , , ) *( , , )0 0=

with: R R Rl c r l c≤ < +1




for plan moment Ppr



ICDP C R P ICDP C R Pc r c lc ii

b

r lc( , , ) * ( , , )0

0=

=∑

with:R R R

P P Plc r l c

b blc r lc

≤ < ∧

< ≤+

+

1

1 1

and

ICDP C R P ICDP C R Pc r p c lc ii a

b

r lc( , , ) *( , , )=

=∑

with:

R R R

P P P

P P P

lc r l c

a p a

b p b

lc r lc

lc r lc

≤ < ∧

< ≤ ∧

< ≤

+

−

+ +

1

1

1 1

for: P Ppr r> 0




for plan moment Ppr


MRP/DRP or LRP

In Table 3-15 the supplementary system equations for networked organisation

management are presented. The review moments Rrc are the moments at which customer


86

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

Pprc. These are the moments in plans for which customer Cc computes expected product

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 Pprc

and the number of plan

moments NPrc may differ per review moment Rrc

. Normally, the next review moment Rr+1c

of customer Cc will occur at plan moment P1rc, as identified in the plans of customer Cc at

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, Pprc

) from

customer Cc at its review moment Rrc for its plan moment Pprc

. The ICDP*(Cc, Rrc, Pprc

),

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

, P0lc) as specified by customer Cc at

its last review moment Rlc for plan moment P0lc

. For MRP/DRP as well as for LRP, the

ICDP(Cc, Rr, P0r) at plan moment P0r

is equal to the sum of ICDP*(Cc,Rlc,Pilc

) from the


87

first plan moment P0lc to plan moment Pblc

, which is the last plan moment of customer Cc

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

, Pplc)

from plan moment Palc to plan moment Pblc

. Palc is the first plan moment of customer Cc,

coinciding with or some time after plan moment Ppr in the NIMIS. Pblc

is the last plan

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.


88

Information flow

Goods flow

S7S4

NIMIS S7LRPNIMIS S4

LRP

Location

BISOrganisation A

NIMIS S1

C7C4

NIMIS C7LRPNIMIS C4

LRP

Location

BISOrganisation B

C1

NIMIS C1

S8S5

NIMIS S8LRPNIMIS S5

LRP

Location

BISOrganisation D

S2

NIMIS S2

X3X2

NIMIS X3LRPNIMIS X2

LRP

Location

NIMIS X1

C8C5

NIMIS C8LRPNIMIS C5

LRP

Location

C2

NIMIS C2

S9S6

NIMIS S9LRPNIMIS S6

LRP

Location

BISOrganisation E

S3

NIMIS S3

C9C6

NIMIS C9LRPNIMIS C6

LRP

Location

C3

NIMIS C3

BIS




S1

X1

BISOrganisation F

Figure 3-8 Configuration flexibility with respect to other NIMISs


89

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


90

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.


91

Information flow

Goods flow

S8S5

NIMIS S8LRPNIMIS S5

LRP

Location

Organisation

S2

NIMIS S2

X3X2

NIMIS X3LRPNIMIS X2

LRP

Location

NIMIS X1

C8C5

NIMIS C8LRPNIMIS C5

LRP

Location

C2

NIMIS C2

BIS




X1

BIS

Organisation

BIS

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


92

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


93

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.


94

Information flow

Goods flow

S7S4

NIMIS S7LRPNIMIS S4

LRP

Location

BISOrganisation

NIMIS S1Rr:

2, 10, 18

C7C4

NIMIS C7LRPNIMIS C4

LRP

Location

BISOrganisation

C1

NIMIS C1Rr:

5, 13, 21

S8S5

NIMIS S8LRPNIMIS S5

LRP

Location

BISOrganisation

S2

NIMIS S2Rr:

1, 3, 9

X3X2

NIMIS X3LRPNIMIS X2

LRP

Location

NIMIS X1Rr:

10, 20, 30

C8C5

NIMIS C8LRPNIMIS C5

LRP

Location

BISOrganisation

C2

NIMIS C2Rr:

5, 10, 15

S9S6

NIMIS S9LRPNIMIS S6

LRP

Location

BISOrganisation

S3

NIMIS S3Rr:

5, 7, 15

C9C6

NIMIS C9LRPNIMIS C6

LRP

Location

C3

NIMIS C3Rr:

7, 37, 67

BIS




S1

X1

Figure 3-10 Timing flexibility in review moments


95

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).


96

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.


97

Table 3-16 Timing flexibility in plan moments

NIMIS Variable Review

moment

Time

NIMIS X1 ICDP List R4 40

Customer Review

moment

Time

NIMIS C1 R5 37

Plan

moment

P05

P15

P25

P35

P45

P55

P65

ICDP* Time 37 45 53 61 69 77 85

Demand 0 1000 2000 3000 4000 3000 2000

Plan

moment

P04

P14

P24

P34

P44

P54

P64

ICDP Time 40 50 60 70 80 90 100

Demand 1000 2000 7000 3000 (2000) — —

Customer Review

moment

Time

NIMIS C2 R7 35

Plan

moment

P07

P17

P27

P37

P47

P57

P67

ICDP* Time 35 40 45 50 55 60 65

Demand 0 4000 3000 2000 1000 2000 3000

Plan

moment

P04

P14

P24

P34

P44

P54

P64

ICDP Time 40 50 60 70 80 90 100

Demand 7000 3000 (5000) — — — —

Customer Review

moment

Time

NIMIS C3 R2 37

Plan

moment

P02

P12

P22

P32

P42

P52

P62

ICDP* Time 37 67 97 127 157 187 217

Demand 0 3000 3000 2000 2000 1000 1000

Plan

moment

P04

P14

P24

P34

P44

P54

P64

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


98

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 P0r.

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


99

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 P04 (time 40) is equal to the demand for P07

to P27 in the ICDP*, since

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 P32

(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.


100

Information flow

Goods flow

S7S4

NIMIS S7LRPNIMIS S4

LRP

Location

BISOrganisation

NIMIS S1LRP

C7C4

NIMIS C7LRPNIMIS C4

LRP

Location

BISOrganisation

C1

NIMIS C1LRP

S8S5

NIMIS S8LRPNIMIS S5

LRP

Location

BISOrganisation

S2

NIMIS S2MRP/DRP

X3X2

NIMIS X3LRPNIMIS X2

LRP

Location

NIMIS X1LRP

C8C5

NIMIS C8LRPNIMIS C5

LRP

Location

BISOrganisation

C2

NIMIS C2MRP/DRP

S9S6

NIMIS S9LRPNIMIS S6

LRP

Location

BISOrganisation

S3

NIMIS S3LRP

C9C6

NIMIS C9LRPNIMIS C6

LRP

Location

C3

NIMIS C3BSC

BIS




S1

X1

Figure 3-11 Algorithm flexibility with algorithm selection


101

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


102

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.


103

Table 3-17 Algorithm flexibility with algorithm transition

Customer

(NIMIS C1, NIMIS C2, NIMIS C3)

Algorithm SIC BSC MRP/DRP LRP

BSC

Addition

of plan value

for P0r

Translation

of plan value

for P0r

Translation

of plan value

for P0r

+

Removal

of plan values

after P0r

Translation

of plan value

for P0r

+

Removal

of plan values

after P0r

NIMIS

(NIMIS X1)

MRP/DRP

Addition

of plan values

for all

plan moments

Translation

of plan value

for P0r

+

Addition

of plan

values after P0r

Translation

of plan values

Translation

of plan values

LRP

Addition

of plan values

for all

plan moments

Translation

of plan value

for P0r

+

Addition

of plan values

after P0r

Translation

of plan values

Translation

of plan values

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


104

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


105

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


106

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.

Chapter 4 Case study implementation

107

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].

Case study implementation Chapter 4

108

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.


109

Componentsin Hong Kong

Finished productsin Hong Kong

Manufacturer 1 KPN Telecom

Customers

Componentsin France

Finished productsin France



Manufacturer 2

Componentsin Japan

Finished productsin Japan

Manufacturer 3

Componentsin Germany

Finished productsin Germany

Manufacturer 4



Manufacturer 5

Customers

Telesales outletin The Netherlands

Customers

Customers

Customers

Distributioncentre in

The Netherlands

Consumer outlet 1 in The Netherlands

Consumer outlet m in The Netherlands

Business outlet 1 in The Netherlands

Business outlet n in The Netherlands

Goods flow OrganisationSingle SKU stock-point

Suppliers

Suppliers

Suppliers

Suppliers

Suppliers

Suppliers

Warehouse inThe Netherlands

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


110

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.


111

OrdersBIS



Suppliers

Manufacturer 2


KPN Telecom

Information flow

Goods flow Business Information SystemBIS

Human interface

Distribution centrein The Netherlands

Orders

Customers

Orders

WinBes CM‘SIC’

Customers

Orders

UNAS‘SIC’

TSAGBS‘SIC’Orders

Customers

Orders

WinBes CM‘SIC’

Customers

Orders

WinBes BM‘SIC’

Customers

Orders

WinBes BM‘SIC’

Orders

Spreadsheet‘DRP’

Masterplans

Frameworkcontract

Forecasts

CentralWinBes CM

Orders

Orders

Orders

CentralWinBes BM

Orders

Orders

Orders





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


112

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


113

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


114

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.


115



Suppliers

Manufacturer 1 KPN Telecom

Networked inventory management

Customers

Componentsin France

Finished productsin France

Suppliers



Suppliers

Manufacturer 2

Componentsin Japan

Finished productsin Japan

Suppliers

Manufacturer 3



Suppliers

Manufacturer 4



Suppliers

Manufacturer 5

Suppliers

Manufacturer 101

Componentsin the USA

Finished productsin the USA

Suppliers

Manufacturer 102

Customers


Customers

Customers

Customers

Warehouse in TheNetherlands

Consumer outletin Europe

Customers

Dealer 1001

Business outletin Europe

Customers

Dealer 1002

Distributioncentre in

The Netherlands





Goods flow Networked organisationSingle SKU stock-point

Componentsin The Netherlands

Finished productsin The Netherlands

Figure 4-3 Supply chains for cordless telephones in a future scenario


116

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


117

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.


118

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.


119

NIMIS NIMIS

Customers



Suppliers

NIMIS NIMIS

Manufacturer 2


KPN Telecom


Information flowGoods flow Networked organisation

Dealer 1002


NIMIS

Customers

NIMIS

Customers

NIMIS

Customers

NIMIS

Customers

NIMIS

Customers



Suppliers

Manufacturer 102


NIMIS NIMIS





Figure 4-4 Networked inventory management by NIMISs


120

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


121

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


122

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


123

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.


124

NIMIS NIMIS

TSA

Customers

BIS

NIMIS NIMIS



Suppliers

Manufacturer 2


NIMIS

WinBes CM


Customers

Orders

KPN Telecom

BIS

NIMIS NIMIS



Suppliers

Manufacturer 102

Information flow

Goods flow



BIS

Human interface


Customers

Orders

NIMIS


Point of sale system

Dealer 1002


GBS UNAS

NIMIS

WinBes CM

Customers

Orders


NIMIS

WinBes BM

Customers

Orders


NIMIS

Customers

OrdersWinBes BM


Orders

Figure 4-5 NIMISs and Business Information Systems


125

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.


126

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.

Chapter 5 Computer network technology analysis

127

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.

Computer network technology analysis Chapter 5

128

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.

Computer network technology5.2.1

Information technology

DOT:

Distributedobject

technology

(5.3)

OST:

Object-orien-ted systemtechnology

(5.2.3)

DST:

Distributedsystem

technology

(5.2.2)

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


129

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.


130

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


131

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


132

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].


133

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


134

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.


135

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


136

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.


137

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]


138

[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,


139

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.


140

Object a1

System C

Object a1

System B

Object a1

System A

Location I

Object a1

System Z

Object a1

System Y

Object x1

System X

Location II

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.


141

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].


142

Computer network technology

Distributed system technology:

• Local computing

• Heterogeneous computing

• Transparent computing

Object-oriented system technology:

• Object classification

• Attribute encapsulation

• Operation invocation

Distributed object technology requirements

NIMIS

DOT:

Distributedobject

technology

OST:

Object-orien-ted systemtechnology

DST:

Distributedsystem

technology

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.


143

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.


144

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


145

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


146

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


147

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


148

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).


149

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


Chapter 6 Distributed object technology design

151

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

Distributed object technology design Chapter 6

152

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.


153

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


154

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


155

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


156

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.


157

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

Environment

Interacts with

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.


158

Environment

OperationalProcessSupplier Strategist Customer


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.

SupplierManager

OperationalManager

InventoryManager

StrategicManager

CustomerManager

NIMIS


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


159

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.

Controls

Deals with

Controls

Deals withSupplier CustomerNIMIS

OperationalProcess

Strategist


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


160

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.

Controls ControlsControls

Deals with Deals with

Controls

Controls

Deals with

Controls

Deals withSupplier

NIMIS

SupplierManager Customer

InventoryManager

CustomerManager

StrategicManager

OperationalManager

OperationalProcess

Controls ControlsControls

Strategist


Figure 6-6 Component associations class diagram


161

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.


162

-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+Write Exception+Read Exception

Inventory Manager

Object

Attributes

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


163

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.


164

-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

Customer Manager

+Write Parameters+Read Parameters+Write Exception+Read Exception

Object

Attributes

Operations

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.


165


166

-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

Supplier Manager


Object

Attributes

Operations

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.


167

-Output Process Order List-Input Process Order List-Actual Inventory-Actual Demand-Actual Supply-Exception

+Get Individual Customer Demand Order+Compute Output Process Order List+Give Output Process Order+Get Individual Supplier Demand Order+Compute Input Process Order List+Give Input Process Order

Operational Manager


Object

Attributes

Operations

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.


168

-Time-Review Moment List-Plan Moment List-Exception-Parameter List-Exception List

+Get Individual Customer Demand Order+Give Individual Customer Demand Order+Get Individual Customer Demand Plan+Give Individual Customer Demand Plan+Get Individual Supplier Demand Order+Give Individual Supplier Demand Order+Get Individual Supplier Demand Plan+Give Individual Supplier Demand Plan

Strategic Manager


Object

Attributes

Operations

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.


169

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.

-Individual Supplier Demand Order-Individual Supplier Demand Plan

+Give Individual Supplier Demand Order+Give Individual Supplier Demand Plan

Customer

Object

Attributes

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).

-Individual Customer Demand Order-Individual Customer Demand Plan

+Get Individual Customer Demand Order+Get Individual Customer Demand Plan

Supplier

Object

Attributes

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).


170

-Actual Inventory-Actual Demand-Actual Supply-Output Process Order List-Input Process Order List

+Give Actual Inventory+Give Actual Demand+Give Actual Supply+Get Output Process Order+Get Input Process Order

Operational Process

Object

Attributes

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.


171

-Parameter List-Exception List-Individual Customer Demand Order List-Individual Customer Demand Plan List-Individual Supplier Demand Order List-Individual Supplier Demand Plan List

+Get Individual Customer Demand Order+Get Individual Customer Demand Plan+Check Individual Customer Demand Plan+Give Individual Customer Demand Plan+Get Individual Supplier Demand Order+Get Indvidual Supplier Demand Plan+Check Individual Supplier Demand Plan+Give Individual Supplier Demand Plan+Read Parameters+Set Parameters+Write Parameters+Read Exception+Handle Exception+Write Exception

Strategist

Object

Attributes

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.


172

NIMIS X1

Object instance Relation

Customer C21

Customer C22

NIMIS C2

Supplier S21

Supplier S22

NIMIS S2

NIMIS C1NIMIS S1Supplier S11 Customer C11

NIMIS C3NIMIS S3Supplier S31 Customer C31

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.


173

Strategist X1

NIMIS X1

CustomerManager S1

CustomerManager S2

CustomerManager S3

SupplierManager X1

InventoryManager X1

CustomerManager X1

SupplierManager C2

StrategicManager X1

OperationalManager X1

OperationalProcess X1

SupplierManager C1

SupplierManager C3

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

X1 deals 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


174

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


175

1.

OperationalProcess

Give/Get OPO

Give/Get AD

Give/Get AD

Give/Get AS

Get/Give AS

Get/Give AD

Get/Give AI

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

Give/Get ICDO

Give/Get ICDOGive/Get ICDO

Give/Get ICDP

Give/Get ICDP

Give/Get ICDPGive/Get ICDP

Give/Get ACDP

Give/Get ICDO

Give/Get ICDP

SupplierManager

Supplier OperationalManager

InventoryManager

Strategist Strategicmanager

CustomerManager

Customer

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


176

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.


177

Read/Write Parameters


Write/Read Parameters
















Write/Read ParametersWrite/Read Exception

Write/Read Exception











OperationalProcess

SupplierManager

Supplier OperationalManager

InventoryManager

Strategist Strategicmanager

CustomerManager

Customer

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


178

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


179

CM Parametersto be written

CM Exceptionto be read

CM Parametersto be read

CM Exceptionto be written

STM readsParameters

from CM

WriteParametersto STM

STM writesParameters

to CM

ReadParametersfrom STM

WriteExceptionto STM

ReadExceptionfrom STM

Exceptionoccursin CM

STM writesException

to CM

ICDO got from C

+Compute ICDO List

ICDP got from STM

+Compute ACDO+Compute ACDP

Get ICDPfrom C

Get ICDOfrom C

Give ICDO toOM and STMto OP

Get ICDPfrom STM

Give ACDPto IM

CM Occasional Management

CM Regular Management

CM Neutral

ICDP got from C

+Compute ICDP List

Give ICDPto STM

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.


180

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.


181

IM Parametersto be written

IM Exceptionto be read

IM Parametersto be read

IM Exceptionto be written

STM readsParameters

from IM



to IM




Exceptionoccurs

in IM

STM writesException

to IM

ACDP gotfrom CM

Get ACDP from CM

IM Occasional Management

IM Regular Management

IM Neutral

Get AI from OM

ASDO givento SM

Give ASDP to SM

Give ASDO to SM

AI got from OM

+Compute EIPP+Compute ISP+Compute IIPP+Compute ASDO+Compute ASDP+Compute TIP

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


182

‘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.


183

SM Parametersto be written

SM Exceptionto be read

SM Parametersto be read

SM Exceptionto be written

ASDO gotfrom IM

Get ASDO from IM

Get ASDP from IM

SM Occasional Management

SM Regular Management

SM Neutral

ISDO given toS, OM and STM

ASDP got from IM

+Compute ISDO List+Compute ISDP List

Give ISDO to S, OM and STM

ISDP gotfrom STM

Give ISDP to S

Give ISDP to STM

Get ISDP from STM

ISDP givento STM

STM readsParameters

from SM



to SM




Exceptionoccursin SM

STM writesException

to SM

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


184

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 Parametersto be written

OM Exceptionto be read

OM Parametersto be read

OM Exceptionto be written

ICDO got from CM

+Compute OPO List

ISDO got from SM

+Compute IPO List

Get AI from OPGet ICDO

from CMGive OPOto OP

Get ISDOfrom SM

Give IPOto OP

Get AD from OP

Get AS from OP

Give AI to IM

OM Occasional Management

OM Regular Management

OM Neutral

AS got from OP

AD got from OP

AI got from OP

STM readsParameters

from OM



to OM




Exceptionoccursin OM

STM writesException

to OM

State Event

Figure 6-23 Operational Manager state diagram


185

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.


186

Parametersbeing set by STR

STM Occasional Management

STM Regular Management

ICDO got from CM

ICDP got from CM

ISDP got from STR

ISDP got from SM

GiveICDOto STR

GiveICDPto STR

GetISDPfromSM

GiveISDPto STR

GiveISDPto SM

ICDP got from STR ISDO got from SM

GetICDPfromSTR

GiveICDPto CM

GiveISDOto STR

GetISDOfromSM

GetISDPfromSTR

GetICDOfromCM

GetICDPfromCM

Parameters ofManagers read

Write Parametersto STR

Read Parametersfrom STR

STM Neutral

Read Parametersfrom Managers

Write Parametersto Managers

Exception beinghandled by STR

Write Exceptionto STR

Read Exceptionfrom STR

Read Exceptionfrom Managers

Write Exceptionto Managers

Exception ofManagers read

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


187

(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.


188

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

ComputeISDP List

ASDP

ISDP List

Supplier

ISDP SA List

ComputeASDP

ASDP

EF List

EF List ISPSA List LT

LT ISP

ASDP

ComputeISP

LS

IN

ISP IN

IIPP

ISP

IIPP EIPP

IIPP EIPP

ComputeEIPP

TIP

TIP ASLS AI AD Customer

EIPP EIPP

AI

ACDP

ComputeACDP

ComputeICDP List

ACDP ACDP ICDP List

ICDP List

ICDP List

ICDP

ComputeISDO List

ISDO

ASDO

SA List

ComputeASDO

EF List

IPO List

ISDO List

LT ISP

ASDO ASDO

ComputeTIP

ASDO

IPO List

ComputeIPO ListISDO List

ISDO List

IPOOperational

Process ICDO ListComputeOPO List ICDO ListOPO

AS AI AP

OPO List

OPO List

ComputeACDP

ACDO

ComputeICDO List

ICDO List

ACDO

ICDO List

ICDO

ProcessData flow 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.


189

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


190

• 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


191

organised around objects that each contain both data and functions of the object, while the

system is executed by interaction between objects.

StrategicManager

Class

OperationalManager

Class

InventoryManager

Class

SupplierManager

Class

CustomerManager

Class

NIMISClass

Object classes

Classification Instantiation

NIMIS S1

SM IM CM

STM

OM

NIMIS X1

SM IM CM

STM

OM

NIMIS C1

SM IM CM

STM

OM

Object instances

NIMIS S3

SM IM CM

STM

OM

NIMIS S2

SM IM CM

STM

OM

NIMIS C2

SM IM CM

STM

OM

NIMIS C3

SM IM CM

STM

OM


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


192

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.


193


NIMIS S1

Attributes

Operations

NIMIS X1

Attributes

Operations

NIMIS C1

Attributes

Operations

NIMIS S3

Attributes

Operations

NIMIS C3

Attributes

Operations

NIMIS S2

Attributes

Operations

NIMIS C2

Attributes

Operations

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


194

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.

NIMIS S1

Attributes

Operations

NIMIS X1

Attributes

Operations

NIMIS C1

Attributes

Operations

NIMIS S3

Attributes

Operations

NIMIS C3

Attributes

Operations

NIMIS S2

Attributes

Operations

NIMIS C2

Attributes

Operations


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


195

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


196

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.


197

Computer

Applicationobjects

Objects

CORBAFacilities

CORBAServices

IDL interfaces

IDLStubs

IDLSkeletons

Object Request Broker

ORBCore

Computer

Applicationobjects

Objects

CORBAFacilities

CORBAServices

IDL interfaces

IDLStubs

IDLSkeletons

Object Request Broker

ORBCore


Operationinvocation

GIOP

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


198

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.


199

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,


200

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


201

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.


202

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.


203


NIMIS S1

Localprocessor

Localmemory

NIMIS X1

Localprocessor

Localmemory

NIMIS C1

Localprocessor

Localmemory

NIMIS S1

Localprocessor

Localmemory

NIMIS S3

Localprocessor

Localmemory

NIMIS S2

Localprocessor

Localmemory

NIMIS C2

Localprocessor

Localmemory

NIMIS C3

Localprocessor

Localmemory

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.


204

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.


NIMIS S1

IDLinterfaces

Virtualmachine

NIMIS X1

IDLinterfaces

Virtualmachine

NIMIS C1

IDLinterfaces

Virtualmachine

NIMIS S1

Localprocessor

Localmemory

NIMIS S3

IDLinterfaces

Virtualmachine

NIMIS S2

IDLinterfaces

Virtualmachine

NIMIS C2

IDLinterfaces

Virtualmachine

NIMIS C3

IDLinterfaces

Virtualmachine

Figure 6-31 IDL interfaces and virtual machines for heterogeneous computing


205

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.


206


NIMIS S1

CORBAServices

ORB

NIMIS X1

CORBAServices

NIMIS C1

CORBAServices

NIMIS S1

Localprocessor

Localmemory

NIMIS S3 NIMIS S2

CORBAServices

NIMIS C2

CORBAServices

NIMIS C3

CORBAServices

ORB ORB

CORBAServices

ORB ORB ORB ORB

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


207

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


208

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.

Chapter 7 Prototype system implementation

209

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

Prototype system implementation Chapter 7

210

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

Visual Works

Distributed Smalltalk

Smalltalk

Computer Y

Visual Works

Distributed Smalltalk

Smalltalk


Figure 7-1 Tools for a network of prototype NIMISs


211

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.


212

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].


213

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


214

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.


215

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.

NIMIS

User-interfaceobjects

Domainobjects

Suppliersystem

Supplierstrategist

Customersystem

Customerstrategist

Operationalprocess

Operator

Strategist

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,


216

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.


217

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.


218

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.


219

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


220

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.

Suppliersystem S11

StrategistS11

OperatorS1

OperationalProcess S1

S11

StrategistS1

NIMIS S1

Customersystem C11

StrategistC11

OperatorC1

OperationalProcess C1

S11

StrategistC1

NIMIS C1

Suppliersystem S21

StrategistS21

OperatorS2


S11

StrategistS2

NIMIS S2

Suppliersystem S22

StrategistS22

Customersystem C21

StrategistC21

OperatorC2


S11

StrategistC2

NIMIS C2

Customersystem C22

StrategistC22

OperatorX1

OperationalProcess X1

S11

StrategistX1

NIMIS X1

Suppliersystem S31

StrategistS31

OperatorS3


S11

StrategistS3

NIMIS S3

Customersystem C31

StrategistC31

OperatorC3


S11

StrategistC3

NIMIS C3

Figure 7-3 Network of prototype systems in imaginary supply chains


221

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.


222


Information flowGoods flow Networked organisation

PrototypeNIMIS

Customers


PC

PrototypeNIMIS

Customers


PC

PrototypeNIMIS

Customers

PC

PrototypeNIMIS

PC

PrototypeNIMIS

Customers


PC

PrototypeNIMIS

Customers


PC


Suppliers

PrototypeNIMIS

PC

PrototypeNIMIS

Plastic componentsin Hong Kong

PC

PrototypeNIMIS


PC

Crystal componentsin Hong Kong

Suppliers

KPN Telecom

Internet

Intranet

Intranet

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


223

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,


224

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,


225

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


226

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


227

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.


228

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


229

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.

Chapter 8 Conclusion

231

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.

Conclusion Chapter 8

232

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


233

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.



234


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.


235

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.


236

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


237

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


238

the information systems to naturally reflect the structure, data and functions of networked


8.1.5 Distributed object technology design

The distributed object technology design constitutes the technical design of NIMISs. The



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


239

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


240

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


241

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.


242

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


243

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.

References

245

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.

References

246

[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.

References

247

[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

References

248

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.

References

249

[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.

References

250

[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.

References

251

[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.

References

252

[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.

References

253

[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.

References

254


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.

References

255

[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.

Abbreviations

257

AbbreviationsACDO 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

BIS Business Information System

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

Abbreviations

258

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

Abbreviations

259

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

Summary

261

SummarySupply 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.

IntroductionMost 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

Summary

262

viewpoint, while the last three stages are devoted to analysis, design and implementation

from a technical viewpoint.

Supply chain management analysisSupply 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







Summary

263

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 designThe 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

Summary

264

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


Summary

265

Case study implementationA 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 analysisComputer 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.

Summary

266



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 designThe distributed object technology design constitutes the technical design of NIMISs. The



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

Summary

267

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 implementationThe 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

Summary

268

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.

ConclusionFrom 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.

Samenvatting

269

SamenvattingLogistieke 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.

InleidingDe 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

Samenvatting

270

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 ketenbesturingLogistieke 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).

Samenvatting

271

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-voorraadbesturingHet 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

Samenvatting

272

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-studyEen 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.

Samenvatting

273

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-netwerktechnologieComputer-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

Samenvatting

274

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 objecttechnologieHet 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

Samenvatting

275

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-systeemEen 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

Samenvatting

276

uitzonderingen. Regelmatige besturing betreft het bewaken en controleren van orders en

plannen die binnenkomen van klanten en uitgaan naar leveranciers.

ConclusieUit 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.

Curriculum vitae

277

Curriculum vitaeMartin 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.

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Networked Inventory Management by Distributed Object Technology

Documents