0% found this document useful (0 votes)
10 views145 pages

Logistics Engineering IV Learner Guide 2020

This document provides an overview of the first study unit of the Logistics Engineering IV module. It introduces logistics engineering and key concepts. The study unit defines logistics and integrated logistics support, explains the need for logistics engineering from customer and supplier perspectives, discusses the history of logistics, and outlines the objectives and learning outcomes of the study unit. The unit aims to motivate the importance of logistics and provide foundational definitions to understand this area of engineering.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views145 pages

Logistics Engineering IV Learner Guide 2020

This document provides an overview of the first study unit of the Logistics Engineering IV module. It introduces logistics engineering and key concepts. The study unit defines logistics and integrated logistics support, explains the need for logistics engineering from customer and supplier perspectives, discusses the history of logistics, and outlines the objectives and learning outcomes of the study unit. The unit aims to motivate the importance of logistics and provide foundational definitions to understand this area of engineering.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

LGE401I/501/0/2020

LEARNER GUIDE 2020

Logistics Engineering IV
LGE401I

Year Module

Mechanical and Industrial Engineering

IMPORTANT INFORMATION
This tutorial letter contains important information
about your module.
LGE401I/501

University of South Africa

All rights reserved

Printed and published by the


University of South Africa
Muckleneuk, Pretoria

2
LGE401I/501

CONTENTS

INTRODUCTION TO THIS MODULE

STUDY UNIT 1: INTRODUCTION TO LOGISTICS

STUDY UNIT 2: RESULTS OF LOGISTICS SYSTEM ENGINEERING

STUDY UNIT 3: LOGISTICS PROJECT MANAGEMENT

STUDY UNIT 4: PRELIMINARY ANALYSIS

STUDY UNIT 5: CONCEPTUAL DESIGN

STUDY UNIT 6: LOGISTICS SUPPORT ANALYSIS

3
LGE401I/501

Dear Student

INTRODUCTION TO THIS MODULE

Welcome to Logistics Engineering IV. We trust that you will find this module
interesting and helpful!

As you work through the study material, keep in mind that certain concepts will
probably only make sense when you have worked through all the study material; we
therefore advise you to work through the whole study material to get an overview
before you attempt to understand the "nitty gritty" details.

Remember that Rome was not built in one day!

1 Goal of this module

This module was designed to give you a framework and fundamental knowledge of
logistics engineering as well as the basic skills to fulfil your engineering roles and
responsibilities as a team member of a system development project.

2 Learning outcomes for this module

When you have completed this module, you should be able to

• describe the concept of integrated logistics support in the context of its


associated technical and management disciplines
• describe the goal, objectives and processes of logistics engineering
• develop an operations and support concept for a simple system

• influence the design of a simple system (that is, phase 1 of the logistics
support analysis [LSA])
• identify the logistics support elements of a simple system (that is, phase 2 of
the logistics support analysis)
• describe the technologies associated with specifying, designing and producing

4
LGE401I/501

the logistics support elements


• explain the three dimensions that determine how customers experience a
system (customer satisfaction) and how each of these dimensions can be
influenced by integrated logistics support (ILS)

Our objective with this module is therefore to enable you to describe the position and
relationship of logistics engineering within the larger context of integrated logistics, to
describe and explain the place and role of logistics engineering within the
development process, and to describe and explain the management and technical
processes associated with logistics engineering.

2 Overview of this module

STUDY UNIT 1: INTRODUCTION TO LOGISTICS


Why do we need logistics engineering?
The history of Logistics
What is logistics and integrated logistics support? (logistics engineering vs
operational logistics; an integrated logistics support model)
The role of business logistics

STUDY UNIT 2: RESULTS OF LOGISTICS SYSTEM ENGINEERING


The results of the logistics system engineering effort
The characteristics of the logistics system
The deliverables of the operational logistics system
The management processes associated with logistics

STUDY UNIT 3: LOGISTICS PROJECT MANAGEMENT


Project management of logistics system engineering (planning, organising, control,
directing)
System engineering in logistics development
The role of the logistics system analysis process
Logistics activities in the life cycle of the system
Documents used in the logistics management process

5
LGE401I/501

STUDY UNIT 4: PRELIMINARY ANALYSIS


Why logistics engineering?
Determining the requirements for ?
The system operations and support concept (definition, functions of an operations
and support concept, the use profile, the maintenance concept)

STUDY UNIT 5: CONCEPTUAL DESIGN


The measurements of logistics (reliability, maintainability, availability, cost,
dependability, supply support factors, test and support equipment factors,
organisational factors, facility factors, distribution and handling factors, effectiveness
factors)
Functional analysis
Requirements allocation
Design criteria

STUDY UNIT 6: LOGISTICS SUPPORT ANALYSIS


The purpose of logistics support analysis in the early design phases: Influencing the
design
The purpose of logistics support analysis in the latter design phases: Determining the
detailed logistics requirements for the design
The logistics support analysis process (design influence and compilation of the
support concept identification of logistics support analysis candidates, development of
logistics support analysis candidate support concepts, conducting a failure mode,
effects and criticality analysis (FMECA), performing the reliability-centred
maintenance process, designing maintenance tasks, defining resources for
maintenance tasks)
American military standards applicable to the logistics support analysis

3 Prescribed book

The prescribed book for this module is:

6
LGE401I/501

Blanchard, BS. 2004. Logistics engineering and management. 6th edition. Upper
Saddle River, NJ: Pearson Prentice-Hall.

7
LGE401I/501

STUDY UNIT 1: INTRODUCTION TO LOGISTICS

Content
1.1 Overview
1.2 Study objectives
1.3 Learning outcomes
1.4 Source
1.5 Definitions
1.6 Why do we need logistics engineering?
1.6.1 The customer-to-customer process
1.6.2 The need for logistics from the customer's perspective
1.6.3 The need for logistics from the supplier's perspective
1.7 The history of logistics
1.8 What is logistics and integrated logistics support?
1.8.1 Logistics
1.8.2 Integrated logistics support
1.8.3 Logistics engineering
1.8.4 Operational logistics
1.8.5 An integrated logistics support model
1.9 The role of business logistics
1.10 The focus of this module
1.11 A lot of common sense!

8
LGE401I/501

1.1 Overview

In this study unit we introduce you to the systems concept and the life cycle
approach, which are required for understanding of logistics engineering.

We discuss the systems concept, the need for logistics engineering, and the definition
and history of the field. The need for logistics is viewed from two perspectives,
namely that of the system supplier and that of the customer. We demonstrate that the
need for logistics is primarily influenced by the drive for customer satisfaction. We
discuss the history of logistics so that you can understand the origin of the philosophy
that is presented in the study material.

We also introduce you to the definitions of the elements of logistics and to integrated
logistics support. We then use these definitions to define the concepts of logistics
engineering and operational logistics (which are integrated into a generic life-cycle
model for integrated logistics support in a related article by PJ Pretorius, which we
refer to later in the text). Lastly, we explain the role and position of business logistics
within integrated logistics support.

1.2 Study objectives

Our objectives with this study unit are to

• provide a generic model of integrated logistics support


• define the systems concept and relate it to the field of logistics engineering
• motivate the need for logistics from a supplier as well as a customer
perspective
• explain the modem perspective in the field by referring to its evolvement
• define the basic concepts of logistics and integrated logistics support
• clearly define the different areas of logistics, to show the relationships between
the different areas of logistics, and to highlight the importance of both
management and technical activities within logistics

9
LGE401I/501

1.3 Learning outcomes

When you have completed this study unit, you should be able to

• define a system and the system concept


• define and describe the importance of logistics engineering in the system
development and life-cycle approaches to logistics
• describe the need for logistics from the perspective of the supplier as well as the
customer
• describe the history of the logistics philosophy as presented in this study unit
• define and describe the concepts of logistic, integrated logistics support,
logistics engineering and operational logistics
• describe how logistics engineering and operational logistics complement each
other
• describe the role and position of business logistics within integrated logistics
support

1.4 Source

The information in this study unit is based on your prescribed book.

10
LGE401I/501

1.5 Definitions

(1) System

A system is a set of interrelated, self-sufficient components that work together


towards a common objective. The generic function of a system is to process inputs
into outputs through its components.

The set of components of a system has the following properties:

• The properties and behaviour of each component of the set has an effect
on the properties and behaviour of the set as a whole.
• The properties and behaviour of each component of the set depend upon
the properties and behaviour of at least one other component in the set.

Each possible subset of components has these two properties; the components
cannot be divided into interdependent subsets.

The system as a whole has the following properties:

• Holism. The focus is on the system rather than on the components.


• Synergy. The system is greater than the sum of its parts (by providing
ability, availability and affordability within safe conditions).

Systems exist within a hierarchy of systems.

A system, as defined here, refers to the collective elements associated with satisfying
a need. This includes the support elements associated with the product. A typical
example is a motor vehicle, the garage facility where maintenance is done on the
vehicle, and the handbooks, manuals, tools, et cetera that are used.

(2) Prime mission system elements

11
LGE401I/501

This refers to the system elements that are involved in the main mission of the
system. It is normally the product itself and does not include the support
elements. A typical example is a motor vehicle.

1.6 Why do we need logistics engineering?

Every part of a profit-seeking business should be aimed at the ultimate goal of


making money, being profitable and staying in business. This is the aim of and the
reason for logistics.

In the past, in most cases, only the prime mission-oriented segments of a system
(product) were engineered and too little attention was directed towards factors such
as reducibility (can the design be manufactured?) and – most importantly –
supportability (can the design be supported?), or to the management processes
associated with these.

You should note that the "system" that we refer to here can be a product as small as
a bicycle or a lawnmower, or a mechanical or electronic system as large as a factory
or a plant. "System" may also refer to an organisation, where the main system parts
are human beings!

Logistics is increasingly becoming a vital necessity from the perspective of both the
supplier and the customer (as we explain below).

1.6.1 The customer-to-customer process

We may summarise the different phases of the logistics life cycle as well as the
primary role players during the phases (also known as the customer-to-customer
process) as follows:

12
LGE401I/501

Figure 1.1: The customer-to-customer process

This figure illustrates that the process is generic in nature and consists of a sequence
of phases. It shows how a system comes into being, how it is operated and
maintained, and how it is eventually phased out. It represents the life-cycle activities
of large-scale systems.

1.6.2 The need for logistics from the customer's perspective

The objective of the organisation should be to meet the needs or requirements of the
customer as effectively and efficiently as possible (for the purpose of making money).
In broad terms, customer satisfaction is based on the success of the following:

1) The capability of the product (performance parameters). What can the system
do? Is it able to accomplish what it is acquired for? Is the system where it is
needed?
2) Availability. When is the system needed? Is the system available at the time
when it is needed? Is the customer able to use the system?
3) The life cycle cost of the system. The customer requires a high-quality system
that is able to fulfil its mission (in terms of its capability) at the lowest possible
cost throughout the lifetime of the system.

These aspects imply the following requirements of the customer:

13
LGE401I/501

• An availability and capability that are as high as possible, with the costs and
risks connected with unavailability or dependability minimised. Costs here refer
to money, time and other resources.
• Lead times that are as short as possible.
• Low variability in quality and other factors (always having what they are used
to).
• A good support capability (after-sales service).
• A support system that is highly flexible.

In short: the benefits obtained from owning the system should, from the customer's
viewpoint, outweigh the costs.

Integrated logistics support influences all three dimensions of how customers


experience the system (what the customer experiences defines customer
satisfaction) in the following ways:

1) The capability of the product can be influenced by how good or bad


maintenance is performed, whether the product is at the right time at the right
place and all its associated requirements (for example data, personnel and
software).
2) Availability. Unavailability is influenced mainly in two ways: through reliability
(MTBF, mean time between failures) and maintainability (MTTR, mean time to
repair). Both of these are inherent logistics characteristics of the design (as we
discuss this later in this tutorial letter) and both can be influenced externally by
the support system.
3) The life-cycle cost of the system. The cost of the product, its operation and its
support can be influenced in a major way by logistics engineering. In complex
systems, operations and support costs generally comprise up to 70% of the
total cost of ownership!

1.6.3 The need for logistics from the supplier's perspective

14
LGE401I/501

The supplier is interested in providing a total solution for an existing customer need.
(A satisfied customer means staying in business, which means making more money!)
The effectiveness of this solution is determined by the combination of the product and
its support. A well-designed product with poor support will result in a poor system;
whereas an average-designed product with excellent support may provide better
customer satisfaction. The amount of support the product will require, is (as we
discuss a little later) determined during the initial design phases. During these
phases, a trade-off is made between spending more initially to avoid costs later in the
life cycle and avoiding high initial costs with the probability of high costs later. From
the perspective of the supplier, the necessity of logistics stems from facilitating
customer satisfaction at the lowest possible overall cost.

Note that when we refer to overall cost, the life-cycle cost (“from the cradle to the
grave") should be considered. Too often unnecessary costs are realised later in the
life cycle due to insufficient logistics engineering in the early stages of the life cycle.

Remember, problems that are encountered downstream are symptoms of


neglect upstream.

A final reason for the supplier’s interest in the field of logistics engineering is that the
related logistics of a system can be a source of income in itself (for example, to keep
the system available to the customer, an after-sales service or sales of parts can be
introduced).

1.7 The history of logistics

Before we define logistics and logistics engineering, we briefly discuss the history of
logistics.

Traditionally logistical (support) elements were developed after the prime mission
segments of the system (the product itself) were already developed and the designs
were fixed. Mostly, this took place after the prime mission system elements became
operational. This was a fairly expensive way of doing things, because the design
lacked provision for supportability.
15
LGE401I/501

You may think of equipment in your own environment that are close to impossible to
perform maintenance on (for example, having to remove engine parts in a certain
motor vehicle to do simple basic maintenance activities or the unavailability of certain
parts of household appliances that often break).

Even today a "downstream approach" to logistics is often encountered.

Because of the rising costs of development and support, higher complexity of


systems and technologies, and the requirement to use resources better, there is
increased pressure to develop and deliver support elements with the prime mission
system elements. The focus is increasingly being placed on materials flow, product
distribution transportation, et cetera during the development of the prime mission
system elements.

It was only recently that the approach of integrating logistics (support) with the prime
mission system elements from the earliest stages of design developed. After all, this
is where the need that justifies the existence of the system is determined! This
approach ensures that support elements are considered throughout the life cycle of
the system, up to the retirement and phase-out of the prime mission system
elements. It also ensures that the support elements are compatible with the prime
mission system elements and, very importantly, with each other.

These factors may sound like common sense to you, but it too often happens that:

• Designers are so involved with the design of the prime mission system
elements that little or no attention is paid to the supportability or support
elements of the system.
• Other people than those who are designing the prime mission system
elements are involved in the design of the support elements. This is a
common mistake of most design teams which have grave
consequences later in the life cycle. The designers of the prime mission

16
LGE401I/501

system elements are the best and most qualified people to be


responsible for and to design the support elements.

1.8 What is logistics and integrated logistics support?

1.8.1 Logistics

The key word in defining Logistics is “support”. Plainly stated, while systems
engineering is concerned with designing the system, logistics takes care of the
system during its entire life cycle.

We may depict the situation as follows:

A need exists (as defined in the user requirement statement), but in reality no natural
solution for that the need exists. This is overcome by a product. Because any product
will most likely fail and because the product is not perfect, logistics becomes
necessary – so that the situation now look as follows:

(The aim throughout the life cycle should be to make the logistics part of the system
as small as possible, because this is the part of the system where the highest costs
are involved.)

17
LGE401I/501

The smaller the logistics part, the better the design should be. A better design
requires less support in terms of equipment, personnel, et cetera. It fails less
frequently and the support elements are designed to consist of as few parts as
possible. Of course, the opposite is also true. The worse a design is, the more
logistics (support) will be required and the more it will cost to support.

The logistics support elements are the visible parts of logistics; they are the physical
elements and the management processes associated with the

• test and support equipment


• maintenance planning
• supply support
• personnel, training and training aids

18
LGE401I/501

• transportation and materials handling


• special facilities
• computer resources
• data

that are necessary to ensure complete customer satisfaction along with the prime
mission equipment during the useful life cycle of the system.

They include aspects such as accomplishing sufficient flow of materials and


distribution, as well as maintenance support during all the phases of the life cycle.
And they involve all the system parts from the system level right down to the
component level.

In short, the logistics support elements are required to perform three major functions
during the operational phase of the system, namely:

1) operational support
2) preventative maintenance, and
3) corrective maintenance

A major consideration (as we discuss later in this tutorial letter) is that without
management processes, the logistics elements mean nothing. Along with the physical
elements, there must be management processes that will guide the abovementioned
three functions. These management processes are: maintenance management,
procurement and supplier management, inventory management, facility management,
supply and distribution management, personnel management and configuration
management.

1.8.2 Integrated logistics support

Integrated logistics support is defined as follows:

19
LGE401I/501

It is a disciplined (according to a specific process that is always followed; it requires


skill, control and commitment), unified (always in the same way to ensure uniformity;
integrating into a complex whole) and iterative (performed repetitively into lower
levels of detail) approach to the management and technical activities that are
necessary to

• integrate support considerations into system and equipment design


• develop support requirements that are related consistently to readiness
activities, to design and to each other
• acquire the required support (to be in place when the system becomes
operational)
• provide the required support during the operational phase at minimum cost

All of the above are elements to ensure customer satisfaction.

Because logistics should be viewed as integrated with all the system elements, it
should be planned and integrated in the overall system development process. It is for
this reason that integrated logistics support is necessary.

Integrated logistics support has two distinct areas of focus, namely management
activities and technical activities – both of which are an important part of integrated
logistics support. Integrated logistics support therefore does NOT only refer to the
management processes (as some literature proposes), because the management
and technical activities of logistics are equally important and mutually supportive in
achieving the objectives of the system.

One of the most important conditions for integrated logistics support is that a life-
cycle approach has to be followed to ensure integrated logistic support over the total
life cycle of the system. Integrated logistics support addresses the total life cycle,
namely the design concept, detail design, production, operations, support and phase-
out of the system. It should be part of each phase, from start to finish. Throughout the
life cycle of the system, logistics should be integrated with the prime mission
equipment and the various restrictions (among other things, the type of people who

20
LGE401I/501

have to operate the system, the money and time that are available and the operating
environment) taken into account.

During the system development the operational environment should also be


considered and the logistics activities should be included from the beginning of the
design.

Stated plainly, integrated logistics support means

• designing according to a certain required capability and considering all the


possible restrictions
• determining and designing what is necessary to effectively support the system
• influencing design to make this part (the part of support) as small as possible

The mechanism for managing this process is managed is logistics systems


engineering.

1.8.3 Logistics engineering

Logistics engineering refers to the management and technical activities that are
necessary to integrate support considerations into the system and equipment design
and to develop support requirements that are related consistently to readiness
objectives, design and each other to ensure the safety, availability and economic
viability of the system during the operational phase. The aim, once again, is customer
satisfaction (remember, we are in the money making business!).
"In essence, logistics engineering covers (1) the design of the prime mission
equipment for supportability, and (2) the design of the overall support capability for
the system. These requirements can be considered as an inherent part of the overall
systems engineering process."

If you look at figure 4 in Pretorius’s article, you will see that in the life cycle the initial
focus of the logistics effort is on logistics engineering and during the production
phase, it moves to operational logistics (more on this below). Note that logistics

21
LGE401I/501

engineering does not only determine the technical elements of logistics, but also the
management processes – which in turn determines the day to day running of logistics
in the operational phase. Logistics engineering ensures the effectiveness of the
support system, while operational logistics ensures its efficiency.

Logistics should be engineered to ensure successful operational logistics.


The purpose of logistics engineering is twofold. Firstly, it is used to ensure that while
the system is designed, all the operational considerations are taken into account in
order to make a design safe, capable, available and supportable from a logistical
viewpoint. Secondly, it is used to ensure that all the resources that will be required for
the system during its operational phase are identified, specified and designed to
successfully operate the system and to support it when it is operated.

In this process, the restrictions that the environment places on the design and the
support system should be considered and a conscious effort should be taken to
ensure that all the market requirements are met. (Keeping customers satisfied means
money!)

Remember, the customer will be satisfied when he has

• a capable system that operates successfully (thanks to our logistics!)


• an available system when it is required (made possible by logistics!)
• an operationally and (logistically speaking) cost-effective system

NOTE: Customers want their systems to have a certain ability, availability and
affordability. These three factors are not only determined by the prime mission
equipment, but are also influenced in a major way by the support (logistics). It is
therefore of the utmost importance to consider the design of the prime mission
equipment and the support system simultaneously to ensure the best possible
combination of ability, availability and affordability during the operational phase of the
system. While integrated logistics support seeks to integrate operations, design and
support over the total life cycle of the system, logistics engineering seeks to integrate
the design of the prime mission equipment with the design of the support system.

22
LGE401I/501

1.8.4 Operational logistics

Operational logistics refers to the management and technical activities that are
necessary to acquire the desired support and provide the required support during the
operational phase to ensure the highest levels of safety, capability and availability
within the cost targets set by the design.

Plainly stated, operational logistics are all the management and technical activities
which are required during the operational and support phase of the system to support
the system's primary reason for existence.

The capability, availability, and cost of operation and support have been established
when the design was made. Therefore, because the characteristics are determined
by the design, there is a limit to improving or optimising each of these during the
operations and support phase. (In other words, they cannot exceed the inherent
optimal characteristics of the design; at best, they can be improved to these levels.)
The single characteristic that is often the target for reducing is that of cost. However,
it is very difficult to change the inherent design characteristics (which on its own can
be very costly) during the operations and support phase.

In the operations and support phase the system is operated and therefore requires
operations support (for example fuel, spares and trained operating personnel)
Furthermore, the system ages over operations and time (it also ages when not in
operation), which results in failure occurrences and the probability of failures
increasing. Depending on the effect of the failure (or potential failure), preventative or
corrective maintenance is performed as follows:

• If the criticality of the effect of the failure is high, preventative maintenance will
be done to try and reduce the probability of failure occurrence.
• If the criticality of the effect is low, then no preventative maintenance is
performed. The system is then operated until the failure occurs and then
corrected at a suitable time.

23
LGE401I/501

The criticality of the failure depends on the severity of the effect, considering safety,
availability, cost and probability of failure.

We explain these aspects in more detail later in this tutorial letter.

The integrated logistics support management activities are mostly concerned with
procurement, inventory management, distribution management, maintenance
management and management of providing operational support.

1.8.5 An integrated logistics support model

Refer to figure 4 in the article by Pretorius for an explanation of how logistics


engineering and operational logistics fit together to constitute integrated logistics
support. As stated before, logistics engineering is concerned with effectiveness
(doing the right things); whereas operational logistics is concerned with efficiency
(doing things right). Of course, doing the right things can only be determined during
the initial phases; therefore, we focus on the initial phases in this tutorial letter.

1.9 The role of business logistics

Traditionally, the field of logistics is focused on business logistics; therefore, it is


appropriate to briefly discuss the position of business logistics within integrated
logistics support as it is defined in your study material.

Ballou , ("Basic Business Logistics, 2 nd edition, Prentice Hall, 1987") defines the
concept of business logistics as follows: "Business logistics deals with all move-store
activities that facilitate product flow from one point of raw material acquisition to the
point of final consumption, as well as the information flows that set the product in
motion for the purpose of providing adequate levels of customer service at
reasonable cost."
"Product" here is used in the broadest sense to include both goods and services.

24
LGE401I/501

Ballou's definition identifies the activities that are of primary importance in achieving
the objectives of logistics. These key activities are:

• order processing (the interface that sets the loop in figure 1.5 below in motion)
• inventory maintenance (making inventory available, for example from stock,
JIT and the like)
• transportation (which includes the various methods of moving the product)

From an organisational point of view, one does not only have to look at the customer
but also at the supplier so that the loop in figure 1.5 becomes a chain.

Now although the organisation also becomes the customer of its supplier, the
(business) logistics functions that are involved are exactly the same.

While we keep the above in mind, we may define business logistics as follows:

25
LGE401I/501

Business logistics is the management and technical activities that are necessary for
the effective flow and storage of raw materials, work in progress, maintenance
requirements and finished products from the point of origin to the point of
consumption for the purpose of conforming to customer requirements.

As you may have guessed by now, business logistics actually forms part of
operational logistics:

The business logistics elements and management processes are a subset of


operational logistics and is therefore also a subset of integrated logistics support.
The business logistics activities are applicable to all material that requires move–
store functions, which includes maintenance requirements. As with operational
logistics, business logistics comprises physical elements as well as the management
processes that governs it.

1.10 The focus of this module

Because logistics engineering is concerned with the first phases of the life cycle, the
focus of this module is on the objectives of integrating support with system and
equipment design and developing support elements which are consistent with
readiness objectives, design and each other.

26
LGE401I/501

Operational logistics
In operational logistics the developed management processes are applied to ensure
the proper use of the developed logistics elements:

● maintenance planning
● test and support equipment
● supply support
● packaging, handling and storage
● transportation
● personnel and training
● facilities
● technical data
● computer resources

Business logistics

Business logistics ensures the proper flow of materials within the operational
environment:

● order processing
● inventory maintenance
● scheduling
● production
● procurement
● protective packaging
● warehousing
● materials handling
● information maintenance
● transportation

27
LGE401I/501

The reason for the focus on the first part of the life cycle is because costs (money,
resources and time) are not yet fixed here. The better the design is in the early stages
of the life cycle, the less resources are necessary later in the life cycle.

This may be depicted graphically as follows:

Production/Acquisition and operations and support comprise 60 to 70% of the total


cost of the system (depicted by the area under the curve). The greatest opportunity to
influence these costs is realised during the early phases of a programme, since the
life-cycle cost is established (committed) during the initial phases of the system life
cycle. Logistics engineering is aimed at precisely this: To keep overall costs as low as
possible by spending a little more during the research and development phase. (This
philosophy is represented by the dotted line). The increase in the cost at the
beginning of the life cycle is much less than the costs that are saved later in the life
cycle. This can be easily explained:

A change on a drawing or specification is much cheaper than changing a


production line!

The other reason for this philosophy is the simple fact that problems that are
encountered downstream in the life cycle are merely symptoms of neglect upstream

28
LGE401I/501

in the life cycle. So, through the process of logistics engineering and the integrated
logistics support approach, a little more is spent initially and the harvest is enjoyed
later.

It is of utmost importance that the user is involved in this process from start to finish.
The user has to provide inputs throughout this process, because our aim is to make
money and (as we said before) the only way to do this is to give the customer exactly
what he wants and not what the supplier may think he wants.

1.11 A lot of common sense!

The most important aspect of logistics is unfortunately impossible to teach: Common


sense!

Nothing can replace the importance of periodically sitting down and thinking logically
about the system elements in terms of support and supportability. We are referring to
a thinking process of actually standing back throughout the design process and
reviewing the design in terms of the following: Where is the system likely to fail? How
will the user know that it has failed? What can be done about it? Is the system
supportable? Can the “vulnerable parts” be reached in case of failure? Are the
support tasks involved easy enough for the operator?

A word of advice: When you work through the study material, be careful not to get
involved in the detail of the discussions to the extent of ignoring your common sense.
It is your most effective tool!

29
LGE401I/501

STUDY UNIT 2: RESULTS OF LOGISTICS SYSTEM ENGINEERING

Content

2.1 Overview
2.2 Study objectives
2.3 Learning outcome
2.4 Source
2.5 The results of the logistics system engineering effort
2.5.1 The characteristics of the system
2.5.2 The deliverables of the operational logistics system
[Link] Support and test equipment
[Link] Supply support
[Link] Support facilities
[Link] Personnel and training
[Link] Technical data
[Link] Packaging, marking, storage and transportation
[Link] Computer resources
[Link] Maintenance plan
2.5.3 Management processes

30
LGE401I/501

2.1 Overview

In this study unit we discuss the elements of the logistics system, that is the results of
the logistics system engineering effort. These elements constitute the whole logistics
(support) system.

2.2 Study objectives

Our objectives with this study unit are to

• give a summary of the end results of the logistics systems engineering effort
• define the end results that the logistics systems engineering effort are aimed at
• give you a clear understanding of the deliverables of the logistics system
engineering effort

2.3 Learning outcomes

When you have completed this study unit, you should be able to

• describe the elements of the logistics (support) system that collectively forms
the output of the logistics system engineering effort
• explain that the output of the logistics system engineering effort not only refers
to the physical elements, but also to the management process associated with
these

• describe the desired results of the logistics system engineering process in


terms of its deliverables and the characteristics that the system should have
after its application; refer to any system of your choice (for example, a motor
vehicle or any system with which you are familiar) and provide specific
examples to illustrate your answer to a question

2.4 Source

31
LGE401I/501

This study unit is based on the prescribed book for this module.

2.5 The results of the logistics system engineering effort

Before we discuss the process and techniques of logistics system engineering, we


briefly discuss the results of this process. In other words, what we are aiming at in
this module: What do we want to see as part of the whole system after we apply the
logistics system engineering process?

The desired results of the process can be divided into two categories, namely:

1) the characteristics that the system should have after the logistics system
engineering process has been applied
2) the deliverables of the logistics system engineering process, that is the
elements that should be delivered along with the prime mission system
elements (We refer to these as the elements of logistics.)

2.5.1 The characteristics of the system

The characteristics that we are aiming at are:

• low life-cycle cost


• adequate system performance
• adequate system supportability
• adequate system availability
• adequate system reliability
• adequate system maintainability, which includes testability, et cetera

2.5.2 The deliverables of the operational logistics system

We referred briefly to the elements of the logistics system in the first study unit. We
will now discuss these and what they consist of in a little more detail. These elements

32
LGE401I/501

are the second part of the output of the whole logistics engineering effort; each of
them is a specialist field and each requires a thorough design process in its own right.

The elements of logistics are the deliverables of the logistics system engineering
effort (in other words, the components of the logistics system that should be delivered
as a result of the logistics engineering effort).

The logistics system consists of the following physical elements and management
processes that are associated with them:

• support and test equipment


• supply support (supplies and consumables)
• support facilities
• personnel, training and training aids
• technical data
• resources or subsystems associated with transportation, packaging, handling
and storage
• computer resources
• maintenance plan

33
LGE401I/501

[Link] Support and test equipment

This refers to the standard ("off-the-shelf") and specially developed ("dedicated")


tools and equipment for supporting and testing the prime mission equipment and the
related logistics system. Included are also diagnostic and test equipment, calibration
equipment, fixtures and jigs for maintenance purposes, and equipment for system
operation.

[Link] Supply support

This element includes all spares (supplies) and consumables that are required for the
operation and support of the prime mission equipment and the related logistics
system. It includes identifying all the spares and consumables that are necessary, all
the documentation that are associated with these, the procurement of the spares and
consumables (supplier management, lot management, scheduling, distribution
aspects, et cetera), inventory management (warehousing and the like) and (logically)
the required personnel.

[Link] Support facilities

This refers to all the facilities that are required for the operation and support of the
prime mission equipment and the related logistics system: property, buildings, plants,
laboratories, clean rooms, warehouses, stores, mobile facilities, utilities (for example
water, electricity, steam, heating, air conditioning and communication), et cetera. The
operations and management of these facilities should of course also be developed.

34
LGE401I/501

[Link] Personnel and training

This refers to all the personnel who are required for the operation and support of the
prime mission equipment and the related logistics system. The required personnel for
the operation and support of the system depend on the type of system and consist,
among others, of the user, the user support organisation and the supplier.
The training (initial and continuous) of all the personnel, as well as the training aids
(simulators, software, videos, et cetera), should also be developed.

[Link] Technical data

This refers to all the technical data that is required for the installation, commissioning,
operation and support of the prime mission equipment and the related logistics
system. It includes data that is required for modification and overhaul; data that is
associated with the facilities, et cetera; and all the drawing and specifications that are
associated with the system.

[Link] Packaging, marking, storage and transportation

This element refers to everything that is required for the preparation, preservation,
packaging, marking, storage, handling and transportation associated with the
operation and support of the prime mission equipment and the related logistics
system. Among these are materials, containers, special provisions (for example, for
highly flammable or radioactive items), procedures and the like.

[Link] Computer resources


This refers to the computer-related items that are required for the operation and
support of the prime mission equipment and the related logistics system, for example
computer and network equipment, software and databases.

35
LGE401I/501

[Link] Maintenance plan


This element integrates all the other support elements and refers to the planning for
the development and deployment of support elements and the associated
management system. It includes planning maintenance schedules, quantities,
distribution aspects, integration of requirements to avoid duplication, allocation of
responsibilities and the like. A proper maintenance programme ensures that the
system attains its full potential by ensuring (and maintaining) the availability of the
system, as well as its inherent safety, at minimum cost.

2.5.3 Management processes

We cannot stress enough that several management processes are associated with all
the elements or deliverables which we discussed above. As we proceed with the
other study unit, these management processes and tools (specifically compiling the
user profile, the maintenance concept, the supply support concept and the
maintenance management concept) will enjoy special attention. Although we do not
discuss them further here, they should definitely be considered a critical part of the
results of the logistics engineering effort.

STUDY UNIT 3: LOGISTICS PROJECT MANAGEMENT

36
LGE401I/501

Content
3.1 Overview
3.2 Study objectives
3.3 Learning outcomes
3.4 Source
3.5 Project management of logistics system engineering
3.5.1 Planning
3.5.2 Organising
3.5.3 Controlling
3.5.4 Directing
3.6. System engineering in logistics development
3.6.1 Logistics system engineering
[Link] Analysis
[Link] Results
[Link] Integration
[Link] Verification
3.7 The role of the logistics system analysis process
3.8 Logistics activities in the life cycle
3.8.1 The concept exploration phase
3.8.2 The demonstration and validation phase
3.8.3 The full-scale development phase
3.8.4 The industrialisation phase
3.8.5 The production phase
3.8.6 The operations and support phase
3.9 The documents used in the logistics management process
3.9.1 Logistics management documentation
[Link] The integrated logistics support plan
[Link] The logistics element plans
3.9.2 Technical logistics documentation
[Link] The operation and support concept
[Link] The logistics support analysis and logistics support analysis record
specifications
[Link] The logistics element specifications
37
LGE401I/501

3.9.3 The documentation evolution process

3.1 Overview

In this study unit we introduce you to the concepts of project management that are
associated with logistics system engineering. We discuss how the principles of
system engineering fits into the logistics development process, the role of the logistics
38
LGE401I/501

system analysis process and the life-cycle approach which is required for
understanding logistics engineering. Furthermore, we give you an overview of the
documents that are used in the logistics management process.

We discuss the project management of logistics system engineering and the life-cycle
approach, but because this is not a module about project management or a study of
the life-cycle approach per se, we only cover the minimum theory on these fields,
which is required for understanding logistics engineering.

3.2 Study objectives

Our objectives with this study unit are to

• provide an overview of the project management that is associated with


logistics system engineering, the role of the logistics system analysis process
and the life-cycle approach
• define the project management that is required for the successful development
of a logistics system
• highlight the importance of proper management and the application of system
engineering principles in the logistics development process
• explain the role of the logistics system analysis process in the logistics
development process
• define and describe the life-cycle approach and the logistics activities for each
phase
• define the different types of documents that are used in the management of
the logistics development process

3.3 Learning outcomes

When you have completed this study unit, you should be able to

• discuss the managerial tasks relating to the project management of the


logistics engineering effort

39
LGE401I/501

• discuss the importance of proper project management during the logistics


engineering effort
• describe how the system engineering activities are applied in the development
of a logistics support system
• discuss how the functions and tasks of system engineering should be applied
in the development of a logistics support system
• discuss why a logistics system analysis is necessary, what its objectives are
and where its focus should be
• explain how logistics fits into the life cycle of the system
• use the life-cycle approach to explain the specific logistics tasks in each phase
of a system's existence from cradle to grave
• describe the three sets of documents that are used in the management of the
logistics engineering process as well as their development processes
• discuss the tasks of the logistics manager with regard to the project
management of the logistics engineering effort and refer to the tasks of
planning, organising, controlling, directing and staffing

3.4 Source

This study unit is based on your prescribed book.

3.5 Project management of logistics system engineering

Before we discuss the technical aspects of logistics system engineering, we briefly


consider the managerial aspects.

The success of the system depends largely on the success of the logistics support
system, which in turn depends on (among other things) proper management of all the
programme phases.
This, of course, is the case with all engineering activities. Hence the need for logistics
project management.

40
LGE401I/501

Logistics project management refers to the effective planning, organising, controlling,


directing and staffing of the logistics system engineering activities. The objectives of
logistics project management are:

• to ensure the incorporation of the necessary logistics in system design and


development to make the logistics part of the system as small as possible
during the design
• to ensure provisioning of adequate support for the prime equipment operation
and maintenance

Logistics project management takes place throughout the life cycle of the system and
involves the following managerial tasks.

3.5.1 Planning

The task of planning may very well be the most important managerial task. The
statement holds true: If you fail to plan, you plan to fail.

Planning includes the following:

• Determining a strategy for the development of a logistics support system.


(This is largely determined by whether the product/system under consideration
is an existing one that is being improved or a totally new one. For example, in
the case of the latter, the logistics engineering process will naturally include a
fair amount of influencing design – which will have a substantial influence on
the development strategy.)
• Determining and stipulating responsibilities for the different aspects of the
logistics engineering process and the resulting logistics support system
(compiling a responsibility matrix).

• Identifying the logistics tasks to be accomplished throughout the life cycle of


the system and integrating these into a structure in which they are separated
into logical work-related units and linked to the available resources (compiling

41
LGE401I/501

a statement of work [SOW] and a work breakdown structure [WBS]).


• Determining a schedule for logistics tasks to be accomplished.
• Preparing cost estimates (budgets) for logistics tasks to be accomplished.

3.5.2 Organising

In the task of organising the key words are tailoring and change. It is of the utmost
importance that the organisation’s structures are tailored to meet the needs of the
specific engineering situation. There are no rights and wrongs here.

Furthermore, these structures are dynamic by nature because the needs change
throughout the life cycle of the system. It is a common phenomenon for a project
team to start out with structure A, change to structure B and then to structure C
during its lifetime.

The task of organising includes the following:

• Determining communication structures within the logistics project.


Tremendous amounts of communication are necessary in the logistics
engineering effort and as any person who has even a little experience in
project engineering would know, these communication structures need special
attention because they can “make or break” the team’s efforts.
• Defining responsibilities and authority structures within the logistics
engineering process.
• Staffing and compiling a project team.

It is most desirable for the design team to also manage the logistics design effort.

3.5.3 Controlling

No amount of planning or organising can ever substitute an efficient control system.


The task of control includes the following:

42
LGE401I/501

• Control of the actual cost. It is necessary to differentiate between two types of


cost here, namely money and time. For example, a project may be 80%
completed in terms of money (80% of budget spent), but 50% completed in
terms of time.
• Control of the schedule. Controlling the technical progress of the project.
• Control of technical performance. Controlling the inputs, outputs and
parameters against which the deliverables are measured, et cetera.

3.5.4 Directing

This includes the managerial tasks of decision making (how decisions are to be made
and making the actual decisions), motivation of personnel and the initiation of courses
of action.

43
LGE401I/501

3.6 System engineering in logistics development

We do not expect you to understand the entire field of system engineering in this
module; however, it is necessary that you understand how the principles of system
engineering are applied in the development process of a logistics support system.

We therefore begin by defining system engineering.

System engineering is the effective application of scientific and engineering methods


to

• transform an operational need into a description of performance parameters


and a preferred system configuration (which of course includes the logistics!)
• integrate related technical parameters that optimise the total system definition
and design
• integrate reliability, availability, maintainability, safety, logistical and other
related specialities into the total engineering effort in order to meet technical
performance, cost and time objectives throughout the life cycle of the system

If we consider the objectives of the system engineering effort as stated above, it is


clear that logistics is included in ALL of them.

The reason for this is simple: A system consists of the product itself and its support.
In choosing and engineering the product, the support is effectively also chosen and
engineered. We have already discussed the definition of a system as consisting of
the product and its support, with the objective to make the latter as small as possible.
The logistics of the system has to be closely incorporated into the design effort
throughout the system's life cycle, which makes the actual designers the best people
to manage the logistics engineering effort. A separate department for logistics is
therefore quite illogical.

3.6.1 Logistics system engineering

44
LGE401I/501

The support requirements should be considered an inherent part of the overall


system engineering process. The functions and tasks of system engineering should
be applied in the development of the logistics support system as follows (note that the
functions are not necessarily chronological and that they may take place in different
sequences).

[Link] Analysis

The following should be analysed:

• The intended use of the system (use studies), that is environmental studies to
arrive at an optimal logistics solution. Factors such as how and by whom the
system will be used and how long operational periods will be have a
determining influence on both the design and the logistics.
• Alternative support concepts for the prime mission equipment. For example,
designing the system with sufficient support systems to make failure
impossible (alternative 1), designing in test systems to enable repair on site
(alternative 2), transporting failed systems to the warehouse where repair
takes place (alternative 3), or replacing and discarding failed systems (in other
words, not attempting to repair them at all) (alternative 4).
• The prime mission equipment design, with the objective of influencing the
design to minimise the logistics part of the total system.
• The prime mission equipment design to determine logistics requirements (the
logistics support requirements, criteria and restrictions).

45
LGE401I/501

[Link] Results

The following result from the above analysis:

• the support concept (to be discussed in more detail later)


• the specifications (including drawings and documentation that states, among
other things, the intended system configuration, the required format of manuals
and how the logistics support analysis is to be performed.
• the definition of the available resources

[Link] Integration

The function of integration in the system engineering process takes place on three
levels:

1) Integration of the prime mission equipment design with the support elements.
This seems like common sense, but all too often a tremendous support system
is designed without taking the prime mission equipment, its use, et cetera into
account – resulting in incompatibility of some degree. Very often, this is merely
the result of a lack of configuration management.
2) Integration of the support elements with each other – ensuring compatibility of
technology and people, et cetera.
3) Integration of the system with the intended operating environment (the people,
et cetera).

[Link] Verification

This function ensures that the delivered system looks like the one that has been
designed and adheres to the requirements.

46
LGE401I/501

3.7 The role of the logistics system analysis process

Logistics system analysis can be considered the means to achieve the objectives of
the system engineering process. The reason why this effort is necessary, is to

• ensure that the support is integrated into the prime mission equipment design
• define support requirements that are consistent with the prime mission,
equipment objectives and design
• define support requirements that are consistent with each other

From the above (on which we focus primarily) follows:

• the design and development of support elements (the detail design of each
support element normally constitutes a specialist field – these are beyond the
scope of this module)
• the acquisition of the support resources
• the provision of the required support

We may summarise the primary objectives of the logistics system analysis


process as follows:

• influencing the design


• determining the detailed logistics requirements
• defining the resources for the support of the prime mission equipment

The logistics system analysis lays the foundation for the configuration management of
the support system and for providing traceability of the support design. It is important
to understand that configuration management should be applied to the total system,
including logistics (in other words, a hardware breakdown structure, baselines, et
cetera should also be compiled for the total system and proper change management
should be done). The reason why it should be considered of equal importance is
because any changes on the prime mission equipment will inevitably lead to changes

47
LGE401I/501

in the support system (and vice versa). Mostly, small changes in the prime mission
equipment design leads to large changes in the logistics system.

3.8 Logistics activities in the life cycle of the system

Figure 3.1 below gives an overall picture of the integrated logistics development
process and how this fits into the life cycle of the system.

Figure 3.2 above shows how the outputs of the logistics engineering process fit into
the life cycle (the production and operations and also the support phases of the life
cycle are not shown here; they follow the production phase).

This figure essentially shows the configuration and baseline management process.
The purpose of this process is to keep close track of the development efforts (not
making the same mistakes again) and to know what the system and its support look
like at any point in time. A lack in this field is the reason for innumerable (and
unbelievable) tales of frustration. For example: A military missile is designed and the
prototype is successfully launched under standing ovation. When the decision is
made to produce more of the missiles for operational purposes, everyone realises
with shock that the prototype that was fired has not been documented property and

48
LGE401I/501

therefore it is quite impossible to duplicate! The only record of the configuration has
gone up in flames and months of engineering effort literally and figuratively has gone
up with it in the air.

Each phase is based on the output of the previous phase. The output of a phase can
be a development model (like a wooden model or a computer simulation) with a
proper set of documents or merely a set of documents. At the end of each phase, a
set of specifications are "fixed" as a “baseline”. (This represents the final choices of
the previous design phase.) The model can never constitute a baseline; every design
aspect has to be properly and fully documented.

The following are a few of the activities that take place in the various phases of the
life cycle.

3.8.1 The concept exploration phase

During this phase, the user requirement statement (for the prime mission system) and
the support requirement (for the support system) are used as input to generate
alternative prime mission and support system concept designs. Trade-offs are made
to choose the most desirable concept. The prime mission system concept should be
chosen along with the support concept, and not sequentially. (One prime mission
system concept and three alternative support concepts are considered three
alternatives). The emphasis in this phase should be on the system as a whole and
care should be taken not to get into too much detail of the subsystem and component
levels of the system.

In cases where the product is an unknown or a totally new one, a formal functional
analysis can be done. This is a process whereby the functions to be accomplished
by the system are hierarchically broken down and serves as an input to the design
process. In most cases, however, a formal functional analysis is unnecessary and is
replaced by the common sense of the designers.
The outputs of this phase are a formal "A"-specification (the system specification) and
a chosen system support concept.

49
LGE401I/501

3.8.2 The demonstration and validation phase

During this phase, hardware is allocated to all the required functions that have been
determined in the previous phases (for each function that the system has to perform,
a piece of hardware is logically required to do it.) If no functional analysis was done,
hardware components are chosen or designed based on the experience of the
designers.

The feasibility of the system should now be proved, in other words: is it possible to
design the system to have ability, availability and affordability? During this phase,
only the high-risk areas of the design are demonstrated.

During the demonstration and validation phase, detailed support concepts for the
chosen hardware items are generated (now also on the levels below system level),
which is (as you will see later) the first phase of the logistics support analysis. These
detailed support concepts also serve as a means to influence the design. The
objective, again, is to improve the prime mission equipment design in order to
minimise the support that is necessary. This is also the last chance to influence the
design.

3.8.3 The full-scale development phase

In this phase detail design and development take place and logistics resources (all
the logistics elements) are determined and developed. You will see later in the
module that this is actually the second phase of the logistics support analysis. All the
system elements are qualified before proceeding with the industrialisation phase.

3.8.4 The industrialisation phase

In this phase the system is made ready for operation or production, and the logistics
support for the remaining life-cycle phases is finalised. The actual production or
operation planning is carried out as well as planning for maintenance in the remaining
life-cycle phases, and the related personnel (end user) training is done. Remember,
the logistics support system should be commissioned along with the prime mission
50
LGE401I/501

system elements. (Everything concerning the logistics should be in place when this
phase is completed, that is the logistics must have been commissioned.)

3.8.5 The production phase

In this phase the total system is produced and delivered. What is important in this
phase is providing transition support. Transition support is when the supplier provides
the help (in whatever form) that is required by the user to start to use the new system.
The system may fail even in this phase.

3.8.6 The operations and support phase

In this phase the system is used and supported. The system (including its support
elements) is modified and upgraded, and the whole development process takes place
again. Logically, the tasks of configuration management and baseline management
continue. It should be stressed, once again, that modification activities are very
expensive in this phase in comparison to the same changes early in the life cycle.
Here a change or modification involves not only documentation and design effort as
would have been the case earlier, but also actual hardware that has been produced.
Failure data is collected, failures are analysed and corrective action is taken.
Maintenance is carried out, as well as maintenance management. Technical support
of system elements takes place. There may even be a necessity to retrain personnel.

Supply support (on both the side of the user and the side of the supplier) is provided
and managed. This includes acquisition, inventory management and distribution, and
the management of all spare parts.

In this phase tasks and management activities relating to the quality assurance of the
system and its support are also performed, and materials handling and facilities
management take place.

3.9 The documents used in the logistics management process

51
LGE401I/501

There are essentially three sets of documents that are used in the logistics
development process, namely:

1) management documentation (which focuses on the people and what they have
to do)
2) technical elements documentation (the specifications of the system), and
3) deliverable documentation (manuals and the like)

The first set, the managerial documentation, tends to change quite often during the
life cycle because of changes in the managerial process (as discussed earlier). The
second set, namely the technical set, usually stays relatively constant after it has
been developed. The third set changes due to configuration management activities
that result in changes to the prime mission equipment and the support elements.

We briefly discuss the most important managerial and technical documentation.

52
LGE401I/501

3.9.1 Logistics management documentation

[Link] The integrated logistics support plan

This document describes the integrated logistics support strategy that will be followed
and provides the what, when, who, how much, et cetera inputs of the logistics
development process. Stated plainly, it describes everything that should be done in
the development of logistics.

The integrated logistics support plan includes the following:

• the requirements for logistics support and the design thereof (the technical
information required for maintenance planning)
• planning and managerial aspects pertaining to the integrated logistics support
system (for example, a breakdown of the logistics tasks to be performed or a
work breakdown structure)
• inputs and outputs for each task to be performed (that is, a statement of work).
• the various logistics element plans (see the next section)

[Link] Logistics element plans

Specific logistics activities and element plans should be developed either as part of
the integrated logistics support plan or as separate documents. These element plans
are equivalent to the overall integrated logistics support plan (which is focused on the
system as a whole), but they are focused on the specific elements and activities of
the logistics support system.

A separate document can be compiled for each support element or it can be


integrated into the overall plan, depending on the size and complexity of the system
that is being developed. All the element plans should be integrated with the higher-
level plan.

3.9.2 Technical logistics documentation

53
LGE401I/501

These documents describe the technical aspects (the system); whereas the
documents that we described in the previous sections describe the managerial
aspects. In the previous sections, we focused on the process of arriving at a logistics
support system; whereas the technical documentation describe or specify the
logistics support system that results from this process.

The most important documentation here are the support concept, the logistics support
analysis and logistics support analysis record (LSAR) specifications, and the logistics
element specifications (types A and B).

[Link] The system operation and support concept

This documentation has to be developed during the earliest phases of the life cycle
and should evolve with the development of the other system elements. This concept
addresses the operation and support concept on a system level (for the system as a
whole) and may be included as part of the "A" specification (the system specification).
In other words, it describes the total integrated logistics support system as it will be
applied, during the operational and the support phases, to the system that is being
developed.

The system operation and support concept consists of the following:

• a use/utilisation profile (how the system will be used, the environment in


which the operations and maintenance will take place, et cetera)
• a maintenance concept (how the system will be maintained, levels of support,
major elements of logistics support, effectiveness requirements, maintenance
environment, et cetera)
• a maintenance management concept ( how the maintenance will be managed,
responsibilities for maintenance, et cetera)
• a supply support concept (how spare parts and other support elements will be
provided to the system, distribution channels, et cetera)
• repair and maintenance policies and constraints (policies on how

54
LGE401I/501

subsystems on lower levels will be maintained, in other words levels of


support, repair policies that are applicable and the like)

It should be stressed that the above concepts should be specified in generic terms for
the logistics system as a whole and care should be taken not to get into too much
detail of the logistics support elements here.

We discuss the support concept in a little more detail later in this module.

[Link] The logistics support analysis and logistics support analysis record
specifications

These plans or specifications consist of a technical set of documents in which the


following are described in generic terms (on system level):

1) How the logistics support analysis will be carried out (how, by whom, the
process, the objectives, et cetera).
2) How the format of the output (the logistics support analysis record) should look.
This includes, among other aspects, specification of
• the relevant data elements to be documented
• how the results will be documented, for example the specification of a data
handling system to support the –logistics support analysis (like a
computerised system to handle great volumes of data)
• how the logistics support analysis data will be integrated
3) How the logistics system analysis and the relevant data will be verified and the
criteria for acceptance (or rejection) thereof.

[Link] The logistics element specifications

These specifications can be included in the "A" and "B" specifications of the total
system, or they can be compiled as separate documents.

55
LGE401I/501

Refer to MIL-STD 490A for the format of the "A" and "B" specifications (not for
examination purposes) and a more detailed discussion on when in the life cycle the
different specifications are developed.

While the system support concept describes the logistics system as a whole in a
CONCEPTUAL format, the logistics element specifications addresses each of the
actual support elements. (Refer back to study unit 2 for a short discussion on the
support elements.)

Each of the support elements is specified on the system level (in other words, the "A"
specification level) and then on the element level (in other words, the "B" specification
level). Examples:

In terms of documentation (which is a support element), the types of documents (a


list) and the format (fonts, paper and language) of a specific document will be
specified on the system ("A"-spec) level.
ORIn terms of the training of personnel, the training system as a whole will be
specified in generic terms on the system ("A"-spec) level, including the training itself
and training aids (how transparencies should look, et cetera).

On the system ("A"-spec) level, the following should be specified:

• the personnel who are involved in the logistics system


• the logistics facilities
• the training system
• the documentation (system)
• the materials handling and distribution (system)
• the packaging and marketing (system)

On the element ("B"-spec) level, the following should be specified:

• the training and training aids


• the tools and equipment

56
LGE401I/501

• the materials handling and distribution (element specific)


• the packaging and marketing (element specific)
• the documentation (element specific)
• the facilities

3.9.3 The documentation evolution process

To conclude our discussion on the logistics documentation, we briefly point out the
precedence in which the abovementioned documents are compiled and how the
logistics support analysis process fits into the whole process.

STUDY UNIT 4: PRELIMINARY ANALYSIS

Content

57
LGE401I/501

4.1 Overview
4.2 Study objectives
4.3 Learning outcomes
4.4 Source
4.5 Determining the requirements of the system
4.6 The system operations and support concept
4.6.1 Definition
4.6.2 Why compile an operations and support concept?
4.6.3 The use profile
4.6.4 The maintenance concept
[Link] The anticipated levels of support
[Link] The maintenance and repair policies/constraints
[Link] The supply support concept
[Link] The maintenance management concept
4.7 Summary

4.1 Overview

In this module we discuss the preliminary analysis of the logistics process. We


explain how to compile an operations and support concept (that is, the use profile and
58
LGE401I/501

the maintenance concept, which includes the anticipated levels of support, the
maintenance and repair policies, the maintenance management concept and the
supply support concept).

4.2 Study objectives

Our objectives with this study unit are to

• provide an in-depth overview of the preliminary analysis of the logistics


process
• explain the focus of the logistical engineering process during the requirements
phase of the system’s life cycle
• highlight the role of the operations and support concept in influencing design
• explain and demonstrate how to compile the use profile
• explain and demonstrate the maintenance concept

4.3 Learning outcomes

When you have completed this study unit, you should be able to

• discuss the logistics support analysis activities in the first phase of the life
cycle
• discuss the function of an operations and support concept
• compile a use profile for a simple system
• compile a maintenance concept that consists of at least the following:
– a level of support concept
– a maintenance and repair policy matrix and related descriptions
– a supply support concept
– a maintenance management concept

You should also be able to very briefly describe the anticipated levels of support of
any system of your choice. You will be required to refer to the levels of maintenance

59
LGE401I/501

and repair, and should give examples of typical tasks that should be carried out on
each support level. You will not be required to design the whole system in detail, but
should provide only enough information to illustrate that you understand and are able
to apply the concepts well. Remember that marks will only be given for applied
knowledge. You should therefore define all the concepts and refer to your system,
providing applicable examples throughout your answer.

4.4 Source

The information in this study unit is based on your prescribed book.

4.5 Determining the requirements of the system

The first step in arriving at a system configuration and an integrated logistics support
system is to determine the operational requirements of the system. From as early as
this phase (determining the system requirements), the logistics of the system should
be addressed. In other words, when the user requirements statement (URS) is
developed, the basic logistics support requirements should also be addressed.

We may summarise the process as follows:

60
LGE401I/501

In our discussion we consider the operational concept and system support concept as
a single document, namely the operations and support concept.

4.6 The system operations and support concept

In the previous study unit we briefly discussed the main documents that are used in
the logistics engineering process. These were divided into three categories, namely
logistics management documentation, logistics technical documentation and logistics
[Link] alpha of the logistic technical documentation is
the Operations and Support concept and we will devote most of this module
to the process of compiling such a document

4.6.1 Definition

The operations and support concept describes the intended operation of the system
and the integrated logistics support system of the total system (how the logistics

61
LGE401I/501

support system will be applied to the system during the operations and support phase
in the system's life cycle). From this concept, the logistics requirements for the design
of the system can be established, and the logistics support system (the logistics
specifications for the system) and a detail maintenance plan can be compiled.

You will recall from the previous study unit that the operations and support concept
consists of the following:

• the use profile (describes the intended use of the system)


• the maintenance concept
• the maintenance management concept
• the supply support concept (describes how the support will be provided to
the system)
• the maintenance and repair policies

4.6.2 Why compile an operations and support concept?

The operations and support concept has the following functions:

• It provides the foundation for the establishment of the support requirements


during prime mission equipment design. (It provides a basis against which
decisions can be made.)
• It provides the foundation for the design criteria of the logistics elements and
their interfaces with the prime mission equipment.
• It provides the foundation for the definition of the total (overhead) logistics
system.
• It provides the foundation for the development of the maintenance plan.

In other words: The operations and support concept provides the foundation for
integrating the support with the design of the prime mission equipment and the
environment. It ensures that all the design and support functions are directed toward
the same goal or mission.

62
LGE401I/501

4.6.3 The use profile

The use profile (or mission profile) is the first part of the operations and support
concept. The use profile should logically differ from one operational environment to
the next (or from one client to the next) in most cases. No two operational
environments of clients are the same in all aspects. One could therefore develop a
different logistics system for every client or environment, and no two systems should
look alike. In the use profile we would typically document a representative sample of
the possible use profile and when we develop the logistics system, take the worst one
(or two) into account.

The following is an example of a schematic layout of the mission profile of a


lawnmower:

4.6.4 The maintenance concept

The maintenance concept is the second part of the operations and support concept. It
is derived from the system’s operational requirements (user requirements statement)
and the mission profile (use profile). Any durable system and most relative expensive

63
LGE401I/501

systems have a maintenance concept. A non-durable item would typically be


discarded when failure occurs (in other words, it is a consumer item).

This is a very important part of the operations and support concept; it sets out the
following:

• the anticipated levels of support (that is, the levels of maintenance and repair)
• the overall repair and maintenance policies
• the applicable logistics (support) elements (facilities, people, et cetera) at each
level
• the maintenance environment
• the effectiveness criteria of or requirements for the support capability at each
level
• the organisational responsibilities for maintenance

In addition to the above, it is necessary to include a supplementary discussion of


each mission profile, stating how the system will be used and by whom, the
environment in which the system should operate, et cetera.

[Link] The anticipated levels of support

The support structure consists of a number of organisational levels where the


different support activities take place. Traditionally, in most systems, three levels are
sufficient because more than three levels make the system unnecessarily complex.

Firstly, you have to define the concepts of on-equipment and off-equipment


maintenance:

• On-equipment maintenance refers to a maintenance situation where the faulty


system component is repaired on the system itself. This could be by replacing
the faulty component with a new one or repairing the component by removing it,
repairing it on site and replacing it immediately. Whether it is a new or repaired
component that replaces the faulty one is irrelevant for the task; the main focus

64
LGE401I/501

is WHERE the replacement is done (for example replacing a worn-out cutting


blade on a lawnmower).
• Off-equipment maintenance refers to a maintenance situation where the faulty
system component is repaired away from the system. In other words, the
component is removed from the system, repaired elsewhere and then returned
to the system and replaced (for example removing the carburettor for repairs at
a service centre).

We will now discuss the maintenance levels:

1) Organisational level. This refers to the owner or end user of the system who
operates the system. Support tasks are performed on equipment by the
operator or maintenance crew. On this level, support resources are limited and
tasks are restricted to the elementary. The objective of organisational
maintenance is operational availability (the reason why the system exists).
2) Intermediate level. This could be a facility inside or outside of the end user
enterprise. The objective of intermediate maintenance is cost effectiveness.
Support tasks are performed by personnel who are more skilled than those at
the organisational level. There is a strong technical element in this
maintenance level (typically a workshop). Support tasks are performed both on
equipment and off equipment.
3) Depot level. This mostly refers to the supplier or manufacturer of the system,
but could also be part of the user organisation. Support tasks are complex and
require a concentration of highly skilled and specialised maintenance
personnel, as well as complex and specialised maintenance equipment. Lead
times are normally much longer than those for the previous two levels.

Two well-known examples of maintenance levels are:

1) For a motor vehicle. The organisational level would be the owner of the vehicle
and his garage. The intermediate level would be the dealer or even the
maintenance vehicles of the Automobile Association (in the case where the
owner is a member). The depot level would be the manufacturer of the vehicle

65
LGE401I/501

or an applicable specialist.
2) For a human being (who needs maintenance in case of illness). The
organisational level would be the first aid kit at home. The intermediate level
would be the pharmacy or general practitioner/dentist. The depot level would
be a medical specialist or the hospital.

[Link].1 An example of a level of support concept


If we return to our lawnmower example, we can depict the level of support concept
graphically as follows:

66
LGE401I/501

67
LGE401I/501

In addition to the above, it would be necessary to include a supplementary


discussion of each support level, the tasks to be accomplished at each level, by
whom, et cetera. For example, if we use the lawnmower example, it would be as
follows.

On the organisational level:

• periodic preventative maintenance tasks (for example cleaning the air filter)
• selective corrective maintenance tasks (for example repairing the electric lead
when it has accidentally been cut by person operating lawnmower)
• support tasks carried out in the garage facility or where the lawnmower is
stored
• functional tests done mostly during inspection while the lawnmower is in
operation by the person operating the lawnmower or the supervisor
• maximum downtime = 15 minutes

On the intermediate level:

• corrective maintenance tasks done by replacing components or sub-


assemblies; few corrective maintenance tasks are carried out on the
component level
• periodic preventative maintenance tasks (for example servicing the lawnmower
in winter time)
• support for the organisational level (for example spare parts and information)
• support tasks carried out in the workshop facility of the lawnmower dealer
• maximum downtime = two days
• maximum duration of individual tasks = 15 minutes

On the depot level:

• corrective maintenance tasks on the component level (and in certain


complex cases on the system level)

68
LGE401I/501

• support for the organisational and intermediate levels (for example spare parts
and information)

The above is merely an example to illustrate the concepts. In practice, the


maintenance concept would contain much more detail. Also, note that each of the
above specifications leads to requirements for the design of both the prime mission
equipment and the support system.

REMARK: In most cases the operator does not carry out the actual technical support
tasks, except where the operator is specified to be a technical person. In this case, a
specification document will have to be compiled where it is specified that the operator
should have a certain technical background. Additional resources would then be
necessary (for example tools) and, logically, there would be additional requirements
for the design of both the prime mission equipment and the support system.

[Link] The maintenance and repair policies/constraints

In this part of the operations and support concept the maintenance and repair
activities per logistics support analysis candidate are described. (Logistical support
analysis candidate is name of any component or subsystem or system on which
some maintenance will be done.) In this document “goals for equipment design in
terms of what is repairable and what is not, and the level of maintenance at which
repair is accomplished" are established. In all cases, the cost of unit disposal and
spares (in case of a non-repairable item) should be weighed against the costs of the
necessary logistics support if the unit was designed as repairable.

A standard way of documenting the maintenance and repair policies is by using the
maintenance and repair policy matrix developed by PJ Pretorius.
We will briefly look at this matrix because it is an easy and logical way of compiling a
concept of maintenance and repair policies/constraints; however, before we do this,
we first have to define a concept that is used in the matrix.

[Link].1 The concept “phantom”

69
LGE401I/501

A phantom is a superficial level that is inserted into the bill of materials or the
hardware breakdown of the logistical analysis of a system for simplification purposes.

Consider the following section of a bill of material:

Say, for example, that subsystem 1.3 has 10 possible ways of failure, and all of these
require a remove and replace repair task (that is, the whole subsystem 1.3 is
removed and replaced by either a new or repaired subsystem, while the failed
subsystem is repaired elsewhere). Assume that subsystem 1.3 is fastened to the rest
of system by fallible bolts. (If the probabilities of failure of the fastening components
are low, they should be omitted from logistical analyses altogether.) We may now
introduce a phantom in the bill of materials, namely an entity that is called
"Subsystem 1.3 installed". This phantom part (here numbered as 1.3) then includes
the hardware component itself as well as the fastening components (the bolts).

Now, instead of having to identify 10 different failures for the subsystem on the
second level, we identify only one failure (for example a functional failure) and a
single repair task of remove and replace. On the next level, the phantom is again
broken down into the primary part (subsystem 1.3, which has now become 1.3.1) and
its fastening components, and the 10 failures that we mentioned earlier are then
documented on this lower level. The fastening components are automatically included
by introducing a phantom, and the logistics analysis and the resulting support are
noticeably simplified because the prime component and its fastening components are
treated as a single logistics support analysis candidate and a single store item
(instead of treating each of the fastening items as a separate item).

70
LGE401I/501

The consequence of introducing a phantom is that even though the maintenance


tasks may be of an off-equipment nature on the third level, on the second level (the
phantom) the support tasks will be of an on-equipment nature. You will remember
that the high-level maintenance takes place on the organisational level and that these
tasks should preferably be of an on-equipment nature. (The off-equipment tasks, for
example that of repairing the subsystem itself, move to the next or third level and
become the next level in the logistics support analysis – as you will see later in this
study guide.)

Furthermore, if subsystem 1.3 fails when the system is deployed in the field, it is
unnecessary either to send the whole system in for repair or to keep all the lower
level components parts at hand for each deployed system. By adding a phantom, the
subsystem is treated as a whole, even though it was not depicted as a whole in the
original bill of materials.

[Link].2 The maintenance and repair policy matrix

This document grows with the development of the system and each time a next level
is developed, the new level is documented on the matrix. Logically, the process starts
at system level and proceeds to subsystem level, then to the next level (the
component level), et cetera! Each time when a non-repairable item is encountered,
the process stops and the next level is therefore not documented in the logistics
support analysis process. Only the logistics support analysis candidates (the
repairable items) are included in this process.

71
LGE401I/501

We will now discuss each column of the matrix separately.

Column 1: Indent level (subsystem level)


This refers to the subsystem level (level 1, 2, 3, et cetera) of the item under
consideration in the bill of materials. (The compilation of a bill of materials is beyond
the scope of this module.)

Column 2: Part number and description


This refers to the unique number and description of the part under consideration.

Column 3: Hardware/Phantom
Here a statement is required of whether the part under consideration is a phantom or
an actual piece of hardware in the bill of materials.

Column 4: Functional check and failure identification


For the specific system part described in column 2, state the level of repair at which
the functionality will be checked and the failure will be identified and isolated. (Briefly
document the specific activities that are applicable here and by whom these activities
will be carried out.)

Column 5: Inspection
For the specific system part described in column 2, state the level of repair for the
inspection and service tasks. (Briefly document the specific activities that are
applicable here and by whom these activities will be carried out.)

Column 6: On equipment
In this column, state the level of repair for on-equipment maintenance.

Column 7: Remove and replace


In this column, state the level of repair for removing and replacing an item.

Column 8: Off equipment

72
LGE401I/501

In this column, state the level of repair for off-equipment maintenance. (This column
is applicable only for items that have been removed from the system.)

Column 9: Discard
In this column, state the level of repair where the discard decision of the item will be
made.

Note that columns 4 to 9 already represent a logistical design and serve as a first-
order design influence. The next four columns are used only when depot/industry
repair is required in any one of the previous columns. (It serves the purpose of
avoiding duplication of these expensive facilities in the field.)

Column 10: Clean room


This column is a tick list to indicate whether the part under consideration requires the
facility for support. The reason for this is to avoid costly duplication in the field.

Column 11: Special equipment


This column is a tick list to indicate whether the part under consideration requires
special equipment for support. The reason for this is to avoid costly duplication in the
field.

Column 12: Special skills


This column is a tick list to indicate whether the part under consideration requires
special personnel skills for support. The reason for this is to avoid costly duplication in
the field.

Column 13: High reliability


This column is a tick list to indicate whether the part under consideration has a high
reliability. (The fact that it fails infrequently does not justify setting up logistics apart
from what is available on the depot level.)

[Link] The supply support concept

73
LGE401I/501

In this part of the operations and support concept the distribution and mechanisms of
the supply support system are described. Supply support refers to the spare parts
and inventories that are necessary for the accomplishment of maintenance actions.
The type and quantity of spare parts to be purchased and stocked (also order
quantities and order periods) should be determined for each maintenance level.

This concept places the focus on a management system for the first time in the
design process, namely the management of everything that is kept in stores (in other
words, not the human element). You will remember that this encloses the primary
focus of business logistics.

The following is an explanation of typical information that is contained in the supply


support concept. This is merely to illustrate the point and should by no means be
considered complete.

Organisational level:

• Limited (expendable) spares (consisting of mostly inexpensive items and minor


components such as air filters and spark plugs) can be carried in the
operator’s facility. It remains the choice of the end user whether or not to carry
the spares.
• Spares are replenished as required by the operator/end user.
• Spares are replenished when the operator collects them personally from
lawnmower dealer.
• Repairable items beyond the repair capability of the operator and more
expensive items are sent to the lawnmower dealer for repair.
• Failed inexpensive items and minor components are disposed of by the
operator.

Intermediate level:

74
LGE401I/501

• Spares consist of inexpensive items and minor components (for example air
filters and spark plugs) as well as modular subassemblies of more complex
system parts (for example carburettors).
• Spares are replenished from the lawnmower producer by sending a light
delivery vehicle as and when required.
• Modular sub-assemblies of more complex system parts (for example
carburettors) are sent to the lawnmower producer for repair by sending a light
delivery vehicle as and when required.
• Irreparable items, failed inexpensive items, and minor components and items
beyond economic repair are disposed of.

Depot level:

• Spares for previous levels and all spares that are needed to perform industry
repairs are kept in the main depot.
• Irreparable items, failed inexpensive items, and minor components and items
beyond economic repair are disposed of.

REMARK: Note how the above influences design already. For example: on the
intermediate level, there has to be a way in which the lawnmower dealer can
distinguish between items that are beyond economic repair and those that are not. In
other words, checking points have to be designed into the system so that these items
(which are beyond economic repair) are not forwarded to the depot level, but
disposed of immediately.

75
LGE401I/501

[Link] The maintenance management concept

In this part of the operations and support concept the management of the support of
the system that is being developed is described.

The following is an example of typical information in the maintenance management


concept. This is merely to illustrate the point and should by no means be considered
complete.

User organisation:

• non-complex preventative maintenance tasks (if preferred by the user)


• non-complex corrective maintenance tasks (if preferred by the user)

Lawnmower dealer:

• preventative maintenance (for example services done on lawnmowers)


• corrective maintenance (remove and replace) to modular level and minor off-
equipment repairs
• routing of repairable modules to lawnmower producer
• procuring and distribution of supply items (for example spares) to users
• data recording of failures and corrective maintenance tasks

Lawnmower producer:

• major corrective maintenance to component level


• contracting, where applicable
• procuring and distribution of supply items (for example spares) and equipment
to dealers and users
• managing suppliers
• data recording of failures and corrective maintenance tasks
• obtaining and training personnel

76
LGE401I/501

4.7 Summary

We have now concluded our discussion on compiling the operations and support
concept, which is the first activity of the logistics engineering effort. We discussed the
two main sections of the operations and support concept, namely:

• the use profile, and


• the maintenance concept

We used examples to demonstrate the main sections of the maintenance concept,


namely:

• an analysis of the anticipated levels of support


• the maintenance and repair policies (documented in a maintenance and repair
policy matrix)
• the supply support concept
• the maintenance management concept

We have now concluded the requirements phase in the life cycle of a system. I n the
next study unit, we discuss logistics in the conceptual design phase of the system.

77
LGE401I/501

STUDY UNIT 5: CONCEPTUAL DESIGN

Content
5.1 Overview
5.2 Study objectives
5.3 Learning outcome
5.4 Source
5.5 Introduction
5.6 The measures of logistics
5.6.1 Reliability
[Link] Series networks
[Link] Parallel networks
5.6.2 Maintainability
5.6.3 Availability
[Link] The reliability, availability and maintainability analysis: An example
5.6.4 Cost
[Link] The time value of money: Present value
[Link] The time value of money: Future value
5.6.5 Dependability
5.6.6 Supply support factors
[Link] Inventory level and turnover
5.6.7 Test and support equipment factors
5.6.8 Organisational factors
5.6.9 Facility factors
5.6.10 Distribution and handling factors
5.6.11 Software factors
5.6.12 Effectiveness factors
5.7 Summary

78
LGE401I/501

5.1 Overview

In this study unit we discuss the translation of the system level requirements (the
output of study unit 4) into detailed qualitative and quantitative design requirements.
These activities take place during the design and development phase. The processes
that we cover in this study unit are that of functional analysis and requirements
allocation. We discuss the other logistics engineering activities, namely those of the
logistics support analysis, in the next study unit.

However, before we start our discussion, we take a brief look at the measures of
logistics. These are quantitative values that aid in the specification and evaluation of
the logistics support system.

5.2 Study objectives

Our objectives with this study unit are to

• provide an in-depth overview of the logistics activities during the conceptual


design phase
• explain and demonstrate how to use the measures of logistics
• explain and demonstrate the process of the translation at system level

We look at the detailed qualitative and quantitative design requirements by using


quantitative logistics measures, functional analysis and requirements allocation.

5.3 Learning outcomes

When you have completed this study unit, you should be able to

• apply the measures of logistics in simple applications (maintainability and


availability [RAM] analysis, et cetera)
• explain the principles of functional analysis
• explain the principles of requirements allocation

79
LGE401I/501

• explain the principles of the allocation of design criteria and how the criteria of
the higher level influence those of the lower levels
• list four ways in which the mean time to repair (MTTR) of a system may be
decreased
• list the ways the produce ability of a system can be increased
• list four ways in which the reliability of a system can be improved

5.4 Source

The information in this study unit is based on your prescribed book.

5.5 Introduction

The preliminary system design (conceptual design) begins with the system level
requirements that are documented in the A-specification (system level specification)
and the support concept documents. These system level requirements are translated
into detailed qualitative and quantitative design requirements through the processes
of functional analysis and requirements allocation. If we refer back to figure 3.1 in
study unit 3, we can now depict a more complete picture in figure 5.1 below:

80
LGE401I/501

81
LGE401I/501

5.6 The measures of logistics

Before we move on to the conceptual design process, we briefly discuss the


measures of logistics since you will encounter some of these calculations in your
prescribed book. Before we start, we have to stress that the more complex the
system becomes, the more difficult these calculations are and the less reliable their
answers! What is of far more value than lengthy calculations is the use of your
healthy logic in the design process.

Furthermore, it is our opinion that the designer who actually has the ability to design
to a specific value of reliability/maintainability/availability is yet to be born because
designers

• design with the objective of making reliability/maintainability as high as


possible and not to be an exact calculated value
• do not have complete control over all the reliability, maintainability and
availability factors of all the components in the designed system

Although we advise you not to attach too much value to the calculations, you should
however note they are of extreme value in the evaluation of the system after the
design and procurement are completed.

5.6.1 Reliability

Reliability (R) refers to the probability (or stated plainly, the fraction of the total time)
that a device/system will perform its purpose adequately (be in an adequate working
state) for the intended period of time under specified operating conditions. The most
important factor of reliability is the MEAN TIME BETWEEN FAILURES (MTBF). For
an item that will be discarded after failure (a user item), this will of course be called
the mean time to failure (MTTF), but it is essentially the same thing as the MTBF.

The reliability of a system can be increased in the following ways:

82
LGE401I/501

• By designing redundancy into the system (more components so that failure of


a certain component has no significant influence on the reliability of the whole
system). In other words: if one of the redundant components fail, the whole
system does not fail and merely a part of the system capability is lost. For
example: providing two or more gauges of a certain type in an aeroplane
cockpit instead of one; if either of the gauges malfunctions, the other can still
provide the information the pilot needs.
• By providing a standby system. This refers to providing an extra system that
automatically takes over when the first one fails. Typical examples are the
emergency light (or cat-eye) system in most modem buildings that activates as
soon as there is a total power failure and the emergency power supply system
(for example a diesel engine with a generator) in hospitals that takes over
when normal electrical power fails.
• By a better design. There are quite a lot of textbooks and literature on this
subject and because of the extreme width of this field, we do not attempt to
cover it in this module.
• By using better materials components.

The most important equations are:

R (t) = 1- F (t) the probability of the device being successful is the


probability of failure subtracted from 1 (in other words, if the probability of success is
25%, the probability of failure is 75% – logically!)

R (t) = e -λ -t the probability of the device being successful, assuming that


the time to failure is described by an exponential density function (the case where λ
[failure rate] is a constant and independent of time).
The failure rate of the device, assuming that the time
λ= 1/MTBF
to failure is described by an exponential density function (the case where λ is a
constant and independent of time). MTBF is the mean time between failures (see the
next paragraphs).
λ = Number of failures/Total operating hours:

83
LGE401I/501

The failure rate of any device where the number of failures may also be described by
(Mission time excl. downtime) a function of time.

[Link] Series networks

Two components (A and B) are in a series relationship when both of them are
required to be successful for system/device success. If either fails, the system/device
fails. We may depict this by a Venn diagram as follows:
RA = the probability of A being successful

RB = the probability of B being successful

Now, the probability of the whole system/device being successful is the probability of
A being successful AND B being successful (that is, the probability of the whole
system/device's success) is the shaded part of the Venn diagram.

Below (and could be depicted by RA R B)

84
LGE401I/501

The probability of the whole device being successful is the product of the
probabilities of success for the individual parts.

With all series systems, the failure rate of the system is calculated by simply adding
the failure rates of the (series) components.
Therefore, from R(t) =, it follows that:
The probability of the whole device being successful, assuming that the time to failure
of the constituent parts are described by the exponential density function ( the case
where all the failure rates of the constituent parts are constant and independent of
time)

[Link] Parallel networks

Two components (A and B) are in a parallel relationship when only one of them is
required to be successful for the system/device’s success. If one fails and the other
does not fail, the system/device does not fail. If both fail, the system/device fails. We
may depict this by a Venn diagram as follows:

85
LGE401I/501

Now, the probability of the whole system/device being successful is the probability of
A being successful OR B being successful (that is, the probability of the whole
system/device's success) is the shaded part of the Venn diagram below (and could

be depicted by RA R B).

The reason for subtracting the middle part of the Venn diagram (where A and B is
successful) is actually quite logical: Not to count it twice. If the RA and RB diagrams
did not overlap, it would of course not be necessary.

An easier way to derive the reliability of parallel systems (especially for more than two
components, as is the case below) is the following:

The probability of the whole system/device being unsuccessful is the probability of A


being unsuccessful, B being unsuccessful AND C being unsuccessful. This is the
shaded part of the Venn diagram below (the part outside the circles):

86
LGE401I/501

87
LGE401I/501

5.6.2 Maintainability

The maintainability of a system refers to the ease, accuracy, safety and economy
with which maintenance can be carried out on a system. We only discuss one of the
frequency factors of maintenance here, namely the MEAN TIME TO REPAIR
(MTTR). This refers to the time that elapses from when the system fails to when it
becomes fully operational again (In other words, we only discuss corrective
maintenance here). You will notice that the author of your prescribed book
(Blanchard) calls this parameter “mean corrective maintenance time (Mct). We
use the more conventional term “mean time to repair”.

The mean time to repair of a system can be decreased by reducing

• the frequency of maintenance (the less it breaks, the better)


• logistics lead times
• administrative lead times (paperwork!)
• maintenance lead times (to do the physical repair or replace a task)

We discuss only the normal distribution since this illustrates the point. If you require
a more in-depth knowledge of the other distributions (because the normal distribution
is not always the appropriate one), you may study it further on your own.

The most important equations here are:

88
LGE401I/501

In your prescribed book (Normal distribution sample) the question is to find out what
percentage of the population (the percentage of the individual times to repair) lies
between 40 and 50 minutes. You have to calculate the area under the curve
between these values. Step (a) in your prescribed book: you could use the method
where the maintenance times of 40 and 50 minutes are "converted to standard
times". What is actually done here is the following:
The approximated probability distribution of the example that is given in your
prescribed book, as explained there, is a normal distribution with its mean (X)
calculated as 61,9. In other words:

89
LGE401I/501

To be able to calculate the required percentage (between 40 and 50 minutes), you


have to convert the above normal distribution to a standard normal distribution.
This refers to a normal distribution with a mean value (X) of zero.

When this is done, all the values change; therefore, the necessity to "convert the
values into standard values" (depicted by Z's). A value X is converted as follows:

Now "Z" represents the number of standard deviations ('s) that X1 and X2 fall above
(or below) the mean, X. The area under the curve can now simply be read from the
tables in your prescribed book – making difficult calculus unnecessary!
The most important equation here is the upper confidence limit for the normal
distribution:

90
LGE401I/501

The upper confidence limit is the value where the chance that the MTTR is above it
is x%, and x is called the risk level. In other words, the probability of the MTTR being
below the upper confidence level is (100-x) %, and this value is called the confidence
level.

When you work through the above, do not get confused between MTTR,MTBM and
MTBR.

Another important concept (which is not discussed by Blanchard) is the repair


rate:

5.6.3 Availability

Availability (A) refers to the probability of being found in the operating state at a
certain time t in the future, given that the system started in the operating state at time
t = 0.
This may seem very close to the definition of reliability, but the difference is the
following: Reliability (R) refers to the probability of staying in the operating state as a
function of time, given that the system started in the operating state at time t = 0.

91
LGE401I/501

Stated plainly, the reliability refers to when the system operates (that it will not
become inoperative); the availability refers to the chance that the system will be
ready for operation at a point in time.

There are three ways to measure availability; each of these reveals another facet of
the system’s availability:

(1) Inherent availability

This is the availability with no lead times taken into account; it is therefore a function
of the design only, thus assuming a perfect logistics system. In most cases the lead
times are not considered due to their unpredictability (even though they have the
greatest influence on the actual availability of the system!). The inherent availability
only takes into account the time that is taken to actually repair the system when it is
broken (in other words, only the corrective maintenance time).

(2) Achievable availability

This is the availability with no lead times taken into account (as is the case with
inherent availability, but achievable availability takes preventative maintenance into
account as well). The achievable availability is, as is the case with inherent
availability, a function of the design itself.

(3) Operational availability

92
LGE401I/501

This is the availability with lead times taken into account; it is therefore a function of
the system design and the logistics design. (Preventative and corrective
maintenance can be influenced only by changing the design of the prime mission
equipment itself; whereas lead times are influenced only by changing the logistics
design.) The problem with determining operational availability is the fact that lead
times are close to impossible to determine; one of the reasons why common sense
is often of more value than calculations!).

Because of the large influence of the lead time factors, this value is of a totally
different order than the other two.

Other important equations:

For Series systems:

[Link] The reliability, availability and maintainability analysis: Examples

93
LGE401I/501

The following are examples of performing a reliability, availability and


maintainability (RAM) analysis:

Example 1

Consider system XYZ, which has the following hardware breakdown


structure:

Subsystem 1

Component A Component B
Quantity: 1 Quantity: 2
 = 0,02 per hr  = 0,03 per hr
 = 0, 1 per hr  = 0, 05 per hr

Assume that in subsystem 1, component A AND either of the two


components of B have to work in order for subsystem 1 to be considered
successful. In other words, if EITHER component A OR BOTH of the
components of B fail, subsystem 1 fails.

Graphically:

B
A
B

We are now going to determine the availability, MTBF and MTTR for the whole
system XYZ.

Step 1: Consider the two parallel components of B in subsystem 1:

• The availability of each of the two parallel components of B:

94
LGE401I/501

 B = 0.03/hr, so that MTBFB = 1/ B = 1/0.03 = 33.333 hr


 B = 0.05/hr, so that MTTRB = 1/ B = 1/0.05 = 20 hrs
 AB = MTBFB / (MTBFB + MTTRB) = 33.333/ (33.333+20) =
0.625

• The combined availability of the two parallel components of B:


 A2B's = 1 - [(1-AB). (1-AB)] = 1 – [(1-0.625). (1-0.625)] = 0.859
375

• The combined failure rate of the two parallel components of B:


 MTBF2B's = 1/B + 1/B – 1/(2x B) = 1/33.333 + 1/33.333 –
1/(2x 33.333) = 49.999 999 hrs = 50 hrs
 2B's = 1/MTTF2B's = 1/ 49.999 999 = 0.02 per hr

• The combined repair rate of the two parallel components of B:


 A = MTBF / (MTBF + MTTR) so that MTTR = (MTBF/A) –
MTBF
 Now MTTR2B's = (MTBF2B's / A2B's ) - MTBF2B's
= (49.999 99/ 0.859 375) - 49.999 99
= 8.181818 hrs.

 2B's = 1/MTTR2B's = 1/ 8.181818 = 0.12222 per hr

Step 2: Consider the two series parts in subsystem 1 (A in series with 2


components of B'):

• The availability of the A-component:


 A = 0.02/hr, so that MTBFA = 1/ A = 1/0.02 = 50 hr
 A = 0.1/hr, so that MTTRA = 1/ A =1/0.1 = 10 hr
 AA = MTBFA / (MTBFA + MTTRA) = 50/ (50+10) = 0.833 333

• The combined availability of the two series parts (A and 2components of


B):

95
LGE401I/501

 AA&2B's = AA . A2B's = 0.833 333 x 0.859 375 = 0.716 146


= ASubsystem1

• The combined failure rate of the two series parts (A and 2 components
fo B):
 A&2B's = A + 2B's = 0.02 + 0.02 = 0.04 per hour = Subsystem1

 MTBFA&2B's = 1/A&2B's = 1/ 0.04 = 25 hrs = MTBFSubsystem1

• The combined repair rate of the two series parts (A and 2 components
of B):

 A = MTBF / (MTBF + MTTR) so that MTTR = (MTBF/A) –


MTBF

 Now MTTRA&2B's = (MTBFA&2B's / AA&2B's ) - MTBFA&2B's


= (25/0.716 146) - 25
= 9.909 083 = MTTRSubsystem1

 A&2B's = 1/MTTRA&2B's = 1/ 9.909 083 = 0.100 918 per hr


= Subsystem1

Example 2

An industrial control system consists of five modules: A, B, C, D and E.


The reliability of the modules are: A=0.95, B=0.90, C=0.85, D=0.95 and
E=0.80.

96
LGE401I/501

B C

A D

B C

B C

A D

B C

A B D

Calculate the reliability of each system:

97
LGE401I/501

A = RS = RA  ( RB + RB ) − ( RB  RB )   ( RC + RC ) − ( RC RC )   RD
RS = 0.95  ( 0.90 + 0.90 ) − ( 0.90  0.90 )   ( 0.85 + 0.85 ) − ( 0.85  0.85 )  0.95
= 0.873
B = RS = RA  ( RB RC ) + ( RB RC )  − ( RB RC )  ( RB RC )   RD
= 0.95  ( 0.765 ) + ( 0.765 )  − ( 0.765 )  ( 0.765 )   0.95
= 0.853
C = RB ( RC + RC ) − ( RC  RC )  = 0.88
RBCC = ( 0.88 + 08 ) − ( 0.88 )( 0.8 )  = 0.976
RS = RA  RBCC  RD
= 0.95  0.976  0.95 = 0.88

Example 3

As the logistics engineer at a vehicle manufacturing company, you were assigned to


the task team that is responsible for the development of a new light delivery van
called the Fetch-it. The vehicle is likely to be driven an average of 100 000 km per
year, for five (5) years, during normal business hours per day. The mean kilometres
between corrective maintenance events is projected to be 20 000 km, while the
between preventative maintenance events is planned at 10 000 km. The average
duration to perform a corrective maintenance action is estimated at 16 hours and the
predicted mean preventative maintenance time is eight hours.

What is the vehicle's expected mean kilometres between maintenance events,


inherent availability and achieved availability?

98
LGE401I/501

5.6.4 Cost

This is most certainly the most tangible of the measures of logistics. It refers to the
costs associated with the actual maintenance, inventories, equipment, personnel,
facilities, et cetera of the total support system.

99
LGE401I/501

A few of the important concepts pertaining to cost estimates are the following.

[Link] The time value of money: Present value

Present value (PV) calculations are used to convert future money values to today's
terms. They provide a method of expressing future cash flows in present Rand
terms, to enable decision makers to compare future cash flows on an equivalent
basis. Logically, the present value (or buying power) of tomorrow's money is less
than its numerical value. The principle works as follows:

Assume that the buying power of money decreases by 8% per year (in other words,
every year a Rand can buy 8% less than the previous year) and John lends Peter
R200 for a term of two years. If Peter repays John at the end of the second year with
the exact amount he borrowed (that is, R200), he would actually be repaying a lesser
amount (stated in terms of the buying power of the amount) than what he borrowed
because the R200 is worth less when John receives it back after two years. It would
therefore only be fair if John added 8% of the original amount per year to
compensate for this.

The actual amount that should be given back to John is actually R233,28:

R200 + (R200 x 8%) = R216, 00 (the value at the end of the first year) R216 + (R216
x 8%) = R233, 28 (the value at the end of the second year).

In other words, 8% is added to the original amount to compensate for the loss of
value in the first year (Peter then actually owes R216,00) and then 8% is added on to
the new amount for compensation for the loss of value in the second year (Peter
then owes R233,28).

100
LGE401I/501

The present value of money (R200,00) therefore has to be multiplied by a certain


factor (which in this case is 1,1664) to determine its future value (R233,28). (John
then actually provides a loan of R200 at an interest rate of 8% per year.)

Any amount which is given in its future value can be multiplied by a certain factor
(that is, the value in the rectangular brackets in the above equation) to determine its
present value (in other words, its value in present buying terms).

This process is called discounting of money, and we say that we discount a future
amount to determine its present value. The factor that is used to multiply the future
value with to arrive at the present value is called a discounting factor and the interest
rate that is used is called the discounting rate.

In John and Peter's case, we can refer to appendix F and read off the factor by going
to the 8% table (Table F-3), the n = 2 row (the money is borrowed for two years at
8%) and the "to find F, given P" column. The factor is given as 1,166 – the same as
we calculated above.

101
LGE401I/501

[Link] The time value of money: Future value

If the future value of an amount is known, the present value can also be calculated
by multiplying the future amount by a certain factor. Say, for example, that after John
and Peter have a discussion about the present and future value of money, Peter
says that the absolute maximum that he would be able to pay back to John after two
years would be R210. What amount should John be willing to lend him without losing
any buying value?
Here the future value of the amount is given, namely R210, and the present value is
required. We can calculate this as follows:

(Say RY is the present value of the amount, in other words the amount John should
be willing to lend at present)
RY + (RY x 8%) = R YYY (the value at the end of the first year)
RYYY + (RYYYx 8%) = R210, 00 (the value at the end of the second year)

Or:
RY x 1, 08 x 1, 08 = RYx 1.1664 R = R210, 00 (as before), from which it follows that
RY = R210, 00 x (1/1.1664)
= R210, 00 x 0.85734
= R180, 04

Here the future value of money (R210,00) has to be multiplied by a certain factor
(which in this case is 0.85734) to determine its present value (R180,04). We can
again refer to appendix F and read off the factor by going to the 8% table (Table F-3
on page 518), the n = 2 row (the money is borrowed for two years at 8%) and the "to
find P, given F" column. The factor is given as 0.8573 – the same as we calculated
above.

102
LGE401I/501

A common mistake here is to assign the availability costs to time units (hours). For
example:

If the total maintenance time of a system is 200 hours per month and the cost of the
maintenance facility (say R500 000) is averaged between these hours, the unit cost
amounts to R500 000 / 200, which amounts to R2500 per hour (considered a "good"
maintenance system due to low hourly costs)

BUT if the total maintenance hours is 10 hours per month for the same system and
the same maintenance actions, the unit cost amounts to R200000 / 10, which
amounts to R20 000 per hour!

The second system could be considered "bad" when we compare the two on a unit
cost basis, even though the system was available a whole lot more! The reasoning,
as you could easily see, defeats the purpose totally.

5.6.5 Dependability

This refers to the probability that the system will complete its mission given that it is
in working order at the start of its mission.

Modelling is a powerful vehicle for determining this measure. The problem here is
that users cannot be modelled because each user (the human factor) applies the
system uniquely to some extent. Just think of the difference in fuel consumption that
is achieved by different users who drive the same model car!

103
LGE401I/501

5.6.6 Supply support factors

These include:

• The probability of success with x spares available. The question here is that of
the probability of success for a certain configuration if a given amount of spares
is kept in stock.
• The probability of being out of stock. Stock is kept to minimise risks. All too
often though, the high levels of stock that are kept cannot be adequately
verified by the probable risks. Too high stock levels, though, is never a cause in
itself but a result of something else: bad predictions, unreliable suppliers, et
cetera.

The problem of too high stock levels is that it leads to too long turnover times, which
in turn leads to a cash cycle that is too long (cash is tied up unnecessary). This
brings us to the next measure:

[Link] Inventory level and turnover

This is a very good measure of the logistics system: The higher the inventory
turnover (and the lower the inventory level, logically!), the better the logistics system
design.

You may ask that considering the (unreliable) suppliers you encountered at your
enterprise, how this is practical at all. The answer to this is somewhat theoretical in
nature: The supplier should be viewed as part of the enterprise and not as its
opponent. There is an increase tendency towards this view worldwide, and it is the
only workable option when moving towards a JIT system.

104
LGE401I/501

5.6.7 Test and support equipment factors

The general category of test and support equipment may include a wide spectrum of
items, such as precision electronic test equipment, mechanical test equipment,
ground handling equipment, special jigs and fixtures, and maintenance stands.
These items, in varying configurations and mixes, may be assigned to different
maintenance locations and geographically dispersed throughout the country (or
world). However, regardless of their nature and application, the objective is to
provide the right item for the job that is intended at the proper location and in the
quantity required.

5.6.8 Organisational factors

The measures associated with maintenance organisation are basically the same as
the factors that are typically to any organisation. Factors that are of particular interest
relative to logistics support are:

• The direct maintenance labour time for each personnel category or skill level
expended in the performance of system maintenance activities. Labour time
may be broken down to cover both unscheduled and scheduled maintenance
individually. It may be expressed as:
– maintenance man-hours per system operating hour (MMH/OH)
– maintenance man-hours per mission cycle (or segment of a mission)
– maintenance man-hours per month (MMH/month)
– maintenance man-hours per maintenance action (MMH/MA)
• The indirect labour time required to support system maintenance activities
(that is, overhead factor).
• The personnel attrition rate or turnover rate (percentage).
• The personnel training rate or the worker-days of formal training per year of
system operation and support.
• The number of maintenance work orders processed per unit of time (for
example week, month or year) and the average time that is required for work-
order processing.

105
LGE401I/501

• The average administrative delay time, or the average time from when an item
is initially received for maintenance to the point when active maintenance on
the item actually begins.

5.6.9 Facility factors

Facilities are required to support the activities for accomplishing the active
maintenance tasks, providing warehousing functions for spares and repair parts,
conducting training, and providing housing for related administrative functions.

Facilities are for

• accomplishing the actual maintenance tasks


• warehousing spares, et cetera
• training
• administration

REMARK: When you consider the utilisation of these facilities, remember the
following:

• If the utilisation of these facilities is high; it could mean that the system is out
of order too often (unreliable).
• If the utilisation is low, it may be an indication that the logistics part of the
system has been over-designed. (Of course, by the time this can be
measured, it is too late to influence the design!)
• A general principle here, with reference to the Elijah Goldrat range of books,
is that only the bottlenecks should be utilised 100%.

106
LGE401I/501

5.6.10 Distribution and handling factors

When evaluating the effectiveness of transportation, one must deal with factors such
as:

• Transportation route(s). In a country, between a country and other countries,


the number of nationalities involved, customs requirements, policies,
procedures, legal factors, et cetera.
• Transportation capacity or capability. For example, transportation modes,
volume of goods transported, quantity of items transported, distance, zones,
ton–miles per year transported, and quantity of car loads or truck loads.
• Transportation time. For example, short-haul time and mean transportation
time. This factor is, of course, significant, particularly because it applies to the
delivery of personnel, spare parts and related resources to support
maintenance activities.
• Transportation cost. For example, cost per shipment, cost of transportation
per carrier per mile, cost of packing and handling, and transportation and
handling cost per year.

5.6.11 Software factors

For many systems, software has become a major element of support. This is
particularly true where automation, computer applications, digital database and the
like are used to accomplish maintenance and logistics functions. Software may be
evaluated in terms of language levels or complexity, the number of program length
on the basis of the number of sources code lines, cost per maintenance subroutine
or something of a comparable nature.

107
LGE401I/501

5.6.12 Effectiveness factors

The aspect of effectiveness that is introduced in chapter 1 of your prescribed book


can be quantified in terms of one or more figures of merit (FOMs), depending on the
specific mission or system characteristics that one wishes to specify and measure.

The following should be considered in terms of effectiveness:

• system performance and physical parameters: capacity, delivery rate, power


output, range, accuracy, volume, speed, weight, et cetera
• system operations and support factors: availability, dependability, capability,
operational readiness, reliability, maintainability, manageability, supportability,
transportability, producibility, et cetera
• total life-cycle cost: research and development cost, production/construction
cost, operation and maintenance cost, retirement and disposal cost, et cetera

Establishing a relationship between a performance or operational parameter and


cost may constitute desirable cost-effectiveness (FOM). Other relationship may be
equally as important. Some examples FOM are:

• Effectiveness FOM = availability/life - cycle cost


• Effectiveness FOM = reliability/ life - cycle cost
• Effectiveness FOM = system capacity/range
• Effectiveness FOM = supportability/life - cycle cost
• Effectiveness FOM = life - cycle cost/facility space or other

108
LGE401I/501

5.7 Summary

In this study unit we provided supplementary discussions on the logistics engineering


activities in the design and development phase which are discussed in the
prescribed book.

109
LGE401I/501

STUDY UNIT 6: LOGISTICS SUPPORT ANALYSIS

Content
6.1 Overview
6.2 Study objectives
6.3 Learning outcomes
6.4 Source
6.5 Definition
6.6 The purpose of the logistics support analysis
6.6.1 Early design phases: Influencing the design
[Link] Design influence relating to reliability
[Link] Design influence relating to maintainability
[Link] Design influence relating to human factors
[Link] Design influence relating to manufacturability
[Link] Design influence relating to quality and safety
[Link] Design influence relating to economic feasibility
[Link] Design influence relating to supportability
6.6.2 Later design phases: Determining the detailed logistics requirements
6.7 The logistics support analysis process
6.7.1 Design influence and compilation of the support concept
6.7.2 Identification of logistics support analysis candidates
6.7.3 Development of logistics support analysis candidate support concepts
6.7.4 Conducting a failure mode, effects and criticality analysis
[Link] Analysing the failure mode
[Link] Analysing the effect of the failure
[Link] Analysing the criticality of the failure
[Link] Further aspects to consider
[Link] Documenting the results of the failure mode, effects and criticality
analysis
6.7.5 The reliability-centred maintenance process
6.7.6 Designing maintenance tasks
6.7.7 Defining resources for maintenance tasks
6.8 American military standards applicable to the logistics support analysis
6.9 Conclusion
110
LGE401I/501

6.1 Overview

In this study unit we discuss the rest of the logistics engineering activities in the
design phase, namely the logistics support analysis. We look at the two main
purposes of the logistics support analysis ( influencing design and determining
detailed logistics requirements). We also look briefly at the logistics support analysis
process and techniques that aid in this process.

6.2 Study objectives

Our objectives with this study unit are to

• provide an in-depth overview of the logistical support analysis process


• explain the purpose of the logistics support analysis
• explain the role of the logistics support analysis in influencing design
• explain the role of the logistics support analysis in determining the detailed
logistics requirements
• explain the process and techniques of logistics system analysis
• give you a clear understanding of the logistics support analysis process and
its related techniques

6.3 Learning outcomes

When you have completed this study unit, you should be able to

• discuss the purpose of the logistics support analysis process during the
design phases
• discuss the role of logistics support analysis in influencing design
• discuss the role of logistics support analysis in determining the detailed
logistics requirements
• apply the logistics support analysis process in simple applications (FMECA,
RCM, et cetera)
• explain on which areas you would focus when you collaborate with the design

111
LGE401I/501

team during the early design phases


• list the advantages of the standardisation of components (or assemblies)
• name the different resources that can be specified for every maintenance task
• define “criticality” and explain how a criticality matrix is drafted

In addition, you should be able to answer the following questions when you perform
a failure mode, effects and criticality analysis (FMECA):

• What criteria can you use to determine the criticality of the impact of each
possible failure?
• What actions can you recommend as a result of the impact of each failure?
• In what ways can the producibility of the system be increased?

6.4 Source

The information in this study unit is based on your prescribed book.

112
LGE401I/501

6.5 Definition

The logistics support analysis is an iterative analytical process whereby the logistics
support that is necessary for the system is identified and evaluated.

6.6 The purpose of the logistics support analysis

In the early design phases, the logistics support analysis is primarily aimed at
influencing the design; whereas in the latter design phases, the objective is to
determine the detailed logistics requirements (to identify logistics support resources).

6.6.1 Early design phases: Influencing the design

Initially, the logistics support analysis aids in the first efforts of determining logistical
support criteria as an input to the system design.

To be able to influence the design, it is critical to understand what the logistical


environment looks like (the characteristics of the logistics environment) and what
the logistics characteristics of the design are (logically). (By logistics
characteristics, we primarily refer to the reliability and maintainability of the design.)
These characteristics are a direct consequence of the design and if the values are
unacceptable, the design has to be revised (in other words, influencing design!)

The logistics support analysis is the vehicle for understanding the above in order to
be able to improve the design in terms of the capability and availability of the system.

The prime objectives of influencing the design are to

• improve the integration of system elements


• improve system capability and reliability
• reduce life- cycle costs

113
LGE401I/501

The design can be influenced with respect to the following factors: reliability,
maintainability, human factors, manufacturability, quality, economic feasibility and
safety. There are several methods or techniques that can be used for each of these
factors.

[Link] Design influence relating to reliability

(1) Reliability predictions, modelling and allocation

The reliability, availability and maintainability analysis and the allocation of


reliabilities can be used for design influence purposes. These techniques indicate
where redesign is necessary due to reliability that is too low. As discussed earlier,
the extensive calculations that are necessary for these methods are often close to
meaningless from the designer's perspective (he or she does not design to a certain
value, but attempts to make the design as reliable as possible). Nevertheless, they
could indicate problem areas in this regard. Economics plays a significant role in
answering the question "How far do we go?"

Other problems regarding modelling are:

• the high costs associated with constructing models that are representative
• tests are often conducted in laboratory circumstances, which of course is not
truly representative of the actual operating environment (when modelling, the
end user and the user environment should be simulated, for example the
educational level of the operator should be kept in mind)

By this, we are not implying that laboratory tests are of no value; they provide a
valuable basis for comparing systems/components.

Remember, healthy logic is worth more than a thousand calculations!

(2) Component selection

114
LGE401I/501

This refers to

• selecting and applying components, preferably standard ones


(standardisation)
• selecting and applying components of the highest possible reliability, and
• using the most reliable suppliers

The standardisation of components (or assemblies) has several advantages, all of


which have a significant cost implication:

• The components are proven, with known characteristics and known quality.
• The number of parts and related support elements are reduced; less storage
space is necessary.
• The support elements, test requirements and maintenance procedures are all
standard.
• Configuration management is less complex.
• In most cases, alternative suppliers are available.

(3) Failure modes, effects and criticality analysis (FMECA)

During this an analysis, the possible failure modes of a device, the effects of the
failures on the device itself, and the environment and the criticality of the failure
modes are considered. By considering these aspects, it can be determined where
redesign is necessary. This analysis is an extremely useful tool that provides a
qualitative, rather than a quantitative, indication of problem areas.

(4) Critical useful life

When analysing this field, one should consider whether items that require
maintenance are reachable. This seems like common sense, but it too often
happens that the process has to reach an item that fails (and can be removed and
replaced in a few seconds), takes hours to reach (for example removing the engine
of a vehicle to change a small part), or can only be reached by a person who is one

115
LGE401I/501

metre tall and has 30-centimetre long fingers. The design should be considered in
this regard and revised to eliminate problems.

(5) Packaging, handling, storing and transporting

Components which are transported, handled or merely stored fail. (Even when lying
on a shelf, ageing takes place and failures occur.) This aspect has a surprisingly
high impact on the system reliability and should be taken into account in the design.

(6) Failure reporting, analysis and corrective action system (FRACAS)

A possible approach here is to consider a similar system (or a truly representative


model) in terms of its failures and to influence the design process thereby.

[Link] Design influence relating to maintainability

(1) Maintainability predictions, modelling and allocation

Refer to the discussion above on Reliability predictions, modelling and allocation.


The problems encountered here are the same ones.

(2) Comparative analysis and design review checklists

Comparative analysis refers to the consideration a similar system in operation (or a


truly representative model) in terms of its maintainability characteristics (and
shortcomings) and to influence the design process of the new system hereby.
Comparative analysis may be used to project supportability related parameters of the
new system/device and to judge the feasibility of its supportability.

(3) Failure modes, effects and criticality analysis and reliability-centred


maintenance)

Reliability-centred maintenance refers to a decision-making diagram which indicates


the type of preventative maintenance that is required. It is a powerful tool in the
116
LGE401I/501

design influencing process. For example, if the analysis indicates that a certain
assembly should be opened often for preventative maintenance purposes, it would
be wise to make the assembly very accessible and its housing easy to open (by, for
example, using a latch instead of a pair of bolts). Refer to the discussion on the
failure modes, effects and criticality analysis. By considering the failure modes, their
criticality and effects, valuable inputs can be provided to influence the design in
terms of maintenance.

[Link] Design influence relating to human factors

The consideration here is the capabilities of the person who is operating and
supporting the system in terms of

• mental abilities
• education
• ergonomic and physical capabilities and the like

[Link] Design influence relating to manufacturability

The design should also be reviewed to make it as producible as possible. This can
be accomplished by

• reducing the total number of components in the system


• using standard components which are easier to support (for example instead
of using four bolts of different sizes, use a standard size that requires a single
size spanner instead of four spanners in the logistics system)
• using standard production processes, which have already been proven
instead of new processes
• ensuring easy assembly/disassembly with as little as possible tools and steps

[Link] Design influence relating to quality and safety

117
LGE401I/501

A quality system refers to one that is successful in doing what it is supposed to do. In
other words, quality refers to simply meeting the requirements of the end user (doing
what it was acquired for). If there is a discrepancy between what the system does
and what the requirement is, the design should be revised.
Safety refers not only to safety with regard to human beings, but also with regard to
the environment and the system itself. This is most probably the most important
aspect that should be taken into account when designing and influencing design.

[Link] Design influence relating to economic feasibility

All the life-cycle costs are applicable and not only the acquisition cost.

[Link] Design influence relating to supportability

Logic is the designer's most powerful tool and when designing the most valuable
design influence, the designer should consider the following regarding the
components that require support:

• Can the part be reached to replace/repair it (is it accessible)?


• How will the operator know it has failed? (fault indication)
• How can the fault be isolated? (to determine which part causes the failure)
• Is the system/device adequately testable?
• With regard to the operator's capabilities, will he or she be able to interpret the
fault signals, et cetera?
• Have facility and equipment restrictions with regard to supportability been
considered?
• Has safety been considered adequately with regard to the system and its
environment, users, et cetera? ( making provision that in case of a failure,
further harm to the system is prevented, secondary failures, et cetera)

6.6.2 Later design phases: Determining the detailed logistics requirements

118
LGE401I/501

As we stated earlier, one of the objectives of the logistics support analysis is to aid in
determining the detailed logistics requirements for the later phases of the design.

This objective, as you will appreciate if you have first-hand experience of system
acquisition and operation, is easier attainable than influencing the design. The
detailed logistics requirements as such refer to all the physical entities and
management processes that are necessary to support the system, among others.
They include:

• supply support elements (type of spares, test and support equipment; how
packaging and marking will be done; consumables; et cetera)
• personnel aspects (skill levels, number of personnel, how the training will be
done, training aids, et cetera)
• transportation and handling (pallets, fork-lifters, et cetera)
• operational and maintenance facilities (overhead cranes, 3-phase electricity,
steam, et cetera)
• operational procedures
• maintenance (both preventative and corrective) procedures
• technical data (physical documents, computerised data, how data is to be
kept, et cetera)
• computer resources

To be able to acquire a cost-effective logistics system, an in-depth understanding of


the technical characteristics of the design is crucial. (This is one of the primary
reasons why the logistics of a system should be developed by the designer: he or
she understands the design best.) The logistics support analysis aids in creating and
understanding the system in terms of its technical characteristics so that the logistics
support elements can be identified.

Logistics support analysis also ensures that only the required support is acquired
(thus eliminating unnecessary redundancy). Because the developer of the logistics
system does not have an adequate understanding of the system, the system is often
over-designed – with costly consequences!

119
LGE401I/501

Logistics system analysis also aids in evaluating design alternatives during the
design process and, eventually, evaluating the system support capability through
user evaluation.

120
LGE401I/501

6.7 The logistics support analysis process

The logistics support analysis process is iterative in nature: A well-designed system


starts out with the analysis process, while analysis requires data (logically) and data
is generated by the design, which requires an analysis effort, and so on!

Remember that the necessity for logistics stems from the fact that failures occur. The
focus of the logistics support analysis is (a) to eliminate these failures by
design/redesign and (b) to support the fallible components adequately. We already
discussed several aspects of and techniques that are used in the logistics support
analyses process; we will now attempt to put these into perspective by discussing
the actual process step by step.

6.7.1 Influencing the design and compiling the support concept

The logistics support analysis process starts with the design and the process of
design influence (which we have already covered). The support concept is compiled
and by keeping the design in mind, the logistics support analysis candidates are
identified.

6.7.2 Identifying logistics support analysis candidates

A logistics support analysis candidate is any part of the system (component,


subassembly, assembly, device, et cetera) which is repairable (in other words, any
system part that requires corrective or preventative operational support. Logically,
there is no need to consider the items that do not require support during the logistics
support analysis process, hence the concept of logistics support analysis candidates.

Logistics support analysis candidates are identified by analysing the hardware


breakdown structure (or bill of materials) from the top downwards (from the system
level, to the assembly level, to the subassembly level, and so on!). When system
parts are analysed from the top downwards and a non-repairable item is found (for
example a bolt or nut), the process is stopped and the item does not become a
logistics support analysis candidate. The logistics support analysis process is then
121
LGE401I/501

terminated for this part of the breakdown structure and the next part is analysed. The
non-repairable items are therefore effectively included on the next higher level.

Certain failures are only noticed when two components are combined. For example:
in the field of lasers, the actual laser may not indicate the failure when it is operated
separately nor may its optics (a set of lenses that is necessary to direct the beam)
indicate any problem under visual inspection, but an alignment failure may occur
when combining the laser with the optics.

The laser–optics combination will then also be considered a logistics support


analysis candidate.

From the above, you will understand the necessity that all the parties involved in the
logistics support analysis and logistics design process should also be involved in
compiling the hardware breakdown structure. Failure in this regard may very well
result in two hardware breakdowns: one that is used for configuration management
purposes in the general design process and one for the logistics analysis and design
process. This is highly undesirable.

6.7.3 Developing logistics support analysis candidate support concepts

For each of the logistics support analysis candidates, a support concept is


developed. We discussed the mechanics of this process earlier in this tutorial letter.

6.7.4 Conducting an failure mode, effects and criticality analysis


A failure mode, effects and criticality analysis is carried out for each of the logistics
support analysis candidates. During the analysis, the following are considered:

• possible ways in which an item (logistics support analysis candidate) can fail
• what the impact of the failure is (in terms of other failures, et cetera that are
caused by the failure)
• how critical the impact of the failure is

122
LGE401I/501

Depending on the criticality of the failure in terms of safety, availability and cost, it is

• eliminated through design (where the impact of the failure is unacceptable in


terms of safety, availability or cost)
• prevented through preventative maintenance (where the impact of the failure
is major in terms of safety, availability or cost), or
• corrected when it takes place (where the impact of the failure is minor in terms
of safety, availability or cost; also where failures with a major impact, as
mentioned above, do actually take place)

In other words, where the impact of the failure is insignificant in terms of safety,
availability and cost, it is merely left until the failure occurs and therefore no attempt
is made to prevent it through preventative maintenance.

[Link] Analysing the failure mode

A failure can be defined as the manner in which an item can fail to meet its design
intent or requirements in terms of performance or customer expectations.

Each potential failure mode for a logistics support analysis candidate should be
considered. This information can be obtained by brainstorming failure mode, effects
and criticality analyses on similar systems, testing, et cetera. All possible failures
should be taken into account, including those that will only occur under certain
operating conditions or environments (even those that the system was not designed
for!).

The failure mode should be defined either functionally or physically (in technical
terms), or both. For example, a functional defined failure would be "the scissors does
not cut properly" and a physically defined failure would be "the blades are blunt".
Failures that are defined on the higher levels of the hardware breakdown structure
will tend to be described more in functional terms, whereas failures on the lower
levels would be more physically described.

123
LGE401I/501

[Link] Analysing the effect of the failure

In this part of the failure mode, effects and criticality analysis we are interested in
what the failure does with respect to other system parts, the end user, the
environment, et cetera. Failures are then identified in other system parts of which the
logistics analyst might not even have thought.

The effect of the failure should be considered locally (what are the immediate effects
on the level where it occurred), on the next higher level and on the system level (the
end effect of the failure).

What is of particular interest in the assessment of the effect of the failure is whether
there are ways whereby the operator can detect the failure (that is, isolation of the
failure). The effects of the failure can be described in terms of what the end user
might see or experience, and should preferably be stated in terms of system
performance or in a way that involves as many of the end user's senses (sound,
odour, colours, et cetera) as possible.

Another factor that is important here is that of operator compensation in case of


failure: Is there anything that the operator can do to compensate for the failure or to
prevent the failure from causing secondary effects or further damage? If there is, it
should be described adequately. A criticality analysis of the failure should then be
done.

[Link] Analysing the criticality of the failure

Criticality is defined in terms of a combination of the following two parameters:

1) how severe the end effect (system level) of the failure will be, and
2) the probability that the failure will occur

Criticality, in other words, assesses the seriousness of the effect (discussed above)
of the failure.

124
LGE401I/501

(1) The severity of a failure

The severity of a failure can be demonstrated by means of a simple example: Say


that the blade of an industrial type lawnmower is secured by a bolt and the blade is
not properly housed. If the blade snaps loose, it will be propelled horizontally in any
direction. If the bolt does fail, the local effect of failure may not be critical at all (for
example, replacing a R10,00 bolt), but the end effect of the failure could be a human
being getting killed! If the probability of such a failure is also significant, the failure is
considered as extremely critical. We may define severity as a qualitative value to
indicate the most serious impact which the

failure of a particular logistics support analysis candidate can have on the system,
environment, end user, et cetera. We may depict the severity as a single character
code as follows:

125
LGE401I/501

TABLE 6.1

The above is only a proposed classification and if desired, the above categories may
be tailored to meet your specific needs (for example by further subdivision, such as
3A, 3B, 3C, et cetera, with 3A being more severe than 3B and so on).

(2) The probability of a failure

126
LGE401I/501

The probability of a failure refers to the likelihood of a failure mode occurring. We


depict the probability as a single character code (a qualitative value), which has a
meaning rather than an actual value, as follows:

TABLE 6.2

Again, the above is only a proposed classification and if desired, the categories may
be tailored to meet your specific needs (for example by further subdivision and other
ways of classification).

(3) Criticality matrix

From the two parameters that we discussed above, a criticality matrix can be
compiled to aid in deciding whether the failure should be

• eliminated through redesign

127
LGE401I/501

• prevented through preventative maintenance and treated through corrective


maintenance in the cases where it does actually occur, or
• merely corrected when it takes place

The criticality matrix is depicted above.

After the failure is classified according the severity and probability thereof, one has to
determine in which of the three sectors in table 5.3 above the failure falls and which
of the following courses of action should be taken:

• If the failure falls in the upper left sector (which is lightly shaded), the failure
is considered as totally unacceptable and redesign is suggested. The redesign
changes should then be described for the applicable items.
• If the failure falls in the middle sector (which is unshaded), preventative
maintenance is suggested to prevent the failure from occurring and corrective
maintenance if the failure actually occurs. The items that fail in this manner are
considered further in terms of reliability-centred maintenance logic (those that

128
LGE401I/501

also require preventative maintenance) to design the corrective and


preventative maintenance tasks.
• If the failure falls into the lower right sector (which is shaded darker),
corrective maintenance is suggested if the failure occurs and no preventative
maintenance is considered necessary. The corrective maintenance tasks
should be designed and documented for these items.

The more failures are situated in the lower right sector, the better the design (and the
smaller the logistics required).

[Link] Further aspects to consider

As we mentioned earlier, other factors that should be incorporated in the failure


mode, effects and criticality analysis are the consideration of the predictability of
the failure (what could give an indication that the failure is going to take place –
before it does), failure indication (how will we know that the failure has taken place)
and isolation of the failure (how will we know which item[s] actually failed).
Furthermore, we can consider what the operator can do to compensate for the
failure, to prevent further failures, et cetera (for example maintenance tasks and
follow-up actions). The possible causes of a failure should also be assessed.

[Link] Documenting the results of the failure mode, effects and criticality
analysis

A proposed documentation format for the results of the failure mode, effects and
criticality analysis is a tabular format, as depicted in logistics and supportability
analysis.

6.7.5 Performing the reliability-centred maintenance process

The reliability-centred maintenance process is aimed at identifying preventative


maintenance tasks for the failures that fall in the middle sector of the criticality matrix
as determined by the failure mode, effects and criticality analysis process we

129
LGE401I/501

described above (that is, only the tasks that are indicated as requiring preventative
maintenance).

PJ Pretorius has developed a decision tree that is based on the failure pattern of the
item to use as a standard method of conducting the reliability-centred maintenance
process. Certain items do not have a failure pattern though (because they fail at
random) and certain components are not applicable to the process (electronic
equipment, for example, where it is more desirable to replace the component only
after it has failed because the probability of failure of such an item decreases with
time). We briefly look at this decision tree here because it is an easy and logical way
of conducting the reliability-centred process.

The analyst who is applying the decision tree is merely required to answer "yes" or
"no" to the questions of the tree and the preventative maintenance tasks (or
combination of tasks) are derived. In certain cases redesign is recommended, rather
than a mere set of preventative maintenance tasks.

The preventative maintenance tasks that are recommended in the decision tree are
the following:

The output of the decision tree is either a combination of the abovementioned tasks
or a proposed redesign. If none of the tasks (or task combination) are applicable and
effective (that is, the last decision in the decision tree), redesign is proposed.

130
LGE401I/501

Redesign is considered

• mandatory where safety is the issue (the first and fourth legs of the logic)
• required where availability and capability is the issue (the second and fifth
legs of the logic)
• desirable where only economy is the issue (the third and sixth legs of the
logic)

The last question in the logic (Is there a task combination applicable and effective?)
actually only means have you answered “yes” to any of the above questions in the
leg of the logic that you are busy with? If all the answers in the leg that you are busy
with were “no”, the answer to the last question is also “no” and redesign is proposed.

When you study the logic of the decision tree, you will notice that the first two
decisions in each tree ("Is the occurrence of a failure evident to the operator?" and
"Does the failure have a direct adverse effect on ...?") are actually part of the failure
mode, effects and criticality analysis process.

6.7.6 Designing maintenance tasks

From the failure mode, effects and criticality analysis process and the reliability-
centred maintenance process, the failures that can be expected are identified and
where preventative maintenance tasks should be developed is indicated. The next
steps of the logistics support analysis process are:

• Identifying corrective maintenance tasks for all the failures


• Identify preventative maintenance for the failures indicated by the reliability-
centred maintenance logic

The above tasks are considered a science on its own and are of course dependent
on the type of system. The field is therefore considered to be too wide to cover within
the scope of this module. These tasks consist of the actual work design for each

131
LGE401I/501

maintenance task, in other words actually describing what should be done during the
maintenance task.

6.7.7 Defining resources for maintenance tasks

The resources can then be defined for each maintenance task. Here we refer to the
following:

• spares that are needed for the task


• tools and test equipment that are needed for the task
• facilities that are needed for the task
• consumables that are needed for the task
• personnel who are needed to accomplish the task
• training and training aids that are needed for the abovementioned
personnel to enable them to accomplish the task
• supporting documentation for the task (typically technical information)
• materials handling and distribution that are needed for the spares, et
cetera associated with the task
• packaging and marking that are needed for the spares, et cetera associated
with the task

The above resources, like the maintenance tasks, are also considered a science on
their own and are dependent on the type of system. The field therefore also falls
outside the scope of this module.

6.8 American military standards applicable to the logistics support analysis

These are not considered part of this module, but are merely included for the sake of
completeness. The applicable standards are:

• Mil-Std 1388 1
• Mil-Std 1388 2

132
LGE401I/501

6.9 Conclusion

Logistics in the production/construction phase chapter in the prescribed book: the


focus moves to operational logistics. The requirements that resulted from conducting
a logistics support analysis and the other logistics engineering activities of the design
phase are now used to acquire the actual system. The production of the designed
logistics support elements and the logistics support during the production process
itself are specifically discussed in this chapter.

In chapter 10 (System operation and support) logistics during the operational phase
is discussed. This chapter specifically covers the evaluation of the system in the
operational phase (Is the system successful?). Remember that when this phase is
reached, it is “too late” to a large extent: There is a tendency in the industry in South
Africa to design and acquire the system as quickly as possible and to overlook the
important issues that we discussed in this tutorial letter. There is seldom time to do
things right the first time, but there is always time to do things over. Furthermore,
when designing of the logistics system, it is critical to keep the retirement of the
system in mind. Very often this phase becomes a very expensive one because the
designers failed to bear in mind the consequences of the retirement of the system!

133
LGE401I/501

How integrated is integrated logistics?

PJ Pretorius
[Link] (Industrial) CPIM MBA
Description: A model is constructed from the necessary conditions derived from the
definition of integrated logistic support that suggests how business logistics and logistics
engineering have to co-exist and be integrated to achieve integrated logistics.

Abstract

Industry and academic a still have a major problem in grasping the extent and
relationships of all functions involved in integrated logistics. This is because business
logistics and logistics engineering developed separately, each with their own following,
resulting in the two so-called different disciplines ignoring each other.
By analysing the definition of integrated logistic support, it is possible to identify the
necessary conditions for an integrated logistics model. From these necessary
conditions, a model of the management functions and technical activities is constructed
to suggest the purpose and place of all logistics functions to work in an integrated way
towards the goal of the organisation. The model suggests that logistics engineering and
business logistics are both required in the organisation and that it is of vital importance
that these functions are executed in unison. This model is different to previous models
in that it approaches logistics from the organisations viewpoint rather than from a
logistics viewpoint.

Keywords: Integrated logistics support, logistics engineering, operational logistics, and


business logistics.

134
LGE401I/501

1 Introduction

The goal of any profit-seeking organisation is to make money (Goldratt, 1990:12). It is


therefore necessary to approach all management and technical activities from this basic
principle. Anything that does not contribute to reaching the goal is a waste of time and
effort. This is also true of logistics within the organisation.

One of the main reasons why it is necessary to discuss the integrated nature of logistics
is because no organisation can afford to operate without close-knit integration amongst
all the business functions. Unfortunately, there is still a wide gap between the business
logistics and the logistics engineering. What is important is to get all logistic functions
working together so that the organisation can make more money, now and in the future.

2 Integrated logistic support

Integrated logistic support (ILS) is defined as "a disciplined, unified and iterative
approach to the management and technical activities necessary to (1) integrate support
considerations into system and equipment design; (2) develop support requirements
that are related consistently to readiness objectives, to design, and to each other; (3)
acquire the required support; and (4) provide the required support during the operational
phase at minimum cost" (Blanchard, 1992:13).

There are two distinct observations that can be made from the definition. The first is that
integrated logistic support considers management and technical activities as mutually
supportive and equally important in achieving the objectives. This constitutes the first
necessary condition for integrated logistic support the second observation is that there
is a logic sequence in the objectives e.g. support cannot be acquired unless it was
developed. The second necessary condition is therefore that a life cycle approach is to
be followed to achieve each of the objectives. Thereby ensuring integrated logistic
support over the total life cycle It can thus be derived that in order to construct an

135
LGE401I/501

integrated logistic support model, the aforementioned necessary conditions must serve
as the basis of the model.

3 Business logistics

Blanchard (1992:3) quotes the Council or Logistic Management definition for business
Logistics as "... the process of planning, implementing and controlling the cost effective
flow and storage of raw materials, in-process inventory, finished goods and related
information from point of origin to point of consumption for the purpose of conforming to
customer requirements." This definition indicates an orientation towards the customer
as well as the suppliers as shown in Figure 1, demonstrating the business logistic
activities applicable to inbound and outbound logistics (Balou, 1992:18).

Lambert and Stock (1993:5) also include activities such as customer service, demand
forecasting, return goods handling, parts and service support as business logistic
activities in addition to those indicated by Balou. From this it is clear that business

136
LGE401I/501

logistics has very strong interfaces with the marketing function through the physical
distribution component of the marketing mix (Lambert and Stock, 1993:42, 44).

4 Logistics engineering

Nowadays the term 'business process re-engineering' is heard frequently, implying that
business processes are to be engineered i.e. constructed in engineering like

manner. In the same way logistics should be engineered i.e. logistics engineering,
before business logistics can come into place. The purpose of logistics engineering is to
ensure that whilst designing a system all operational considerations are taken into
account in order to make that design supportable from a logistical viewpoint.
Furthermore, logistics engineering ensures that all resources that will be required by the
system during its operations phase for operations and support are designed and
available when the system goes into operation. "In essence, logistics engineering
covers (1) the design of the prime mission equipment for supportability, and (2) the
design of the overall support capability for the system." (Blanchard, 1992:14)

137
LGE401I/501

These two primary goals arc achieved by vigorously pursuing design activities that
considers the customer/market environment, that considers restrictions this environment
places on the design and support system, that ensures the market requirements are
met. In order to have a total system, the support system is designed and implemented
as the logistic elements as indicated in Figure 2. These two primary goals of logistics
engineering clearly demonstrate a strong marketing orientation. What is aimed at when
striving for a logistically supportable system is system ability, system availability and
system affordability? If we have a capable system (that runs smoothly because of
logistics), available when required (through a logistic support system) and cost effective
(because it was designed to be that way), the organisation can make more money.

Logistics engineering is clearly the vehicle used to achieve the first two objectives of
integrated logistic support, especially on the technical activity side. However, it cannot
be achieved without considering the operational environment providing for the third
necessary condition. There may be some doubt as to whether business logistics will

138
LGE401I/501

achieve the final two objectives, due to the strong maintenance connotation to logistics
engineering. Consider for the moment that business logistics will not achieve the final
two objectives of integrated logistics support and define a new category, namely
operational logistics.

5 Operational logistics

Operational logistics (i.e. logistic activities performed during the preparation for and
operational phases of the life cycle) can be defined as (analogue to ILS definition) those
management and technical activities necessary to (1) acquire the required support; and
(2) provide the required support during the operational phase at minimum cost. This can
only be successful if the output from the logistics engineering is used. Figure 3 indicates
what is implicated in operational logistics. However, in order to achieve the second
objective, providing the support, changes will inevitably take place, which will again

139
LGE401I/501

require logistics engineering. From this follows the fourth necessary condition for the
model, namely that logistics engineering should be available during the operational
phase until phase out in order to support changes taking place in the design.

6 Integration of logistics engineering and operational logistics

These two categories, logistics engineering and operational logistics can now be
integrated into one model (Figure 4) using the necessary conditions. It is clear that all
four necessary conditions are met, namely considering both management and technical
activities, the life cycle approach, engineering logistics considering the operational
environment and logistics engineering support existing until phase out.

140
LGE401I/501

This model can now be used for any system, irrespective of its nature. This model is as
applicable to a military system as it is to an organisation. It may be that the terms used
to describe different functions within the different systems may vary, but in essence are
aimed at achieving the same function. It is fairly easy to visualise how this model can be
applicable to a military system. To aid in the visualisation as to how this model is
applicable to an organisation is to consider that an organisation is also designed and
engineered, with all its supporting functions in order to operate it to achieve production,
along with a preventive and corrective maintenance function.
This model is applicable on two levels of any organisation. First of all, on the
engineering and operation of the organisation itself and secondly on the products and/or
services the organisation delivers to the market. When engineering the logistics for the
product and/or service, it is imperative to integrate the operational logistics of the
product/service with that of the organisation and the market environment.

7 The role of business logistics

It is quite clear that business logistics is only one of many needed functions within the
operational logistics and not the single key factor that makes or breaks the organisation.
All the parts have to work together well for an organisation to be successful. Where the
proposed model focuses strongly on the technical activities of the physical logistic
elements involved, the emphasis of business logistics is more on the management of
the operational logistics, including the business logistic functions required for the
maintenance support Therefore business logistics has a major part to play within the
operational environment, while at the same time getting involved in the logistics
engineering phases, in order to support the organisation as a whole in achieving its
goal.

8 Conclusion

The conclusion that is drawn is that logistics engineering have in the past focused too
much on the technical activities and elements of product systems, disregarding the

141
LGE401I/501

management processes that are needed to be engineered for the operational phase of
both the product systems and the organisation. Also, business logistics focused too
much on the management processes of the organisation that were not well engineered
or not engineered at all. Furthermore, the maintenance support and the associated
business logistics required by the maintenance function were also totally ignored. The
time has come to accept integrated logistic support as the only definition for total
logistics involving both management and technical activities. In order to be competitive
management needs to closely integrate all functions of the organisation. Logistics in
itself has no purpose. Logistics supporting an organisation in an integrated way
provides an impetus to achieving the goal, MAKING MONEY.

142
LGE401I/501

9 References

Blanchard, B.S., 1992, Logistics engineering and management, Fourth Edition, Prentice
Hall, Englewood Cliffs, New Jersey Balou, R.H., 1987, Basic business logistics, Second
Edition, Prentice Hall, Englewood Cliffs, New Jersey

Goldratt, E.M., 1990, The Haystack Syndrome, North River Press, New York

Lambert, D.M. Stock, J., 1993, Strategic Logistics Management, Third Edition, IRWIN,
Homewood, Illinois

10 Association
PJ Pretorius
Senior Lecturer
Department of Industrial and Systems Engineering
University of Pretoria
0002 Pretoria

e-mail:pret-pj@[Link]

143
LGE401I/501

144
LGE401I/501

145

You might also like