occar-ea iss guideiss guide issue 2 – may 2013 - page 2 of 275 1. occar-ea is a european armament...

OCCAR-EA ISS Guide

OCCAR

Preparation and Management of OCCAR Programmes’

In Service Phase

Configuration Management

MaintenanceManagement

RM&T Analysis

SecurityManagement (DS)

OrganisationUpdate

History & Lessons Process

Concept & Doctrine Review

ST&E Management

Disposal Management

Safety Management

Software Support

System Engineering

Manpower & Human Factors Analysis

Life Cycle Costing

EnvironmentalImpact Management

Facilities & Infra Management

General Support of PD

InformationManagement

Contract & Legal SupportRisk

Management

Financial, Budget Management

Planning & ReportingManagement

Quality Management

Security Management (PD)

General ProgrammeManagement Activities

ILS related and Domain Specific Activities

Main ISS Activities

Supply SupportManagement

Technical SupportServices

ObsolescenceManagement

Technical Info & Data Services

Training Support Services


MaintenanceManagement

RM&T Analysis

SecurityManagement (DS)

OrganisationUpdate



ST&E Management

Disposal Management

Safety Management

Software Support

System Engineering


Life Cycle Costing

EnvironmentalImpact Management



InformationManagement

Contract & Legal SupportRisk

Management


Planning & ReportingManagement

Quality Management


General ProgrammeManagement Activities


Main ISS Activities

Supply SupportManagement

Technical SupportServices

ObsolescenceManagement




Maintenance Management

RM&T Analysis

Security Management (DS)

Organisation Update



ST&E Management

Disposal Management

Safety Management

Software Support

System Engineering


Life Cycle Costing

Environmental Impact Management



Information Management

Contract & Legal Support Risk

Management



General Programme Management Activities


Main ISS Activities

Supply Support Management

Obsolescence Management



Planning & Reporting Management

Quality Management

Technical Support Services


Issue 2, May 2013

ISS Guide issue 2 – May 2013 - Page 1 of 275

Author/editor: Franck Ramaroson / Reyes Torres Garcia / Cyril Heckel

Contact address:

OCCAR-EA, Central Office, 53175 Bonn, GERMANY Tel: + 49 228 5502 165/137 Fax: + 49 228 5502 140

Email: [email protected]

Date: [email protected]

May 2013

Record of changes

Date Issue Changes

11/2010 Issue 1 First Issue

05/2013 Issue 2

Changes due to harmonisation work between IPs, ASD S5000F.

• Update of chapters 1 to 4 to allow a clearer under-standing and faster, purpose driven navigation in the ISS Guide

• Chapter 5.7: clarification • Chapter 7.1.12, 8.12, 12.12: clarify Software Support

Changes due to Industrial, Member States, OCCAR Staff comments and editorial prove reads

Disclaimer: This document has been established by OCCAR-EA and shall at all times remain property of OCCAR-EA. All rights are reserved. No intellectual property rights or licences are granted by OCCAR-EA in connection with any information in this document. This document is supplied on the condition that the information shall not be used for any purpose other than for commenting, as agreed in OILSP. The document or any information of it shall not be dis-closed in whole or in part to any third parties, without OCCAR-EA’s prior written consent.

mailto:[email protected]�



1.

OCCAR-EA is a European Armament Organisation tasked by its Member States to provide Programme management services for collaborative Defence Programmes through their life cycle. The In-Service phase of a Defence System is usually its longest and costliest phase and it is therefore vital to plan and manage the Defence System throughout this phase in a cost-effective way. This In-Service Support (ISS) Guide covers the necessary activities.

Executive Summary

The ISS Guide provides Member States, Industry, OCCAR-EA employees and other stakeholders w ith a comprehensive description of tasks and tools that enable effective management of Defence Systems during the In-Service phase. I t outlines the ISS tasks/ services that can be managed by OCCAR-EA on behalf of Participating States (PSs). The ISS Guide supports OCCAR’s ambition to set a best practice reference in ISS Management to be progressively used by OCCAR PSs and eventually across Europe.

Scope of the ISS Guide

The build-up of the ISS Guide, from policy to concrete matters and from overview to detail, allows all interested parties to satisfy their individual information needs on all management levels.

One ISS Guide for all Stakeholders

To enhance understanding, the ISS Guide addresses at the beginning, briefly, OCCAR’s Through Life Management (TLM) approach and how Integrated Logistic Support (ILS) fits w ithin. Follow ing this, all management elements are described and the scope of OCCAR ISS work is applied, resulting in the feasible elements for OCCAR Management.

Then, the OCCAR ISS Process Model is introduced and used to structure the more detailed description of the ISS sub-activities and tasks to be managed in the In-Service phase by OCCAR-EA, including also the part of the work which w ill probably be contracted out to Industry or assigned to other organisations and also how system availability can be assessed through Performance Parameters. These attached Performance Parameters form a complete system and are mathematically connected to demonstrate their contribution to the System Operational Availability. The combined information is finally aligned to a generic, functional structure of an OCCAR-EA Programme Division during the In-Service phase.

OCCAR strives to attain its vision of being a centre of excellence in Programme management. Therefore, we are always ready to discuss and exchange ideas for improvement. P lease contact us and we w il l enter into a dialogue w ith you on any related topic.

Return on Experience

Your advice / questions / input are very w elcome: [email protected]

Tim Rowntree

OCCAR-EA Director May 2013



2.

The reader of the ISS Guide may have two different approaches/purposes.

How to use the ISS Guide

This ISS Guide offers information in different levels of detail. Depending on the reader’s knowledge of OCCAR, of the ISS processes and on her/his information requirement it is pos-sible to select topics out of the offered information levels of detail.

Purpose: Reading from Overview to Detail

No Detail Executive Summary

General Information

Aim

Scope

Introduction of OCCAR

OCCAR’s TLM

Medium Level of Detail

ILS to prepare ISS

General ISS Portfolio

OCCAR’s boundary conditions

OCCAR’s ISS Portfolio

OCCAR’s ISS Process Model

Higher Level of Detail

Table of Content

ISS Phase Activities

Transition Problems

Generic Programme Division

References, Acronyms and Definitions

Performance Parameters

For the establishment of a work breakdown structure, when entering the ISS phase as well as for the distribution of workload between OCCAR-EA PD, Industry and PSs, the ISS Guide can be used in the following way.

Purpose: Establishing a work breakdown structure for ISS management


Task Reference

Get an overview of necessary management task Chapter 8

Establish a Common Support Strategy Chapter 8

Write outline of a Common Support Plan Chapter 12 tables1

Write Statement of Work for Contract

, columns 1-3 Chapter 12

tables, columns 4-5

Define Performance Parameters for a perform-ance based contract

Chapter 12 tables, column 6,

annex B

Support establishment of MoU Chapters 8, 12

Establish Programme Decision Chapters 8, 12, 14, annex B

Note

To establish national deviations from common support strategies, the ISS Guide provides also assistance.

For convenience, the ISS Guide provides internal links, which are indicated by blue col-oured interactive words or phrases.

All Internal Procedures (IP) and Internal Guidance (IG) referenced in the present Guide are accessible through the OCCAR-EA Intranet only. They provide details on how OC-CAR-EA will perform the management tasks.

1 Table… indicates the ISS element tables of chapter 12


1. Executive Summary.......................................................................................... 2

Table of Contents

2. How to use the ISS Guide ................................................................................ 3 Table of Contents ................................................................................................... 5 3. Aim and Scope of the ISS Guide ....................................................................... 9 4. ISS Guide Overview ....................................................................................... 10 5. Introduction to OCCAR-EA in its ISS Management Role ................................ 11

5.1 Convention .............................................................................................................................. 11 5.2 OCCAR-EA’s Vision, Mission and Values ...................................................................................... 11 5.3 OCCAR-EA’s Role ..................................................................................................................... 12 5.4 Legal Framework ..................................................................................................................... 12 5.5 OCCAR Organisation ................................................................................................................ 12 5.6 OCCAR-EA’s Rules and Procedures ............................................................................................ 12 5.7 Governance ............................................................................................................................. 13

6. ISS as part of OCCAR’s Through Life Management (TLM) of Programmes ..... 14 6.1 OCCAR’s TLM Definition ............................................................................................................ 14 6.2 In Service orientation of OCCAR’s TLM approach ........................................................................ 14

7. Integrated Logistic Support (ILS) as preparation of the ISS Phase ............... 16 7.1 Elements of ILS ....................................................................................................................... 17

7.1.1 LSA and LSAR ............................................................................................................. 17 7.1.2 Supply Support ........................................................................................................... 17 7.1.3 Technical Information and Data ................................................................................... 17 7.1.4 Maintenance Planning ................................................................................................. 17 7.1.5 Support and Test Equipment ........................................................................................ 17 7.1.6 Reliability, Maintainability & Testability (RM&T).............................................................. 18 7.1.7 Facilities and Infrastructure.......................................................................................... 18 7.1.8 Packaging, Handling, Storage and Transportation (PHS&T) ............................................. 18 7.1.9 Training and Training Equipment .................................................................................. 18 7.1.10 Manpower and Human Factors ..................................................................................... 18 7.1.11 Disposal 18 7.1.12 Software Support ........................................................................................................ 19 7.1.13 In Service Monitoring .................................................................................................. 19 7.1.14 Life Cycle Costing........................................................................................................ 19 7.1.15 Obsolescence ............................................................................................................. 19 7.1.16 Configuration Management .......................................................................................... 19

7.2 ILS Strategy ............................................................................................................................ 20 7.2.1 Purpose of an ILS Strategy .......................................................................................... 20 7.2.2 Development of an ILS Strategy ................................................................................... 20 7.2.3 Factors influencing an ILS Strategy ............................................................................... 20

7.3 ILS tailoring ............................................................................................................................ 21 7.4 Integrated Logistic Support Plan as central ILS instrument of control ............................................ 21 7.5 Deliverables of the Integrated Logistics Support Plans ................................................................. 21

7.5.1 Preparation Phase (Concept Phase) .............................................................................. 22 7.5.2 Definition Phase .......................................................................................................... 22 7.5.3 Development Phase .................................................................................................... 23 7.5.4 Production Phase ........................................................................................................ 23 7.5.5 In Service................................................................................................................... 24 7.5.6 Disposal ..................................................................................................................... 24

7.6 The ILS Team.......................................................................................................................... 25 8. The complete ISS Portfolio ............................................................................ 26 9. Boundary Conditions ...................................................................................... 36

9.1 Dependencies .......................................................................................................................... 36 9.2 Boundary with the Industry / Third Party ................................................................................... 36


10. OCCAR ISS Portfolio /non-OCCAR managed ISS Portfolio ............................. 38 10.1 ISS Portfolio not managed by OCCAR ......................................................................................... 38 10.2 ISS Portfolio managed by OCCAR .............................................................................................. 38

11. OCCAR ISS Process Model .............................................................................. 39 11.1 Aim of the ISS Process Model .................................................................................................... 39 11.2 Operational availability and the ISS Process Model ...................................................................... 39 11.3 Methods and Tools ................................................................................................................... 39

11.3.1 Performance based approach ....................................................................................... 39 11.3.2 The EITVOX methodology ............................................................................................ 40 11.3.3 EITVOX method applied to ISS OCCAR architecture ........................................................ 40

12. List of ISS phase activities managed by OCCAR-EA, detailed to basic activities ....................................................................................................................... 43 12.1 Configuration Management ....................................................................................................... 43

12.1.1 Objective of Configuration Management in the ISS phase ............................................... 44 12.1.2 Contract the overall Configuration Management ............................................................. 44 12.1.3 OCCAR-EA manages the overall Configuration ................................................................ 44 12.1.4 Stakeholders in Configuration Management ................................................................... 45

12.2 Maintenance Management ........................................................................................................ 53 12.2.1 Objective of Maintenance Management in the ISS phase ................................................ 53 12.2.2 Contract the overall Maintenance Management .............................................................. 53 12.2.3 OCCAR-EA manages the overall Maintenance ................................................................. 53 12.2.4 Stakeholders in Maintenance Management .................................................................... 54

12.3 Supply Support Management .................................................................................................... 60 12.3.1 Objective of Supply Support Management in the ISS phase ............................................. 60 12.3.2 Contract the overall Supply Support Management .......................................................... 60 12.3.3 OCCAR-EA manages the overall Supply Support ............................................................. 60 12.3.4 Stakeholders in Supply Support Management ................................................................. 61

12.4 Technical Support Services........................................................................................................ 69 12.4.1 Objective of Technical Support Services in the ISS phase ................................................ 69 12.4.2 Contract the overall Technical Support Services ............................................................. 70 12.4.3 OCCAR-EA manages the overall Technical Support Services ............................................ 70 12.4.4 Stakeholders in Technical Support Services .................................................................... 71

12.5 Obsolescence Management ....................................................................................................... 79 12.5.1 Objective of Obsolescence Management in the ISS phase ............................................... 80 12.5.2 Contract the overall Obsolescence Management ............................................................. 80 12.5.3 OCCAR-EA manages the overall obsolescence ................................................................ 80 12.5.4 Stakeholders in Obsolescence Management ................................................................... 81

12.6 Technical Information and Data (TID) Services ........................................................................... 88 12.6.1 Objective of Technical Information and Data Services in the ISS phase ............................ 88 12.6.2 Contract the overall Technical Information Data Services ................................................ 88 12.6.3 OCCAR-EA manages the overall Technical Information and Data Services ......................... 89 12.6.4 Stakeholders in Technical Information and Data Services ................................................ 89

12.7 Training Support Services ......................................................................................................... 95 12.7.1 Objective of Training Support Services in the ISS phase ................................................. 95 12.7.2 Contract the overall Training Support Services ............................................................... 96 12.7.3 OCCAR-EA manages the overall Training Support Services .............................................. 96 12.7.4 Stakeholders in Training Support Services ..................................................................... 97

12.8 Support and Test Equipment (S&TE) Management .................................................................... 104 12.9 Facilities and Infrastructure Management ................................................................................. 106 12.10 Life Cycle Costing ................................................................................................................... 108 12.11 Manpower and Human Factors Analysis.................................................................................... 110 12.12 Software Support ................................................................................................................... 112 12.13 Reliability, Maintainability and Testability (RM&T) Analyses ........................................................ 115 12.14 Security Management of the Defence System ........................................................................... 117 12.15 Organisation Update ............................................................................................................... 119 12.16 Concept and Doctrine Review .................................................................................................. 121 12.17 Environmental Impact Management ......................................................................................... 123


12.18 Disposal Management ............................................................................................................ 125 12.19 Systems Engineering .............................................................................................................. 128 12.20 Safety Management ............................................................................................................... 130 12.21 Information Management ....................................................................................................... 132 12.22 Contract and Legal Support .................................................................................................... 134 12.23 Risk Management .................................................................................................................. 137 12.24 Financial and Budget Management .......................................................................................... 140 12.25 Quality Management .............................................................................................................. 143 12.26 Planning and Reporting including Performance Management ..................................................... 146 12.27 Security Management related to the Programme Division .......................................................... 149 12.28 Programme History and Lessons Process ................................................................................. 152 12.29 General Support of Programme Division ................................................................................... 155

13. Transition Problems ..................................................................................... 157 13.1 Phase Transition .................................................................................................................... 157

13.1.1 Non optimal management .......................................................................................... 158 13.1.2 Use of opportunities .................................................................................................. 158

13.2 Contractual Transition ............................................................................................................ 158 13.2.1 From DDP Contract to ISS Contract – same Contractor ................................................. 159 13.2.2 From DDP Contractor to ISS Contractor – different Contractors ..................................... 159 13.2.3 Interim Support Contract ........................................................................................... 159 13.2.4 Service Level Agreements .......................................................................................... 159 13.2.5 Change of Contractor during ISS Phase....................................................................... 159 13.2.6 Incorporation of new Programmes after DPP ............................................................... 159

13.3 Organisational Transition ........................................................................................................ 159 13.3.1 Transfer of management responsibility from OCCAR to Nations ..................................... 159 13.3.2 From DDP OCCAR Organisation to ISS OCCAR Organisation (PD internal) ...................... 159 13.3.3 From National ISS to OCCAR ISS ................................................................................ 159

14. Generic PD ................................................................................................... 160 14.1 General Considerations ........................................................................................................... 160 14.2 Functional Description ............................................................................................................ 160 14.3 Considerations for the PD Breakdown ...................................................................................... 162 14.4 Establishing a concrete PD ...................................................................................................... 163 14.5 Changes in Functional Generic PD Structure as Function of Phase .............................................. 164

15. Annexes ....................................................................................................... 165 Annex A: Related Documents, Acronyms, Definitions and Explanations ............ 166 Annex B: Performance Parameter Definitions .................................................... 178 Annex C: About the formulas and their link with Ao… ....................................... 274 Annex D: Your Notes .......................................................................................... 275

List of reference documents/acronyms/definitions/explanations

The list of Reference Documents, Acronyms, Definitions and Explanations can be found under Annex A.


List of Tables Table 1: ILS tasks in Preparation Phase ................................................................................................ 22 Table 2: ILS tasks in Definition Phase ................................................................................................... 22 Table 3: ILS tasks in Development Phase ............................................................................................. 23 Table 4: ILS tasks in Production Phase ................................................................................................. 24 Table 5: ILS tasks in In Service Phase................................................................................................... 24 Table 6: ILS tasks in Disposal Phase ..................................................................................................... 25 Table 7: ISS portfolio of activities and services .................................................................................... 35 Table 8: Configuration Management sub-activities .............................................................................. 52 Table 9: Maintenance Management sub-activities ................................................................................ 59 Table 10: Supply Support Management sub-activities ......................................................................... 68 Table 11: Technical Support Services activities and sub-activities ...................................................... 78 Table 12: Obsolescence Management sub-activities ............................................................................ 87 Table 13:Technical Information & Data Services sub-activities ........................................................... 94 Table 14: Training support Services sub-activities ............................................................................. 103 Table 15: Support and Test Equipment Management sub-activities .................................................. 105 Table 16: Facilities and Infrastructure Management sub-activities ................................................... 107 Table 17: Life Cycle Costing sub-activities .......................................................................................... 109 Table 18: Manpower and Human Factors Analysis sub-activities ...................................................... 111 Table 19: Software Support sub-activities .......................................................................................... 114 Table 20: Reliability, Maintainability and Testability (RM&T) Analyses ............................................. 116 Table 21: Security Management of the Defence System sub-activities ............................................. 118 Table 22: Organisation update sub-activities ..................................................................................... 120 Table 23: Concept and Doctrine Review sub-activities ...................................................................... 122 Table 24: Environmental Impact Management sub-activities ............................................................ 124 Table 25: Disposal management sub-activities .................................................................................. 127 Table 26: Systems Engineering sub-activities..................................................................................... 129 Table 27: Safety Management sub-activities ...................................................................................... 131 Table 28: Information Management sub-activities ............................................................................. 133 Table 29: Contract and Legal Support sub-activities .......................................................................... 136 Table 30: Risk Management sub-activities ......................................................................................... 139 Table 31: Finance and Budget Management sub-activities ................................................................ 142 Table 32: Quality Management sub-activities ..................................................................................... 145 Table 33: Planning and Reporting including Performance Management sub-activities .................... 148 Table 34: Security Management related to the Programme Division sub-activities .......................... 151 Table 35: Programme History and Lessons Process sub-activities .................................................... 154 Table 36: General support of the Programme division sub-activities ................................................ 156

List of Figures Figure 1: ISS Guide Overview ................................................................................................................. 9 Figure 2: From discrete linear to continuous use-centric ..................................................................... 14 Figure 3: ILS Element Groups in a Through Life view ........................................................................... 16 Figure 4: Complete ................................................................................................................................. 26 Figure 5: ISS Process Model: Overall elements breakdown ................................................................. 42 Figure 6: Navigation Map for the Configuration Management element ............................................... 46 Figure 7: Navigation Map for the Maintenance Management Element ................................................ 55 Figure 8: Navigation Map for the Supply Support Management element ............................................ 62 Figure 9: Navigation Map for the Technical Support Services element................................................ 72 Figure 10: Navigation Map for Obsolescence Management element ................................................... 82 Figure 11: Navigation Map for Technical Information and Data Services element ............................. 90 Figure 12: Navigation Map for the Training Support Services element ............................................... 98 Figure 13: Functional Generic Programme Division Structure during ISS Phase (pure ISS) ............ 161 Figure 14: Functional breakdown of generic pure ISS Programme Division (upper level) ............... 162 Figure 15: Generic methodology to estimate structure and administrative cost of an future PD .... 164 Figure 16: PD structure as function of the management need during the phases. ........................... 164


3. Aim and Scope of the ISS Guide

The guide on Managing OCCAR Programmes during the In Service Support Phase (ISS Guide) aims to provide Member States, Industry, OCCAR-EA employees and other stakeholders with a comprehensive set of tasks and tools to enable effective manage-ment of Defence Systems during the In Service Support (ISS) Phase.

Its scope is to outlines the ISS tasks/services/activities that can be managed, or not, by OCCAR-EA on behalf of Participating States (PSs). The ISS Guide supports OCCAR’s am-bition to set a best practice reference in ISS Management to be progressively used by OCCAR PSs and eventually across Europe.

Figure 1: ISS Guide Overview

For industry

What then can expect

from OCCAR

during ISS Phase

For Nations

What

OCCAR manages

during ISS Phase

For OCCAR PD Staff High level ISS Overview

ISS GUIDE

ILS related Activities Domain Specific Activities

General Programme Management activities

Main ISS Activities

Post Design Services Training support Services

Technical Documentation Management






OCCAR TLM

ISS Tailoring Performance Parameters

Programme Division Contract Inclusions

ILS input


4. ISS Guide Overview

OCCAR-EA considers Programme management as a complete and integrated process across the whole Defence System and through its life cycle. All OCCAR-EA management processes, planning and costing activities follow the Through Life Management Concept (TLM Concept). The Board of Supervisors (BoS) has tasked OCCAR-EA to work in the In Service Support field and identify In Service Support tasks/services/activities that could be managed on behalf of PSs.

The OCCAR ISS Guide describes how OCCAR-EA is organised to perform its ISS man-agement role. It derives the organisational structure and its management tasks from its primary role to manage collaborative defence Programmes, taking into account its con-vention, strategies, procedures and its specific responsibilities assigned by the Member States (MSs) and PSs. ISS phase management activities are detailed, which need to be performed in accordance with OCCAR’s Through Life Management (TLM) methodology and performance based logistics. For OCCAR management purposes the In Service Phase also includes Disposal activities.

The ISS Guide is a document which points to more detailed documentation available on the OCCAR-EA Internet for open public access and via the OCCAR-EA intranet for infor-mation restricted to OCCAR staff only.

As such this ISS Guide provides MSs and PSs, Industry, OCCAR-EA employees and other stakeholders with a comprehensive guide of tasks to enable effective management of Defence Systems during the In Service phase.


5. Introduction to OCCAR-EA in its ISS Management Role

5.1 Convention

The OCCAR Convention is OCCAR-EA’s foundation document that details a set of ar-ticles agreed by the Member States with the intention of increasing armaments cooperation, improving efficiency, reducing life cycle costs and strengthening the competitiveness of the European defence Industry. The following articles refer specifically to Programme management and are the core motivation for OCCAR-EA Programme management provision.

5.2 OCCAR-EA’s Vision, Mission and Values

Deriving from the OCCAR Convention, the mission describes OCCAR-EA’s overall purpose, as defined by the Member States. OCCAR-EA’s vision is the high level statement, describing the ideal situation, which OCCAR-EA aspires to achieve. OC-CAR-EA’s values are the basic principles, underlying all activities and decisions. OCCAR-EA’s mission, vision and values statements, as laid down in the OCCAR Business Plan are shown below.

Article 7 “OCCAR shall coordinate, control and implement those armament programmes that are assigned to it by Member States and coordinate and promote joint activities for the future, thereby improving the effectiveness of project manage-ment in collaborative projects in terms of cost,schedule and performance.”. Article 8 “OCCAR shall fulfill the following tasks, and such other functions as the Member States may assign to it: (a) Management of current and future cooperative programmes which may

include configuration control and in service support, […]; (b) Management of those national programmes of Member States that are assigned to it […]

Our Mission “To facilitate and manage collaborative European armament Programmes and Technology Demonstrator Programmes, through their life cycle to the satisfaction of our customers”. Our Vision “To be a centre of excellence, and first choice in Europe, for collaborative defence equipment programmes on a Through Life Management basis”. Our Values

• Belief in Europe’s future. • Professionalism, teamwork and positive attitude towards change. • Cultural diversity. • Integrity.

http://www.occar-ea.org/16�



5.3 OCCAR-EA’s Role

OCCAR-EA was established to facilitate and manage collaborative European arma-ment Programmes and it plays a role in the European Security and Defence framework. OCCAR-EA has developed strong links with:

• The armed services and procurement/support organisations of the PSs; • Industrial organisations of the OCCAR Member states, Industrial Prime Con-

tractors and suppliers; • The European Defence Agency (EDA); • European Standardisation Agency (CEN); • Aerospace and Defence Industries Association of Europe (ASD); • NATO Expert Working Groups; • NATO Agencies including the Maintenance and Support Agency (NAMSA).

5.4 Legal Framework

OCCAR-EA is an International organisation with full legal personality. It was cre-ated to co-ordinate, control and implement co-operative armament Programmes that are assigned to it by the Member States. For each Programme to be managed by OCCAR-EA the following set of documents are required:

Board of Supervisors (BoS) Integration Decision: A BoS decision adopted by the representatives of all Member States to authorise the integration of the Pro-gramme into OCCAR-EA;

A Programme Memorandum of Understanding (MoU): A MoU, signed by the PSs, providing their commitment to the Programme;

Programme Decision: The legally binding document approved and signed by the Programme Board representatives. The Programme Decision details the way the Programme shall be managed by OCCAR-EA and shall outline the rules and principles that shall apply.

5.5 OCCAR Organisation

The current OCCAR-EA Organisation is detailed in the OCCAR Business Plan and in the OCCAR brochure.

5.6 OCCAR-EA’s Rules and Procedures

An integrated set of OCCAR-EA Management Procedures (OMPs) have been devel-oped and agreed by the Member States. They provide clear and concise instruc-tions on how to integrate and manage a collaborative Programme, including tools, templates and examples. These procedures are mandatory for all Programmes in-tegrated into OCCAR-EA.

OCCAR-EA has the flexibility to assimilate new PSs and Associated States into an existing Programme set up. OMP 2 details the applicable rules and procedures. It can also accommodate the need for National Eyes-only Information on national variants, or represent a single Nation’s needs if required.

All OMPs, plus other corporate documents such as the OCCAR Convention and Business Plan, can be viewed or downloaded from the OCCAR-EA website: www.occar-ea.org. The website also provides information on the OCCAR-EA




http://www.occar-ea.org/�


managed Programmes and details on how to contact OCCAR-EA, via e-mail, telephone and post.

5.7 Governance

OCCAR-EA is closely governed by the Member and PSs and is tasked to deliver ef-fective Programme Management services, in terms of cost, schedule and system performance. It is lean in terms of management overhead and maintains the high-est standards of integrity in dealing with Nation’s financial resources, assets, Defence Systems and information on Nations’ variants. This high standard also includes dealings with Industry related issues like sensitive information.

The Director is accountable to the Board of Supervisors and the respective Programme Boards for the effective and efficient management of all Programmes. OCCAR-EA monitors and reports its performance against Strategic Objectives and against High Level Objectives set by the individual Programme Boards.


6. ISS as part of OCCAR’s Through Life Management (TLM) of Programmes

The Mission of OCCAR-EA requires the organisation to manage Programmes through their life cycle. For OCCAR this means to be capable of collaborative management of De-fence Systems from their integration to their disposal with a strong ‘use-centric’ view. OCCAR-EA’s TLM incorporates the advantages of using one lean and flexible manage-ment organisation through the life cycle of a Defence System, with the economical ad-vantages of collaborative approaches, and the requirement to deliver and sustain high Defence System availability. To extend these considerable advantages fully to the PSs, a through life commitment by them to a particular collaborative Programme is highly beneficial. However, should a non-OCCAR approach be desired by some PSs during the life cycle of a Programme, OCCAR-EA TLM approach allows flexible arrangements that will make a change feasible with minimised disruption.

6.1 OCCAR’s TLM Definition

Through Life Management means managing a Programme throughout its whole life cycle, in a use-centric way. TLM is achieved by applying and integrating best practice management techniques in a coherent manner across all system aspects in order to deliver, sustain and dispose the required cost-effective Defence System.

6.2 In Service orientation of OCCAR’s TLM approach

Filling the capability gap requires initiating a process, which will eventually bring a Defence System into service and lead to the final disposal of the Defence System after its use. The In Service phase represents the major part of the Life Cycle of a Defence System whether in terms of duration or cost. Hence, the in service use of a Defence System has to be the centre of management attention at any time of its life cycle.

Thus TLM requires a culture of use-centric management. The use-centric represen-tation (Figure 2) of this approach is replacing the step-by-step approach and linear representation which is mainly focused on fulfilling goals in a given phase.

Figure 2: From discrete linear to continuous use-centric

HAP, UHTHAP, UHTHAP, UHTDefinitionPreparation DevelopmentDevelopment Production In Service

DisposalDisposal

OCCAR conventional Programme Management Model

OCCAR use-centric Through Life

Programme Management Model

from discrete

linear

to continuoususe-centric

HAP, UHTHAP, UHTHAP, UHTDefinitionPreparation DevelopmentDevelopment Production In Service

DisposalDisposal


HAP, UHTHAP, UHTHAP, UHTDefinitionDefinitionPreparationPreparation DevelopmentDevelopmentDevelopmentDevelopment ProductionProduction In ServiceIn Service

DisposalDisposal

DisposalDisposal


OCCAR use-centric Through Life

Programme Management Model

from discrete

linear

to continuoususe-centric


At every decision point and for every aspect within the life cycle of the Defence System there are two questions, which have to be answered positively before the choice of a possible solution is found by rigorous application of Life Cycle Cost Analysis in support of a value for money decision. Feasible choices are down se-lected in 3 steps by applying the following questions:

• Will the design of the Defence System fill the capability gap through its in service life?

• Will the Defence System be operationally available whenever the com-mander on operations needs it?

• Rigorous application of Life Cycle Costing to the remaining choices will al-low selecting the best decision.

Further, it has to be highlighted that the greatest opportunity to reduce life cycle costs usually occurs during the early stages of a Programme.

For OCCAR-EA this requires the creation of a coherent set of procedures and atti-tudes which have a through life and use-centric focus. Risk management, Life Cy-cle Cost (LCC) analysis, information management, decision making during Pro-gramme management etc. need to also follow this approach.


7. Integrated Logistic Support (ILS) as preparation of the ISS Phase

Through Life Management fulfils, among other functions, the requirement to integrate Logistics and Procurement not only at the in service date of a Defence System or the transition between Production and ISS phase but from end to end of the Programme management of a Defence System. This is done by Integrated Logistic Support (ILS) management. Goal of ILS is to minimise the support cost while ensuring that the De-fence System meets the required operational availability. To reach this goal ILS has to:

• Influence the Design early enough to be effective for logistic purposes and cost-effectiveness. The ILS Principle of Design Influence can be stated as: 'The timely application of informed influence to the design of the hardware, software and human aspects of a Defence System in order to minimise support related risks and any potentially adverse effects of the design of the Defence System on the support requirements and maximise cost-effectiveness of the De-fence Equipment’. Design Influence is achieved through Logistic Support Analysis (LSA). The par-ticular tasks and activities to be performed will be carried out by the PD or the Contractor.

• Identify, develop and acquire the support resources. A key ILS principle is the identification of the logistic support requirements for the operations and sup-port functions. This considers the tasks that must be performed in the intended environment for each equipment alternative in order that the system achieves its intended level of capability.

• Provide the required means for In Service Support. • Enable ILS management.

ILS elements are applied through the life cycle of a Defence System, and during the ISS phase, ILS activities support ongoing equipment management and support including modification action. A pictorial representation is shown at Figure 3.

Figure 3: ILS Element Groups in a Through Life view

Enable ILS

Management

Provide Support Resources

Influence Design Modifications

Means for ISS Disposal


7.1 Elements of ILS

To achieve the aims, ILS addresses most support areas by the following elements:

7.1.1 LSA and LSAR

Requirements are identified through the Logistic Support Analysis (LSA) process during early lifecycle stages and kept updated until Disposal Phase. The LSA process has to be tailored to fit the Programme. LSA is only cost-effective where its results are likely to reduce LCC. It is recorded in the Lo-gistic Support Analysis Record (LSAR) to define relevance, justification, specification and cost. LSAR is the data depository for many other ILS elements. (See also Chapter 8, column other ILS activities)

7.1.2 Supply Support

Supply Support as part of ILS is responsible for the timely positioning, dis-tribution and replenishment of spares, repair parts and special or consum-able supplies. It includes the definition of the Initial Provisioning List (IPL) (For details see IP Supply Support Management and Chapter 8 activity 3 and Chapter 12.3).

7.1.3 Technical Information and Data

Technical Information and Data is the documentation necessary to install, operate, maintain, repair and support equipment throughout its life (details see IP Documentation Management and Chapter 8 activity 6 and Chapter 12.6).

7.1.4 Maintenance Planning

Maintenance Planning establishes the maintenance concepts and require-ments for equipment using analysis tools and methodologies such as (de-tails see IP Maintenance Management and Chapter 8 activity 2 and Chapter 12.2):

• Failure Mode, Effects and Criticality Analysis (FMECA);

• Reliability Centred Maintenance Analysis (RCMA);

• Level Of Repair Analysis (LORA);

• Maintenance Task Analysis.

7.1.5 Support and Test Equipment

Support and Test Equipment is the equipment (mobile or fixed) required to support the operation & maintenance of the Defence System and include:

• Tools;

• Maintenance equipment;

• Associated multi-use end items;

• Metrology and calibration equipment;

• Test equipment and automatic test equipment;

• Special Tools and Test Equipment (STTE). (See also Chapter 8 activity 8 and Chapter 12.8).


7.1.6 Reliability, Maintainability & Testability (RM&T)

Reliability, Maintainability and Testability (RM&T) are vital characteristics of Defence equipment. They affect the sustained delivery of the required per-formance in the field and are major drivers of the LCC. RM& T must be de-signed and built into a system during development and manufacture, if high levels of sustainability are to be achieved in service (see also Chapter 8 activity 13 and Chapter 12.13).

7.1.7 Facilities and Infrastructure

Facilities and Infrastructure is the management of all fixed, permanent buildings and structures, land, utilities and facility management services in support of the Defence System (see also Chapter 8 activity 9 and Chapter 12.9).

7.1.8 Packaging, Handling, Storage and Transportation (PHS&T)

Packaging, Handling, Storage and Transportation (PHS&T) management ensures that all system equipment and support items are packaged, han-dled, stored and transported properly and in conformance with appropriate legislation, particularly for hazardous materials (see also Chapter 8 activity 3 and Chapter 12.3).

7.1.9 Training and Training Equipment

Trained, qualified operators and maintainers are required to operate and support equipment in service. Good training reduces LCC and increases cost-effectiveness, safety capability and availability (for details see IP Train-ing Support and Chapter 8 activity 7 and Chapter 12.7).

7.1.10 Manpower and Human Factors

Manpower is concerned with 'how many people are required and when', Human Factors focuses on human beings and their interaction with tech-nology and the environment. The capabilities and limitations of the military and civilian personnel required to operate and maintain the equipment or facility in service are used to define requirements (see also Chapter 8 activ-ity 11 and Chapter 12.11).

7.1.11 Disposal

Disposal as ILS Element consists of

• the planning for phasing out of a complete Defence System at the end of its service life cycle (Disposal Phase) in an efficient, effective, safe and environmentally friendly way;

• the planning and removal of spares, consumables and equipment discarded as result of modification throughout the ISS phase of a Defence System;

• advise to the decision maker on the most cost-effective time for the removal of the Defence System from the inventory of the forces.

Disposal needs to consider the possibilities of re-deployment, sale, waste as well as environmental impacts (For details see IP Disposal Management and Chapter 8 activity 18 and Chapter 12.18).

http://intranet.occar.int/occar_intranet/96�




7.1.12 Software Support

Software Support is an intrinsic aspect of the support for any system with software content. LSA for Software might be considered.

Software Support is managed and controlled to ensure that intended use of the Defence System is not compromised (See also Chapter 8 activity 12 and Chapter 12.12).

7.1.13 In Service Monitoring

In Service Monitoring means the collection and analysis of usage data from the field. The comparison of anticipated and actual performance and In Service costs permits decisions to be made which allow changes in the support strategy. This allows whole life costs to be managed by improving the design and/or supportability characteristics as appropriate (see also Chapter 8 activity 4 and Chapter 12.4).

Note: It is getting more common to manage the Software Support like Hardware. The way to proceed has to be defined during the tailoring proc-ess of a programme.

7.1.14 Life Cycle Costing

Life Cycle Cost (LCC) identifies the system or equipment costs of (details see IP Life Cycle Costing and Chapter 8 activity 10 and Chapter 12.10):

• Initial acquisition;

• Development;

• Operation;

• Support;

• Disposal.

LCC must be taken into account during the selection of competitive tenders and the whole life cycle of the Programme whenever there are decisions to be made. LCC also informs the budget forecast.

7.1.15 Obsolescence

Obsolescence is defined as the loss, or impending loss of the manufactur-ers or suppliers of items, or shortages of raw materials. The rate of techno-logical innovation coupled with the challenging in service lives of Defence Equipments, mean that it is almost inevitable that Obsolescence will impact on all Programmes at some stage (details see IP Obsolescence Management and Chapter 8 activity 5 and Chapter 12.5).

7.1.16 Configuration Management

Configuration Management (CM) applied over the life cycle of a Programme provides control and visibility of the Defence System’s functional and physi-cal attributes. CM provides verifiable evidence that the Defence System is capable of meeting requirements and is identified in sufficient detail as an aid to supportability throughout the life cycle (details see IP Configuration Management and Chapter 8 activity 1 and Chapter 12.1).






7.2 ILS Strategy

7.2.1 Purpose of an ILS Strategy

The Integrated Logistic Support (ILS) Strategy describes the methodology to reach the goals stated at the introduction to Chapter 7. The elaboration of the ILS Strategy will involve all stakeholders including the end users.

The strategy should be focused on the objective of ILS: equipment avail-ability at a desired level of LCC (optimised level of cost-effectiveness). It must be tailored to the needs of the Programme. The amount and type of analysis is largely dependent on the procurement strategy adopted.

The ILS strategy normally includes: • Programme-specific tailoring requirements. • The method by which the required support and supportability is to

be achieved. • The method of demonstrating that the Contractor has achieved an

acceptable level of supportability. • The means and timing by which delivery of support resources are to

be integrated with delivery of the prime equipment. • The method by which supportability risk is to be managed, including

the interaction between the contracting strategy and the ability to procure the required support resources and data.

• The work breakdown proposed to identify the resources required to conduct the ILS process.

Specifying supportability at minimum LCC implies taking risk. Over insur-ance in capability and stocks, whilst operationally robust, takes scarce re-sources from other requirements. Under insurance in capabilities and stocks, on the other hand, it can have operational consequences far in ex-cess of the value of the saving made by too low supportability levels.

7.2.2 Development of an ILS Strategy

During the Preparation Phase (Concept), the ILS strategy concentrates on identifying support concepts for each equipment option and obtaining esti-mates of LCC to inform investment decision options. During this phase, to-gether with Design Phase, design influence is possible and the ILS Strategy needs to address this. In later phases, the ILS strategy concentrates on the means to refine support concepts into support plans, refine LCC estimates and identify, procure the necessary support resources and prepare for smooth logistic support during the ISS phase.

7.2.3 Factors influencing an ILS Strategy

Risk Management must be included as part of the ILS strategy, to quantify tradeoffs and ensure a balance between capability and cost in accordance with the User Requirements Document and System Requirements Document.

A use-centric view needs to be applied during all phases and for all decision making; existing policies; any existing facilities; the Users’ procedures and the resources, which may be relevant to the support of the new equipment.


A considerable amount of data may be required to determine the support-ability aspects of the design and provide for the successful in service man-agement of the equipment requiring a robust Through Life Information Management Solution useable for several decades.

Non-Development Item / COTS acquisition may not permit a full analysis of the support options, since the proposed supplier may not have applied ILS and may not have the required data or the contractual relationships with his suppliers, to permit its acquisition. This may make a particular procure-ment option inappropriate and requires careful analysis of the supportabil-ity risk in the ILS strategy.

The ILS strategy needs to consider the potential cost benefit of collecting performance data for management purposes even where none was avail-able from the outset.

7.3 ILS tailoring

As each Programme is different in complexity and has different requirements in depth of activities, the list of ILS elements has to be applied to each Programme in a flexible way. ILS activities are sometimes very complex and costly and therefore an analysis is necessary to determine if all ILS elements are applied. This means, in order to ensure cost-effective application of ILS, at the beginning of a Pro-gramme, scope and depth of the elements need to be tailored to meet the specific needs of the respective Programme. This tailoring process should be reviewed dur-ing the life of the Defence System.

7.4 Integrated Logistic Support Plan as central ILS instrument of control

The ILS Plan (ILSP) is the Programme Division’s (PD’s) statement of the complete ILS Programme for the Programme, and it is the implementation plan for logistic support. It includes the requirements, tasks, interfaces and milestones for the cur-rent phase and plans for the succeeding phases. It should provide all necessary support inputs to other Programme documents and papers. It will contain support-ability goals, support strategy and all associated plans.

The ILSP is a live document that is maintained throughout the Programme life as part of the Through Life Management Plan (more details see IP Through Life Pro-gramme Management ) of the Programme and will form part of the Common Sup-port Concept document as well as PSs National Support Concepts documents. It should include subordinate plans covering specific project activities and define all interfaces between the delegated authorities. The ILS Manager produces an ILSP for the Programme (in case of a very complex Programme for all projects of the Programme) on the bases of the ILSP taken over from EDA (or other organisations) at the time of integration of the Programme into OCCAR. It is up-dated throughout the life of the programme.

7.5 Deliverables of the Integrated Logistics Support Plans

The Programme Divisions (PDs) and contractors should produce ILS deliverables throughout the Programme life cycle, to plan, manage, undertake and audit ILS tasks. An overview to the main ILS plans and deliverables is provided below, including deliverables from the pre-OCCAR managed phases.




7.5.1 Preparation Phase (Concept Phase)

During the Preparation Phase (Concept), the (ILS) Manager should produce the following

outputs:

• Develop and document ILS Strategy. • Draft Logistics Support Analysis (LSA) Strategy. • Initiate Use Study. • Develop Work Breakdown Structure (WBS). • Develop ILS Statement of Work (SOW). • Develop ILS Plan and ILS Element Plans.

The (ILS) Manager should also provide

inputs and support to:

• Provide Support Focus for the User Require-ments Document (URD).

• Supportability Objectives. • Support Concept in the Support Strategy Paper

for Business Case. • If partnering approach is considered, ILS part of

PD-Enterprise integration plan. • Quality Assurance Plan, Risk Management Plan

and LCC Plans.

Table 1: ILS tasks in Preparation Phase

7.5.2 Definition Phase

In the Definition Phase, support strategies and outline support plans are developed, together with an estimate of Life Cycle Cost (LCC).

During the Definition Phase, the ILS

Manager should produce the

following outputs:

• Review and develop ILS Strategy. • Detail LSA Strategy. • Tailor the LSA. • Update Use Study. • Develop WBS. • Write ILS SOW. • Detail ILS Plan and ILS Element Plans. • Develop the Supply Support Procedures (SSP). • Develop the Technical Documentation Plan. • Develop the LSA Candidate Item List.

The ILS Manager should also provide inputs and

support to:

• Provide Support Focus for the URD. • Ensure that the System Requirement Document

(SRD) includes the detailed support strategy developed by the ILS Manager in response to the URD support requirements.

• Identify and justify Supportability Objectives. • Develop and document Support Concept in the

Support Strategy Paper for the Business Case. • Provide inputs to the Quality Assurance (QA)

Plan, Risk Management Plan and LCC Plan.

Table 2: ILS tasks in Definition Phase


7.5.3 Development Phase

During the Development Phase, the support plans from the Design Phase are further developed as more detail becomes available.

During the Development Phase, the ILS Manager should produce the fol-

lowing outputs:

• Review and develop ILS Strategy. • Review and develop LSA Strategy. • The Logistics Support Analysis Record (LSAR ). • Tailor LSA. • Update Use Study. • Develop and update WBS. • Write ILS SOW. • Detail ILS Plan and ILS Element Plans. • Develop the SSP. • Update the Technical Documentation Plan. • Update the LSA Candidate Item List.


support to:

• Identify and justify Supportability Objectives. • Develop and document Support Concept in the

Support Strategy Paper for the Business Case. • Provide ILS inputs to the Quality Assurance

Plan, Risk Management Plan and LCC Plans. • Ensure that the SRD includes the support

strategy developed by the ILS manager in re-sponse to the URD.

Table 3: ILS tasks in Development Phase

7.5.4 Production Phase

In the early part of the Production Phase, the support plans are reviewed and updated, as more information becomes available. Where design changes occur during the Production Phase, their impact on support strategies and plans will need to be evaluated and agreed.

During the Production Phase, the ILS Manager

should produce the following outputs:

• Reviewed and updated LSA Strategy. • The Updated LSAR Review. • LSA tailoring revisions. • Reviewed and updated WBS and ILS mile-

stones. • Reviewed and updated ILS SOW. • Develop Disposal Plan. • Updated ILS Plan for In Service and ILS Ele-

ment Plans. • Updated Supply Support Procedures. • Updated Technical Documentation Plan.


support to:

• Ensure that the ILS requirements detailed in the SRD and URD are met.

• Ensure that the support solutions are within the support requirement of the PSs /common


logistic requirements. • Provide ILS inputs to the TLMP, QA Plan, Risk

Management Plan and LCC Plans. • Perform ILS Tailoring.

Table 4: ILS tasks in Production Phase

7.5.5 In Service

During the In Service Support Phase, the support plans are reviewed and updated, as more details become available, support feedback is collected and the real costs are measured against the estimate. The application of ILS during the ISS phase ensures that the support pro-vided is adequate and effective. Support plans and procedures might need to be modified to eliminate problems, improve performance or allow changes to the design or reflect changes in equipment use or operating en-vironment.

During the In Service Support Phase, the following outputs

should be produced

• Revised and updated ILS Strategy for the In Ser-vice Support Phase.

• Revised and updated Support Strategy. • Updated ILS Plan and ILS Element Plans for ISS

Phase. • Updated Integrated Supply Support Procedures. • Updated Technical Documentation Plan. • Updated Obsolescence Management Plan • LSA tailoring revisions and LSAR update. • Reviewed and updated WBS - and ILS mile-

stones. • Reviewed and updated ILS SOW. • Reviewed and updated Disposal Plan.

The following inputs and support should be

provided

• Ensure that the ILS requirements detailed in the SRD and URD are continued to be met.

• Ensure that the support solutions are within the support requirement of the PSs /common logistic requirements.

• Provide ILS inputs to the TLMP, QA Plan, Risk Management Plan and LCC Plans.

• Initiate/perform In Service Monitoring (collection and analysis of usage data from the field) and work closely with Industry to improve reliability, maintainability and availability performance.

Table 5: ILS tasks in In Service Phase

7.5.6 Disposal

During the Disposal Phase, the support plans are reviewed and updated and the real costs measured against the estimate.


Application of ILS ensures that the disposal of the Defence System is per-formed in a cost-effective and timely manner. The Disposal Plan has to re-flect the withdrawal of all Items of the Defence System, all supporting equipment and elements like training, organisation etc. Unpredictable fu-ture during a long service life of a Defence System requires storing and up-dating necessary System information till the end of disposal.

Prediction of the most cost-effective time for disposal and possible change to a new Defence System filling the Capability is essential.

During the Disposal Phase, the following

outputs should be produced:

• ILS Strategy for the Disposal Phase. • Updated Disposal Strategy. • Updated ILS Plan for Disposal and ILS Element

Plans. • Updated Supply Support Procedures. • Technical Documentation Disposal Plan. • Reviewed and updated WBS - and ILS mile-

stones. • Reviewed and updated ILS SOW.

The following inputs and support should be

provided :

• Identify and justify Disposal Objectives. • Provide ILS inputs to the Health and Safety

Plan, Risk Management Plan and LCC Plans. • Provide input to Lessons Process of OCCAR2

.

Table 6: ILS tasks in Disposal Phase

7.6 The ILS Team

APD normally includes an ILS team to address ILS issues within the Programme. During the integration process of the Programme into OCCAR, the OCCAR-EA Di-rector proposes the size and structure of the ILS team (see OMP 2), the PM pro-poses changes to the team as necessary to adapt to changes of requirement dur-ing the life cycle of the Programme. OCCAR-EA Central Office can assist the proc-ess of defining a PD with analytical tool similar to the way described in Chapter 14.

2 Lessons Process of OCCAR is part of the OCCAR-EA Process Model, sub-process 1.14 (Identify &

manage lessons), the input comes through the sub-process 2.11.1 (Maintain Programme History & Identify Lessons)



8. The complete ISS Portfolio

ISS starts with the first piece of equipment of a new Defence System entering the ser-vices of the forces and ends with the last piece of equipment leaving the services. The complete ISS portfolio comprises:

• Main ISS Elements are those ISS Activities considered as having a direct influence on system operational availability and for which a set of performance parameters have been defined (see OMP 3-H). They are activities 1 to 7;

• Other ILS related Activities that consist of collecting and analysing ILS elements, using information feedback and considering their redefinition in case of new modifi-cations to be studied and implemented. For this latter, a Logistic Support Analysis (LSA) process might have to be undertaken and it is recommended to continue to maintain the Logistic Support Analysis Record (LSAR). The depth and extent of this analysis will depend on the type of Defence System and the scale of changes. The activities concerned are 8 to 13 and 18;

• Domain specific Activities are those that pertain to a certain specific domain The activities concerned are 14 to 17 and 19 to 20;

• General Programme Management Activities provide the framework for the execution of all the activities. For this OCCAR-EA maintains a set of Management Procedures and uses some specific tools. Activities are 21 to 29.

Figure 4: Complete ISS Portfolio of Activities



RM&T Analysis

Security Management (DS)

Organisation Update


Concept & Doc-trine Review

ST&E Management

Disposal Management

Safety Management

Software Sup-port

System Engi-neering


Life Cycle Cost-ing

Environmental Impact Management



Information Management

Contract & Le-gal Support Risk

Management


Planning & Reporting Management

Quality Management


General Programme Man-agement Activities

ILS related and Domain Spe-cific Activities

Main ISS Elements







In order to understand the framework in which the Activities of the complete ISS Portfo-lio would be undertaken, it is suggested to distinguish for each defined element:

• Recurrent Sub-activities and tasks provided to the users of the Defence System in order to enable continued operation and a sustainable service; it in-cludes monitoring of the performance of the Defence System and services and the identification, classification, and reporting of anomalies, deficiencies, and failures of the Defence System and services;

• Studies and implementation of modifications to the Defence System as result of new requirements or identified problems. This includes Integrated Lo-gistic Support activities.

In principle the following list represents the complete ISS portfolio. Each element listed contains both “Recurrent Sub-activities and tasks” and “Sub-activities and tasks related to the studies and implementation of modifications”. They are distinguished in the table (when applicable). Both the scope and depth of these elements need to be tailored to meet the specific requirements of each Programme.

Description of Activities Recurrent Sub-

activities and tasks during ISS Phase

Sub-activities and tasks related to the studies

and implementation of modifications including

ILS

1.

Configuration Management All sub-activities and tasks necessary to direct and control the functional characteristics of Defence System as described in its technical documenta-tion and later achieved in the Defence System, to manage the modification process, to record and monitor all con-figuration data and information.

Configuration Status Accounting and Configu-ration Audits allow the day to day management of the status and de-scriptions of the various versions and configura-tions of the Defence System.

Configuration Identification is an ILS task. It has to be undertaken during ISS when Baselines have to be updated after implementa-tion of modifications. Configuration Control al-lows the management of the modifications approval process and the implemen-tation

2.

Maintenance Management All sub-activities and tasks taken to retain the Defence System in or re-store it to a specified condition.

Execution of Mainte-nance (inspection, test-ing, servicing), Monitor-ing and Control of field maintenance data (clas-sification as to service-ability, and reclamation) are performed on a day-to day basis.

Maintenance Planning up-date is an ILS activity that has to be undertaken dur-ing the ISS phase in case of a modification or changes requested by the users (from feedback). Failure Mode and Effects and Criti-cality Analysis (FMECA), Reliability Centred Mainte-nance (RCM),Level Of Re-pair Analysis (LORA), Sup-port and Test Equipment revisions might have to be performed.

Note The numbers of the activities introduced in Chapter 8 repeats itself in the sub-Chapter numbering of Chapter 12 for ease of reference and coherence; for instance Configura-tion Management is in Chapter 8 activity 1 and in Chapter 12 it can be found under 12.1. Chapter 8 headers are linked to corresponding sub-Chapters of 12.






ILS

3.

Supply Support Management All sub-activities and tasks necessary to determine, acquire, catalogue, cod-ify, receive, store, transport, issue, depot level repair and dispose of spares and components necessary for the support of a Defence System.

All Supply Support ac-tivities are performed on a day-to-day basis: up-date Requirements (range and scale of spares including appro-priate modelling), Mate-rial Provisioning and Acquisition, Repair Ad-ministration, Packaging, Handling, Storage and Transport (PHS&T) and Inventory Maintenance and Control.

When a modification has to be implemented and needs the definition of an initial supply support, the ILS ac-tivities that have to be un-dertaken are related to the Initial Determination of Re-quirements, Initial Material Provisioning and Acquisition (including new Source cod-ing) of the modified equip-ment, and the redefinition of its PHS&T.

4.

Technical Support Services All sub-activities and tasks necessary to monitor and control Reliability, Maintainability and Testability (RM&T) characteristics of a Defence System, maintain agreed performance levels and enhance them.

In Service Monitoring of RM&T Performance (ac-tual gathering of Reli-ability, Maintainability, Testability and Support data realised in service, which needs to be re-corded and compared with predicted data), In Service (or Technical) Events Management (Technical Events re-ports and analysis) are performed on a day-to-day basis

If In Service Monitoring of RM&T Performance results, In Service (or Technical) Events Management analy-sis and PDS lead to the study and implementation of a modification, all ILS activities have to be per-formed. Post Design Services are sub-activities that consist of further development work undertaken after accep-tance into service to ensure that the Defence System continues to meet its ap-proved specification

5.

Obsolescence Management All sub-activities and tasks necessary to minimise the impact of the lack of supply or supportability due to obso-lescence.

Obsolescence Manage-ment is a continuous activity during ISS. It includes Obsolescence Identification (monitor-ing of obsolete items and provide visibility on obsolescence risk…), Obsolescence Resolution (evaluation, coordina-tion, proposal and moni-toring of obsolescence solutions and mitigation of obsolescence ef-fects…), and Obsoles-cence data accounting (tracking of obsoles-cence solutions propos-als and implementa-tions…).

If Obsolescence Resolution leads to the study and im-plementation of a modifica-tion, all ILS activities have to be performed.






ILS

6.

Technical Information and Data (TID) Services All sub-activities and tasks necessary to produce, give access, utilize and maintain information and data neces-sary to operate, maintain, repair, sup-port, train and dispose of equipment. This information and data could be paper, fiche, drawings, Computer Aided Design data, Interactive Elec-tronic Technical Publications, non-textual data.

The day-to-day support services related to TID are TID Revision and Maintenance Service (compliance verification, monitoring of corrective actions implementation)

In case of modification or as result of Revision and Maintenance Service, the following ILS activities have to be performed: Data and Documentation Develop-ment process (for the up-dates of TID) and Docu-ment Management (produc-tion and delivery of up-dated TID).

7.

Training Support Services All sub-activities and tasks necessary to ensure that appropriate training (both for initial training and recurrent training) is ensured to personnel and provides them with the competencies to operate, maintain and administer the Defence System during the In Ser-vice Phase. It includes also all sub-activities and tasks necessary to en-sure that the training continuously meets the User Requirements. This could include procurement of addi-tional Training Equipments, Training Courses, management of the support of the Training Equipment and the re-definition of and their redefinition in the frame of new modifications.

Day To day sub-activities consist of Training Evaluation (Monitoring, Perform-ance Analysis, Reporting and upgrading services), collecting Data and in-formation relating to the usage and Training Equipment and manag-ing the support of the Training Equipment to ensure their continuous availability.

In case of modification or as result of Training Evaluation, the following ILS activities have to be performed: Training Objec-tives Identification, Training Gap Management, Training Procurement and Training Implementation. Redefinition of Training Equipments and Courses in case of modification (appli-cation of ILS activities on new modification or specific user requirements).

8.

Support & Test Equipment Management All activities necessary to ensure that the Support and Test Equip-ments (S&TE) continuously meet the User Requirements. This could include procurement of additional S&TE, management of the support of S&TE and redefinition of S&TE in the frame of new modifications.

Collection of Data and information relating to the usage and support of S&TE and man-agement of the sup-port of the S&TE to ensure their continu-ous availability.

Redefinition of S&TE in case of modification (appli-cation of ILS activities on new modification or specific user requirements).






ILS

9.

Facilities and Infrastructure Man-agement All activities necessary to ensure that the Facilities and Infrastructure used for operating, training, storage, shel-tering and maintaining of the Defence System continuously meet the User Requirements. This could include pro-curement of additional Facilities and Infrastructure, management of the support of the Facilities and Infrastruc-ture and redefinition of the Facilities and Infrastructure in the frame of new modifications.

Collection of Data and information relating to the usage and support of the Facilities and In-frastructure and man-agement of the support of the Facilities and In-frastructure to ensure their continuous avail-ability.

Redefinition of Facilities and Infrastructure in case of modification (application of ILS activities on new modification or specific user requirements).

10.

Life Cycle Costing All activities necessary to provide Life Cycle Cost estimates and studies that could be used as benchmark against which value for money options can be measured, a tool for decisions during any trade-off analysis and a means to set up Cost Plans. It includes Costing Boundary definition, Data and Assump-tions Collection, Modelling, quantitative risk and uncertainty analysis, Analysis and Reporting.

The Recurrent support services consist of up-dating the Data and As-sumptions definition by collecting the data from the usage of the De-fence System, cost and price updates.

In case of modification studies, determine life cycle cost implications of pro-posed changes. Perform estimations in or-der to identify the optimum date of retirement

11.

Manpower and Human Factors Analysis All activities necessary for the man-agement of the personnel directly in-volved with the Defence System due to changes in use, doctrine and policies in connection with the Defence System.

Recurrent sub-activities consist of managing the Manpower and collecting data and information on Manpower usage

Manpower and Human Fac-tors Analysis has to be car-ried out in case of new modification and changes of requirements of the de-fence system (application of ILS activities on new modi-fication or specific user re-quirements).

12.

Software Support All activities necessary for the support and modification of any software re-lated to the Defence System. It in-cludes Operational servicing support (installation, de installation, data load-ing…), management support and modification tasks. Note: It is getting more common to manage the Software Support like Hardware. The way to proceed has to be defined during the tailoring process of a programme.

Operational servicing support (installation, de installation, loading, software configuration and data loading) and some management tasks (problem report-ing, user support) are the day-to-day tasks.

Modification of the software could be corrective, adap-tive and perfective. A com-plete Software Support Analysis is carried out in the frame of ILS activities. In case of modification of the system, compatibility of the Software with the hardware has to be en-sured and if not modifica-tion of the software is un-dertaken.






ILS

13.

Reliability, Maintainability and Testability (RM&T) Analyses All activities necessary to be under-taken for the design of new modifica-tion. RM&T are vital characteristics of Defence equipment. They affect the sustained delivery of the required per-formance in the field and are major drivers of the LCC. RM&T must be de-signed and built into a system if high levels of sustainability are to be achieved.

Not applicable Note: Availability and reliability monitoring to compare actual per-formance with con-tracted requirement (es-sential if using CLS Con-tract for example) is part of Technical Sup-port Services

This is an ILS activity that has to be performed for a modification study and im-plementation. The results of the analyses are inputs for the LSAR Update (see activity 8)

14.

Security Management of the De-fence System All activities necessary to ensure that security rules related to classified equipment such as Crypto devices.

Application of security measures and update of Security Management processes if required by the users

Update of Security Man-agement processes if im-plied by the implementation of modifications

15.

Organisation Update All activities necessary for the analysis and update of the support organisa-tional structures to adjust to changes in use, doctrine and policies.

Regular analysis of In Service feedback data and update of Organisa-tion of the user, if re-quired

Update of Organisation if implied by the implementa-tion of modifications

16.

Concept and Doctrine Review All activities necessary to review Con-cept and Doctrine as result of the in-fluence of the In Service activities of the Defence System.

Regular assessment of the need for Review and update Concept and doctrine of the User if required.

Update of Concept and doctrine if implied by the implementation of modifica-tions

17.

Environmental Impact Manage-ment All activities to manage the environ-mental considerations associated with the operation and support of the De-fence System and/or changes of regu-lations and laws with influence on the Defence System that have to be con-sidered.

Regular assessment of the Environmental Im-pact and application of corrective measures.

In case of modifications environmental impact is assessed.






ILS

18.

Disposal Management All activities necessary to

• plan for the phasing out of a complete Defence System at the end of its service life cycle (Disposal Phase) in an efficient, cost-effective, safe and envi-ronmentally acceptable way by establishing and maintaining a Disposal Strategy and Plan as part of the TLMP;

• update the planning for Dis-posal (Disposal Strategy and Plan, Product Disposal File (PDF) data requirements) and removal of spares, consumables and equipment discarded as re-sult of modification and mainte-nance action throughout the ISS phase of a Defence System by using the PDF;

• advise the decision maker on the most cost-effective time for the removal of the Defence Sys-tem from the inventory of the forces;

• phasing out of the Defence Sys-tem in accordance with the Dis-posal Plan and by utilising the PDF (Disposal Phase).

Disposal of the dis-cardable equipments that have to be re-placed according to the maintenance con-cept / strategy / plan. Regular update of the Disposal Strategy and Plan and PDF in case of evolution of appli-cable regulations (eg new banned sub-stances, strengthen-ing of health and safety…).

In case of modification, disposal analysis has to be undertaken in the frame of ILS.

19.

Systems Engineering All activities necessary to analyse and harmonize requirements for new modi-fications (from users or after analysis of In Service feedback), verify that the specified modification requirements are fulfilled and assist in the validation of the delivered modified part of the Defence System.

Not applicable This activity in performed during modification study and implementation.

20.

Safety Management All activities that ensure continuous safety of the operation and support of the Defence System. This means all of the activities ensuring that, at any time in its operating life, the Defence Sys-tem complies with the safety require-ments in force and is in a condition for safe operation.

A Safety Management system including for example Occurrence Reporting System (for airworthiness) has to be maintained.

In case of modifications, safety requirements have to be taken into account.






ILS

21.

Information Management All activities necessary to facilitate in-formation exchange between Pro-gramme stakeholders whilst applying appropriate data processing and pro-tection (Classification; Sensitiveness; Privacy; Limited Need To Know; Intel-lectual property rights.).

General Management Activity that facilitates the ex-change and sharing of information concerning users’ feedback, new requirements, performance of the sys-tem…

22.

Contract and Legal Support All activities necessary to manage and place contracts, elaborate procurement strategy, optimise common positions, monitor legal aspects of existing con-tracts and provisions and assist in re-solving contractual disputes, assist in the compilation of documents such as Memorandum of Understanding and Service Level Agreement and ensure new contracts are compliant with OC-CAR Rules.

General Management Activity that allows Contract management for all the necessary support of the Defence System (including amendments…) OMP 5 and OMP 6 are the OCCAR Management Procedures for contracting

23.

Risk Management All activities necessary to identify and share risk information across the whole Programme including support to operations, logistics, supply chain, In-dustry, enable the measurement of risk exposure and identifies timely mitigation actions to minimise impact on all stakeholders particularly the Us-ers, integrate risk with other ISS man-agement activities.

General management Activity that allows the management of risks linked to the support and operation of the Defence System OCCAR-EA uses Active Risk Manager (ARM) tool to manage risks

24.

Financial and Budget Manage-ment All activities necessary for the budget and financial plan preparation and ap-proval, management of budgets, commitments, funds and payments. It includes also Financial Accounting and Statements. (OMP10)

General Management Activity used for the Finan-cial and Budgetary management of the opera-tional and administrative costs associated to the Recurrent support of the defence system OMP10 is the OCCAR Management Procedure for Financial and budgetary Management. In addi-tion, OCCAR-EA uses Planning Financial Manage-ment Tool








ILS

25.

Quality Management All activities that ensure that the In Service Support is managed in an effi-cient and effective way and the ser-vices provided achieve customer satis-faction. It includes clear identification of processes and responsibility, man-agement by objectives, comprehensive process control of documentation at all levels, periodic reviews of quality plans. (ISO15288)

General Management Activity that allows the maintenance of a Quality Management System and ensures Customer satisfaction for the ser-vices delivered by OCCAR-EA and the Contractor. OMP7 is the OCCAR Management Procedure for Quality Management. OCCAR is certified ISO 9001:2008

26.

Planning and Reporting includ-ing Performance Management All activities necessary to prepare and update the Through Life Man-agement Plan (TLMP) and to report to the relevant Board and Commit-tees on the status of the Pro-gramme. This includes Perform-ance Management, which consist of all activities necessary to assess the Programme and OCCAR-EA’s management performance, man-age High Level Objectives and monitor real time performance.

General Management Activity that aims to main-tain the TLMP, to provide relevant, concise and timely reporting to the Programme Board and the Programme Committee, to measure the perform-ance of the Activities for the support of the De-fence System. OMP1 is the OCCAR Management Procedure for the establishment and maintenance of the TLMP (currently Programme Management Plan). OMP3 is the OCCAR Management Procedure for the reporting to Programme Board and Pro-gramme Committee. OCCAR-EA uses Balance Scorecard system, and the set of performance parameters developed in the ISS process model

27.

Security Management related to the Programme Division All activities that ensure that Pro-gramme classified information are adequately protected and sensitive information is handled appropri-ately.

General Management Activity that consists of es-tablishing and updating the Programme Security Instruction (PSI) and applying the security meas-ures. OMP11 and OMP12 are the OCCAR Management Procedures for the Security Management.

28.

Programme History and Les-sons Process All activities necessary to maintain a Programme History record of sig-nificant events and decisions or a record of other important informa-tion throughout the life of the Pro-gramme. It includes also identifica-tion and analysis of Programme best practices, Issues and Mistakes and implementation of necessary corrective / improvement actions as part of lessons learnt

General Management Activity that consists of maintaining Programme History and implement lessons learnt.








ILS

29.

General Support of Programme Division All activities necessary to manage Human Resources and the Site where the Programme Division is geographically located. It includes also secretariat work.

General Management Activity that consists of management of Human Resources (Recruit-ment,…), Site Management (office manage-ment…) and secretariat. Staff Regulations are defined in OMP8.

Table 7: ISS portfolio of activities and services



9. Boundary Conditions

The depth of OCCAR-EA’s management depends very much upon the dependencies on Nations’ support and the type of Contract chosen by the PSs. This latter would define the boundary between Industry (or Third Party) tasks to be managed through the men-tioned Contract and OCCAR-EA tasks to be delivered by the organisation itself to the PSs.

9.1 Dependencies

If chosen by the PSs to manage the In Service phase of a Programme, OCCAR-EA has the following dependencies on Nations’ support:

• Resources: In addition to Programme Division staff resourced by the PSs, OCCAR-EA also relies on Nations to provide the necessary specialist re-source for specific tasks (Expert Working Groups) and/or seconded national experts;

• User Furnished Information: For OCCAR-EA to be effective in providing the Services detailed in this ISS Guide, it will require specific information and operating data from the Users and other relevant stakeholders. Provision of this information must be agreed by OCCAR–EA and the PSs prior to the In Service phase;

• OCCAR-EA’s ISS activities are limited to management activities, excluding ‘hands on’ activities which would have to be built up by OCCAR-EA and which do already exist like maintenance facilities and ware houses. These activities will be used from other governmental organisations through Ser-vice Level Agreements, will be contracted out to Industry or are defined as national activities;

• OCCAR-EA will not interfere in the way PSs operate their Defence Systems. Operational issues are considered the domain of Nations and when OCCAR-EA manages aspects of the In Service phase of a Programme, it will not impact operations. However operational activities and logistic services must be integrated, therefore it is anticipated that OCCAR-EA will support Users in resolving operational issues such as poor availability and reliability;

• There are also ISS activities, which cannot be managed by OCCAR because they are strictly national in character.

9.2 Boundary with the Industry / Third Party

The depth of OCCAR-EA’s management depends very much upon the type of Con-tract that the PSs entrusted OCCAR to place. The procurement strategy will con-sider the different types of contracts, also the option of a performance based (see Chapter 12.22). In general two types of Contract can be distinguished:

Case 1: Global contract: PSs task OCCAR-EA to Contract all ISS Elements to be performed by one or more contractors and to be controlled by the OCCAR-EA PD via a high level performance indicator. In this case:

• OCCAR-EA as the management organisation will place a Contract on a cer-tain level of system operational availability or the First level Performance


parameters (Chapter 11) to Industry. An increase of the Defence System performance can be achieved by inserting incentives in the contract;

• OCCAR-EA will ensure, through a lean and competent Programme Division, the compliance with the contract, the long term cost-effective sustainability of the Defence System, the effective interfaces to Contractor and PSs and the most efficient date and execution of the disposal of the Defence Sys-tem.

Case 2: Contract for selected ISS Elements: PSs entrust OCCAR-EA to contract the overall Management of selected ISS Elements to a third party, the remaining being the management responsibility of the organisation. In this case:

• OCCAR-EA as management organisation will place a Contract with Industry with incentives linked to management efficiency and constant improvement of these selected Elements;

• OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for the Elements by the use of first level element of the Performance Parameter (First level Performance Parameter of these ele-ments. Chapter 12 details this approach specifically (for Performance Pa-rameter definition see Annex B) for the Services;

• OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for the Elements by the use of second or third level Performance Parameters. Chapter 12 details this approach specifically (for Performance Parameter definition see Annex B));

• OCCAR-EA will ensure that the Contract contains provisions for the links among the ISS Elements and the other activities of the ISS Portfolio.


10. OCCAR ISS Portfolio /non-OCCAR managed ISS Portfolio

10.1 ISS Portfolio not managed by OCCAR

Taking into account the general boundary conditions the following aspects of ISS are generally accepted to be outside of the current scope of OCCAR-EA:

• Hands on activities such as

o Training (actual teaching and direct training support);

o Execute the maintenance (Repairing and Overhauling);

o Packaging, Storing Handling and Transporting;

o Warehousing of spares and consumables.

• Facilities and Infrastructure Management (national aspects; impossi-ble to influence by OCCAR);

• Safety Management (national aspects associated with the safe operation and support of the Defence System);

• National specific activities such as

o Organisation update and management;

o Concept and Doctrine Review;

o National manpower management;

o Operational activities.

• Environmental Impact (due to different national laws and regulations)

However, OCCAR-EA could be mandated by the PSs to support these activities, for example by preparing, executing and managing common contracts.

10.2 ISS Portfolio managed by OCCAR

With consideration to the exclusions above, OCCAR-EA can manage directly or by contracting through the Industry all the activities listed in Chapter 8.


11. OCCAR ISS Process Model

11.1 Aim of the ISS Process Model

The ISS process model is an application of performance based logistics to the In Service environment which can be implemented by PSs, OCCAR-EA and/or Indus-try.

The aim of this ISS process model is to detail each Main ISS Element (here num-bered from 1 to 7) of the complete ISS Portfolio and to assess the overall effec-tiveness of the ISS management for a Complex Defence System. It offers different levels of assessment criteria, from the overall Main ISS element (e.g. Training Ser-vices Management) down to activities (e.g. Training Objectives Identification) and sub-activities (e.g. Training Concept Development).

The model describes the Main ISS Elements and quantifies their impact on Ao.

11.2 Operational availability and the ISS Process Model

For the owner of a Defence System, the ownership value is defined by the ability to actually use the system. The most common term for this value is system opera-tional availability, or the probability that a Defence System will be ready to per-form missions or functions under the stated conditions when called upon to do so at a random time.

The term Ao is used in the logistic field when a realistic support environment and all maintenance actions are considered in addition to the Defence System.

The Ao defines the percentage of time when, under actual operating conditions, the weapon system is available to perform its scope.

The basic formula for calculation of Ao is:

During the In Service Support phase all activities are aimed at optimising the Sys-tem Operational Availability while monitoring the LCC of the Defence System.

Analysis of the Main ISS Elements has enabled to define generic PPs able to meas-ure the performances achieved in the management of the support environment and to describe its impact on system operational availability. These PPs should be tailored case by case to the needs of the Programme.

By adopting a systematic approach for the description of the Main ISS Elements, activities and sub-activities, the model identifies the logical and mathematical links between PPs at every level and between different levels, therefore allowing to trace and justify each parameter that contributes to the system “Up Time” and/or “Down time”, in other words to the system operational availability.

The operational availability is considered to be the Major Performance Parameter (MPP) for this ISS process model.

11.3 Methods and Tools

11.3.1 Performance based approach

PPs are basic to the measures and generally can be used for:

DowntimeUpTimeUpTime

TimeTotalTimeCapableMissionAo +

==_

__


• Evaluating the strong points and weaknesses of an organisation;

• Controlling performance with respect to contractual objectives;

• Comparing performance with that of other organisations (benchmarking).

Following the EITVOX modelling method (see next paragraph) the PPs have been organised with different levels or layers.

The highest level of PPs is called First level Performance Parameter (FPP) and measures the result achieved by the overall Main ISS Element man-agement in terms of contribution to the System Operational Availability, the MPP.

The lower levels of PPs refer to activities (Second Level performance pa-rameters, SPP) and sub-activities (Third Level Performance Parameters, TPP).

Different levels of PP are linked through the utilisation of a Derived PPs.

The Annex B illustrates structure of PPs for each ISS element.

11.3.2 The EITVOX methodology

For each Main ISS Element managed by OCCAR, the Entry criteria, Inputs, Output, Stakeholders, Required competencies, Assessment of maturity, PPs, process description and Procedures to be applied have been organized according to the EITVOX modelling method.

This acronym recalls the letters identifying the main information that the method describes:

E Entry Criteria Criteria for beginning activity

I Inputs Data/Information required during execution of activity

T Tasks Tasks to carry out the prescribed activity

V Validation Data collected to validate the activity

O Outputs Data/Information produced during execution of activity

X Exit Criteria Criteria defining completion of activity

The aim of the EITVOX forms is to guide the developer in identifying and describing for every element – from the top level to the lowest level corre-sponding to each sub-activity – the above data.

11.3.3 EITVOX method applied to ISS OCCAR architecture

By the analysis of the In Service phase for a generic System, seven Main ISS Elements have been identified by OCCAR-EA (see Chapter 8):

• Configuration Management; • Maintenance Management; • Supply Support Management;


• Technical Support Services; • Obsolescence Management; • Technical Information and Data Services; • Training Support Services.

Each Main ISS Elements has been defined as a “first level” of the overall ISS process model corresponding to the first level of EITVOX form.

Through a further development of the EITVOX method, two lower levels corresponding to activities and sub-activities (second and third level) have been defined by the description of all information needed to set up, to steer and monitor them.

This information has been collected into the OCCAR-EA IPs to provide a de-tailed description of each activity and sub-activity included on the Main ISS Elements that OCCAR-EA could be requested to manage during the ISS phase. These IPs can be considered the textual description of the EITVOX forms contents. The same EITVOX forms for each Main ISS element have been considered as an annex of the specific IP.

The information relevant to the PPs, including all metrics and correlations, has been collected into special forms that furnish all data needed to get and use them (see Annex B on Performance Parameters).

The following table on figure 5 represents the synthetic graphic of the re-sults obtained through the application of the EITVOX method to the OC-CAR-EA ISS process Model:

“Overall elements breakdown”;

“Performance Parameters breakdown” shown in annex B.


Figure 5: ISS Process Model - Overall elements breakdow n


12. List of ISS phase activities managed by OCCAR-EA, detailed to basic activities

The previous Chapters describe the framework within which OCCAR-EA could manage a collaborative Programme in the ISS phase. It has been shown that:

• the OCCAR ISS phase is fully embedded in its TLM approach;

• the ISS Elements are systematically derived from the application of ILS of the ISS preceding phases;

• the complete ISS portfolio has been tailored by the strict application of OCCAR boundary conditions;

• the application of performance based logistics can be achieved through the im-plementation of the ISS process model;

For each of the ISS management activities within its scope, OCCAR-EA would, in princi-ple:

• assist Participating States (PSs) in developing harmonised requirements;

• produce detailed specifications;

• place contracts (or SLAs);

• monitor the performances by applying specific performance parameters and/or apply performance parameters agreed by the PSs (according to Chapter 11.3.1).

• assist the PSs with the deliverables and acceptance of goods and services;

• support the PSs to manage national ISS activities.

12.1 Configuration Management

As basic references for the OCCAR-EA Configuration Management (CM) the follow-ing documents have been utilised:

• Allied Configuration Management Publication (ACMP 1-6);

• STANAG 4159, NATO Materiel Configuration Management Policy and Procedures for Multi-National Joint Projects;

• MIL-HDBK-61A: “CM Life Cycle Management and Planning”.

OCCAR-EA has implemented an Internal Procedure IP 26-5 on Configuration Man-agement including a template on the respective Strategy and Management Plan (S&MP).

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

According to the OCCAR-EA Process Model (Chapter 11) the overall Configuration Management is considered as “first level” activity concerning the ISS phase.

Note The number of the following sub-Chapters repeats the numbering of the activities in-troduced in Chapter 8 for ease of reference and coherence, for instance Configuration Management is in Chapter 8 activity 1 and in this Chapter it can be found under 12.1. The described PPs in the tables are hyperlinked to the respective definition of the PP in annex B.


The Configuration Management consists of all sub-activities and tasks necessary to direct and control the functional characteristics of a Defence System as described in its technical documentation and later achieved in the Defence System, to man-age the modification process, to record and monitor all configuration data and in-formation.

12.1.1 Objective of Configuration Management in the ISS phase

Within the ISS organisation, the objective of PSs and OCCAR-EA will be:

• To provide an approach for the configuration control through man-agement of the design, manufacture, test and acceptance proc-esses, including installation, maintenance and support;

• To provide functional and physical properties identification for every Configuration Item (CI) and record all changes of any such proper-ties and their implementation status - whether related to hardware (Hardware Configuration Item), software (Software Configuration Item), firmware or documentation - hence ensuring overall trace-ability of configuration.

• To Maintain, as far as possible, a common configuration baseline for best possible interoperability and costs effectiveness;

This activity has an impact on the achievable value of System Operational Availability. The proposed FPP is called “Configuration Data Confidence” (CDC). For a mathematical description of this first level performance pa-rameter and its link with lower level performance parameters see Annex B.

12.1.2 Contract the overall Configuration Management

If the PSs decide to contract the overall Configuration Management to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to configuration management efficiency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level element (FPP: Configuration Data Confidence).

12.1.3 OCCAR-EA manages the overall Configuration

If the PSs decide that OCCAR-EA will manage the overall Configuration Management, the second/third levels (respectively activities and sub-activities) can be managed and performed by OCCAR-EA or contracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level Performance Parameters, as specified in following Element Table.

Configuration Management involves one coordination second level activity and four conceptual “second level” activities, according to the OCCAR-EA ISS Process Model:

1) Coordination Activities

2) Configuration Identification: this is a pre-requisite for any other Configu-ration Management sub-process. It defines the functional and physical characteristics of a CI to the level of detail that enables - depending on the


phase of the Programme - its selection, development, testing, evaluation, production, acceptance, operation, maintenance and support.

3) Configuration Audits: verification of compliance with the relevant con-figuration documentation. Compliance shall be verified separately by 2 dif-ferent audit types: Functional Configuration Audit (FCA) and Physical Con-figuration Audit (PCA).

4) Configuration Accounting: recording and reporting on the configuration baseline of all changes (proposed and approved), including their status of implementation.

5) Configuration Control: evaluation, co-ordination and approval of all modifications and configuration documentation. Configuration Control can start after formal establishment of the configuration baseline and involves monitoring the implementation of all approved changes.

Each one of these second level elements has been detailed on a third level of tasks and completed with Performance Parameters in the following table.

12.1.4 Stakeholders in Configuration Management

Along with OCCAR-EA, the main actors who participate in Configuration Management are:

• Individual PSs’ User and associated support organisations;

• Industry - the Design Authority and/or 3rd party Industry service providers;

The coordination activities between different stakeholders concerning the Configuration Management are not covered by the ISS Process Model but form an integral part of the overall Configuration Management performed by OCCAR-EA.


Figure 6: Navigation Map for the Configuration Management element


Configuration Management – Element Table

Second Level: Activity

Third Level: Sub-activity

Performance Parameters Name Definition

Performed by Industry through a Contract man-

aged by OCCAR-EA Managed by OCCAR-EA

Coordination Activities

Establish and maintain effective organ-isational interfaces communication among all stakeholders

No Contract for this task

OCCAR-EA has the respon-sibility to maintain commu-nications by means of Ex-pert Working Groups, work-spaces, e-mails…

Establish and maintain a fully docu-mented common configuration man-agement plan in conjunction with the PSs and the design Authority.

OCCAR-EA will contract the provision of the Configuration Management Plan

OCCAR-EA will verify that the Configuration Manage-ment Plan complies with the PSs requirements

OCCAR-EA will coordinate and facilitate the meetings of the Joint Configuration Management Panel (JCMP) in charge of ECP approval


OCCAR-EA has the respon-sibility to maintain commu-nications by means of Ex-pert Working Groups, work-spaces, e-mails…

Establish and maintain the process of ‘Identify and Manage Lessons’.


OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mails…




Third Level: Sub-activity Performance Parameters Name Definition



Configuration Identification

Configuration Item Selection

Update the list of Configuration Items in the Configuration docu-mentation Records as result of new selection criteria, new modifica-tions, Obsolescence Reports OCCAR-EA will contract to

the Industry for configuration identification

OCCAR-EA will ensure that the Industry meets the per-formance metrics that will be set up for this activity

Percentage of Identified Items against total

number of items se-lected for Configuration

Management

Supporting Data Aggregation

Update all data necessary to iden-tify Configuration Items.

Percentage of Common Items against total

number of items se-lected for Configuration

Management

Configuration Validation

Ensure that the Configuration base-line documentations are consistent and coherent with regards to the Configuration items list, reliability and Maintainability Evaluations and other documentations

No Contract for this task OCCAR-EA will perform this validation in coordination with the PSs.

Configuration Audit Execution

Execute Functional Configuration Audits on Request of the PSs on re-procured articles. OCCAR-EA will contract/or

not the provision of Configu-ration Audit Report

OCCAR-EA will perform or contract audits in coordina-tion with the PSs and fol-lowing approved test pro-cedures and validation test data defined in the Configu-ration Management Plan

Percentage of Configu-ration Audits vs total number of items se-

lected for Configuration Management

Execute Physical Configuration Au-dits on Request of the PSs on re-procured articles.








Configuration Audit

Analysis of Results

Verify compliance of the Current Approved Configuration Baseline against the audited Configuration Baseline

No Contract for this task OCCAR-EA will perform the analysis of the compliance

Percentage of Outstanding Action

items vs total number of items selected for


Identify Action items by providing Discrepancies/Changes Reports as result of the audit

OCCAR-EA will contract/or not the provision of Configu-ration Audit Report


Monitor Outstanding Action Items by defining, implementing and tracking the status of the necessary corrective actions

OCCAR-EA will contract/or not the provision of Configu-ration Audit Report









Configuration Accounting

Configuration Status Accounting

Data Recording: Record all data from the other Configuration Man-agement activities (Current ap-proved configuration Baseline, Re-sults of Configuration Audits, ECPl status and plan)

Depending on the specifics of the Programme this task could be contracted to the Industry

Depending on the specifics of the Programme this task could be undertaken by OCCAR-EA, Nations or In-dustry

Percentage of Ac-counted Items vs. total number of identified Items

Controlling Information Security: the information security procedures shall be guaranteed and applied to prevent unauthorized access and loss of data


OCCAR-EA will provide pro-cedures and Depending on the specifics of the Pro-gramme this task of guar-anteeing security could be undertaken by OCCAR-EA, Nations or Industry

Percentage of Account-ing Error vs. total num-ber of items selected for Configuration Manage-ment

Configuration Data Management

Elaboration of Information Needs: Define the information related to configuration management that is necessary to be provided to the PSs and other stakeholders


OCCAR-EA will define the necessary information to be shared and exchanged in the Configuration Manage-ment Plan

Provide Configuration Reports that could comprise for example the list of configuration related documents, the list of Engineering Change Pro-posals, the outstanding action list from the audits and audit status, the configuration breakdown, the current approved Configuration Baseline.


OCCAR-EA will provide to the PSs Configuration Re-ports within a certain pe-riodicity defined in the Con-figuration Management Plan through a Contract placed with the Industry or by collecting all the neces-sary information (depend-ing on the the Programme)






Performed by Industry through a Contract

managed by OCCAR-EA

Managed by OCCAR-EA

Configuration Control

Engineering Change Proposals

(ECP) Management

Modification Need Analysis: assess technical solutions, financial and logistic impact and commercial terms and conditions of ECP. En-sure interoperability requirements are met. Provide a study Report and if applicable inputs to Technical Events or Obsolescence Issues. Collect ECPs, non-mandatory change requests, Request for De-viations and Request for Waivers from anywhere in the organisation.

OCCAR-EA could contract some studies.

OCCAR-EA could perform some studies in coordination with the Industry and the PSs.

ECP Issue: issue and Engineering Change proposal according to Modi-fication Needs Analysis, assign category and priority level.

OCCAR-EA will contract the issue of the ECP.

OCCAR-EA will ensure that the Industry issues the ECP within the contracted timeframe. The definition of categories and pri-ority levels are written in the Configuration Management Plan.

Mean Time to Process Engineering Change Proposals

ECP Approval: approve the ECP according to category and priority level and request for technical sup-port if required.

OCCAR-EA could contract Industry for technical support if needed.

OCCAR-EA will coordinate and facilitate the meetings of the Joint Configuration Manage-ment Panel (JCMP) in charge of ECP approval and will pro-vide technical support if re-quired.


Table 8: Configuration Management sub-activit ies






managed by OCCAR-EA

Managed by OCCAR-EA


Implementation of Changes

Embodiment Decision and Contract Finalisation: prepare budget and implementation plans for embodi-ment decision. Provide an ECP im-plementation plan which might consider the impact on not yet de-livered Defence Systems.

Some ECP implementation plans could be contracted (if technical support re-quired)

OCCAR-EA will prepare the embodiment decision and will place the Contract for the im-plementation of the ECP

Percentage of Engineer-ing Change Proposals with embodiment deci-sion but not yet imple-mented vs total number of Identified Items

Execute implementation of the ECP OCCAR-EA will contract to the Industry or the PSs will perform the execution

Implementation Status Reporting: Provide ECP implementation Status Report with information from the Field Data Reports


OCCAR-EA will inform the PSs on the implementation of changes. A processing time should be agreed with the PSs


12.2 Maintenance Management

As basic references for the OCCAR-EA Maintenance Management the following documents have been utilised:

• ASD 2000M, Inter. Spec. for Material Management;

• NAVSEA- S9081-AB-GIB-010 Reliability Centred Maintenance Hand-book.

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation. According to the OCCAR-EA Process Model (Chapter 11) the overall Maintenance Management is considered a “first level” activity concerning the ISS phase.

Maintenance Management consists of all the sub-activities and tasks taken to re-tain the Defence System in or restore it to a specified condition. Maintenance Management scope excludes Maintenance of Infrastructure and Facilities.

12.2.1 Objective of Maintenance Management in the ISS phase


• To maintain agreed maintenance performance levels, and;

• To enhance maintenance performance (if achievable and economic to do so) in order to improve defence capability and/or drive down LCC.

According to the above statement this activity has an impact on the achiev-able value of System Operational Availability (as component of system ca-pability). The proposed FPP is called ‘Maintenance Management Effectiveness’.

For a mathematical description of this first level performance parameter and its link with lower level performance parameters see Annex B.

12.2.2 Contract the overall Maintenance Management

If the PSs decide to contract the overall Maintenance Management to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to maintenance management efficiency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level element (FPP: Maintenance Management Effectiveness).

12.2.3 OCCAR-EA manages the overall Maintenance

If the PSs decide that OCCAR-EA will manage the overall Maintenance Management the second/third levels (respectively sub-activities and tasks) can be managed and performed by OCCAR-EA or contracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level performance Parameters, as specified in following Element Table.


Maintenance Management involves four conceptual “second levels” of sub-activities:

1. Coordination activities,

2. Maintenance Planning: To plan all identified maintenance tasks for every corrective maintenance cycle of each new or modified Main-tenance Significant Item (MSI) and to schedule the tasks in confor-mance with the operational/maintenance cycles, and with the avail-able assets and resources.

3. Maintenance Monitoring and Control: To collect and manage field maintenance data, to measure the achieved performance against specified standards and to review/revise current Maintenance Plans, tools, test and working procedure.

4. Execute maintenance: To ensure the fulfilment of preventive main-tenance requirements and corrective maintenance actions to restore serviceable conditions in a damaged system/equipment.


12.2.4 Stakeholders in Maintenance Management

Along with OCCAR-EA, the main actors who participate in maintenance ac-tivities could be:


• National maintenance organisations - maintenance and technical staff working as a central service on behalf of all PSs;


• Designated Agency such as NAMSA.

The coordination activities between different stakeholders concerning the Maintenance tasks are not covered by the ISS Process Model but form an integral part of the overall Maintenance activity performed by OCCAR-EA.


Figure 7: Navigation Map for the Maintenance Management Element


Maintenance Management – Element Table





managed by OCCAR-EA

Managed by OCCAR-EA


Establish and maintain organisa-tional interfaces with all stake-holders.


OCCAR-EA has the responsibil-ity to maintain communications by means of Expert Working Groups, workspaces, e-mails…

Maintenance Working Group will be formed to ensure cooperation, inte-gration and harmonisation of the PSs ISS requirements (including cross maintenance agreements).


OCCAR-EA has the responsibil-ity to maintain communications by means of Expert Working Groups, workspaces, e-mails…

Organise & Chair Maintenance Working Groups to ensure mainte-nance meets the Users require-ments (coming from reliability, maintainability, availability evalua-tions).

OCCAR-EA may contract study on case by case (see Technical Support Service)

OCCAR-EA has the responsibil-ity to maintain communications by means of Expert Working Groups, workspaces, e-mails… and react to the requests.

Establish and maintain the process of ‘Identify and Manage Lessons’. No Contract for this task

OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-mails…







managed by OCCAR-EA

Managed by OCCAR-EA

Maintenance Planning

Maintenance Analysis

To update the “Maintenance Con-cept” as result of RM&T Evalua-tions, analysis of change in Mainte-nance Policy, Obsolescence Re-ports.


OCCAR-EA will provide recom-mendation for updating the Mainte-nance Concept as result of the analysis

Maintenance Plan Com-pleteness (third level)

Development Plan

To update the “Maintenance Plan” (Maintenance Programme, provid-ing preventive maintenance details) as result of modifications, update of the maintenance concept, Damage Assessment Reports, Infrastructural Details, Operational Demands, etc.

No Contract for this task OCCAR-EA will assist the PSs in updating the Initial Maintenance Programme

Maintenance Plan Correctness (third level)

To update the “Maintenance Plan” (Maintenance Significant Items List) as result of modifications, update of the maintenance concept.

OCCAR-EA will place a Contract with Industry with incentives linked to maintenance efficiency and constant improve-ment

OCCAR-EA will ensure that the In-dustry meets the performance met-rics that will be set up for this activ-ity

To update the “Maintenance Plan” (Work Order Technical Definition) as result of modifications, update of the maintenance concept.

OCCAR-EA will place a Contract with Industry with incentives linked to maintenance efficiency and constant improve-ment

OCCAR-EA will ensure that the In-dustry meets the performance met-rics that will be set up for this activ-ity







managed by OCCAR-EA

Managed by OCCAR-EA

Maintenance Monitor and

Control

Status Accounting

Data recording: provide, collect, store and update all data originating from maintenance activities (Maintenance la-bour hours, list of utilized spares, dis-crepancies on maintenance procedures, etc.).

Depending on the specif-ics of the Programme this task could be contracted to the Industry.

Depending on the specifics of the Programme this task could be undertaken by OCCAR-EA, Nations or Industry.

Controlling Information Security: the in-formation security procedures shall be guaranteed and applied to prevent unau-thorized access and loss of data

Depending on the specif-ics of the Programme this task could be contracted to the Industry.

OCCAR-EA will provide proce-dures and depending on the specifics of the Programme this task of guaranteeing secu-rity could be undertaken by OCCAR-EA, Nations or Indus-try.

Maintenance Data Completeness Rate (second level)

Maintenance Control

Control of databases coherence; ensure the coherence between current Baseline Maintenance View and any other view (i.e. Logistic view).

No Contract for this task. OCCAR-EA is responsible for verifying the databases coher-ence.

Measure of performance: to measure Maintenance Management Performances against specified performance levels and report upon.

No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.

Provide Maintainability Reports on: Cur-rent approved maintenance view, list of maintenance documents, maintenance performances, determination of material and human resource needed, mainte-nance labour hours, proposed modifica-tion on maintenance plan - maintenance concept and Training Support Services.

Depending on the specif-ics of the Programme this task could be contracted (in full or partially) to the Industry.

OCCAR-EA will provide the overall management to deliver maintainability reports.






Name Definition Performed by Industry

through a Contract man-aged by OCCAR-EA

Managed by OCCAR-EA

Execute Maintenance

Preventive Maintenance

Perform the specific maintenance task and report on this task through the Mainte-nance Works Record (MWR)

OCCAR-EA will place a Con-tract with Industry with in-centives linked to mainte-nance efficiency and con-stant improvement.

OCCAR-EA will ensure that the Industry meets the performance metrics

that will be set up for this activity.

Expected Mean Preven-

tive Time (third level)

Corrective Mainte-nance

Perform the specific maintenance task, to restore the required operational capability also on operations and to report on this task through the Maintenance Works Rec-ords.

OCCAR-EA will place a Con-tract including maintenance support on operations, with incentives linked to mainte-nance efficiency.

Expected Mean Time To Repair (third level)

Close Maintenance Task

Closure of the MWR represents the end of the maintenance task. The MWR, issued upon returning the system to the user shall detail: description of maintenance activity, final list of material and consumables, technical status documentation, defects discovered, correction proposal for any further minor defect, service certification documentation, personnel quantity and skill levels.

OCCAR-EA will place a Con-tract with Industry with in-centives linked to mainte-nance efficiency and con-stant improvement.

Variation % ADT (third

level)

Warranties, Guar-antees, Safety and Examinations (task

repeated in Con-tracting and Tech-

nical Support)

Warranty and performance guarantees will be carefully monitored and enforced. Fol-low on work could include assisting in the preparation of service bulletins and har-monising PSs requirements in order to ini-tiate modification action.

OCCAR-EA will define war-ranties and Guarantees in the contracts to the Industry

Table 9: Maintenance Management sub-activities


12.3 Supply Support Management

As basic references for the OCCAR-EA Supply Support Management the following documents have been utilised:

• ASD 2000M, Inter. Spec. for Material Management;

• MIL-STD 1367 – PHST Program Requirements.

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

According to the ISS Process Model (Chapter 11) the overall Supply Support Ser-vices is considered a “first level” element concerning the ISS phase.

Supply Support Management consists of all activities and sub-activities necessary to determine (identify and quantify), acquire (acquire and ensure replenishment), catalogue, codify, receive, store, transport, issue, repair3

In principle OCCAR-EA will use the ASD S2000M specifications for the manage-ment of Supply Support, but this will be subject to PSs decision on a Programme by Programme basis. The management of ASD S2000M messages and data ex-changes would preferably rely on Third Party S2000M system (eg: NAMSA) through the placement of a Service Level Agreement. OCCAR-EA Information Man-agement system will interface with the S2000M framework within the limits of the information that is needed to be managed in the Supply Support Management area.

and dispose of spares and components necessary for the support of a Defence System.

12.3.1 Objective of Supply Support Management in the ISS phase

Within the ISS organisation, the objective of PSs and OCCAR-EA will be to optimize the Mean Logistic Downtime. This activity has an impact on the achievable value of System Operational Availability. The proposed FPP is called “Supply Support Effectiveness” (SSE). For a mathematical description of this first level performance parameter and its link with lower level per-formance parameters see Annex B.

12.3.2 Contract the overall Supply Support Management

If the PSs decide to contract the overall Supply Support Management to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to Supply Support Management effi-ciency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level ele-ment (FPP: Supply Support Effectiveness).

12.3.3 OCCAR-EA manages the overall Supply Support

If the PSs decide that OCCAR-EA will manage the overall Supply Support Management, the second/third levels (respectively activities and sub-activities) can be managed and performed by OCCAR-EA or contracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level performance Parameters, as specified in the follow-ing Element Table.

3 Return to serviceable condition with the associated Certificate of Conformity (ex: EASA Form 1).


Supply Support Services involve six conceptual “second levels” of activities:


2. Determination of Requirements: starting from the Procurement Poli-cies Plan, logistic data, field reports: a) To define initial and replen-ishment requirements for spares, repair parts, and consumables and for the various elements of the logistic support (e.g.: support and test equipment, training equipment, etc); b) To manage the “rang-ing process” and “scaling process”.

3. Material Provisioning and Acquisition, providing to items’ source coding, preparation of stock lists and procurement documentation, as well as acquisition and delivery of material.

4. Repair administration, providing all those management activities that cover Repair Order Placement and Administration, Repair Activ-ity and Procurement Planning and Information on Repair Order status and Inspection.

5. Packaging, Handling, Storage, and Transportation, comprises per-sonnel, technical data, computer resources and mobile facilities and all materials, equipments and special provisions necessary for pack-aging, safety and preservation, storage, handling and/or transporta-tion of all systems / equipments.

6. Inventory Maintenance and Control, collect and analyse logistic data throughout the systems’ life cycle, to assess the effectiveness of Supply Support capability. Establish a demand rates historical data-base, enabling to adjust provisioning factors, hence improving the Supply Support Management.


12.3.4 Stakeholders in Supply Support Management

Along with OCCAR-EA, the main actors who participate in supply support activities could be:


• National support organisations and technical staff working as a cen-tral service on behalf of all PSs;



The coordination activities between different stakeholders concerning the Supply Support are not covered by the ISS Process Model but form an inte-gral part of the overall Supply Support Management performed by OCCAR-EA.


Figure 8: Navigation Map for the Supply Support Management element


Supply Support Management – Element Table





managed by OCCAR-EA

Managed by OCCAR-EA


Establish and maintain organisational interfaces with all stakeholders.



Supply Support Working Group will be formed to ensure cooperation, inte-gration and harmonisation of the PSs ISS requirements (including cross supply support agreements and strat-egy for supply support).When appli-cable, this group will update the S2000M Guidance Document and identify functionalities to be imple-mented in the national information system and/or third Party.



Organise & Chair Supply Support Working Groups to ensure supply support activities meet the Users re-quirements (coming from reliability, maintainability, availability, support-ability, evaluations).

OCCAR-EA may contract study on case by case (see Technical Support Service)

OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-mails… and react to the requests.

Organise ad-hoc meetings to respond to critical supply support problems.

OCCAR-EA will contract for the participation of Industry at meetings


Establish and maintain the process of ‘Identify and Manage Lessons’. No Contract for this task

OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-maile-mails…






Performed by Indus-try through a Con-tract managed by

OCCAR-EA

Managed by OCCAR-EA

Determination of

Requirements

Ranging Process

To provide/update the Requirements for spares/repair parts and consumable iden-tifying item replacements, demand rates, repair and re-supply cycle, condemnation factors and repair policy. Such process is based on maintenance policy, procure-ments policy, level of repair analysis, criti-cality analysis and application of spare optimization tools.

Depending on the spe-cifics of the Programme OCCAR-EA can con-tract for this task

Depending on the spe-cifics of the Programme , OCCAR-EA is performing the task in accordance with the defined scope or is contracting for ranging

Criticality Evaluation

To assess the impact of selected items on system effectiveness. Every selected item (and quantity) shall be justified by de-mand rate predictions and the effects for not having the item on stock shall be as-sessed.


PNSS (second level)

Scaling Process

To provide/update the Provisioning List by calculating the required numbers of each spare at pre-defined repair level and their initial procurement quantities. Initial pro-visioning or re-provisioning, to support the system for a specific period of time, is accomplished through statistical analysis, optimization and simulations. Periodical review of scaling should be done consid-ering experience gained from field, chang-ing of operational or environmental sce-nario.


Spare Utilization Rate (second level, only

contractual PP)







OCCAR-EA

Managed by OCCAR-EA

Material Provisioning

and Acquisition

Source Coding Codification of items of supply. Support the NATO codification process, pro-vide/update the Codification List

OCCAR-EA will place a Contract with Industry with incentives linked to efficiency and constant improvement

OCCAR-EA will provide the overall management to deliver the Codification List

Spare pool level (sec-ond level, only contrac-

tual PP),

Delay time for spares (second level derived PP linked to Material Provisioning and ac-

quisition)

Procurement Documentation

To provide/update the Procurement Plan and related contracts: Identification of suppliers, price determination, pricing in-formation, scheduling date and procure-ment time, Contract change management.


Percentage of spares/repairs with ap-

proved procurement plan

(third level, only con-tractual PP)

Material Provisioning

To provide/update the Provisioning Plan and related contractual management. Several organisational options are possi-ble depending on National requirements. Virtual spares pool, spare lease (the spares are owned and managed by a Con-tractor), Nations local stocks, Nations owned stock, mutual supply support, common spares pool, mutual emergency supply, etc.

OCCAR-EA will place a Contract with Industry with incentives linked to availability of spares/repairs (if appli-cable)

OCCAR-EA will manage the performance metrics associated to the contract

Percentage of spares/repairs with ap-

proved provisioning plan

(third level, only con-tractual PP)

Acquisition

Order and invoice administration: invoic-ing and monitoring correct Contract ful-filment. This activity could involve other administrations.

Order and administra-tion through third party

Place Service Level Agreement with third party







OCCAR-EA

Managed by OCCAR-EA

Repair Administration

Repair Activity and Procurement

Planning

To produce/update the following docu-mentations: Repair Activity Planning (as-sessment of type and quantity of items to be returned for repair within a defined time), Repair Procurement Plan, Request for Repair Quotation, Approved Customer Price List.

Depending on the spe-cifics of the Programme OCCAR-EA may place a Contract on availability

Depending on the spe-cifics of the Programme , OCCAR-EA may perform the activity itself, place a SLA with third party or place a Contract with a Contractor

TAT (second level)

Repair Order Placement and Administration

To issue the Repair Order Placement (de-fining repair activity type, applicable re-pair scheme, material condition of repair items). This activity covers also the Order Administration

Depending on the spe-cifics of the Programme OCCAR-EA may place a Contract on availability

Depending on the spe-cifics of the Programme , OCCAR-EA may perform the activity itself, place a SLA with third party or place a Contract with a Contractor

% of Repair Items into the approved cus-

tomer Price list (third level, only contractual

PP)

Status Informa-tion and Repair

Inspection

This function allows the Nations to be in-formed on Repair Order Status. The Na-tions can also request repair inspection at several states of the repair process. The results will be contained in a Repair In-spection Report.


OCCAR-EA is performing the task in accordance with the defined scope and the PSs.







OCCAR-EA

Managed by OCCAR-EA

PHS&T

PHS&T plan

Update PHS&T planning in accordance with processes under Configuration Man-agement, Maintenance Management, change of operational requirements

No contract for this task


Packaging

Execute packaging (All operations and devices required to prepare items for shipment, including preservation, packag-ing, marking, unitize and palletize). All these operations are regulated in the PHS&T Plan.

These PHS&T activities are part of other contract

No role for OCCAR-EA except for Contract man-agement

Handling

Execute handling (Moving item from one place to another within a limited range (normally limited to a single area). Hand-ing of special material must be docu-mented into the system database to ac-count for any additional support equip-ment required). All these operations are regulated in the PHS&T Plan.



Percentage of mis-handling items (sec-

ond level)

Storage

Execute storage (Short or long storing of items, either in temporary or permanent facilities). All these operations are regu-lated in the PHS&T Plan.



Transportation

Execute transportation (Transferring an item to distance using commonly available means of transportation). All these opera-tions are regulated in the PHS&T Plan.



Mean Delay Time for transportation (third

level)


Table 10: Supply Support Management sub-activities






OCCAR-EA

Managed by OCCAR-EA

Inventory Maintenance, Monitor and

Control

Status Accounting

Data recording: provide, collect, store and update all data originating from supply sup-port activities (orders, procurement data, inventory records, stock list, provisioning factors, consumption rate, repair and recycle time, pipeline and procurement lead time, ect). To enable this function pre-formatted reports shall be utilized (i.e Discrepancies reports, Back order reconciliation, etc).

Depending on the spe-cifics of the Programme this task could be con-tracted to the Industry

Depending on the specif-ics of the Programme this task could be undertaken by OCCAR-EA, Nations or Industry

TAT (second level)

Controlling Information Security: the infor-mation security procedures shall be guaran-teed and applied to prevent unauthorized access and loss of data


OCCAR-EA will provide procedures and Depend-ing on the specifics of the Programme this task of guaranteeing security could be undertaken by OCCAR-EA, Nations or Industry

% of Repair Items into the approved cus-

tomer Price list (third level, only contractual

PP)

Supply Support Control

Control of databases coherence; ensure the coherence between current Baseline Logistic View and any other view (i.e. Maintenance view).


OCCAR-EA is responsible for verifying the data-bases coherence.

Supportability data completeness (second level)

Measure of performance: to measure Supply Support Performances against specified per-formance levels and report upon.


OCCAR-EA is performing the task in accordance with the defined scope.

Provide Logistic Reports on: Current ap-proved logistic view, list of logistic docu-ments, logistic breakdown list, supply sup-port performances, spare consumption rate, spare outages, etc.)

Depending on the spe-cifics of the Programme this task could be con-tracted (in full or par-tially) to the Industry

OCCAR-EA will provide the overall management to deliver maintainability reports


12.4 Technical Support Services

As basic reference for the OCCAR-EA Technical Support Services the following documentation has been utilised:

• ASD 3000L Issue 1.0 – International procedure specification for Lo-gistic Support Analysis (LSA)

• ARMP-6 Ed 3 - Allied Reliability and Maintainability Publication – Guidance for managing In Service Reliability and Maintainability;

• Defence Standard 00-42 (Part5) – Reliability and Maintainability As-surance Activity Part 5 – In Service Reliability Demonstrations

• SAE JA1000-1 Issue 1999-03 – Reliability Programme Standard Im-plementation Guide

• AMC – 20-8 EASA document on “occurrence reporting”

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation. According to the ISS Process Model (Chapter 11) the overall Technical Support Ser-vices is considered a “first level” element concerning the ISS phase.

The Technical Support Services consist of all activities and sub-activities necessary to monitor and control the reliability and maintainability of a Defence System, to maintain agreed performance levels and enhance them.

12.4.1 Objective of Technical Support Services in the ISS phase

Within the ISS organisation, the objective of the PSs and OCCAR-EA will be:

• To develop technical proposals (modifications) for the PSs;

• To propose technical and operational improvement programmes ac-cording to Nation’s needs (Post Design Service management);

• To identify and eliminate the failure mechanisms (Technical Event Management).

• To maintain agreed performance levels and enhance the perform-ance of the Defence System and its associated support systems by means of failure and maintenance data analysis. The results can be measured in terms of improvement of the Defence System’s Reli-ability

For these reasons, during ISS phase, OCCAR-EA, in conjunction with the Users, will facilitate the access to a comprehensive technical knowledge base and will provide general advice and guidance to User’s technical staff and the Design Authority. OCCAR-EA will in particular account and manage data related to Users feedback and Technical Events.

OCCAR-EA will manage and co-ordinate responses to Technical Support re-quest on behalf of PSs. In particular, if a technical event results in the need for a design change that is not mandatory, OCCAR-EA will act on behalf of


PSs to harmonise the requirement and, through the PDS process, contract and implement the design change with the Design Authority. In this con-text, OCCAR-EA will endeavour to maximise the benefits of economy of scale through common contracting.

This activity has an impact on the achievable value of System Operational Availability. The proposed FPP is called “Technical Support Capability” (TSC). For a mathematical description of this first level performance pa-rameter and its link with lower level performance parameters see Annex B.

12.4.2 Contract the overall Technical Support Services

If the PSs decide to contract the overall Technical Support Services to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to Technical Support Services efficiency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level element (FPP: Technical Support Services Capability).

12.4.3 OCCAR-EA manages the overall Technical Support Services

If the PSs decide OCCAR to manage the overall Technical Support Services, the second/third levels (respectively activities and sub-activities) can be managed and performed by OCCAR or contracted out. Whatever the case, the performance may be evaluated by the usage of second and third level Performance Parameters, as specified in following Element Table.

Technical Support Services involves four conceptual “second levels” of ac-tivities:

1. Coordination activities with a particular care on agreeing on com-mon reporting templates for gathering/collection data related to Technical Support Services.

2. In Service Monitoring of RM&T Performance is the gathering and accounting during In Service phase of actual RM&T data, which needs to be compared with predicted data. This activity is under-taken within the framework of In Service Reliability, Maintainability and Testability Demonstrations4

3. In Service (or Technical) Event Management is the collection, analy-sis, solving and storage of events that occur during operation, main-tenance or servicing of the Defence System. The scope of the events that are managed in this activity will have to be defined with and agreed by the PSs. These events impair or could impair safety and/or operational performance and/or supportability performance. Technical Event Management is intended to minimise the impacts of these events by providing timely decisions and solutions. In order to prevent their repetitions and simplify future maintenance actions, Technical Event Management always aims at removing root causes.

for which the Statement of Work and technical specifications have been defined in the procurement contract.

4 Other terms could be used such as In Service Reliability Maintainability and Testability Evaluation (ISMRTE).


4. Post Design Services (PDS), deals with preparing (Technical Assis-tance) and contracting (Order Administration) for technical services aiming at: a) correcting design shortfalls; b) maintaining agreed performance levels; c) enhance the performance of the Defence System and its associated support systems. In general PDS is not responsible for major redesigns required to meet new operational requirements.

Each one of these second level activity has been detailed on a third level of sub-activities and completed with Performance Parameters in the following table.

12.4.4 Stakeholders in Technical Support Services

Along with OCCAR-EA, the main actors who participate in Technical Sup-port Services activities could be:

• Individual PSs’ User;

• National technical staff working as a central service on behalf of all PSs;



The coordination activities between different stakeholders concerning the Technical Support Services are not covered by the ISS Process Model but form an integral part of the overall Technical Support Services performed by OCCAR-EA.


Figure 9: Navigation Map for the Technical Support Services element


Technical Support Services – Element Table

Second Level: activ-

ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA


Work in close cooperation with the Users, the Industry Design Authority and other 3rd party Industry service providers, to implement services in order to maintain, restore or improve Defence System performance levels.



Organise & Chair the PDS Working Group to manage Users PDS require-ments and respond to critical PDS is-sues


OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mail e-mails…

Establish Technical Events Manage-ment Plan defining in particular the Events Reporting Process and the mathematical model and statistical analysis to be used for the analysis of trends in terms of reliability and main-tainability.

OCCAR-EA will place a Contract to the Indus-try for the establish-ment of this plan

OCCAR-EA will ensure that the Technical Events Management Plan complies with the PSs requirements

Be a focal point for technical issues and technical decision-making, and maintain technical knowledge for the benefit of all Users. Be a point of con-tact of Industry for common technical matters



Organise and chair regular Technical meetings, to ensure that technical is-sues are fully understood and a com-mon approach is taken in the resolu-tion of technical events.

OCCAR-EA will contract for the participation of Industry Industry at meetings


Establish and maintain the process of ‘Identify and Manage Lessons’.


OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces,




ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA

e-mails…

In Service Monitoring

of RM&T Performance

Data Accounting

Data Recording: provide, collect and store all data and information neces-sary to monitor RM&T performance. This includes Technical Events data and Reports, Reliability, Maintainability and Testability evaluation Reports, ECP implementation Status (from Configu-ration Management).

Depending on the spe-cifics of the Pro-gramme this task could be contracted to the Industry

Depending on the specifics of the Programme this task could be undertaken by OCCAR-EA, Nations or Industry

Percentage of In Service Events Re-ports on Data Re-ports with RM&T

evaluation (Second level)

Data compliance Evaluation: ensure that the data collected meets the re-quirements defined in the Contract for RM&T performance (regarding in par-ticular the Baseline Standard)


OCCAR-EA has to ensure that the data collected fulfils the conditions defined in the con-tract

Data Storage: store the formatted, checked and compliant data for further analysis and ensure that the informa-tion security procedures are guaran-teed Depending on the

specifics of the Programme this task could be contracted to the Industry


Data Management

RM&T Statistical evaluations: process the data collected in order to obtain RM&T statistical results and trends in RM&T metrics

Analysis and initiation of actions: pro-vide analysis of information and initi-ate the necessary actions (ex: PDS, modifications…)




ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA

In Service (or

Technical) Event

Management

Maintainability and Reliability

Services

In Service Events Reports Check: col-lect In Service Events Reports and per-form preliminary checks

Reliability Growth Rate, validity of TEM solutions) (Second

level)

In Service Events Reports storage: Maintain a history of problems, failure reports, trends and corrective actions in a data repository in order to build technical knowledge on behalf of Us-ers.



Percentage of ac-counted Events/Data

Reports vs total number of total in Service Event Re-ports and Data Re-ports (Third level)

In Service Events Report statistical evaluation: based on the mathematical and statistical model defined in theTechnical Events Management Plan, update statistical data with regards to the Technical Events Reports and iden-tify trends and design problems. Pro-vide Reliability and Maintainability Evaluations Reports



In Service (or

Technical) Event

Management

Technical Investigation and Solution

Implementation

Research Cause of Event: provide Technical Investigation Reports to re-spond to the Technical Events Reports.

Depending on the complexity of the In Service Event, this task could be contracted to the Industry

Depending on the complexity of the Event, OCCAR-EA could perform this task in coordina-tion with the PSs or contract it to the Industry

Dispatch Interruption Rate (second level, no related to Ao)

Mean Time for proc-essing Tech. Events Report (third level, no related to Ao)




ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA

Solution Definition: define the appro-priate solution upon a number of vi-able solutions defined in the Technical Investigations Report.

Depending on the complexity of the In Service Event, this task could be contracted to the Industry

Depending on the complexity of the Event, OCCAR-EA could perform this task in coordina-tion with the PSs or contract it to the Industry

In Service Event closure: track the status of the implementation of the solution. Upon completion of the im-plementation, the Events Reports will be officially closed and the database updated accordingly


Upon completion of the correc-tive actions defined in Techni-cal Investigation Reports, OC-CAR-EA will propose the clo-sure of the Event

Percentage of root causes removed vs

total number of Technical Events

Reports (third level)

In Service (or

Technical) Event

Management

Specific Events Management

Safety related events: ensure that any Safety Warning Report initiated has been properly diffused to all stake-holders concerned. Ensure that the Industry concerned deliver the pre-liminary assessment within an agreed timeframe.

A Contract will be placed to the Industry for investigations

OCCAR-EA will ensure the dif-fusion of the Safety related Events Reports

Mean time to TAS intervention (second level NO related to

Ao)

Warranties, guarantees and examina-tions: ensure that any equipment sub-ject to warranty and guarantee and for which a Technical Event Report is de-livered is appropriately treated.


OCCAR-EA will enforce the terms and conditions of con-tract when warranties, guaran-tees and examinations apply




ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA

Post Design Services

Technical Assistance

Requirements Management: track all the requirements that drive the initia-tion of Post Design Services activities. These requirements could be sourced from Field Technical Data Reports, Configuration Reports, Request for Contractor Assistance, Reliability and Maintainability Evaluations, Technical Events Reports...


OCCAR-EA will keep track of all the requirements that drive to the initiation of PDS activi-ties

Percentage of Technical

Investigations carried out vs total number

of Requests for Contractor Assistance

(second level)

Development of solutions: develop the solutions related to the requirements for PDS activities. This could lead to additional information request for Field Data Report, Reliability and Maintain-ability Evaluations or development of specifications


OCCAR-EA will develop the specifications in coordination with the PSs

Implementation of PDS solution: ECPs are implemented through Configura-tion Management and may also influ-ence all ILS and ISS elements (see Configuration Management / ECP im-plementation)

OCCAR-EA will contract this task to the Indus-

try

OCCAR-EA will manage the Contract and ensure that the deliverables and services com-ply with the PSs Requirements




ity



Name Definition


OCCAR-EA

Managed by OCCAR-EA

Order Administration

Procurement Planning and Order Is-sue: Analyse proposed solutions and the Services needed and establish pro-curement planning for approved Engi-neering changes. Manage the Contract and the deliverables and Services pro-vided for PDS activities



Status Information and Service Inspec-tion: provides Service Administration Reports that could include Order and Invoicing plan, Service Activity Plan, Service Procurement Plan, Service Or-der Status



Table 11: Technical Support Services activities and sub-activities


12.5 Obsolescence Management

As basic references for the OCCAR-EA Obsolescence Management the following documents have been utilised:

• STANAG 4597 (Edition 1) – Obsolescence Management;

• STANAG 4598 – COTS Management;

• MIL HDBK 338B – “Electronic Reliability Design”.

• (MIL PRF 49506 (Performance Specification Logistics Management Information)

• Integrated Logistic Support Handbook (James V Jones)

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation. According to the ISS Process Model (Chapter 11) the overall Obsolescence Man-agement is considered a “first level” activity concerning the ISS phase.

Obsolescence Management (OM) consists of all sub-activities and tasks necessary to minimise the impact of the lack of supply or supportability due to obsolescence. This is performed through the identification, quantification and resolution of obso-lescence and thereby achieving optimum cost-effectiveness. OM focuses on the system-wide application of Risk Management and is applicable to the entire Pro-gramme life cycle, becoming an integral part of the design, development, produc-tion and In Service phases of the Programme. The main obsolescence issues are equivalent for both HW and SW. The strategies to identify and to mitigate the ef-fects of obsolescence are described by Design Authority in the Obsolescence Man-agement Plan, managed by OCCAR-EA and subject to approval by the Nations. The Obsolescence Management Plan shall describe the factors leading to the choice of the Obsolescence Strategy, as well as the analysis and trade-offs to sup-port such choice. It is essential that these factors are revisited regularly to ensure that the OM strategy is kept effective with time. Sharing the Obsolescence moni-toring between different Nations leads to high cost savings (this is thought to be an added value of OCCAR-EA).

OCCAR-EA considers OM to be an essential Through Life Management activity, which shall be fully integrated into all OCCAR Programmes. In accordance with STANAG 4597, each OCCAR-EA Programme will as a minimum:

• Generate and manage an OM Plan;

• Link the OM Plan to the Risk Management activity;

• Ensure OM costs are budgeted into the Programme;

• Employ a proactive strategy for OM.

Each Programme will ensure that Industry plans for obsolescence and undertakes “obsolescence prevention” and produces an OM Plan that is applicable for the whole lifecycle of the Defence System.


12.5.1 Objective of Obsolescence Management in the ISS phase

Within the ISS organisation, the objective of PSs and OCCAR-EA will be to minimise the impact of the lack of supply or supportability by means of identification and resolution of critical obsolescence throughout the De-fence System’s Life Cycle.

This activity has an impact on the achievable value of System Operational Availability. The proposed FPP is called “Obsolescence Management Confi-dence” (OMC). For a mathematical description of this first level perform-ance parameter and its link with lower level performance parameters see Annex B.

12.5.2 Contract the overall Obsolescence Management

If the PSs decide to contract the overall Obsolescence Management to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to Obsolescence Management effi-ciency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level ele-ment (FPP: Obsolescence Management Confidence).

12.5.3 OCCAR-EA manages the overall obsolescence

If the PSs decide that OCCAR-EA will manage the overall obsolescence, the second/third levels (respectively sub-activities and tasks) can be managed and performed by OCCAR-EA or contracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level per-formance Parameters, as specified in following Element Table.

Obsolescence Management involves four conceptual “second level” of func-tions:


2. Obsolescence Identification, monitoring materials and components used in the design, as well as processes, SW, standards and specifi-cations; assessing how obsolescence interacts with the Pro-gramme’s implementation, technology and support strategy; classi-fying the obsolescence “level of severity”, as defined by Obsoles-cence Management Plan through operational risk analysis,

3. Obsolescence Resolution, deriving the best strategy for Obsoles-cence Resolution based on obsolescence assessment,

4. Obsolescence Accounting, approving the needs for Obsolescence Resolution; monitoring, recording and reporting on obsolescence status.

Each one of these second level elements has been detailed on a third level of tasks and completed with Performance Parameters in the following table. It shows the obsolescence services that could be managed by OCCAR-EA on behalf of the PSs, subject to customization on a Programme-by-Programme basis.


12.5.4 Stakeholders in Obsolescence Management

Along with OCCAR-EA, the main actors who participate in Obsolescence Management activities could be:


• National support organisations and technical staff working as a cen-tral service on behalf of all PSs;



The coordination activities between different stakeholders concerning the Obsolescence Management are not covered by the ISS Process Model but form an integral part of the overall Obsolescence Management performed by OCCAR-EA.


igure 10: Navigation Map for Obsolescence Management element


Obsolescence Management – Element Table




Performed by Industry through a Contract managed

by OCCAR-EA

Managed by OCCAR-EA


Establish and maintain organisational inter-faces with all stakeholders (including aca-demic and industrial accessible networks).


OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, work-spaces, e-mails…

Establish/maintain /update the Obsolescence Management Plan

OCCAR-EA will con-tract for the participa-tion of Industry at meetings

OCCAR-EA will work in cooperation with Industry and PSs for the devel-opment of the Obsolescence Man-agement Plan

Organise & Chair Obsolescence Working Groups to ensure supply support activities meet the Users requirements (coming from reliability, maintainability, availability, sup-portability, evaluations).

OCCAR-EA may con-tract study on case by case (see Technical Support Service)

OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, work-spaces, e-mails… and react to the requests.

Organise ad-hoc meetings to respond to criti-cal obsolescence problems.

OCCAR-EA will con-tract for the participa-tion of Industry at meetings


Establish and maintain the process of ‘Iden-tify and Manage Lessons’.









managed by OCCAR-EA

Managed by OC-CAR-EA

Obsolescence Identification

Monitoring

Obsolescence Monitoring

Data definition: defining data requirements (ac-cording to the Obsolescence Management Plan) to contract for Obsolescence Monitoring, defin-ing/updating the Critical and Strategic Item Sum-mary.


OCCAR-EA is perform-ing the task in accor-dance with the defined scope.

Obsolescence status confidence (second

parameter)

Data acquisition: to provide/ update the Support-ability Analysis Summary report (SAS)


Percentage of Identified

critical Items vs total OM items (third level)

Data aggregation: to verify the SAS report as specified in the Contract and Obsolescence Man-agement Plan, to request additional Supportability analysis, to ensure obsolescence is properly con-sidered for modifications and upgrades, to prevent obsolescence to become a factor in Technical Sup-port Services, Supply Support and Post Design.

No Contract for this task additional supportability analysis if needed


Percentage of Obs. Data errors (third level)

Percentage of obsolescence issues for items not Included on

OM (second level) Obsolescence

Identification

Risk Assessment: classifying, from Risk Assess-ment, the levels of severity of obsolescence, con-sidering impact, cost, probability. The final results shall be clustered into a Risk Matrix.



Obsolescence classification: to produce/update the System Obsolescence Status. This document shall contain the Updated Obsolescence List, Updated Obsolescent List, Risk Matrix, Supportability Analy-sis Summary









OCCAR-EA

Managed by OCCAR-EA

Obsolescence Resolution

Derive Strategy

Solutions proposal: the output of this process should be a Proposal for Provisioning Order, Identification of Need for modification (ECP) or a Request for additional Supportability Analysis. The result shall be presented with a Report on Obsolescence Analysis. This task is closely linked with Post Design Service activ-ity.


Obsolescence analysis confidence (second

parameter)

Execution of Obsolescence Resolution: ECP are implemented through Configuration Man-agement/ Contracting / Supply Support and may also influence other ILS/ISS elements.


Depending on the specifics of the Programme this task could be undertaken by OCCAR-EA, Nations or In-dustry

To monitor the status of implementation is essential to avoid critical obsolescence dead-lines. This task could be linked with Configu-ration Management.








OCCAR-EA

Managed by OCCAR-EA

Obsolescence Resolution

Assess Obsolescence

Issues

To analyse Obsolescence Issues. The results shall be clustered in the Report on System Obsolescence Analysis.

Depending on the spe-cific of the Programme OCCAR may place a Contract or Not.

Depending on the specific of the Programme OCCAR-EA may perform the task in accordance with the de-fined scope or independent verification of report on System Obsolescence Analysis.

To define strategy Options and identify cost-effective solutions. The results shall be clus-tered in the Report on System Obsolescence Analysis.

Depending on the spe-cifics of the Programme OCCAR may place a Contract or Not.

Depending on the specific of the Programme OCCAR-EA may perform the task in accordance with the de-fined scope or independent verification of report on System Obsolescence Analysis.

Mean Time To process Obsolescence (third

level, only contractual parameter. No linked

with system operational availability)

To analyse possible solutions: according to the Obsolescence Management Plan. The cost impact shall be assessed for each solu-tion. Budget planning shall account for the chosen strategy and allow for full implemen-tation



Table 12: Obsolescence Management sub-activities


Second Level:

Activity



managed by OCCAR-EA Managed by OCCAR-EA

Obsolescence Accounting

Status Accounting

Data recording: provide, collect, store and update all data originating from obsolescence activities (Obso-lescence documentation reports, Critical and Strate-gic Summary, Obsolescent List, Obsolescence List, Supportability Analysis Summary, etc). To enable this function pre-formatted reports shall be utilized.



Percentage of ac-counting errors

(third level)

Controlling Information Security: the informa-tion security procedures shall be guaranteed and applied to prevent unauthorized access and loss of data.


OCCAR-EA will provide proce-dures and Depending on the specifics of the Programme this task of guaranteeing secu-rity could be undertaken by OCCAR-EA, Nations or Industry

Percentage of sup-portability analysis

vs total items under OM

(No linked to the Ao)

Obsolescence rate for the inventory

(No linked to the Ao)


Control

Control of databases coherence; ensure the coherence between current Baseline Logistic View and any other view (i.e. Maintenance view).

No Contract for this task OCCAR-EA is responsible for verifying the databases coher-ence.

Measure of performance: to measure Obsoles-cence Management. Performances against specified performance levels and report upon.


Provide Obsolescence Reports on: System Ob-solescence Status, System Obsolescence Ana-lysis etc.)

Depending on the specifics of the Programme this task could be contracted (in full or par-tially) to the Industry

OCCAR-EA will provide the overall management to deliver obsolescence reports


12.6 Technical Information and Data (TID) Services

As basic reference for the OCCAR-EA Technical Information and Data Services the ASD 1000D, International Specification for Data Management has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation. According to the ISS Process Model (Chapter 11) the overall Technical Information and Data Services is considered a “first level” activity concerning the ISS phase.

Technical Information and Data Services consist of all sub-activities and tasks nec-essary to produce, give access, utilize and maintain information and data neces-sary to operate, maintain, repair, support, train and dispose of equipment. This in-formation and data could be paper, fiche, drawings, Computer Aided Design data, electronic text, non-textual data.

In principle OCCAR-EA will use ASD S1000D as the basis for developing Interactive Electronic Technical Publications. OCCAR-EA will agree a TID Management Plan (DMP) with the PSs, detailing how TID will be managed and supported for the life of the Defence System. It will describe how the TID is produced, referenced and controlled, delivered, and amended.

OCCAR-EA will ensure the management of the Operational Phase of the Technical Information and Data services, in particular:

• The referential TID is kept up-to-date and accessible;

• The requirements for TID changes are properly managed and implemented within the timeframe defined by the PSs;

• The validation process of the changes implementation is carefully applied in particular when the changes are Safety related.

12.6.1 Objective of Technical Information and Data Services in the ISS phase

Within the ISS organisation, the objective of PSs and OCCAR-EA will be to allow a rational approach to the production, accessibility, management, dis-tribution and utilization of technical information throughout the Defence System life cycle.

This activity has an impact on the achievable value of System Operational Availability. The proposed FPP is called “Technical Data Effectiveness” (TDE). For a mathematical description of this first level of performance pa-rameter and its link with lower level performance parameters see Annex B.

12.6.2 Contract the overall Technical Information Data Services

If the PSs decide to contract the overall Technical Information Data Ser-vices to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to Technical Information Data Services efficiency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level element (FPP: Technical Data Effectiveness).


12.6.3 OCCAR-EA manages the overall Technical Information and Data Services

If the PSs decide that OCCAR-EA will manage the overall Technical Infor-mation and Data Services, the second/third levels (respectively sub-activities and tasks) can be managed and performed by OCCAR-EA or con-tracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level performance Parameters, as specified in following Element Table.

Technical Information and Data Services involves four conceptual “second level” activities:


2. Data Development Process: consists of two different processes: 1. Program Guidance Management 2. Data capture and Data Module (DM) development,

3. Publications Development Process: The development phase pro-vides the planning, production and technical validation of IETP and delivery documentation,

4. Configuration Management for publications: this phase involves the document management and Revision and maintenance service.

Each one of these second level elements has been detailed on a third level of tasks and completed with Performance Parameters in the following table. It shows the TID services that could be managed by OCCAR-EA on behalf of the PSs, subject to customization on a Programme-by-Programme basis.

12.6.4 Stakeholders in Technical Information and Data Services

Along with OCCAR-EA, the main actors who participate in TID Services could be:

• Individual PSs’ User;

• National technical staff working as a central service on behalf of all PSs;


The coordination activities between different stakeholders concerning the TID Services are not covered by the ISS Process Model but form an integral part of the overall TID Services performed by OCCAR-EA.


Figure 11: Navigation Map for Technical Information and Data Services element


Technical Information & Data Services – Element Table





OCCAR-EA

Managed by OCCAR-EA


Adapt the Technical Information and Data Management Plan (TIDMP) from the pro-curement phase, and Interactive Electronic Technical Publication (IETP) and Technical Information and Data (TID) verification plans to In Service with PSs

No Contract for this task OCCAR-EA has to establish a TID Management Plan

Establish TID procedures for IETP manage-ment and all TID during the in service phase

Adapt the Review procedures to the required operating times

Hold technical information guidance confer-ences following major changes to the con-figuration of the main and support system

Organise and chair the TID Working Group OCCAR-EA will contract for the participation of Industry at meetings

OCCAR-EA has the responsi-bility to maintain communica-tions by means of Expert Working Groups, work-spaces, e-mails…







OCCAR-EA

Managed by OCCAR-EA

Data Development

Process

Programme Guidance

Management

Produce and update rules and require-ments for the production of Data and document, validation process, information sets and delivery conditions (TID Man-agement Plan)

No Contract for this task OCCAR-EA will ensure that the updates comply with the requirements of the PSs

Technical Documenta-tion Completeness

Rate (third level)

Produce and Update reference documents as Document type definition, Data Module requirement List, Technical Documenta-tion Validation Plan

OCCAR-EA will contract some tasks to the In-dustry

OCCAR-EA will produce the Technical Documentation Validation Plan in coordina-tion with the PSs

Data Capture and Development

Produce or update the necessary Data to comply with the requirements

OCCAR-EA will ensure that the updates comply with the requirements of the PSs

Data Module Coher-ence

(third level)

Validation of Data: ensure that the Data produced are systematically validated and provide Validation Report

OCCAR-EA will assess the Validation Report provided by Industry






Performed by IIndus-try through a Con-tract managed by

OCCAR-EA

Managed by OCCAR-EA

Document Development

Process

Development of Publications

Link the updated and newly produced data to form meaningful publications

OCCAR-EA will contract this activity to the In-dustry

Technical Documenta-tion correctness Rate

(second level)

Validation Activity

Theoretical validation (Desk-top testing) which consists on verifying the TID with-out performing physical comparison with hardware, simulation of fault condi-tions…Provide testing Desk-top testing Report

No Contract for this task OCCAR-EA will perform this task in coordination with the PSs and provide the Report

Apply validation method that consists of testing concretely the application of the TID (On-Object testing). Provide On-Object testing Report

No Contract for this task OCCAR-EA will ask the PSs to perform this task


Table 13:Technical Information & Data Services sub-activit ies





managed by OCCAR-EA Managed by OCCAR-EA


for Publications

Publications Management

Referencing and configuration control: maintain the referential of TID and its configuration history. Produce Reports on Publications Configuration highlighting the status of the updates implementation, the history of the changes

OCCAR-EA will place a Con-tract to Industry with incen-tives on technical documen-tation services efficiency


Level of TID updating

(second level)

Production: produce updated publication in accordance with Users Requirements and following Data and publication De-velopment processes

OCCAR-EA will place a Con-tract with incentives on technical documentation services efficiency

OCCAR-EA will perform inde-pendent analysis to ensure that the deliverables comply with PS requirements

Delivery: deliver the TID through Physical Delivery Service and Electronic Delivery Service. This could include translation of TID

OCCAR-EA will place a Con-tract with incentives on technical documentation services efficiency

OCCAR-EA will perform inde-pendent analysis to ensure that the deliverables comply with the PS requirements

Revision and Maintenance

Service

Verification of publication compliance: verify the compliance of the TID with all Data and information from field such as maintainability reports, Maintenance Works Records, ECP implementation…and write the discrepancies Reports

No Contract for this task OCCAR-EA will ask the PSs to perform this task

Skill factor (second level)

Action items identification: provide dis-crepancies Reports with proposal for cor-rective actions such as update of TID or verification of logistic studies

No Contract for this task OCCAR-EA has to establish a TI&D Management Plan that defines the validation process

Monitoring Corrective Actions Implemen-tation: keep track of all required action items to TID and issue a validation Report to close action items

No Contract for this task OCCAR-EA has to establish a TI&D Management Plan that defines the validation process


12.7 Training Support Services

As basic references for the OCCAR-EA Training Support Services the following documents have been utilised:

• MIL-HDBK 29612A – Guidance for Acquisition of Training Data Products & Services;

• MIL PRF 29612 – Performances Specification Training Data Prod-ucts.

Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation. According to the ISS Process Model (Chapter 11) the overall Training Support Ser-vices is considered a “first level” activity concerning the ISS phase.

Training Support Services consist of all sub-activities and tasks necessary to en-sure that appropriate training (both for initial training and recurrent training) is en-sured to replacement personnel and provides them the competencies to operate, maintain and administer the Defence System during the In Service Phase. It in-cludes also all sub-activities and tasks necessary to ensure that training continu-ously meets the User Requirements. This could include procurement of additional Training Equipments and Training Courses, management of the support of the training equipments and redefinition of the training equipments and courses in the frame of new modifications.

Training Support Services are therefore considering to be the whole training envi-ronment, including facilities, simulators, training resources (classrooms, training equipment and aids etc.), Computer Based Training (CBT), and distance learning, syllabi, manuals (it’s strongly recommended the use of standard digital data), plans and procedures. OCCAR-EA will not be involved in the actual ‘hands-on’ training of personnel as this is currently outside of its’ scope. However OCCAR-EA will support PSs in the requirements, specification and implementation of training resources. OCCAR-EA could manage the contracts and monitor the performance of training delivered by Industry. OCCAR-EA could also provide technical, logistic and cross maintenance advice for course syllabi improvement and revision.

12.7.1 Objective of Training Support Services in the ISS phase


• To ensure that the training provided is coordinated with the other Integrated Logistic Support elements;

• To ensure that the right number of personnel, with the appropriate skills, is available when required, and the individual assigned to the job must be properly trained and motivated.

Effective training of defence personnel contributes directly to military effec-tiveness. Lack of timely or inadequate training can have serious impact on operations and ISS. The proposed FPP is called “Training Services Effec-tiveness” and it is considered a factor of Personnel Skill Factor. For a mathematical description of this first level performance parameter and its link with lower level performance parameters see Annex B.


12.7.2 Contract the overall Training Support Services

If the PSs decide to contract the overall Training Support Services to a third party, OCCAR-EA, as management organisation, will place a Contract with Industry with incentives linked to Training Support Services efficiency and constant improvement. OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this first level element (FPP: Training Services Effectiveness).

12.7.3 OCCAR-EA manages the overall Training Support Services

If the PSs decide that OCCAR-EA will manage the overall Training Support Services, the second/third levels (respectively sub-activities and tasks) can be managed and performed by OCCAR-EA or contracted out. Whatever is the case, the performance will be evaluated by the usage of second and third level Performance Parameters, as specified in following Element Ta-ble.

Training Support Services involves five conceptual “second levels” of activi-ties:


2. Training Objectives Identification: This activity is concerned with the assessment of existing training and the development of new needs based on a Trainings Needs Analysis. The purpose of this activity is to identify all the tasks required to operate and to maintain the equipment and to use these tasks in order to develop a Personnel Performance Profile (PPP) and a Training Needs Analysis (TNA). This phase is a joint work performed in collaboration with Design Authority and the PSs through OCCAR-EA Programme Division,

3. Training Gap Management: This phase is a joint work performed with Design Authority and the PSs. The training gap is defined as the training required by comparing the levels of performance neces-sary to achieve the Operational Performance Statements (OPS) with levels of performance assumed to be achieved by the current train-ing regime. The Training Gap Analysis and the Training Options Analysis are conducted to indicate the gap that cannot be con-ducted within existing training totality and to examine a range of potential media and equipments that could meet the training re-quirements. OCCAR-EA and the PSs will have sought to have identi-fied and exploited the fullest benefits of common support solutions. There are clear financial, support and operational advantages in de-veloping common training facilities and resources,

4. Training Procurement: The first step is the definition of Procure-ment methodology: the contracting activity has to be based on Functional Requirements and not on Technical solutions. This proc-ess includes various intermediate steps and has the main objective of defining the training requirements in details and of agreeing with the Nations on the basis for Industry ’s offer included in the Pro-posal. Contracting has to be intended as preparation for capability delivery,


5. Training Implementation: This activity provides information related to long range training program resource requirements, for person-nel and equipment, training planning data and training course con-trol data. It includes the training service implementation, manage-ment and final evaluation.

Each one of these second level elements has been detailed on a third level of tasks and completed with Performance Parameters in the following table. This table shows the training services that could be managed by OCCAR-EA on behalf of the PSs, subject to customization on a Programme-by-Programme basis.

12.7.4 Stakeholders in Training Support Services

OCCAR-EA will work closely with the Users and other support stakeholders to manage Training Support, respond to Training Support performance is-sues raised by the Users, manage Users Requirements for Training and up-date Programme Plans and Information.

Along with OCCAR-EA, the main actors who participate in training support activities could be:


• Industry the Design Authority and/or 3rd party Industry service providers;

• Designated sub-contracted Agency.

The coordination activities between different stakeholders concerning the Training Support Services are not covered by the ISS Process Model but form an integral part of the overall Training Support Management per-formed by OCCAR-EA.


Figure 12: Navigation Map for the Training Support Services element


Training Support Services – Element Table





OCCAR-EA

Managed by OCCAR-EA


Establish and maintain organisational in-terfaces with all stakeholders.


OCCAR-EA has the respon-sibility to maintain communi-cations by means of Expert Working Groups, work-spaces, e-mails…

Training Working Group will be establised to ensure cooperation, integration and harmonisation of the PSs ISS require-ments (including cross training services agreements).



Organise & Chair Training Working Groups to ensure training activities meet the Users requirements.

OCCAR-EA may con-tract study on case by case (see Technical Support Service)

OCCAR-EA has the respon-sibility to maintain communi-cations by means of Expert Working Groups, work-spaces, e-mails… and react to the requests.

Organise ad-hoc meetings to respond to critical training problems.

OCCAR-EA will contract for the participation of Industry at meetings








OCCAR-EA

Managed by OCCAR-EA

Training Needs Analysis

- Objectives

Identification

Training Concept Management

To provide/update the Training Concept: the objective is to describe the process to support the design and development pre-requisites of new course and equipments or modification for the existing ones.

Depending on the spe-cifics of the Programme OCCAR-EA can contract for this task

Depending on the spe-cifics of the Programme , OCCAR-EA is performing the task in accordance with the defined scope or is contracting for this task

Operational tasks analysis complete-ness (second level)

Operational Tasks Analysis

Management

To assess/update the Requirement Tasks Analysis: to update the Operational Task Inventory (list of tasks and sub-tasks), DIF analysis and the Operational Perform-ance Statement.

OCCAR-EA will place a Contract with Industry with incentives linked to the efficiency and con-stant improvement


Requirement Tasks Identification Com-

pleteness (third level)

To assess the Functional Requirement Specification (identify the scope and func-tional requirement for new courses and training equipment): to update the Train-ing Aids Functional Requirement Specifi-cation.

OCCAR-EA will place a Contract with Industry with incentives linked to the efficiency and con-stant improvement


Functional Require-ments specification

(third level)







OCCAR-EA

Managed by OCCAR-EA

Training Needs Analysis

- Gap

Management

Gap Identification

To assess the Training Gap Analysis for new Training Objective (identify the gap that can not be performed within current training services): to provide the Gap Analysis Report.

Depending on the spe-cifics of the Programme OCCAR-EA can contract for this task

Depending on the spe-cifics of the Programme , OCCAR-EA is performing the task in accordance with the defined scope /Nations and may con-tract for this task

Gap Management Effectiveness (sec-

ond level)

Training gap Analy-sis completeness

(third level)

To assess the Training Options Analysis for new Training Objective: to provide the Options Description and Options Analysis for each new training Gap.

Training Options

Analysis Complete-ness

(third level)

Gap Overcoming

To provide/update the Preliminary Train-ings Design for new Training Objective (to explain the process used to develop the courses/aids/equipments) it includes the Preliminary Catalogue of Training and Personal Profiles

Catalogue of Train-ing Completeness

(third level)

To develop/update the Training Analysis Reports for new Training Objective







OCCAR-EA

Managed by OCCAR-EA

Training Procurement

Contracting

To produce/update the Invitation To Ten-der (ITT) for new Training Services.

No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope and the PSs.

Training Procure-ment Effectiveness

(second level)

To manage the Contract placement proc-ess. This activity includes the manage-ment of the following documents: Support Specification, Statement of Work, Industry Proposal and Contract.

No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope and the PSs.

Contract adherence (third level)

Design &

Qualification

To manage the design and development of new Training Services (to detail Train-ing course contents, functional require-ments, options for facilities and equip-ments, ect.). This activity shall pro-vide/update the Training Technical Speci-fication (Training Scenario, Support Op-tions, Facility Design Criteria).


If this task is not done by the Nation, OCCAR-EA will monitor the Contract fulfil-ment

Technical Specifica-tion Completeness

(third level)

To manage the Qualification Management Process of new Training Services. To pro-duce/update the (Preliminary) Qualifica-tion Management Plan, the Compliance Record Document, the Acceptance Dis-crepancies Reports.


If this task is not done by the Nation, OCCAR-EA will monitor the Contract fulfil-ment

Discrepancy Report evaluation (third level)


Table 14: Training support Services sub-activities





Performed by In-dustry through a

Contract managed by OCCAR-EA

Managed by OCCAR-EA

Training Implementation

& Evaluation

Planning &

Deliver

To produce/update the Training Schedule, the Training Library, Training Program Structure Document and the Acquisition Plan


If this task is not done by the Nation OCCAR-EA is perform-ing the task in accordance with the defined scope.

Quantity of success-fully Personnel

Trained per period (third level)

To produce/update the Training Course Con-duct Information Package (it contains all in-formation concerning the management organi-sation for Training Support Services)

OCCAR-EA will place a Contract with Industry

OCCAR-EA will monitor the Contract fulfilment

Contract adherence (third level)


& Evaluation

Training Evaluation

To monitor the compliance between Training Data Products and Data Item Description.



To monitor the training effectiveness. This ac-tivity is linked to the Report on Maintenance activities and Technical Events Reports.

Performances analysis assessment: To pro-duce/update the Training Evaluation Document and Lessons Identified Document.

Percentage of Ap-proved Conclusions and Recommenda-

tions (third level)

Reporting and upgrading service: to assess reports on training activities, equipments and change proposals. The following document shall be produced (Training Evaluation Sum-mary, Training Change proposals, Assets and Equipment Utilization-Status-Faults, Perform-ance Parameters Computation).

Training Evaluation Summary Accuracy

(third level)


12.8 Support and Test Equipment (S&TE) Management

As basic reference for the OCCAR-EA S&TE, the UK Defence Logistic Support Chain Manual (JSP886) Volume 7 on Integrated Logistic Support has been utilised. Adap-tations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

S&TE comprises all equipment (mobile or fixed) required to support the operation and maintenance of a Defence System. This includes associated multi-use end items, tools, metrology & calibration equipment and test equipment. As part of this discipline equipment specific Special Tools and Test Equipment (STTE) must be considered.

The objective of S&TE Management is to ensure that the S&TE continuously meets the User Requirements. This could include procurement of additional S&TE, man-agement of the support of S&TE and redefinition of S&TE in the frame of new modifications.

S&TE management involves the following sub-activities:

• Recurrent sub-activities and tasks during the ISS that consist mainly of: collecting data and information relating to the usage and support of S&TE: this is done through the sub-activities Maintenance Monitoring and Control of Maintenance Management, analysing these data and informa-tion and support the S&TE in terms of calibration and maintenance in order to ensure their continuous availability.

• Studies for additional procurement and/or redefinition of S&TE that are triggered by the result of the analysis of the data and information collected above and/or implementation of modifications of the Defence System. In this case, S&TE requirements are identified through Maintenance Plan-ning sub activity, which is part of Maintenance Management activity. This principally consists of identifying, documenting and procuring the re-quired Support Equipment, Test Equipment and Tools to support the modi-fied Defence System.


S&TE Management - Element Table




through a Contract managed by OCCAR-EA

Managed by OCCAR-EA Main Activities (or

related sub-activities)

associated

Recurrent Sub-activities

Data Collection

Collect Data and Information relating to the usage and support of S&TE in the frame of Status Accounting of Mainte-nance Monitoring and Control



Maintenance Monitoring and

Control

Analyse Data Evaluate the adequacy of S&TE with the requirements and expectations from the Users

No contract OCCAR-EA is performing the task in accordance with the defined scope.


Control

Report on S&TE Usage

This is part of the Maintainability Report in the Maintenance Monitoring and Control- the part for S&TE will focus on the ade-quacy of S&TE to Users and Performance Requirements

Depending on the specifics of the Programme this task could be contracted (in full or partially) to the Industry

OCCAR-EA will provide the overall management to deliver maintainability reports


Control

Support S&TE

Manage the maintenance and support of S&TE (Execution of Maintenance, Repair Administration, S&TE Spares Provisioning and PHS&T)

OCCAR-EA will place a Con-tract with Industry with incen-tives linked to maintenance efficiency and constant im-provement

OCCAR-EA will ensure that the Industry meets the performance metrics that will be set up for this activity

Execute Maintenance Supply Support Management

Sub-activities related to

Studies and Implementation

of Modifications

Define Requirements

for S&TE Identify the S&TE requirements that are necessary for the support of modifications


Harmonize requirements Configuration

Control, Maintenance Planning

Procuring S&TE

Procure the S&TE (and the related docu-mentation) necessary for the support of the new modified equipment

OCCAR-EA will place a con-tract

Manage the Contract for S&TE procurement

Table 15: Support and Test Equipment Management sub-activities


12.9 Facilities and Infrastructure Management

As basic reference for the OCCAR-EA Facilities and Infrastructure Management, The UK Defence Logistic Support Chain Manual (JSP886) Volume 7 on Integrated Logistic Support has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Facilities and Infrastructure consist of the permanent and semi-permanent real prop-erty assets required to support a system as well as facilities for e.g. training, equip-ment storage, maintenance, supply storage, ammunition storage, and computer hardware/software systems.

The objective of Facilities and Infrastructure Management is to ensure that the Facili-ties and Infrastructure used for operating, training, storage, sheltering and maintain-ing of the Defence System continuously meet the User Requirements. This could in-clude procurement of additional Facilities and Infrastructure, management of the support of the Facilities and Infrastructure and redefinition of the Facilities and Infra-structure in the frame of new modifications.

As defined in the ISS Portfolio not managed by OCCAR,, the Organisation will not be in-volved in this activity unless explicitly stated by the PSs in terms of Contract place-ment. An information exchange needs to be established between OCCAR PD and PSs to ensure timely information on modifications influencing national Facility and Infra-structure Management. For information, the Facilities and Infrastructure management includes the following sub-activities:

• Recurrent sub-activities that consist of supporting the Facilities and Infrastruc-ture, studies to define types of facilities or facility improvements, location, space needs, environmental and security requirements.

• Studies and implementation of modifications of the Defence System: the Fa-cilities and Infrastructure requirements will be identified through Mainte-nance Planning sub activity of Maintenance Management for the Mainte-nance Infrastructure and Facilities; Training Procurement sub activity of Training Support Services for Training Infrastructure and Facilities; and PHS&T sub activity of Supply Support Management for Storage Infrastruc-ture and Facilities.


Table 16: Facilities and Infrastructure Management sub-activities

Facilities and Infrastructure Management - Element Table





Managed by OCCAR-EA

Main Activities (or related

sub-activities) associated

Recurring Sub-activities

Periodic Checks and Inspections

Verify that the infrastructures and facili-ties are constantly compliant with envi-ronmental, health & safety and security regulations and requirements

PSs might place a Contract to Industry

No role for OCCAR-EA

Maintain and Support the Facilities

Ensure maintenance and support of the facilities used for storage, training, main-tenance




Studies and Implementation of Modifications

Define Requirements for Storage Facilities

Identify requirements for storage for the new modification (if applicable)

PSs might place a Contract to Industry or ask OCCAR-EA to place the contract

OCCAR-EA could provide support

Configuration Control PHS&T

Define Requirements for Training Facilities

Identify requirements for training facilities for the new modification (if applicable)



Configuration Control Training Support Ser-vices

Define Requirements for

Maintenance Facilities

Identify requirements for Maintenance facilities for the new modification (if ap-plicable)



Configuration Control Maintenance Planning

Procure Facilities Procure if applicable storage, training and maintenance facilities




12.10 Life Cycle Costing

As basic reference for the OCCAR-EA Life Cycle Costing, the NATO technical report on “Methods and models for Life Cycle Costing” (RTO-TR-SAS-054) has been util-ised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Life Cycle Cost (LCC) consists of all direct costs plus indirect-variable costs associ-ated with the procurement, Operating & Support and disposal of the system. Indi-rect costs may include linked costs such as additional common support equipment, additional administrative personnel and non-linked costs such as new recruiters to recruit additional personnel. All indirect costs related to activities or resources that are not affected by the introduction of the system are not part of LCC.

The objective of Life Cycle Costing is to refine and update the LCC estimate of the Defence System in use by using actual recorded data in order to provide a forecast of future spending on Operating & Support costs and estimating the disposal costs. In addition it will assess the costs of activities to be performed as results of a modification or changes in the planned In Service Support activities.

As a subset of Life Cycle Costing activities, OCCAR-EA might use its capability to assess tradeoffs among different In Service Support Contract durations. This trade-off would consist of evaluating the benefit of having short, medium or long term contracts with regards to non recurring costs, performance and risks.

Life Cycle Costing consists of the following sub-activities:

• Recurrent sub-activities that consists of updating the Data and Assump-tions Definition Document (DADD) with actual recorded data, the cost model that refers to the DADD, Risks and Uncertainties Analysis and the Reports;

• Studies and implementations of modifications estimates that consist of es-timating the cost of any modification through life. This implies setting up the cost boundaries associated to the modification, establishing a DADD, modelling, evaluating risks and uncertainties and reporting on the results. These include ad hoc studies such as disposal studies, new spares ranging and scaling estimation, obsolescence alternatives

OCCAR-EA has established a Life Cycle Costing capability with a complete proce-dure (IP 26-12-1) based on international standards and tools that cover all the dif-ferent cost estimating methods: parametric, optimization, simulation and aggrega-tion.



Life Cycle Costing - Element Table





Managed by OCCAR-EA

Main Activities (or related sub-activities) associated


Update DADD Update the Data And Assumptions Definition Document with actual re-corded (actual costs, actual technical and actual organisational data)

This update might be con-tracted to Industry

OCCAR-EA uses its LCC capability to do the task itself or to assess Industry deliverables

Actual technical and organ-isational data come from the different performances monitoring and control re-ports

Risks and Uncertainties

Analysis

Perform Risk and Uncertainties analy-sis on the data and assumptions cap-tured

This task might be con-tracted to Industry

Cost Model Update

Update the LCC cost model based on the updated DADD

Reports on the Result

LCC estimate Report will be provided at least once per year or on request from the PSs



of Modifications

Define the Cost Boundary

of the Study

Establish based on the scope of the study or modification the cost boundary to be considered

Provide a DADD

Establish a DADD for the study or modification - the existing DADD is used as a basis

Risks and Uncertainties

Analysis

Perform Risk and Uncertainties analy-sis on the data and assumptions cap-tured

Modelling On the basis of the existing cost model perform specific cost modelling for the study or modification

Reports on the Result

LCC estimate Report for the study or modification

Table 17: Life Cycle Costing sub-activities


12.11 Manpower and Human Factors Analysis

As basic reference for the OCCAR-EA Manpower and Human Factors Analysis ASD 3000L Issue 1.0 – International procedure specification for Logistic Support Analy-sis (LSA) has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organi-sation.

The Manpower and Human Factors aspects focus on the various standards con-cerning anthropometric, ergonomic, environmental and other physiological as-pects.

The objective of Manpower and Human Factor Analysis is to manage the personnel directly involved with the Defence System and re-evaluate Manpower and Human Factors aspects due to changes in use, doctrine and policies in connection with the Defence System. It considers the effects a particular procurement would have on human engineering, manpower (numbers) for the job, personnel (physical attrib-utes skills and ability), training, system safety and health hazard assessment. The overall objective is to influence materiel and support systems design to ensure conformance with the capabilities and limitations of military and civilian personnel who will operate and maintain the system.

As defined in the ISS Portfolio not managed by OCCAR, the Organisation will not be involved in the management of the national Manpower. An information exchange needs to be established between OCCAR PD and PSs to ensure timely information on modifications influencing national Manpower Management. Manpower and Hu-man Factors analysis includes the following sub-activities:

• Recurrent sub-activities that consist of collecting and analysing the data from Maintenance Monitoring and Control and In Service Monitor-ing of Logistic Performances sub-activities from the Manpower as-pect and managing the Manpower;

• Studies and implementation of modifications: each modification or pro-posed design change could require changes in maintenance, which require review of the Manpower and Human Factor constraints and limitations. Therefore, depending on the nature of the modification to be implemented, Manpower and Human Factors analyses have to be performed. The deci-sion on carrying out a Human Factor analysis will have to be decided dur-ing the Configuration Control sub activity (Modification Need Analysis task). OCCAR-EA will contract this activity to the Industry and will evaluate the deliverables with regards to the PSs requirements.


Manpower and Human Factors analysis - Element Table





Managed by OCCAR-EA Main Activities (or re-lated sub-activities)

associated


Data Collection

Collect Maintenance, Logistic Perform-ance and Training Data related to Man-power and Human Factors

Depending on the specifics of the Programme this task could be contracted to In-dustry


Maintenance Monitoring and Control / In Service Monitoring of Logistic Performances / TSS

Analyse Data Evaluate the adequacy of Manpower and Human Factors with the require-ments and expectations from the Users

No contract OCCAR-EA is performing the task in accordance with the defined scope.


Reports on Manpower and Human factors

This would be part of Maintainability Re-port, Logistic Performance Report and Training Evaluation Reports


OCCAR-EA will provide the overall management to deliver the reports


Manage Na-tional

Manpower

Manage the operational, logistic and administrative Manpower required to operate and support the Defence Sys-tem

National task that might be contracted to Industry No role for OCCAR-EA


Studies and Implementation of Modifications

Identify Requirements for Manpower

Identify the Manpower requirements that are implied by the modification: this could be for new Maintenance Planning

Depending on the specifics of the Programme this task could be contracted (in full or partially) to Industry

Harmonize requirements Configuration Control Maintenance Planning

Consider Hu-man Factors

Integrate in the studies and modification requirements human factors aspects in relation to operation, maintenance, PHS&T and training

Depending on the specifics of the Programme this task could be contracted (in full or partially) to Industry

Harmonize requirements Configuration Control Maintenance Planning / PHS&T / TSS

Acquire the necessary Manpower

As result of the requirements identifica-tions acquire or reduce manpower

National task that might be contracted to Industry No role for OCCAR-EA

Table 18: Manpow er and Human Factors Analysis sub-activities


12.12 Software Support

As basic reference for the OCCAR-EA Software Support ASD 3000L Issue 1.0 – In-ternational procedure specification for Logistic Support Analysis (LSA) has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Software consists of “Programs, procedures, rules, data and any associated docu-mentation pertaining to the operation of a computer system.”

The objective of software support is to ensure effective maintenance and servicing support that consist of installation, de-installation, data loading, management of these Services and modification tasks.

For software support, a clear distinction between maintenance aspects and real software modification should be established:

• Recurring sub-activities includes Software Technical Events Management and maintenance aspects that might include loading of working software or required data to equipment and the management of these tasks. These are considered under Maintenance Management and Technical Events Management.

• Modification covers aspects that deal with the change of the source code to fix a problem, improve the performance of a software package or adapt to changes in procedures, data, or systems that affect the software per-formance. This is covered under Configuration Management.

Note: It is getting more common to manage the Software Support like Hardware. The way to proceed has to be defined during the tailoring process of a pro-gramme.


Software Support - Element Table





Managed by OCCAR-EA Main Activities

(or related sub-activities)

associated

Recurrent Activities

Software related Technical Events

Management

Collect software failures data as part of Technical Events tasks - Data to be collected for Software might be differ-ent from Hardware

Depending on the specifics of the Programme this task could be contracted to Industry


Technical Events Management

Technical Investigation and solution implementation - request for Contrac-tor assistance would be required

OCCAR-EA will place a Con-tract to Industry for all tech-nical investigation and solu-tion implementation for software

OCCAR-EA has to follow the implementation of the solution and ensures that any change of the soft-ware configuration is dealt with Configuration Control


User Support User Support is related to ad hoc sup-port for installation, set-up or operation of software, help desk/hotline, queries and training

OCCAR-EA will place a Con-tract to Industry for User Support

OCCAR-EA will manage the performances associ-ated to the contract

Post Design Ser-vices

Software Opera-tional Servicing

This includes loading working software or required data to equipment, installa-tion, de installation and configuring the software for its intended usage

OCCAR-EA will place a Con-tract to Industry for Software Operational Servicing or this task is done nationally

OCCAR-EA will manage the performances associ-ated to the Contract or has no role

Execute Mainte-nance

Software Recovery in case of prob-lems due to the above tasks: basic diagnosis, simple recovery actions and problem reporting

OCCAR-EA will place a Contract to Industry for Software Operational Servicing or this task is done nationally

OCCAR-EA will manage the performances associ-ated to the Contract or has no role

Execute Mainte-nance


Software Support - Element Table





Managed by OCCAR-EA Main Activities

(or related sub-activities)

associated

Activities related to


of Modifications

Identify Requirements for

Software Modification

If a modification of the hardware is undertaken, compatibility with the software has to be ensured

OCCAR-EA will place a Contract to Industry

OCCAR-EA will manage the performances associated to the Contract

Configuration Iden-tification


Software Support Analysis that con-sists of identifying maintenance relevant events for software, identify-ing Support tasks, performing FMECA, Schedule Maintenance Analysis and LORA


Maintenance Planning

Implementation of Changes on

Software

Coding, compilation and testing Configuration Control

Delivering appropriate training and documentation

Configuration Con-trol / Training Sup-

port Services / Technical Informa-tion and Data Ser-

vices

Table 19: Software Support sub-activities


12.13 Reliability, Maintainability and Testability (RM&T) Analyses

As basic reference for the OCCAR-EA RM&T Analyses, ASD 3000L Issue 1.0 – In-ternational procedure specification for Logistic Support Analysis (LSA).has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

RM&T consist of three disciplines:

• Reliability is the duration or probability of failure free performance of a sys-tem under stated conditions, or the probability that an item can perform its intended function for a specified interval under stated conditions.

• Maintainability is the measure of the ability of an item to be retained in or restored to a specified condition, when maintenance is performed by per-sonnel having specified skill levels, using prescribed procedures and re-sources, at each prescribed maintenance level and repair.

• Testability is a design characteristic which allows the status (operable, in-operable, or degraded) of an item and the location of any fault/failures within the item to be confidently determined in a timely fashion.

RM&T analyses objective is to ensure that the equipment subject to such a study is sustainable and is delivered with the required performance in the field. RM&T analyses have to be performed in order to ensure that cost effective solution will be delivered.

RM&T analyses are performed only in case of studies and modifications. Depend-ing on the depth of the modification to be implemented, the decision on carrying out a complete RM&T analyses will have to be made during the Configuration Control sub activity (Modification Need Analysis task). OCCAR-EA will contract this activity to Industry and will evaluate the deliverables with regards to the PSs requirements. The related tasks to be contracted are:

• Reliability Analysis that consists of reliability predictions (e.g. Mean Time Between Failures - MTBF) related to the intended usage scenario of the item subject to such a study. The determination of reliability values is a de-sign and development related task but the documentation of the results of this analysis is of crucial importance for ISS.

• Maintainability Analysis that consists of investigating the supportability of an item (good accessibility, installation concept in special zones…) and al-ternative repair solutions. The results of the maintainability analysis must be carefully documented; therefore, maintainability reports should be de-fined and harmonised with the Contractor. In addition to these reports, some results of the maintainability analysis will be documented within a lo-gistic database and within the maintenance concept.

• Testability analysis that consists of investigating the ability to detect failure on an item and the ability to perform functionality test of an item after re-pair. Testability analysis is closely connected to the maintainability analysis and the depth of failure detection ability/verification is one of the most im-portant influencing factors on an applicable maintenance concept. The types of data concerning testability features will be documented in a logis-tic database and special testability reports.


Reliability, Maintainability and Testability Analyses - Element Table






related sub-activities)

associated

Activities re-lated to Stud-ies and Imple-mentation of Modifications

Decision on performing

RM&T Analysis

Depending on the depth of the studies and modifications a decision has to be taken on the performance of RM&T - this decision is based on cost effectiveness considerations

No Contract OCCAR-EA has to coordi-nate the activities related to this decision


Reliability Analysis

This could include Failure Mode Effect (and Criticality) Analysis and could use the results from Technical Event Man-agement

OCCAR-EA will contract reliability Analysis to In-dustry


Configuration Control / Technical Event

Management

Maintainability and Testability

Analysis

This could include Schedule Maintenance Analysis, Damage and Special Events Analysis and Maintenance Task Analysis

OCCAR-EA will contract maintainability and test-ability Analysis to Industry


Configuration Control / Maintenance Plan-

ning

Provide Reports on the Analyses

performed Reports on Reliability, Maintainability and Testability analyses performed

OCCAR-EA will contract the provision of these Re-ports to Industry



Include Results in Database

Include the results of the analysis in a logistic support database if applicable

OCCAR-EA will contract the inclusion of the results in logistic database to In-dustry



Table 20: Reliability, Maintainabil ity and Testability (RM&T) Analyses


12.14 Security Management of the Defence System

As basic reference for the OCCAR-EA Security Management of the Defence Sys-tem, OCCAR-EA related OMPs and OCCAR Programme Security Instructions have been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Security is the condition achieved when designated information, materiel, person-nel, activities and installations are protected against espionage, sabotage, subver-sion and terrorism, as well as against loss or unauthorized disclosure.

The objective of Security Management of the Defence System is to ensure the se-curity of any item, substance or device from which classified information can be derived. This includes Documents, equipment or components (these will be called “classified material”). In particular all security aspects regarding Packaging, Han-dling, Transport and Storage (PHS&T) of the “classified material” are defined in specific documents as required by OMP11: the Programme Security Information (PSI) including Security Classification Guides. The PSI is established by OCCAR-EA with the National Security Authority / Designated Security Authorities (NSA/DSA). It may supplement the OCCAR Security Regulations or national procedures.

Security Management of the Defence System includes:

• Recurrent activities that consist of periodic checks and reports on the appli-cation of the security measures and maintenance of existing security certi-fications or approvals of the Defence System.. In the event of failure, OC-CAR-EA with the PSs and any other needed stakeholder will assess the damage caused, limit its consequences and adopt the necessary remedial measures such as update the security management processes.

• Studies and implementation of modifications: the security management processes could have to be updated. The analysis of these update is per-formed by OCCAR-EA and the NSA/DSA during the Configuration Con-trol sub activity (Modification Need Analysis task) when applicable.



Security Management of the Defence System - Element Table






related sub-activities) associated


Apply the Security

Procedures

Apply the security procedures de-fined for the "classified material" of the Defence System (mainly for PHS&T)

Contractual requirements on security of the Defence System might have to be inserted in the contract

No role for OCCAR-EA PHS&T

Adopt remedial Measures

In the event of failure in the applica-tion of the security procedures, as-sess damages and adopt necessary remedial measures

No role for Industry No role for OCCAR-EA PHS&T

Maintain existing Security

Certifications

Ensure that the existing security cer-tifications or approvals are main-tained

Requirements for ensuring the maintenance of security certifi-cations might have to be in-serted in the contract

OCCAR-EA might provide support to the PSs

Update Procedures

As necessary update the security procedures associated to the De-fence System

No role for Industry OCCAR-EA might provide support to the PSs

PHS&T

Activities related to Studies and Implementation of Modifications

Identify Requirements

for Security

Identify the need for new security measures associated to the modifi-cations

Contractual requirements on security of the Defence System might have to be inserted in the contract

OCCAR-EA might provide support to the PSs

Configuration Control PHS&T

Update Procedures

As results of the requirements iden-tification, update the security proce-dures

No role for Industry OCCAR-EA might provide support to the PSs

Table 21: Security Management of the Defence System sub-activities


12.15 Organisation Update

As basic reference for the definition of an organisation, OCCAR-EA has utilised the ISO 9000:2000 on Quality Management Systems – Fundamentals and vocabulary. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

An Organisation is a group of people and facilities with an arrangement of respon-sibilities, authorities and relationships. During the ISS Phase, the PSs will have de-fined the national logistic support and operational organisations to support and operate the Defence System. In the same extent they will have approved a struc-tural organisation of the OCCAR-EA Programme Division that has to manage ISS.

The objective of Organisation update is to update the organisational structures to adjust to changes in use, doctrine and policies.

Organisation update includes the following sub-activities:

• Recurrent sub-activities: the return of experience on the usage and support of the system might imply the necessity to change the above-mentioned organisations. This could be triggered by Maintenance Monitoring and Control and In Service Monitoring of RM&T Performances sub-activities. As far as the national organisations are concerned OCCAR-EA will not be involved. However, concerning the Programme Division, OCCAR-EA might have on request of the PSs to review and propose for approval an update of its organisation.

• Studies and implementation of modifications: the impact on the organisa-tional structures has to be analysed during the Configuration Control sub activity (Modification Need Analysis task).


Organisation update - Element Table





Managed by OCCAR-EA

Main Activities (or related sub-activities)

associated


Analyse Data collected

Analyse data collected that might have an impact of the lo-gistic and operational organisa-tions

No Contract through OCCAR-EA

No role for OCCAR-EA or OCCAR-EA might provide advice on request

Maintenance Monitoring and Control - In Service Monitoring of RM&T Per-

formances

Identify the necessary

Update Definition of the update of the organisation


No role for OCCAR-EA or OCCAR-EA might provide advice on request

Implement Update

Implement organisational update through new recruiting, new re-location…


No role for OCCAR-EA (but information would be provided)

Activities related to Studies and

Implementation of Modifications

Identify Requirements

for Update

Identify the need for an organi-sation update as a result of the modification

This task could be contracted to the Industry

OCCAR-EA might provide support on request


Implement Update

Implement organisational update through new recruiting, new re-location…


No role for OCCAR-EA (but information would be provided)

Table 22: Organisation update sub-activities


12.16 Concept and Doctrine Review

As basic reference for the definition of concept and doctrine, OCCAR-EA has util-ised the Allied Administrative Publication AAP-6 on NATO glossary of terms and definitions. Adaptations have been made where deemed necessary to fit the spe-cial situation of OCCAR as a European collaborative armament organisation.

Concept and Doctrine are usually defined nationally. They are defined as:

• Concept: a notion or statement of an idea, expressing how something might be done or accomplished, that may lead to an accepted procedure.

• Doctrine: fundamental principles by which the military forces guide their actions in support of objectives. It is authoritative but requires judgment in application.

The objective is to review Concept and Doctrine as result of the influence of the In Service activities of the Defence System. In particular a focus on the interface of the Concept and Doctrine within the international environment would be consid-ered.

This activity is by nature national. Any review of the national concept and doctrine will be initiated and undertaken by the PSs. As defined in Chapter 10.1 OCCAR-EA has no role in this review. An information exchange needs to be established be-tween OCCAR PD and PSs to ensure timely information on modifications which might have influence on national Concept and Doctrine.


Concept and Doctrine Review - Element Table





Managed by OCCAR-EA




Assess Need for Review

Considering all feedback from the op-eration and support of the Defence System, assess the need for Review to adapt Concept and Doctrine

No role for Industry No role for OCCAR-EA

Implement new Concept and

Doctrine

Implement according to national proc-esses new concept and doctrine as identified in the assessment of the need for Review


Apply Concept and Doctrine

Implement the necessary changes in operation and support procedures to comply with the new Concept and Doctrine

Contract to Industry changes in procedures if necessary

OCCAR-EA has to implement the nec-essary changes that concern its proce-dures



of Modifications

Assess Need for Review

Assess whether the new modification would need a change in Concept or Doctrine

No role for Industry No role for OCCAR-EA Configuration Control

Implement new Concept and

Doctrine

Implement according to national proc-esses new concept and doctrine as identified in the assessment of the need for Review


Apply Concept and Doctrine

Implement the necessary changes in operation and support procedures to comply with the new Concept and Doctrine

Contract to Industry changes in procedures if necessary

OCCAR-EA has to implement the nec-essary changes that concern its proce-dures

Table 23: Concept and Doctrine Review sub-activities


12.17 Environmental Impact Management

As basic reference for the OCCAR-EA Environmental Impact Management, the UK MoD Sustainability and Environment Appraisal Tools Handbook have been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Environment is a broad term that reflects our surroundings - the interactions be-tween land, sea, air, flora and fauna, and the presence of people and built devel-opments. Negative environmental interactions that we may have include produc-tion of waste and contamination, use of natural resources, water use and disposal, loss of species and habitats, soil erosion and damage to landscape. Positive inter-actions include landscape restoration and habitat creation. The objective of Envi-ronmental Impact Management is to ensure that the environmental considerations associated with the operation and support of the Defence System and/or changes of regulations and laws with influence on the Defence System are considered.

For this activity an Environment Management System (EMS) has to be set up. EMS is that part of an organisation’s overall management system that includes organ-isational structure, planning activities, responsibilities, practices, procedures, proc-esses and resources for developing, implementing, achieving, reviewing, and maintaining the environmental policy. Due to the different laws and regulations applicable in the different Nations OCCAR-EA cannot establish an EMS as it could not set up an Environment policy. Therefore, as defined in Chapter 10.1, this activ-ity is under national responsibility. An information exchange needs to be estab-lished between OCCAR PD and PSs to ensure timely information on modifications that might have environmental impact or amendments in national laws that might trigger the need for modifications of the Defence System.

Environmental Impact Management consists of the following sub-activities:

• Recurrent sub-activities: detailed evaluation and analysis of the environ-mental aspects of a Programme from feedback reports. As a minimum this will have to consider Emissions to air, Greenhouse gas emissions, Noise and vibration, Releases to underground and surface waters, Use of hazard-ous materials, use of natural resources, Waste disposal, Changes to eco-systems and Defence System life cycle.

• Studies and implementation of modifications: when applicable scoping of the environmental aspects of a modification by the PSs have to be per-formed during Configuration Control sub activity (Modification Need Analysis task).


Environment Impact Management - Element Table





Managed by OCCAR-EA



Recurrent Activity

Update Environment

Impact Management Plan

Update Environment Management Plan that defines the Environment Management System including organisation, data and information collection, reporting, measures

A Contract might be placed to the Industry at national level


Data Collection Collect data on the Environmental Impact of the use and support of the Defence Sys-tem

Corrective Measures

In case of Environment Impact issue take the necessary corrective measures

Report on Environmental

Impact Provide regular Report on Environmental Impact issues and corrective measures



of Modifications

Identify Requirements for

Environmental Impact Aspects

Identify the environmental aspects associ-ated to the new modifications Configuration Control

Update Environmental

Impact Management Plan

Update Environment Management Plan that defines the Environment Management System including organisation, data and information collection, reporting, measures


Table 24: Environmental Impact Management sub-activities


12.18 Disposal Management

As basic reference for the OCCAR-EA Disposal Management ASD 3000L, NATO AAP-20, ALS-10 and ISO/IEE 15288-2008 have been utilised and complemented. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

OCCAR-EA Disposal Management consists of all activities necessary to

• plan for the phasing out of a complete Defence System at the end of its service life cycle (Disposal Phase) in an efficient, cost-effective, safe and environmentally acceptable way;

• advise the decision maker on the most cost-effective time for the removal of the Defence System from the inventory of the forces (ISS Phase);

• disposing of parts of the Defence System in an cost-effective and environ-mentally acceptable way during IS Phase;

• phasing out of the Defence System in accordance with the Disposal Plan and by utilising the Product Disposal File (PDF) (Disposal Phase).

OCCAR Disposal Management does not include the decision making process per-formed by the owner of the Defence Systems to discontinue the use of the De-fence System, but it supports this decision making with appropriate analysis re-sults.

Details of the Management of the Disposal Phase can be found in OCCAR-EA IP 212-1 on Disposal.


Disposal Management - Element Table





Managed by OCCAR-EA



Recurrent Activity

Planning Disposal Process

Establishing and maintaining of a Disposal Strategy and Disposal Plan considering all Programme aspects. Strategy and Plan are part of the TLMP.

OCCAR-EA will contract Industry for the participa-tion in respective meetings

OCCAR-EA in very close cooperation with PS.

Close coordination with PSs required. All

Management Ele-ments involved.

Disposal Analysis Analyse disposal needs for parts of the Defence System and the complete De-fence System. This process needs to be tailored.

OCCAR-EA to contract this task as part of the DDP and ISS contract.

Tailoring needs to be performed

Product Disposal File (PDF) Data Definition, File Creation and

Updating

Define all data necessary to be kept in the PDF file. Create the PDF and fill with re-quired data to be available for disposal action during ISS Phase and Disposal Phase.

OCCAR-EA to contract tailored requirements as part of a complete TLM information requirement

Tailor and define data requirement

Activities laid down in ASD S3000L, Chapter

17.4

Preparation for Decision on

Disposal Date

Analyse most cost-effective disposal date subject to LCC development, in service lead time of a possible follow up Defence System for the same capability gap and further influencing factors.

No Contract needed Perform analysis to inform national de-cision makers

Mainly LCC activity and information re-

quired from OM, CM and MM.



of Modifications

Disposal Demonstration

Plan and execute Disposal Demonstrations (random check) to ensure that disposal planning is adequate for Disposal Phase.

OCCAR-EA to place a Contract with Industry for each case.

Plan and evaluate Disposal Demon-strations.

Disposal of Part of the Defence

System

Dispose parts of the Defence System as consequence of modifications or change in policy by using Disposal Plan and PDF.

OCCAR-EA might place a Contract with Industry de-pending on the case.

Manage, depending on scope of work plan and PDF. Co-ordinate with PS

Coordination mainly with MM, SS, CM.


Table 25: Disposal management sub-activities

Disposal Management - Element Table






Main Activities (or related sub-

activities) associated

Disposal Phase Activities

Analyse most Cost-effective Way

to dispose the Defence System

The most cost-effective way has to be de-termined to dispose the Defence System subject to political, environmental and in-dustrial constraints.

OCCAR-EA will contract Industry for certain analy-ses tasks depending on OCCAR involvement.

OCCAR-EA in very close cooperation with PS if en-trusted.

Analyse feasible alter-natives. Possibly in-volve national Dis-posal Agencies.

Dispose Hardware and Software in

Accordance with Disposal Plan

Execute the Disposal Plan under the given constraints for hardware and software of the Disposal Plan, PDF and the nationally decided way to dispose.

OCCAR-EA will contract Industry (or Disposal Agencies) for certain tasks depending on OCCAR in-volvement.


Sell, gift or dispose environmentally ac-ceptable as waste.

Dispose Management

Elements

Determine all occurrences of the Defence System in each Management Element and dispose all Management Elements in exe-cution of the Disposal Plan.

OCCAR-EA might contract Industry for certain tasks depending on OCCAR in-volvement


All Management Ele-ments involved. Most

activities are with PSs.

Close Programme Organisations and

Contracts

Determine all management organisations with tasks connected with the Defence System, finalise the respective tasks and close the organisational structure. Finalise contracts.

No contract OCCAR-EA to as-sist and advise

Main activities within PSs.

End of Programme Activities

File Programme History, carry

forward Lessons Learnt and archive

Files

Finish concise Programme history, provide lessons learnt to respective higher level management organisations and archive management files in accordance with OC-CAR and national regulations.

No contract OCCAR-EA in very close cooperation with PS

Close down Programme

Division Close down OCCAR Programme Division No contract

OCCAR-EA in very close cooperation with PS

All activities. Func-tions of OCCAR-EA CO will be involved.


12.19 Systems Engineering

As basic reference for the OCCAR-EA System Engineering ISO 15288 on Systems Engineering – System Life Cycle processes has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Systems Engineering is an interdisciplinary field of engineering that focuses on how complex engineering Programmes should be designed and managed. Issues such as logistics, the coordination of different teams, and automatic control of ma-chinery become more difficult when dealing with large, complex Programmes. Sys-tems Engineering deals with work-processes and tools to handle such Pro-grammes, and it overlaps with both technical and human-centred disciplines such as Control Engineering and Programme Management.

The objective of Systems Engineering is to analyse and harmonize requirements for new modifications (from users or after analysis of In Service feedback), verify that the specified modification requirements are fulfilled and assist in the validation of the delivered modified Defence System.

Systems Engineering is applied in case of studies and implementation of modifica-tions. It consists first of getting the agreement on the modification (part of Con-figuration Control sub activity). After an agreement is made, the planning of the modification implementation has to be defined (Configuration Control sub activity). Then the technical process is undertaken. This consists of analysing and harmonis-ing the requirements, synthesising a solution that satisfies the modification re-quirements and implementing it. The process ends with the verification of the im-plementation of the modification which consists of confirming that the specified modification requirements are fulfilled.


Systems Engineering - Element Table





Managed by OCCAR-EA





of Modifications

Analyse and Harmonize

Requirements

Analyse and harmonize the requirements that might come from the PSs or as a result of Technical Support Services or Obsolescence

OCCAR-EA might place a Contract to the Industry

OCCAR-EA might per-form the work or man-age the deliverables of the contract


Define the Solution

Synthesizing all possibilities and propose a solution - This is part of the design of the modification

OCCAR-EA will place a Con-tract to the Industry

OCCAR-EA will man-age the deliverables of the contract


Implement the Solution

Produce the necessary modification through manufacturing process

OCCAR-EA will place a Con-tract to the Industry

OCCAR-EA will man-age the deliverables of the contract

Verification Ensure that the modification fulfils the requirements of the PSs - this is part of Quality Assurance

No Contract to Industry OCCAR-EA will make the verification in asso-ciation with the PSs

Table 26: Systems Engineering sub-activities


12.20 Safety Management

As basic reference for the OCCAR-EA Safety Management, the AMC – 20-8 EASA document on “Occurrence reporting” has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Safety is defined as freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property, or damage to the environment.

The objective of safety management is to ensure continuous safety of the opera-tion and support of the Defence System. This means ensuring that at any time in its operating life, the Defence System complies with the safety requirements in force and is in a condition for safe operation.

A Safety Case should communicate a clear, comprehensive and defensible argu-ment that a system is acceptably safe to operate in a particular context. The de-velopment and acceptance of Safety Cases is a key element of safety regulation in a number of sectors – including Defence and Aerospace

As defined in Chapter 10.1, national aspect associated with the safe operation and support of the Defence System is outside of OCCAR ISS Portfolio scope. An infor-mation exchange needs to be established between OCCAR PD and PSs to ensure timely information on modifications that might have impact on the safe operation of the Defence System. Safety Management is associated to Technical Events Man-agement and includes:

• Recurrent sub-activities that consist of maintaining a Safety Management Plan including a procedure to coordinate and manage incident / accident and occurrence data from all users and implement safety measures;

• Studies and implementation of modifications that consist of identifying safety requirements of the Defence System and include them in the Con-tract for modification.


Safety Management - Element Table



Name Definition Performed by

Industry through a Contract managed

by OCCAR-EA

Managed by OCCAR-EA


associated


Maintain a Safety

Management System

Maintain and update a safety management system in particular the procedure to coordi-nate and manage incident/accident and occur-rences.

Contract might be placed to Industry

OCCAR-EA will main-tain such a system


Report on Safety Issues

Whenever a safety issue occurs during In Ser-vice a Report is provided to all stakeholders for information and action


OCCAR-EA will en-sure the Report is pro-vided to all stake-holders


Apply Safety Measures

In case of safety issues raised, apply the nec-essary measures to ensure that safety is en-sured (ex: decide that the whole fleet is grounded)

No Contract to In-dustry

No role for OCCAR-EA except as advisor if required


Report on Safety

Performance

Defined in the Safety Management System, Safety Performance will be reported periodi-cally


OCCAR-EA will en-sure the Report is pro-vided to all stake-holders


Activities related to Studies and

Implementation of Modifications

Identify Safety Requirements

Identify safety requirements associated to the modification - these are based on the Use rs requirements and safety regulations re-quirements


OCCAR-EA will sup-port the PSs Configuration Control

Implement Safety

Requirements Implement the safety requirements by applying safety engineering method

OCCAR-EA will con-tract to the Industry

OCCAR-EA will as-sess the deliverables Configuration Control

Certification of the

Modification The modification has to be certified according to the applicable safety regulations

No Contract to In-dustry

No role for OCCAR-EA except as advisor if required

Table 27: Safety Management sub-activities


12.21 Information Management

As basic reference for the OCCAR-EA Information Management the OCCAR-EA In-formation Management Concept paper CP113-2 has been utilised. Adaptations have been made where deemed necessary to fit the special situation of OCCAR as a European collaborative armament organisation.

Information is defined as meaningful data. This means information is data that has been recorded, classified, organised, related or interpreted within a framework so that the meaning that emerges becomes information. Information comes from the association of raw data in context to provide meaning.

In the context of ILS/ISS, the objective of Information Management is to ensure that timely, accurate and relevant information is provided for the management of the ISS activities to the Users Communities, National Authorities, Agencies, Indus-try Design Authority and other stakeholders involved in ISS and operations. It can include information from all the Main ISS activities, the ILS related and Domain specific Activities as well as General Programme Management Activities (see Chap-ter 8).

OCCAR-EA has to facilitate information exchange between Programme stake-holders whilst applying appropriate data processing and protection. OCCAR-EA will support and where needed develop the appropriate interfaces with Nations and other stakeholders Information Systems.

Information Management consists of the following sub-activities:

• Assess Information needs: information needs are collected and analysed and set within an appropriate information standards framework. Needs are formalized within an information architecture. This sub activity is under-taken within the scope defined by the PSs;

• Manage Information: establishes and updates the Information Management Plan. It defines the content, semantics, formats and medium for the repre-sentation, retention, transmission and retrieval of information;

• Perform Information Management tasks: provides a relevant, timely, com-plete, valid and, if required, confidential information service to authorized parties by generating, collecting, transforming, retaining, retrieving, dis-seminating and disposing of information. It is directed by the relevant in-formation management plan;

• Manage Information Management System: plans and provides the estab-lishment, sustainment and of an Information Management System. It con-siders both existing Information Management Systems and the develop-ment of new ones where necessary. The Information Management System is associated to hardware, software, Interfaces, Network and related ser-vices, procedures and processes.

OCCAR-EA has an Information and Communication Technology system based on servers located in OCCAR-EA sites and connected through a VPN network, secured up to restricted level. This supports the continuous and secure exchange of infor-mation among the different OCCAR-EA sites. A corporate solution for Through Life Information Management is currently in planning.


Information Management - Element Table

Second Level:

Activity





Main Activities (or re-lated sub-activities)

associated

Assess Information

Needs

Identify the Scope The scope of information management is defined in the scope of ISS work that the PSs give to OC-CAR-EA

No Contract to Industry No role for

OCCAR-EA except as advisor

All sub-activities associated to data and information collection,

processing and reporting Define the

Information to be Exchanged

Based on the scope define the information to be exchanged between the stakeholders

OCCAR-EA might contract this task to the

Industry

OCCAR-EA will perform this task or contract to In-

dustry

All sub-activities associated to data

collection

Build an Information Architecture

Based on the standard that will be used for infor-mation exchange build an information architecture

Manage Information

Update Information Management Plan

Update Information Management Plan that defines the content, semantics, formats and medium for the representation, retention, transmission and retrieval of information

Perform Information Management

Establish and maintain information networks for sharing and exchanging data. Ensure the efficient exchange of information for general Programme management reporting and information

Manage Information

Management System

Set up an Information

Management System

Establish an information infrastructure to meet the information needs of the PSs

Maintain existing Information

Management System

Ensure the maintenance, support and availability of existing information systems that could be used

for the Programme

Ensure Data and Information

Security Ensure security, data integrity, confidentiality

Table 28: Information Management sub-activities


12.22 Contract and Legal Support

A Contract is a mutually binding written agreement between Parties (PSs and Con-tractor). It includes Service Level Agreement (SLA) placed to a Government/State, an International Organisation or an Agency.

The legal aspect covers the relationship between OCCAR and the other stake-holders, ownership, disclosure, use and protection of information and special con-tractual issuers.

The objective of Contract and Legal Support is to achieve best value for money, while ensuring that contracts are compliant with National and European laws and contractual disputes solved. OCCAR-EA’s procurement principles are based on competition.

During the In Service phase OCCAR-EA will work on behalf of the PSs to elabo-rate:

• The Procurement Strategy and Contract Route to obtain new In Service Support Services including studies and modifications. The Procurement Strategy will consider the option of a performance based contracts (on ISS activity(s) or for the entire operational availability);

• Manage the entire procurement process according to the Procurement Strategy and Contract Route while optimizing common positions and buy-ing power to negotiate best terms and conditions and realize best value for money;

• Manage existing contracts, contract amendments, contractual disputes, delivery and acceptance for ISS Services including studies and modifica-tions;

• If required, contract on behalf of one Participating State to deliver an ef-fective national solution

OCCAR has already a set of management procedures for Contract and Legal Sup-port. These are:

• OMP 4 that provides legal direction, which may arise from the management of the Programme by OCCAR (but excluding matters relating to employ-ment of staff);

• OMP 5 that provides the procedure and policy to be followed when placing a Programme contract; this includes tender activities and complaint proce-dures prior to Contract placement;

• OMP 6 that provides standard Contract terms and conditions that were es-tablished using knowledge of National and International contracting rules and procedures.





Contract and Legal Support – Element Table

Second Level:

Activity




Managed by OCCAR-EA



Procurement Strategy

(PS)

Procurement and Support

Options

The procurement and support options are assessed in suffi-cient detail appropriate to the situation for which the Strategy is being compiled.

No Contract to Industry

OCCAR-EA will manage the

task in coordination with the PSs

All activities that have to be

contracted are concerned

Selection and Justification

Weigh the advantages and disadvantages of the major op-tions (including fall back options) against the performance of deliverables, life cycle costs and risks

Assess additional

Issues

Address additional issues that have to be covered in the Procurement Strategy such quality requirements, global bal-ance… (see IG 22)

Contract Route

A dedicated and more detailed Contract Route, taking into account the relevant points of the PS, will be developed and proposed to the Approving Authority before placement of any Contract not sufficiently addressed by the PS

Manage Procurement

Process

Advertise OCCAR-EA requirements are advertised according to the instructions of the OMP5

Supplier Selection

The widest application of competition is sought (See OMP5 for details)

Establish a Tender

Assessment Panel (TAP)

TAP has to evaluate all Tenders to determine compliance and value for money (see OMP5 for details)

Tender Procedure

Prepare the Invitation To Tender (ITT), issue ITT, ensure controlled communication with potential Tenderer(s), assess

Tenders (see OMP5 for details) Contract Award

TAP recommendation, negotiate with fully compliant Tenderer(s), award Contract (see OMP5 for details)

Solve Disputes

Complaints regarding exclusion from the Tender List will be dealt with in accordance with Annex OMP5-I





Contract and Legal Support – Element Table

Second Level:

Activity




Managed by OCCAR-EA



Manage Contract

Control Work Execution Authorize Contractor's work at the appropriate time


OCCAR-EA will manage the

task in coordi-nation with the

PSs

All activities that have to be con-tracted are con-

cerned

Monitor Performance

Monitor Contractor cost, schedule and technical performance

Control Quality Inspect and verify the adequacy of Contractor's product

Integrate Changes

Assure that changes are properly approved and that all those with a need to know are aware of such changes

Contract Risk Ensure that risk associated to the Contract are mitigated

Table 29: Contract and Legal Support sub-activities


12.23 Risk Management

Risk is an event which may occur and modify the Programme, with either a posi-tive or negative effect in terms of cost, time, performance or other attributes.

The objective of risk management is to identify correctly the risks to the achieve-ment of objectives and to ensure that control strategies are in place to manage them. The strategy for this will be to apply a continuous cycle of identifying, as-sessing, managing and reporting risks, while also reviewing the control strategies in place to deal with them.

Risk Management is a general management services that has to be applied to all ISS activities. In particular Risk Management is an important aspect of Obsoles-cence Identification monitoring, Safety Management and Security Man-agement of the Defence System. Risk Management consists of:

• Establishing a Risk Management Plan: The Risk Management Plan identifies and establishes the activities of risk management for the Programme;

• Risk Identification: involves identifying potential Programme risks and documenting their characteristics. Risk identification results in a Pro-gramme Risk List;

• Risk Analysis: Qualitative and Quantitative Risk Analysis assesses the im-portance of the identified risks and develops prioritisation lists of these risks for further analysis or directed mitigation;

• Risk Mitigation and Response Plan: focuses on the risks evaluated in the Qualitative and/or Quantitative Risk Analysis. It identifies and assigns par-ties to take responsibility for each risk response;

• Risk Monitoring and Control: Risk monitoring and control actively follows the progress of the risk and its probability, as well as the status of any mitigation/contingency strategies that have been executed;

• Reports to Stakeholders: Risk Management would be regularly addressed as an agenda item at Programme Working Group (PWG) and Programme Committee (PC) levels. This approach should be developed also during the sessions of PC open to Industry, so stimulating the involvement of the Con-tractor as well. If required, risks of strategic impact on Programme In Ser-vice Support High Level Objectives may be addressed at the Programme Board (PB) level as well.

OCCAR-EA has implemented systematic and structured Risk Management with a complete Internal Procedure (IP 32) based on international standard practices (ex: Programme Management Body of Knowledge or PMBOK) and supported by a tailored risk management software.



Risk Management - Element Table

Second Level:

Activity




Managed by OCCAR-EA



Risk Management

Plan

Update Risk Management

Plan Maintain and update the Risk Manage-ment Plan (activities and staff assignment)

OCCAR-EA might contract Industry to update its part of the Risk Management Plan

OCCAR-EA will manage all inputs for the Risk

Management Plan

All main activities with a particular

focus on Obsolescence Management

Distribute Risk Management

Plan Distribute to all stakeholders the Risk Management Plan No Contract to Industry

OCCAR-EA will manage the distribution of the

document

Risk Identification

Apply Tech-nique for Risk Identification

Identify the risks per ISS activity and es-tablish a first risk Register per ISS activity

OCCAR-EA might contract Industry to identify risks re-

lated to its activities

OCCAR-EA will manage the coordination of the

risk identification

Identify Cross Activities Risks

Identify risks that might apply to several ISS activities




risk identification

Populate Risk Register

Populate OCCAR-EA Risk Register in the Risk Management System




risk identification

Risk Analysis

Qualitative Analysis

Assess the importance of the identified risks and develop prioritisation lists of these risks for further analysis or directed mitigation

OCCAR-EA might contract Industry to analyse risks re-



risk analysis

Quantitative Analysis

Numerically estimate the probability that an ISS activity will meet its cost and time objectives. Simultaneous evaluation of the impact of all identified and qualified risks




risk analysis






risk analysis


Risk Management - Element Table

Second Level:

Activity




Managed by OCCAR-EA



Risk Mitigation

and Response

Plan

Define the Strategy for

Risk Response

Define whether the risk will be avoided, transferred, mitigated or accepted

OCCAR-EA might contract Industry to set up Response

Plan related to its risks


risk response plans

All main activities with a particular fo-

cus on Obsolescence Management

Define Response Plan

Identify the activities that will be applied in accordance with the Strategy defined




risk response plans






risk response plans

Risk Monitoring and Control

Monitor Progress

Monitor the application of the Risk Re-sponse Plan

OCCAR-EA might contract Industry to report on risk

monitoring for its activities


risk monitoring

Manage Changes on the Response Plan

If changes are necessary update the Re-sponse Plan accordingly




risk monitoring

Closure of Risks

Close the risks if it is mitigated or if the risk occurs - it could be also in a dormant status




risk monitoring

Reports

Manage Regular Meetings

Manage regular Risk Review meetings per ISS activities

OCCAR-EA might contract attendance of Industry to

these meetings

OCCAR-EA will manage these activities

Reports at appropriate

Levels

Report on Risk Management status at Programme Board, Committee and at Ex-pert Group levels when appropriate

OCCAR-EA might contract attendance of Industry to

these meetings

OCCAR-EA will manage these activities

Table 30: Risk Management sub-activities


12.24 Financial and Budget Management

The field of Finance deals with the concepts of time, money and risk and how they are interrelated. It also deals with how money is spent and budgeted (Budget Planning).

Budget is the approved estimate for all revenues and expenditures associated with the internal functioning and the operational costs of each Programme.

The objective of Financial and Budget Management is to maintain the accuracy, re-liability, relevancy and transparency of the financial and budget information pro-duced and to ensure the identification of financial risks. It means also update, monitor and control financial commitments and the total cost of programmes with the aim to react as soon as possible if a cost overrun of the programmes, by com-parison with a Programme Decision, should appear.

Financial and Budget Management is a General Programme Management Activity that consists of:

• Budget Preparation and Approval: preparation, screening and approval of OCCAR-EA Administrative and Operational Budgets, with their associated Financial Plans. The budget process is managed by OCCAR-EA and coordi-nated externally with national representatives at a FC, PC or BoS/PB level.

• Budget Management: is undertaken by OCCAR-EA and consists of budget implementation, transfers, commitment approval and financial control;

• Payment and Banking: is managed by OCCAR-EA and consists of establish-ing Bank accounts for each Nation participating within a Programme, gen-erating call for funds, paying to suppliers to meet commercial obligations and accounting.

OCCAR-EA’s financial principles are detailed in OMP 10. OCCAR-EA uses Financial Accounting and Planning Software to enable fast, effective and accurate manage-ment of all financial and accounting activities. Moreover, the system accounts separately for different Phases of the Programme, allowing the User to independ-ently track the various elements such as ISS.


Finance and Budget Management - Element Table

Second Level:

Activity




Managed by OCCAR-EA



Budget Preparation

and Approval

Budget Requirements

Aggregate inputs from various sources such as Business Plans, Programme Management Plans, Corporate Support Strategies…(see OMP10 for de-tails)


Task Managed by OCCAR-EA

Budget Screening

Screening is made in 3 Phases: OCCAR-EA Internal Phase for screening draft requirements, External Phase for screening by the Nations and Approval Phase (see OMP10 for details)

Task managed by OCCAR-EA with the

PSs

Budget Submission

Submit the budget for approval to the Nations (see OMP10 for details)


PSs

Budget Management

Budget Implementation

According to the approved budget figures, against each Budget Line Item book in the accounting soft-ware the relevant amounts (expenditures part) for each budget area (see OMP10 for details)

Task managed by OCCAR-EA

Budget Transfers

Manage transfers between Budget Line Items trans-fers within the limits of OCCAR rules (see OMP10 for details)


Commitments Initiate and approve commitments and undertake legal commitments (such as contract) within the lim-its of OCCAR rules (see OMP10 for details)


Financial Control

Financial scrutiny on the day-to-day budget execu-tion (see OMP10 for details)




Finance and Budget Management - Element Table

Second Level:

Activity




Managed by OCCAR-EA



Financial Data Management: Restitutions, Reports and Budget Scorecards - Forecast of Outturn exer-cise (see OMP10 for details)



PSs

Payment and Banking Management

Revenue Management

Call for Funds to the PSs for Operational and Admin-istrative Budget (see OMP10 for details)


PSs

Deposit of the received fund on the relevant Bank Account (see OMP10 for details)

Task managed by OCCAR-EA through a

bank

Manage Surplus of Funds that are not immediately required and placed on term deposit (see OMP10 for details)


bank

Short and Long Term

Borrowing

Manage authorised overdraft with the house bank and the short-term credit facility for Nations (see OMP10 for details)

Task managed by OCCAR-EA with the PSs through a bank

Expenditure Management

Payments made to suppliers to meet commercial obligations, payments made to cover employment costs to include invoice handling, accounting for banking transactions, use of Credit Cards (see OMP10 for details)


bank

Table 31: Finance and Budget Management sub-activities



12.25 Quality Management

Quality is the degree to which a set of inherent characteristics fulfils requirements. (ISO 9000)

The objective of Quality Management is to deliver to the PSs effective In Service Support Programme management services in terms of schedule, cost and Defence System performance. Quality Management enables clear identification of processes and responsibilities, systematic focus on customer (Users) satisfaction, managing activities by objectives, measures and actions, comprehensive process control of documentation at all levels and control and updating of Programme Plans.

Quality Management is a General Programme Management Activity that consists of:

• Quality Planning: identifying which quality standards are relevant to the Programme and determining how to satisfy them;

• Performing Quality Assurance: applying the planned, systematic quality ac-tivities to ensure that the Programme employs all processes needed to meet requirements. OCCAR-EA can request PSs to provide Government Quality Assurance (GQA);

• Performing Quality Control: monitoring specific Programme results to de-termine whether they comply with relevant quality standards and identify-ing ways to eliminate causes of unsatisfactory performance.

To ensure internal quality, OCCAR-EA has set up a Quality Management System (QMS) described in a Quality Manual (IP 10). OCCAR-EA plans and implements the necessary internal audit, monitoring, measurement, and analysis to demonstrate conformity to customer requirements, to ensure conformity of the QMS and to continually improve its effectiveness and efficiency. OCCAR-EA is ISO 9001 certi-fied.



Quality Management - Element Table

Second Level:

Activity


Name Definition Performed by Indus-try through a Con-tract managed by

OCCAR-EA

Managed by OCCAR-EA



Quality Planning

Identify Quality Requirements

For the Services to be procured or provided identify standards requirements, consider Stra-tegic Aims, Programme High Level Objectives and OCCAR-EA Quality Objectives


OCCAR-EA will manage this task with the PSs

Assign Objectives

Cascade the quality requirements in the rele-vant Management Plans and individual objec-tives - establish quality metrics

This task might be contracted to Industry

Plan Quality Reviews

Establish a periodic plan (ex: yearly) for man-agement reviews, training and process review


Establish and maintain Quality

Management Plan

Describe how the Quality Requirements will be fulfilled


Quality Assurance

Quality Audit Programme

Define the subject, scope and objectives of the planned audit, as well as the timescales and composition of the audit teams


GQA Services Request

Request GQA services in accordance with OMP 7 No Contract to Industry OCCAR-EA will initiate

the Request

Conduct Quality Audit

Collect and verify information, record audit find-ings, identify corrective actions and Report No Contract to Industry

OCCAR-EA will manage this task with the PSs except in case of GQA

Services



Quality Management - Element Table

Second Level:

Activity


Name Definition Performed by Indus-try through a Con-tract managed by

OCCAR-EA

Managed by OCCAR-EA



Follow-up Audit Outcome

Implement agreed actions from the Audit and close audit findings upon completion of correc-tive actions


OCCAR-EA will manage this task with the PSs except in case of GQA

Services

Quality Control

Data Collection Collect data pertaining to quality metrics, re-sults of audits, follow-up actions, and request for improvements.



All activities associ-ated to In Service

feedback

Analysis of Data

Analyse to data to provide information on cus-tomer satisfaction, performance of suppliers, characteristics and trends of processes, meth-ods and tools, effectiveness of improvement actions

No Contract to Industry OCCAR-EA will manage this task with the PSs

Continual Improvement

Ensure continual improvement through corpo-rate and management reviews, handling of suggestions for improvement, management or innovative actions



Table 32: Quality Management sub-activities


12.26 Planning and Reporting including Performance Management

Planning is both the organisational process of creating and maintaining a plan; and thinking about the activities required to create a desired goal on some scale.

Reporting ensures timely and appropriate generation, collection, distribution, stor-age, retrieval and ultimate disposition of Programme information. Reporting pro-vides the critical links among people and information that are necessary for suc-cessful communications.

Reporting includes Performance Management that consists of collecting and dis-tributing performance information. This includes status reporting, progress meas-urement and forecasting.

The objective of Planning and Reporting including Performance Management is to observe Programme execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary to control the execution of the Programme. In particular Programme Performance is observed and measures regularly to identify variances from the Plans.

Planning and Reporting including Performance Management consists of:

• Maintaining the Through Life Management Plan (TLMP) - current Pro-gramme Management Plan (PMP) - which defines how the Programme In Service Support is executed, monitored and controlled.; it may be com-posed of one or more subsidiary management plans and other planning documents;

• Update Performance Measurement Baseline that is an approved plan for the In Service Support activities against which definition In Service Support execution is compared and deviations measures for management control;

• Collect performance information from the execution of the plans;

• Providing relevant, concise, and timely reporting, internally and externally, via the OCCAR-EA Director, to the Programme Board and the Programme Committee and via the Programme Division to the Expert Groups and other stakeholders.

OCCAR-EA Planning and Reporting principles are detailed in OMP3. OCCAR-EA uses a Balance Scorecard Software to manage the High Level Objectives (HLOs) in terms of performance, time and cost and to monitor real time performance. For the In Service Support specifics OCCAR-EA has defined a set of Performance Pa-rameters (Annex B).



Planning and Reporting including Performance Management - Element Table

Second Level: activity




Managed by OCCAR-EA


associated

Maintain Programme

Through Life Management Plan (TLMP)

Update all Subsidiary

Plans

Update all subsidiary plans attached to the TLMP such as Configuration Management Plan, Risk Management Plan, Obsolescence Management Plan…

Some plans might be contracted to Industry

OCCAR-EA will manage this task and the delivered

plans from the Industry

All activities for which a plan has to be set up

Synchronise the Plans

Synchronise the planning of the ISS activities and the resources needed to execute the mis-sion

No Contract for this task OCCAR-EA will manage this task with the PSs


Produce PMP Review and approve the PMP and attached subsidiary plans. NOTE: Current PDs may decide not to adopt the TLMP and continue using the PMP.



Performance Management

Collect Performance

Data

Collect all data related to performance - Data are captured in the Performance Management System

Part of this task might be contracted to Industry


data from the Industry

All activities for which a performance measure

is defined

Aggregate Data

Data are aggregated according to the definition of performance indicators and parameters in the Performance Management System



is defined

Manage Deviations

Measure deviations from baseline and provide explanations and corrective actions





is defined

Update Baseline

Update Performance measurement baseline according to the PSs requirements and other factors that have to be defined



is defined


Planning and Reporting including Performance Management - Element Table

Second Level: activity




Managed by OCCAR-EA


associated

Reporting

Periodic Reporting

Periodic reporting to High Level Committees and Board according to OMP3 to some dedi-cated Working Groups or for internal purposes





is defined

Ad hoc Reports

Provide ad hoc Report on some issues or ini-tiatives that do not enter in the frame of the periodic Reporting





is defined

Table 33: P lanning and Reporting including Performance Management sub-activities



12.27 Security Management related to the Programme Division

Security is the condition achieved when designated information, materiel, person-nel, activities and installations are protected against espionage, sabotage, subver-sion and terrorism, as well as against loss or unauthorized disclosure.

The objective of Security Management related to the Programme Division is to safeguard classified, restricted and sensitive information from unauthorised disclo-sure, safeguard important installations housing Classified Information from sabo-tage and malicious wilful damage, limit the consequences of failing to do so, and be capable to swiftly adopt the necessary remedial actions.

Security Management related to the Programme Division consists of:

• Maintaining and updating a Programme Security Instructions (PSI), which includes the compulsory security provisions required for the performance of in service activities, all specifics required by the Nations with regards to classified operational information, the appropriate clearance of OCCAR-EA personnel;

• Implement and apply security measures in accordance with the PSI and with OCCAR-EA procedures;

• Implement corrective actions in case of breach of security.

OCCAR has already a set of management procedures for Security Management re-lated to the Programme Division. These are:

• OMP11: lays down the basic principles and minimum standards of security to be applied by OCCAR and its Member States, so that it is assured that a common standard of protection is established for Classified Information and uniform practices are applied;

• OMP12: establishes the principles and procedures to be applied for the pro-tection and management of OCCAR Sensitive Information originated within OCCAR-EA or which is received from Member States or non-OCCAR sources.




Security Management related to the Programme Division - Element Table

Second Level:

Activity




by OCCAR-EA

Managed by OCCAR-EA



Maintain Programme

Security Instruction

(PSI)

Identify new Threats

Maintain a survey on the new threats that could have an impact on OCCAR-EA and the Programme Division


OCCAR-EA will manage this task

with the PSs

Update the PSI PSI might be updated on request of the PSs or due to new risks to be taken into consideration

Implement and apply Security

Measures

Ensure Personnel Security

Ensure security instruction of the personnel and security clearances. (see OMP11 and for details)

Ensure Physical Security

Prevent unauthorised persons from gaining access to Clas-sified Information. This includes visit procedures.

Ensure Security Classifications and

Markings

Apply instructions described in the PSI regarding classifica-tion and markings of documents - perform periodic or ad hoc checks (see OMP11 and 12 for details)

Manage Classified and Sensitive Information

Apply instructions described in the PSI regarding transfer, handling and release of information - perform periodic or ad hoc checks (see OMP11 and 12 for details)

Ensure Industrial Security Clearance

Ensure compliance with the PSI within industrial facilities involved in the Programme pursuant to the national laws and regulations (see OMP11 and 12 for details)

No role for OCCAR-EA - PSs

responsibility


Security Management related to the Programme Division - Element Table

Second Level:

Activity




by OCCAR-EA

Managed by OCCAR-EA



Breaches for Security

Report on Breach of Security

Report could be provided through event or ad hoc and peri-odic checks



with the PSs

Investigate Investigate the reasons for the breach of security and the responsibilities

Take Measures Take the necessary corrective and disciplinary measures to prevent from the breach of security identified

Table 34: Security Management related to the Programme Division sub-activities


12.28 Programme History and Lessons Process

A Programme History is a record (or a reference to relevant records and informa-tion) of significant events and decisions or a record of other important information throughout the life of a Programme. A lesson is a "good work practice" or innova-tive approach that is captured and shared to promote repeat application. A lesson may also be an adverse work practice or experience that is captured and shared to avoid recurrence.

A lesson is considered as “lessons learned” when the lesson is deemed to be a true contribution to best practice and is taken into the corporate memory (corporate documentation like OMP, IP, IG etc.) because lessons are mostly of not much value for the originator of the “lesson identified” but only for similar cases in other business units.

The objective of Programme History and Lessons Process is to maintain a high level audit trail of the key factors of important Programme decisions (who, what, when and why) and avoid repeating mistakes, identify improvements and tips, im-prove procedures and practices through the sharing of experiences with others (i.e. mainly other PD and CO, but also feedback to Nations where necessary) for their benefit.

Programme History and Lessons Learned process consists of:

• Establish and maintain Programme History and ensure its accessibility and transfer on a need-to-know basis (IG 211-1);

• Lessons identification and dissemination that identifies the potential sources of potential lessons, prepare lesson document and disseminate les-sons;

• Process the lessons identified into lessons learned by implementing the necessary changes in the corporate documentation and ensuring traceabil-ity of the linkage between lessons and changes implemented.



Programme History and Lessons Process - Element Table



Name Definition Performed by In-dustry through a


Managed by OCCAR-EA


associated

Establish and maintain

Programme History

Control of Records

Define the structure and overview of Programme History record including identification, storage, protection, retrieval, retention and disposition


OCCAR-EA will manage this task with

the PSs

All activities are concerned with Lessons and Programme History

(see coordination activities)

Maintain a separate

History File

Establish and maintain the Programme History either as a sepa-rate Programme History file or as an overview sheet (with a list of relevant references)

Manage Inputs

Ensure that all inputs in the Programme History file includes a short description of the significant events or decisions, the date, and the file references of the relevant documents

Manage Legal Inputs

Where legally required, authenticated paper copies of key docu-ments shall be maintained

Manage Access Rights

Define appropriate access rights for information pertaining to Programme History and make it available to those with a need to know

Lessons Identification

and Dissemination

Manage Potential Sources

Manage and participate to potential forum, working groups from which lessons could be captured (ex: Community of Practice, ex-pert working groups, international forum…

Document Lessons Identified

Capture all lessons identified using the same format with at least a clear statement of the lesson, a background summary, benefits and suggestion how the lesson may be learned, contact informa-tion for additional detail, key data fields to aid searchability

Disseminate Lessons

Disseminate the lessons by using a central repository, work-spaces, discussion forum. Ensure that the recipients have the necessary access rights to know the lessons


Programme History and Lessons Process - Element Table



Name Definition Performed by In-dustry through a


Managed by OCCAR-EA


associated

Implement Lessons Learned

Propose and assess

Changes

Propose changes to be implemented in order to learn from the lessons - these changes could be developed by the initiator, the Community of Practice or an Expert Working Group and as-sessed independently


OCCAR-EA will manage this task with

the PSs

All activities are concerned with Lessons and Programme History

(see coordination activities)

Approve Changes Get approval of the changes in the highest management boards

Implement Changes

Implement changes in the corporate framework and maintain traceability between the changes and the lessons identified

Table 35: Programme History and Lessons Process sub-activities


12.29 General Support of Programme Division

General Support of the Programme Division is all about providing all necessary support to the staff for their daily work.

The objective of General Support of Programme Division is to ensure that the staff of the Programme Division works in a good condition according to Health, Envi-ronment and Safety regulations.

General Support of Programme Division consists of:

• Human Resources Management including recruitment and training;

• Site Assets and Services Management including travel management, Health, Environment and Safety and Secretariat.

OCCAR-EA Personnel Regulations are defined in OMP8, Staff Selection Principles are defined in OMP9 and there are internal procedures that have been developed for Site Assets and Services Management (IP68).




General Support of the Programme Division - Element Table





Managed by OCCAR-EA



Human Resources

Management

Staff Recruitment Recruit the necessary staff according to OMP9 (planning, advertisement, selection and appointment)



with support of PSs

Staff Integration Provide new staff with all necessary information and support in respect of the workplace, the duty station and more broadly about OCCAR-EA’s core business.


Staff Training Manage identification, planning and assess-ment of training

Staff Assessment Staff members holding an OCCAR-EA person-nel Contract are assessed according to OMP8

Manage Staff Disputes and

Disciplinary Actions Manage complaints and appeals with the rules and regulations outlined in of the OMP 8.

Manage Payroll and Emoluments

Manage payroll and emoluments with the rules and regulations outlined in of the OMP 8.

Manage Site Assets and

Services

Manage Duty Travels

Manage duty travel arrangements, orders and claims

Manage Property Items

Record, store, protect and dispose of consum-ables and non consumable items under the responsibility of OCCAR-EA


OCCAR-EA will manage this task and the contracts

Manage Administra-tive Procurement

Procure supplies and services funded under the OCCAR-EA administrative budget


OCCAR-EA will manage this task and the contracts

Table 36: General support of the Programme division sub-activities


13. Transition Problems

Note: The Transition Problems Chapter is still in draft conditions. These are the first ideas which will be further enhanced by other topics and published at the next issue.

OCCAR’s main role is to manage collaborative programmes through life. While this man-agement task requires already excellent planning, execution of plans and skilful reaction to unexpected events, there are problems arising in the life cycle of a Programme which require even more coordination, planning and foresight; Transition Problems. During the ISS Phase of a Programme, the occurrence of these transition problems happen fre-quently at the entering into service of the defence system, change of Contractor and transfer of management responsibility between management organisations generating significant undesirable operational and/or economical consequences for the user if not managed in a timely and adequate manner.

Transition problems are therefore defined as:

Transition Problems are additional management tasks stemming from changes of Programme Phases, Contracts and/or Management Organisations.

The majority, if not all, of the transition problems are in reality risks that have material-ised. OCCAR Programme Management policy includes a strong requirement for Through Life Risk Management. Consequently the risks should have been identified and recorded in the Programme Risk Register together with the associated recovery/ mitigation ac-tions and contingency plans. The implementation of a robust Risk Management as part of the Programme Management is undoubtedly the best antidote against Transition Problems.

This Chapter of the ISS Guide aims at identifying these transition problems and make recommendations on actions that could be undertaken to manage them adequately. All effort has been made to limit this Chapter to the description of transition problems and not ‘normal management problems’. For the purpose of addressing these problems, they have been classified in three groups as follows:

• Transition between Programme Phases (Phase Transition).

• Transition between different contractual situations (Contractual Transition).

• Changes in the Organisation to adapt it to a new situation (Organisational Transi-tion).

Many of the problems arising during the transition phases can be avoided or mitigated to a significant extend adopting a TLM and long term contracting approach. Therefore it is recommended that the PSs task OCCAR-EA already at integration of the Programme into OCCAR with Through Life Management of the Programme to ease possible transi-tion problems in later phases.

13.1 Phase Transition

As this document focuses on ISS, among the spectrum of phases in the Life Cycle, it will concentrate only on two types of Phase Transitions during the Life Cycle of a Defence System:


• Transition from Design, Development and Production (DDP) Phase to ISS Phase (between first and last unit of the Defence System entering the forces)

• Transition from ISS Phase to Disposal Phase (between first and last unit of Defence System leaving the forces).

Although both transitions are quite different, in the military world both show the phenomenon of extremely long overlaps.

Analysing all commonly known Phase Transition Problems of both of the Phase Transitions they show only two reasons.

13.1.1 Non optimal management

There seems to be no problem which really can be traced to the fact that it is occurring only in the transition period into ISS phase. All arising problems can be avoided/ dealt with by good management. Undoubtedly, a long overlap of phases brings a higher frequency of the same problems, which would have needed to be managed by a very short transition period. Good planning, in difficult cases by a transition plan, and consequent execution of the plan is the solution to the problems.

13.1.2 Use of opportunities

Some of the assumed ‘Phase Transition Problems’ stem in reality from the utilisation of opportunities only offered by the fact that development and production as well as the use of the system are running in parallel or that there are still some units of the Defence System in use while the rest has been disposed already. Two examples will explain:

• During the use it is detected, that the reliability of a sub-unit is not as high as expected and a modification is decided. The fact, that there are still systems in production can be used to introduce the modifications directly in the production process into the still to be produced systems. This saves money and time for the introduction of the modification into the whole fleet.

• At the end of service life some spare parts are rare. The transition into the Disposal Phase can be used to dismantle already disposed systems to recover badly needed spare parts for the remaining fleet in the forces.

These type of opportunities need to be managed carefully and they might need additional planning and manpower, but are not by themselves ‘prob-lems’ but opportunities.

13.2 Contractual Transition

The nature and the scale of the contractual transition problems will very much de-pend on the contracting approach adopted in the Procurement Strategy and sub-sequent contracting arrangements (DDP Contract only, DDP including Initial Sup-port, Through Life Contract, etc).

.


13.2.1 From DDP Contract to ISS Contract – same Contractor

Initial support included or not in the DDP contract

Interim arrangements

Change of Contractor organisation

13.2.2 From DDP Contractor to ISS Contractor – different Contractors

13.2.3 Interim Support Contract

13.2.4 Service Level Agreements

13.2.5 Change of Contractor during ISS Phase

Long time needed from evaluation of old Contract until full operation of the new contract.

13.2.6 Incorporation of new Programmes after DPP

13.3 Organisational Transition

Organisational Transition refers to the organisational problems arising from the fact that responsibility of management is transferred from OCCAR to any other Or-ganisation or vice versa. In simple terms, change in the responsibility of manage-ment will necessarily require changes in the Organisation.

In a true TLM environment the transition between organisations is avoided, never-theless the organisation will need to be adapted to the new situation and a differ-ent stakeholder community is involved.

13.3.1 Transfer of management responsibility from OCCAR to Nations

13.3.2 From DDP OCCAR Organisation to ISS OCCAR Organisation (PD internal)

New roles, smooth transition, ILS TL elements (MS, TP, TR, CM, etc) same people, numbers to be checked but possibly, depending on the OCCAR ISS role, additional manpower needed. Flexibility to Contract duration to ac-commodate to needs (ex: rather 6,5 years for an A3 than a new person for 2 years).

13.3.3 From National ISS to OCCAR ISS

Transfer of the required information in easy format, IT system.

Transition period processes running in parallel.


14. Generic PD

A PD is an OCCAR’s business unit managing a defined Programme. The tasks and re-sponsibilities of the Programme Manager are listed and defined in OMP 1.

14.1 General Considerations

There is no rules for the built up of a PD nor is there a fixed size fitting all re-quirements and phases. The structure of a PD is a function of the entrusted tasks to OCCAR and other factors which are described in this Chapter.

14.2 Functional Description

In this Chapter a generic PD is described as result of the needed functionalities during a pure ISS phase without considerations of overlap. The functionalities are taken from the description of Chapter 8 and Chapter 12 and the numbering is con-sistent with the numbering of these Chapters. For the main ISS activities (1 to 7) it is also consistent with the ISS Process Model described in Chapter 11.

It is obvious that only a functional built up can be derived without knowing the ex-act circumstances of a future PD in the ISS phase. As a result of complexity, the kind of Contract and the activities/sub-activities entrusted by the PSs to OCCAR management, a weight can be attributed to any functionality. After adding up weighted functionalities5

to fill individual posts with similar functions a structure can be derived showing posts instead of functions.

5 If a weight reveals more than one man-year full time equivalent, the function has to be divided among more than one post.


Figure 13: Functional Generic Programme Division Structure during ISS Phase (pure ISS)


14.3 Considerations for the PD Breakdown

As a consequent derivation of the functions, their subdivision and the need for general management functions as well as internal support the following upper level functional structure is proposed.

Figure 14: Functional breakdown of generic pure ISS Programme Division (upper level)

In Chapter 8 the main ISS activities, the ILS activities in the ISS phase and the domain specific activities (1 to 20) are subdivided into two groups which are trans-lated into two sections of the generic PD:

• User Support Section dealing with the Recurrent Support activities and tasks provided to the users of the Defence System in order to enable continued opera-tion and a sustainable service; it includes monitoring of the performance of the Defence System and services and the identification, classification, and reporting of anomalies, deficiencies, and failures of the Defence System and services.

• ISS Technical and Modification Section dealing with studies and implemen-tation of modifications to the Defence System as result of new requirements, identified problems and technology considerations. This includes Integrated Lo-gistic Support activities.

Two additional sections are necessary to hold coordination and enable functionalities:

• Programme Support Section is the enabling section of the PD providing cross-divisional support.

• Coordination Section supports the Programme Manager in his functions of planning and reporting, keeping contact documenting history and lessons, ana-lysing required performance levels of the Defence System and general admini-stration.

Of course, if the complexity of the management task is low, sections could be combined or the Section Leader tasks could be even performed by the Programme Manager.

Programme Manager

Coordination Section

Programme Support Section

User Support Section

Technical & Modification

Section


Using this section structure, the functions of the day to day business with the user and the logistic support of the Defence System are combined in one section and the long term activities like studies and modifications and all their consequences are combined in another section. Hence, the functions of Maintenance Management (2), Supply Support (3), Technical Support Services (4) need not to be divided in the two sections;

Obsolescence Management (5), as recurrent task is placed fully into the Technical & Modification Section, as the cause of obsolescence comes out of technology problems and does not stem from use problems of the Defence System;

The functions of Software Support and Information Management are together in the Programme Support Section because of the probable synergy effect. The same is true for the function of the Security Management of the Defence System and the Security Management of the PD.

Although Disposal Management is an ILS element, it should be a part of the Pro-gramme Support Function because it provides support when disposing undesired parts of the Defence System during most of the ISS phase. Depending on the de-cision of the PSs at the approaching end of service life, the importance of this function will grow and a new decisions need to be taken on the place of the func-tion in the structure.

14.4 Establishing a concrete PD

OCCAR-EA, PMSD has a capability to support in the estimation and refinement of a concrete PD.

Using the functional description under this Chapter, the estimation takes into ac-count all factors describing the weight for each function like:

• Number of PSs • Number of services using the Defence System • Life Cycle Cost of Programme • Number of units of Defence Equipment • Type of ISS Contract • Type of Support Concept • Number of different spare parts • Maintenance levels • etc

The methodology used by OCCAR-EA to estimate the weight to the functions and ulti-mately determine a proposal for a PD Organisation and its associated administrative costs will then look as indicated in the next figure. It will of course be agreed between OCCAR-EA and the PSs.

After the first estimate, refinements can be applied to reach the initial agreed solution. The actual size and structure of a PD will then be consciously screened to reach the most cost-effective PD for the situation.


Figure 15: Generic methodology to estimate structure and administrative cost of an future PD

14.5 Changes in Functional Generic PD Structure as Function of Phase

As there might be a long time of overlap between DDP phases and ISS phase, a mix of functions need to be considered and the posts have to be filled with officers of the required skills.

Figure 16: PD structure as function of the management need during the phases.

D D P ISS

Generic PD with DDP functions only

Generic PD with DDP and ISS functions

Generic PD with ISS functions only

Generic Equipment Cycle D, D, P, ISS phases

A N A L Y S I S

Statement of

Work

List of

Tasks

Set of Generic

Functions

Annual Workload

in man.hours per function

per task per system

Administrative Cost

Estimate

# Systems to be

supported

Organisational Structure

Set of required

Skills

Workload in man.hours per function

per task for each year

Extrapolation Laws

Number and Type

of required FTEs per

function for each

year

# Experience on previous programme


15. Annexes

Annex A Related Documents, Acronyms, Definitions and Explanations Annex B Performance Parameter Definitions Annex C Your Notes

Annex A: Related Documents, Acronyms, Definitions and Explanations



Related documentation

• All Internal Procedures (IPs) and Internal Guidance (IG) (OCCAR Intranet only, pro-viding details on how to perform the management tasks).

• All OCCAR Management Procedures (OMP) in Internet

• AAP-20, NATO

• ALP-10, NATO

• ASD S3000L

• ASD S5000F

• CP 14-1 Through Life Management Concept, short TLM Concept (OCCAR Intranet only)

• CP113-2 Information Management Concept

• ISO 15288

• ISS Strategy (OCCAR Intranet only)

• MIL-HDBK-61A(SE) 7 Feb. 2001

• OCCAR Business Plan, latest version (Internet)

• OCCAR Convention (internet)

http://intranet.occar.int/occar_intranet/Konakt�

http://intranet.occar.int/occar_intranet/Konakt�










Acronyms, Definitions and Explanations

Name Definition / Explanation Source

Ao System operational Availability ASD AeroSpace and Defence, Industries Association of Europe

Board of Supervisors (BoS) Integration

Decision

BoS decision adopted by the representatives of all Member States to authorise the integration of the Programme into OCCAR-EA.

OMP 2

Capability Gap The difference between the ability of existing systems to meet operational requirements and expectations.

CDC Configuration Data Confidence CEN European Standardisation Agency CI Configuration Item CM Configuration Management CO Central Office of OCCAR-EA

Codification

Codification provides a way to formally identify, classify and number items of the Defence Inventory in accordance with the NATO Codification System, as set out in the NATO Manual for Codification. It provides a unique identifier and a simple and common reference. Codification avoids unnecessary duplication of common items, thus ensuring economy of scale in provision-ing and facilitates inter-operability between NATO countries.

NATO Manual of Codification

Concept Concept is a notion or statement of an idea, expressing how something might be done or accomplished, that may lead to an accepted procedure.

AAP 6

Configuration [1] The functional and physical characteristics of a materiel as described in its technical documentation and later achieved in the materiel.

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration Audit (CA)

Checking an item for compliance with its configuration documentation. There are 2 kinds of CA: functional configuration audit (FCA) and physical configuration audit (PCA).

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration base-line (baseline)

(1) An agreed-to description of the attributes of a system, at a point in time, which serves as a basis for defining change.

(2) An approved and released document, or a set of documents, each of a specific revision; the purpose of which is to pro-vide a defined basis for managing change.

(3) The currently approved and released configuration documentation.

(4) A released set of files comprising a software version and associated configuration documentation. See: Allocated Baseline (ABL), Functional Baseline (FBL), and System Baseline (PBL).

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration control

(1) A systematic process that ensures that changes to released configuration documentation are properly identified, docu-mented, evaluated for impact, approved by an appropriate level of authority, incorporated, and verified.

(2) The configuration management activity concerning: the sys-tematic proposal, justification, evaluation, coordination, and disposition of proposed changes into (a) the applicable con-figurations of a product, (b) associated product information, and (c) supporting and interfacing products and their asso-ciated product information.

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration Documentation

Allocated Configuration Documentation [ACD], Functional Con-figuration Documentation [FCD], and System Configuration Documentation [PCD].)

MIL-HDBK-61A(SE)

7 Feb. 2001)


Configuration Identification

(1) The systematic process of selecting the system attributes, organizing associated information about the attributes, and stating the attributes.

(2) Unique identifiers for a system and its configuration documents.

(3) The configuration management activity that encompasses the selection of CIs; the determination of the types of configuration documentation required for each CI; the is-suance of numbers and other identifiers affixed to the CIs and to the technical documentation that defines the CI's configuration; the release of CIs and their associated con-figuration documentation; and the establishment of con-figuration baselines for CIs.

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration Item (CI)

A Configuration Item is any hardware, software, or combination of both that satisfies an end use function and is designated for separate configuration management. Configuration items are typically referred to by an alphanumeric identifier which also serves as the unchanging base for the assignment of serial numbers to uniquely identify individual units of the CI.

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration Management (CM)

A management process for establishing and maintaining consis-tency of a system’s performance, functional, and physical attrib-utes with its requirements, design and operational information throughout its life.

MIL-HDBK-61A(SE)

7 Feb. 2001

Configuration Status Accounting

storage of, and access to, configuration information needed to manage systems and system information effectively.

MIL-HDBK-61A(SE)

7 Feb. 2001

Contract

The mutually binding written agreement between the Parties as described in Article 1.1 (Applicable Articles and Documents).It includes Contract or Service Level Agreement (SLA) placed a Government/State, an international organisation or agency.

OMP 6, SLA sentence added.

Corrective Mainte-nance

Maintenance carried out after fault recognition and intended to restore the Defence System to a state in which it can perform a required function.

Cat of ISS Ser-vices

COTS Commercial Of The Shelf. A Defence Equipment that is readily available on the commercial marked and not specially developed for military purposes.

Critical Items List Provide details of assemblies that contain supply, maintenance or safety critical items.


DADD Data and Assumption Definition Document

Data Recorded information, regardless of form or method of re-cording

MIL-HDBK-29612-4A 31 August 2001

Data Management

The approach and methods planned to establish and maintain a data Management system and the interrelationship with the de-sign-capture system and integrated repository. Includes descrip-tions of how and which technical documentation will be con-trolled and the method of documentation of project engineering and technical information. Also includes plans for security and preparation of deliverable data.


Data Reporting, Analysis, & Correc-tive Action System

(DRACAS)

A process providing the means for collecting test or field infor-mation, analyzing the data, then implementing and tracking cor-rective actions.


DDP Design, Development and Production

Defence System

Defined as a composite of systems, sub-systems (or sets), skills, and techniques capable of performing and/or supporting a mili-tary role. A complete Defence System includes related concepts, facilities, materiel, services, organisation and personnel required

OCCAR_EA, derived from UK MoD Def Stan 05-57


for its operation to the degree that it can be considered self-sufficient in its intended military and/or support environment. Example: Aircraft Type A400M as complete package as described above. This term is also used to determine services

Design Authority

An organisation appointed by Contract to be responsible for a design or modification of a design, and for signing the Certifi-cate of Design. The authority for acceptance of a design and any change to that design remains with the OCCAR-EA Pro-gramme Manager.


Disposal

Disposal removes a Defence System or parts of it from the op-erational environment with the intent to end its existence in ac-cordance with all legal and regulatory requirements to safety, security, and the environment. This includes also all manage-ment elements of the Defence System. Disposal can be per-formed in many ways, including reuse in other systems, recycle and sale etc.

OCCAR-EA, De-rived from

NATO AAP-20 (ed2)

Disposal Manage-ment

Disposal Management in OCCAR consists of all activities neces-sary to: • plan for the phasing out of a complete Defence System at the

end of its service life cycle (Disposal Phase) in an efficient, cost-effective, safe and environmentally acceptable way (De-sign to Production Phase);

• advise the decision maker on the most cost-effective time for the removal of the Defence System from the inventory of the forces (ISS Phase);

• dispose parts of the Defence System in an cost-effective and environmentally acceptable way during IS Phase;

• phase out the Defence System in accordance with the Dis-posal Plan and by utilising the PDF (Disposal Phase).

OCCAR Disposal Management does not include the decision making process performed by the owner of the Defence Sys-tems to discontinue the use of the Defence System, but it sup-ports this decision making with appropriate analysis results.

OCCAR-EA, IP 212-1 Issue1,

draft1

DM Data Module

Doctrine Doctrine is a fundamental principle by which the military forces guide their actions in support of objectives. It is authoritative but requires judgment in application

AAP 6

EA Executive Administration like in OCCAR-EA ECP Engineering Change Proposal EDA European Defence Agency

EITVOX

The aim of the EITVOX process model is to guide the developer in identifying and describing all activities – from the top level to the lowest level in a structured manner. The EITVOX acronym reflexes the letters identifying the main elements that the model describes.

EMS Environment Management System

Engineering change

(1) A change to the current approved configuration documenta-tion of a configuration item. (2) Any alteration to a system or its released configuration documentation. Effecting an engineering change may involve modification of the system, system information and associated interfacing systems.

MIL-HDBK-61A(SE)

7 Feb. 2001

Engineering Change Proposal (ECP)

The documentation by which a proposed engineering change is described, justified, and submitted to (a) the current document change authority for approval or disapproval of the design change in the documentation and (b) to the procuring activity for approval or disapproval of implementing the design change in units to be delivered or retrofit into assets already delivered.

MIL-HDBK-61A(SE)

7 Feb. 2001


Environment

Environment is a broad term that reflects our surroundings - the interactions between land, sea, air, flora and fauna, and the presence of people and built developments. Negative environ-mental interactions that we may have include production of waste and contamination, use of natural resources, water use and disposal, loss of species and habitats, soil erosion and dam-age to landscape. Positive interactions include landscape resto-ration and habitat creation.

UK MOD Sus-tainability and Environmental Appraisal Tools

Handbook

Environment Man-agement System

(EMS)

EMS is that part of an organisation’s overall management sys-tem that includes organisational structure, planning activities, responsibilities, practices, procedures, processes and resources for developing, implementing, achieving, reviewing, and main-taining the environmental policy.

ISO 14001

Equipment Part of a Defence System ETLCM European Through Life Capability Management CP 14-1

EU European Union Cat of ISS Services

Events Any happening associated with the Defence System, which is not in accordance with expectations.

New (adapted from A400M)

Facilities and

Infrastructure Management

Facilities and Infrastructure consist of the permanent and semi-permanent real property assets required to support a system as well as facilities for e.g. training, equipment storage and shelter, maintenance, supply storage, ammunition storage, and com-puter hardware /software systems.

ALP 10

FPP First level Performance Parameter

Functional Configu-ration Audit (FCA)

The formal examination of functional characteristics of a con-figuration item, or system to verify that the item has achieved the requirements specified in its functional and/or allocated con-figuration documentation.

MIL-HDBK-61A(SE)

7 Feb. 2001

FMECA Failure Mode and Effects and Criticality Analysis GQA Government Quality Assurance

High Level Objec-tives (HLOs)

Are concrete statements describing what the Programme is try-ing to achieve. They should be Specific, Measurable, Attain-able/Achievable, Realistic and Time-bound and are used to manage the Programme in a focused, measurable way.

OMP 1

HLO High Level Objective IETP Interactive Electronic Technical Publication IG Internal Guidance ILS Integrated Logistic Support ILS Integrated Logistic Support

In Service Date (ISD)

The date by which the equipment or a specified number of equipments will contribute to the operational capability of the Service concerned.

In Service Event

An In-service Event is an Event that takes place without the user’s intention. It impairs or could impair safety, and/or opera-tional performance, and/or supportability performance. In Ser-vice Events could be attributable to technical or non technical factors. However, due to the usage in many OCCAR-EA Member States the term Technical Event and In Service Event will be used interchangeably.

(adapted from A400M)

In Service Phase The phase, which aims to “use, support and maintain Defence System capability to fulfil operational requirements”.

In Service Support Date (ISD)

Is declared when the military capability provided by the system is assessed as available for operational use in its minimum use-fully deployable form.

Information Information is defined as meaningful data ISO 9000 / CP 113-2


Information Man-agement

Information Management is an integrated processing of informa-tion across its life cycle inside an organisational framework. CP 113-2

Information System

A system, whether automated or manual, that comprises peo-ple, machines, and/or methods organized to collect, process, transmit, and disseminate data that represent User information. Also, any telecommunications and/or computer related equip-ment or interconnected system or subsystems of equipment that is used in the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmis-sion, or reception of voice and/or data, and includes software, firmware, and hardware.

Initial Provisioning

The process of determining the range and quantity of items (i.e., spares and repair parts, special tools, test equipment, and support equipment) required to support and maintain an item for an initial period of service. Initial Provisioning is based upon the functional ASD S2000M.

Integrated Logistic Support (ILS)

Practices, processes and standards that ensure supportability and considered early in the acquisition lifecycle, with the aim of influencing design and optimising the life cycle costs.

OCCAR CP 14-1

Interactive Electronic Technical Publication

(IETP)

A set of several related technical manuals including: mainte-nance documentation, illustrated parts catalogue, tool and con-sumable information, periodic service documentation (bulletins, newsflashes, etc.), related documentation (e.g. general repair techniques, specific equipment manuals). An IETP is ‘interactive’ because the display of information can be based on the User’s response, rather than in the order that the originator chose to present it. The electronic format of an IETP also makes it possi-ble to provide links to other publications and systems. IETP are preferably established by using ASD S 1000D.

IP Initial Provisioning ISO International Standard Organisation ISS In Service Support

ISS Guide Short title of this document with the full title of ‘Managing OC-CAR Programmes during the In Service Support Phase’.

ISSC In Service Support Committee IT Information Technology

JCMP Joint Configuration Management Panel OMP 2

Legal Aspects The legal aspect covers the relationship between OCCAR and the other stakeholders, Ownership, Disclosure, Use and Protec-tion of Information and special contractual issuers.

OMP 4

Life Cycle The complete set of phases for a system from Preparation to Disposal. Consists of Preparation, Design, Development, Produc-tion, In Service and Disposal Phase.

Life Cycle Cost (LCC)

Life Cycle Cost consists of all direct costs plus indirect-variable costs associated with the procurement, Operating & Support and disposal of the system. Indirect costs may include linked costs such as additional common support equipment, additional administrative personnel and non-linked costs such as new re-cruiters to recruit additional personnel. All indirect costs related to activities or resources that are not affected by the introduc-tion of the system are not part of LCC.

NATO study report RTO-TR-SAS028 on cost structures and life cycle costs for military sys-

tems. IP 26-12-1

Logistic Support Analysis (LSA)

The selective application of scientific and engineering efforts undertaken during the Development process and continuing throughout the complete Life Cycle (of a Defence System) as part of the engineering and design process, to assist in comply-ing with supportability and other ILS activities.

ASD S3000L

Logistic Support Analysis Record LSAR A database where the relevant logistic data is collected. ASD S3000L


LORA Level Of Repair Analysis LSA Logistic Support Analysis

LSAR Logistic Support Analysis Record

Maintainability

Maintainability is the measure of the ability of an item to be re-tained in or restored to a specified condition, when maintenance is performed by personnel having specified skill levels, using prescribed procedures and resources, at each prescribed level maintenance and repair.

ASD S3000L

Maintenance Combination of all technical and administrative actions, including supervision actions, intended to retain an item in, or restore it to, a state in which it can perform a required function.

Manpower and Hu-man Factors Analysis

The Manpower and Human Factors aspects focus on the various standards concerning anthropometric, ergonomic, environmental and other physiological aspects.

JSP 886

Materiel Defined as the generic term covering system, equipment, stores, supplies and spares including related documentation manuals, computer software, firmware and services.

UK MoD Def-Stan 05-57

Memorandum of Un-derstanding (MoU)

Arrangements between Participants in respect of a collaborative Programme, a specific phase of a Programme, a Project, a Technology Demonstrator Programme or a study.

OMP 2

Modifications

Modification covers aspects that deal with the change of the source code to fix a problem, improve the performance of a software package or adapt to changes in procedures, data, or systems that affect the software performance.

ASD S3000L

MPP Major Performance Parameter MTBF Mean Time Between Failures

NAMSA NATO Management and Supply Agency NAMSO NATO Management and Supply Organisation

NSA/DSA National Security Authority / Designated Security Authorities OMP 11 NSO National Support Organisation

Obsolescence Decreasing value of functional and physical assets or value of a part of a Defence System or facility from technological changes rather than deterioration.

Obsolescence management

Is an activity intended to minimise the impact of this loss of supply on a Programme through the identification, quantification and resolution of obsolescence and thereby achieve optimum cost-effectiveness. Obsolescence Management focuses on the system-wide application of risk Management and is applicable to the entire Programme life cycle, becoming an integral part of the design, development, production and In Service support phases of the Programme. Activities that are undertaken to mitigate the effects of obsolescence. Activities can include last-time buys, lifetime buys and obsolescence monitoring.

OCCAR OCCAR Organisation Conjointe de Coopération en matière d’ARmement

OCCAR-EA’s TLM

OCCAR-EA’s Through Life Management is the approach of man-aging a Programme throughout its whole life cycle, in a use-centric way. TLM is achieved by applying and integrating best practice management techniques in a coherent manner across all system aspects in order to deliver, sustain and dispose the required cost-effective defence system.

CP 14-1

OM Obsolescence Management OMP OCCAR Management Procedure OPS Operational Performance Statement

Optimisation (Model-ling)

This category contains all the models that are based on some type of optimization method, be it mathematical programming, heuristics, or other types of optimization approaches. Linear programming is a mathematical modelling technique designed to


optimize the usage of limited resources while heuristic ap-proaches use standardized rules of thumb repeated many times in order to find a good enough solution to a problem. These models are most frequently used as support methods for the life cycle cost estimation process. They are frequently employed to determine stock levels, maintenance regimes and supply chain impacts.

Organisation An Organisation is a group of people and facilities with an ar-rangement of responsibilities, authorities and relationships ISO 9000:2000

Packaging Handling Storage and Trans-portation (PHS&T)

The resources, procedures, design considerations and methods to ensure that all system equipment and support items are packaged, handled, stored and transported properly6

. The re-quirements shall include environmental limitations, equipment preservation requirements for short and long-term storage and transport requirements. PHS&T shall conform to appropriate legislation, particularly for hazardous items such as munitions, weapons and missiles.

PB Programme Board Cat of ISS Services

PC Programme Committee Cat of ISS Services

PCA Physical Configuration Audit

PD Programme Division Cat of ISS Services

PDF Product Disposal File

PDS Post Design Services Cat of ISS Services

PHS&T Packaging, Handling, Storage and Transportation

Physical Configura-tion Audit (PCA).

The formal examination of the "as-built" configuration of a con-figuration item against its technical documentation to establish or verify the configuration item's system baseline.

MIL-HDBK-61A(SE)

7 Feb. 2001

PM Programme Manager Cat of ISS Services

Post Design Services (PDS)

Work undertaken to ensure that modifications and minor design alterations are properly appraised and implemented if required. It includes the redesign, redevelopment and engineering to pre-serve the equipment capability at the performance levels re-quired by the Participants as well as the Design Authority work necessary to maintain the design and manufacturing data and reference equipment. PDS may also be used for minor en-hancements such as meeting new/safety legislation, or for re-ducing In Service support costs PDS is not to be used for major redesign to meet new requirements.

PP Performance Parameter PPP Personnel Performance Profile

Preventive Mainte-nance

Maintenance Activities to prevent the occurrence of critical fail-ures or damages in conjunction with safety, economical or eco-logical aspects. The preventive maintenance also includes activi-ties after special events, where these events, chronological in-tervals or other regular thresholds cannot be defined.

ASD S3000L

Prime Contractor A supplier that makes a Contract with an acquirer to supply a system.

Product Life Cycle Support (PLCS)

The standard is an extension to the existing proven exchange capability of the Standard for Exchange of Product Data, also known as ISO 10303 (STEP). The PLCS Standard is published as

6 PHS&T requirements are determined during the DDP phase through Logistic Support Analysis and recorded in the LSAR.


an Application Protocol to the STEP standard as ISO 10303, AP 239. ISO 10303-239 (PLCS) is an international standard that specifies an information model that defines what information can be ex-changed and represented to support a product through life. This definition is provided by using the EXPRESS information model-ling language. The basic data structures that are exchanged are defined by EXPRESS Entities.

Programme Decision

The legally binding document approved and signed by the Pro-gramme Board representatives The Programme Decision shall detail the way the Programme shall be managed by OCCAR-EA and shall outline the rules and principles that shall apply.

OMP 2

Programme Man-agement

Programme Management is the planning, organisation, monitor-ing and control of all aspects of a Programme and the motiva-tion of all involved to achieve the Programme objectives safely and within agreed time, cost and performance criteria.

PS Participating State PSI Programme Security Instruction OMP 6, Annex A QA Quality Assurance

Quality Management System (QMS)

Is a system used to direct and control an organisation with re-gard to quality.

RCM Reliability Centred Maintenance

Reliability

Reliability is the duration or probability of failure free perform-ance of a system under stated conditions, or the probability that an item can perform its intended function for a specified interval under stated conditions.

ASD S3000L

Risk An uncertain event or condition that if it occurs has a positive or negative effect on a project’s objective. OMP 7

Risk Management

Risk management is to identify correctly the risks to the achievement of objectives and to ensure that control strategies are in place to manage them. The strategy for this will be to apply a continuous cycle of identifying, assessing, managing and reporting risks, while also reviewing the control strategies in place to deal with them.

OMP 1

RM&T Reliability, Maintainability and Testability

Safety Safety is defined as freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property, or damage to the environment

FAA System Safety

Handbook SAS Supportability Analysis Summary

scaling / scaling process

To provide/update the Provisioning List by calculating the re-quired numbers of each spare at pre-defined repair level and their initial procurement quantities. Initial provisioning or re-provisioning, to support the system for a specific period of time, is accomplished through statistical analysis, optimization and simulations. Periodical review of scaling should be done consid-ering experience gained from field, changing of operational or environmental scenario.

Security

Security is the condition achieved when designated information, materiel, personnel, activities and installations are protected against espionage, sabotage, subversion and terrorism, as well as against loss or unauthorized disclosure.

AAP 6

Security Manage-ment of the Defence

System

Security management of the Defence System is to ensure the security of any item, substance or device from which classified information can be derived. This includes Documents, equip-ment or components

OMP 11

Service Level Agreement (SLA)

Contract between customer and a supplier that stipulates and commits to a required level of service. An SLA should contain a specified level of service, support options, enforcement or pen-

http://www.webopedia.com/TERM/S/Service_Level_Agreement.html�


alty provisions for services not provided, a guaranteed level of system performance as relates to downtime or uptime, a speci-fied level of customer support and what software or hardware will be provided and for what fee.

Shared Data Envi-ronment

A secure electronic environment enabling all authorised mem-bers of a Programme to collaborate and share information across Intranet, Extranet and – in some cases – Internet in a controlled manner.

Simulation (Model-ling)

This category contains all the models based on system dynam-ics, discrete event simulation and Monte Carlo simulation. Sys-tem dynamics and discrete event simulation are both forms of simulation models that allow a representation of the activities of a system over time. Monte Carlo simulation is used in defence cost analysis to generate frequency or probability distributions, which are otherwise too difficult or impossible to generate mathematically, that is, using formulae.

SLA Service Level Agreement Cat of ISS Services

Software Software consists of “Programs, procedures, rules, data and any associated documentation pertaining to the operation of a com-puter system.”

IEE Standard 610.12-1990: IEEE Standard

Glossary of Software Ter-

minology

Spares Pooling A pool of spares that is managed and shared in common by all the PSs.

SOW Statement of Work SRD System Requirement Document SPP Second level Performance Parameter SSP Supply Support Procedure

Sub-Contractor Any legal entity that enters into a Sub-Contract. OMP 6, Anney A S&TE Support and Test Equipment

Sub-System

A subsystem is defined as a group of assemblies, designed to-gether to form a major part of a system, complete in its own right performing a specific function or functions. Example: A radar scanner in the A400M airplane.

OCCAR-EA, De-rived from

NATO AECT 100, Environ-mental Guide-lines for De-

fence Materiel

Supply Chaine

(1) The entire materiel chain from procurement and provision of an item to the point of consumption and its disposal as well as the return supply chain in the case of repairable goods. (2) A supply chain consists of all organisations involved, directly or indirectly, in fulfilling a customer's support requirements.

ASD S3000L

Supply Support

The process conducted to determine, acquire, catalogue, codify, receive, store, transport, issue, depot level repair and dispose of spares and components necessary for the support of a Defence System and its associated support equipment (Test equipment, ground equipment etc). This includes initial provisioning, re-provisioning; codification, procurement planning, order admini-stration, invoicing, repair administration and reverse supply.

Support and Test Equipment (S&TE)

S&TE comprises all equipment (mobile or fixed) required to sup-port the operation and maintenance of an Defence System. This includes associated multi-use end items, tools, metrology, cali-bration equipment and test equipment. As part of this discipline equipment specific Special Tools and Test Equipment (STTE) must be considered.

JSP 886


System

A system is a combination of sub-systems and/or parts/components organised to perform a function or functions. A system is one unit of a De-fence System. Example: One A400M airplane.

OCCAR_EA, Derived from NATO AECT

100, Environ-mental Guide-lines for De-

fence Materiel

System Engineering

Systems Engineering is to analyse and harmonise requirements for new modifications (from users or after analysis of In Service feedback), verify that the specified modification requirements are fulfilled and assist in the validation of the delivered modified product

OCCAR-EA, de-rived from ISO

15288

Technical Documen-tation

The information necessary to operate, maintain, repair, support and dispose of equipment throughout its life. It includes paper, fiche, drawings, Computer Aided Design data, electronic text, non-textual data e.g. graphics, video etc. Includes Illustrated Parts Catalogues, System description and operation; System servicing and maintenance; Diagnostic support; Repair informa-tion; Supporting flow, system and wiring diagrams; Software documentation.

Technical Event See In Service Event

Testability

Testability is a design characteristic which allows the status (op-erable, inoperable, or degraded) of an item and the location of any fault/failures within the item to be confidently determined in a timely fashion.

ASD S3000L

Through Life Man-agement

Through Life Management means managing a Programme throughout its whole life cycle, in a use-centric way. TLM is achieved by applying and integrating best practice management techniques in a coherent manner across all system aspects in order to deliver, sustain and dispose the required cost-effective defence system.

OCCAR CP 14-1

Through Life Man-agement Plan

A TLMP defines and connects all management activities of a Programme logically and time-wise throughout its whole life. OCCAR CP 14-1

TID Technical Information and Data TLM Through Life Management TLMP Through Life Management Plan TNA Training Need Analysis

Training Instruction and applied exercises for the attainment and reten-tion of knowledge, skills and attitude

MIL-HDBK-29612-4A

31 August 2001

Training equipment Items used in the support of training, such as trainers, opera-tional equipment, and other associated hardware.

MIL-HDBK-29612-4A

31 August 2001

Training Needs Analysis (TNA)

Is a structured survey and analysis of training requirements aris-ing as a result of new Defence System procurement, doctrinal change, organisational change, or changes to legislation. It gen-erally includes a comparison of different training methods and equipment, with a view to recommending the optimum training system for maximum cost-effectiveness.

Training system An integrated combination of all elements (e.g. training material and equipment, personnel and support) necessary to conduct training

MIL-HDBK-29612-4A

31 August 2001

Transition Problems Transition Problems Transition Problems

URD User Requirement Document

Use-centric The attribute describing that the in service use of a defence sys-tem has to be in the centre of attention at any time of the life CP 14-1


cycle of a defence system.

Waivers, Conces-sions

A specific, written authorisation to depart from a particular re-quirement of a Defence System’s current approved configuration documentation for a specific number of units or time period (A variance differs from an engineering change in that an approved engineering change requires corresponding revision of the De-fence System’s current approved configuration documentation).

WBS Work Breakdown Structure

Annex B: Performance Parameter Definitions



Performance Parameter Definition

One aim of the ISS Process Model is to establish a set of PPs able to calculate and/or measure the performances achieved by the support activities management.

The knowledge of the conventional interactions (or mathematical link) between these performance parameters7

Such a calculation can be performed even before the availability of a system is measur-able. Hence, together with LCC calculations, it represents a valuable tool for cost-effectiveness analyses. The ISS Process Model is described in

and the metrics that compose the availability formula allows to link each element in the ISS domain (element, activity and sub-activity) to the final Ma-jor Performance Parameter, the System Operational Availability.

Chapter 11.

The current annex provides all definitions of the PPs used within the ISS Process Model. It also provides the links between First level Performance Parameters and second and third level PPs.

The link between FPPs and Ao are described in annex C.

7 Due to the fact that the performance parameters and their mathematical interaction represent only one possible way to link the support elements with the system operational availability, they have to be clearly defined and agreed during the contractual phase.

Remark:

For the ISS Process Model a Patent Application at the EPO has been filed and a patent is pending.



Definition of Performance Parameter 1

Indicator Title CDC

Configuration Data Confidence

Service CM

Ref. 1

Unit Decimal Number

Owner OCCAR

Freq. Monthly

Description &

Formula

As a combination of DPP, it represents the confidence level reached in the configuration data management at any given time or the adherence be-tween Baseline Build Standard (BBS) and the real systems configuration. Value is between 0 and 1, 1 is best value.

CDCpCDCrCDC *=

Data required for

computation

Ref. Data Description

CDCp Configuration Data Completeness, it measures completeness of configuration data.

CDCr Configuration Data Correctness, it measures correctness of configuration data.

Score computation

Overcoming a predefined value shall set off problem identification and cor-rective actions. Conventionally it is possible to link this performance pa-rameter to the System Operational Availability:

MDTMTMBMTBMAo

+=

))1(1(* CDCMLDTMMTMDT −++=

If CDC =1 then MDT has its nominal value.



Definition of Performance Parameter 1.1

Indicator Title CDCp

Configuration Data Completeness

Service CM

Ref. 1.1

Unit Decimal Number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

As a combination of TPP, it represents the completeness of data defined for Configuration Management. A CDCp value less than 1 signals the pres-ence of unidentified CM items. Value is between 0 and 1, 1 is best value.

100*

100PAIPIDCDC p =

Data required for

Computation

NB: Each Item must be

considered multiplied for its own “criti-cality factor”.


PID Percentage of identified Items

Shared Data Environment (e.g. TIMS)

PAI Percentage of Accounted Items

Score computation

Overcoming a predefined value shall set off problem identification and cor-rective actions.




Indicator Title CDCr

Configuration Data Correctness

Service CM

Ref. 1.2

Unit Decimal Number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

As a combination of four TPP, it represents the correctness of data defined for Configuration Management. A CDCr value less than 1 signals the pres-ence of configuration data errors. Value is between 0 and 1, 1 is best value.

)100PCA-(1*)

300PNIPAEPOA(-1CDCr

++=

Data required for

Computation

NB: Each Item must be con-sidered multi-plied for its

own “criticality factor”.


POA Percentage of outstanding actions

PAE Percentage of accounting errors

PNI Percentage of ECP with embodiment decision but Not yet Implemented

PCA Percentage of Configuration Audits

Score computation




Definition of Performance Parameter 1.1.1

Indicator Title PID

Percentage of Identified Items HW & SW

Service CM

Ref. 1.1.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of identified items HW/SW (with defined the functional and physical characteristics) vs total items under Configuration Management. A PID value less than 100 signals the presence of items not identified by CM. 100% is best value.

100*TIDI PID =

Data required for

Computation


own “criticality factor”


DI

Total number of identified Items (completed with configuration data) (metric). Shared Data Environment

(e.g. TIMS)

TI Total number of Items designed for CM (metric)

Score computation

- The score computation can be used for PBL contracts.

- Overcoming a predefined value shall set off problem identification and corrective actions.

- Conventionally it is possible to link this performance parameter to spe-cific system requirements (e.g. Operational Availability)

Other contractual specifications




Indicator Title PAI

Percentage of Accounted Items

Service CM

Ref. 1.1.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of accounted Items vs total Identified items A PAI value less than 100 signals Items not yet accounted by CM. 100% is best value.

100*DIAI PAI =

Data required for

Computation

NB: Each Item must be consid-ered multiplied

for its own “criti-cality factor”


AI Total number of Accounted Items avail-able on the information system (metric) Shared

Data Environ-ment

(e.g. TIMS) DI Total number of identified Items (com-

pleted with configuration data) (metric)

Score computation





Indicator Title POA

Percentage of Outstanding Actions

Service CM

Ref. 1.2.1

Unit Percentage

Owner Industry

Freq. Monthly

Description &

Formula

Percent of outstanding action items vs total items under CM. A POA value greater than 0 signals outstanding action Items coming from Discrepancies/Changes Reports (Configuration Audit). 0% is best value.

100*TI

OA POA =

Data required for

Computation




OA Total number of Outstanding actions for different items. (metric) Shared

Data Environment (e.g. TIMS) and

Discrepancies /

Changes Reports TI Total number of Items designed for CM (metric)

Score computation








Indicator Title PAE

Percentage of Accounting Errors

Service CM

Ref. 1.2.2

Unit Percentage

Owner Industry

Freq. Monthly

Description &

Formula

Percent of Accounting Error (HW-SW) vs total items under CM. A PAE value greater than 0 signals errors in the accounting process (Con-figuration Accounting). 0% is best value.

100*TIAR PAE =

Data required for

Computation




AR Total number of accounting errors for different items (metric)

Shared Data Environment (e.g.

TIMS) and Discrepancies

/ Changes Reports TI Total number of Items

designed for CM (metric)

Score computation








Indicator Title PNI

Percentage of ECP not yet implemented

Service CM

Ref. 1.2.3

Unit Percentage

Owner Industry

Freq. Monthly

Description &

Formula

Percentage of Engineering Change Proposals with embodiment decision but not yet implemented vs total number of Identified Items. A PNI value greater than 0 signals Engineering Change Proposals with embodiment decision but not yet implemented. (Configuration Control). 0% is best value.

100*TINI PNI =

Data required

for Computation




NI Number of ECP approved but Not Yet implemented for different items (metric)

Shared Data Environment

(e.g. TIMS) and “ECP implementation Status”

TI Total number of Items de-

signed for CM (metric)

Score computation



- Conventionally it is possible to link this performance parameter to specific system requirements (e.g. Operational Availability)





Indicator Title PCA

Percentage of configuration audits

Service CM

Ref. 1.2.4

Unit Percentage

Owner Industry

Freq. Monthly

Description &

Formula

Percent of Configuration Audits vs total items under CM. (Configuration Audit). 100% is best value.

100*TICA PCA =

Data required for

Computation

NB: Each Item must be con-

sidered multiplied for its own “criti-cality factor”


CA Number of configuration audits for different items (metric)

Shared Data Environment (e.g.

TIMS) and “Result and status of Con-

figuration Audits” TI Total number of Items designed for CM (metric)

Score computation








Indicator Title MTE

Mean Time to process ECP

Service CM

Ref. 1.2.5

Unit Hours

Owner TBD

Freq. Monthly

Description &

Formula

TECP measures the medium time elapsed to process Engineering Change Proposals until the final approval/disapproval decision.

NE

TEMTE

NE

∑= 1

Data required for

Computation

NB: Each Item must be consid-

ered multiplied for its own “criticality

factor”


TE Time for processing ECP (metric)


NE Total number of approved/disapproved ECP (metric)

Score computation


- Overcoming a predefined time shall set off problem identification and corrective actions.

- This parameter is not considered on the evaluation of system operational availability.




Link between CDC and relative second and third level PPs.

CDC is judged under considerations of correctness and completeness. It is then obtained multiplying a factor taking into consideration correctness of the configuration process, CDCr, and another factor which takes into account the completeness of the process.

CDCpCDCrCDC *= (1) CDCp is the combination of 2 percentages: percentage of identified and percentage of accounted items so it is the product of these 2 percentages.

100*

100PAIPIDCDC p = (1.1)

CDCr takes into account percentages of the outstanding actions (POA), of the accounting errors (PAE) and of ECP not yet implemented (PNI) and it also considers that having some configuration audits (PCA) improve the configuration process. So POA, PAE and PNI decrease CDCr, as these 3 categories may contain same items, the decreasing effect was chosen as an average

)300

PNIPAEPOA(-1CDCr++

=

Furthermore, the configuration audits will help into improving the process (direct impact on

POA and PAE) so by multiplying the decreasing factor 300

PNIPAEPOA ++ by an increasing



factor considering the positive aspect of audit )100PCA-(1 [the best PCA is, the greatest influ-

ence on CDCr you will have). So we have finally the formula:

)100PCA-(1*)

300PNIPAEPOA(-1CDCr

++= (1.2)

As they are percentages, PID, PAI, POA, PAE, PNI and PCA are basic calculation (classical “partial number”/”total number”).




Indicator Title

MME

Maintenance Management Effectiveness

Service MM

Ref. 2

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the level of effectiveness reached in maintenance manage-ment activity at any given time. It is influenced by the effectiveness of all the other sub-activities in which MM has been spread. Value is between 0 and 1, 1 is best value.

ADTDEMMCRMPRMPCMME δ−++= *

3

Data required for

Computation


MPC Maintenance Plan Completeness, it measures completeness of Maintenance Plan (2.1.1)


MPR Maintenance Plan Correctness, it measures correctness of Maintenance Plan (2.1.2)

DMER (P) Disparity between MTTR (MPMT) expected and measured (2.2.1/2.2.2)

δADT Administrative Delay Time before mainte-nance actions (2.2.3)

MCR

Maintenance Data Completeness, it meas-ures the percentage of Maintenance Sig-nificant Items with updated maintainability data (2.3)

Score computation

The score computation is obtained from the evaluation of sub-level pa-rameters. Overcoming a predefined value shall set off problem identifica-tion and corrective actions. Conventionally it is possible to link this performance parameter to the Sys-tem Operational Availability through the usage of a derived perform-ance parameter called “Skill factor” (Sk, see derived Performance Parameter A).




Indicator Title MPC

Maintenance Plan Completeness

Service MM

Ref. 2.1.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of Maintenance Significant Items (MSI) with an approved and updated Maintenance Plan 100% is best value.

100*SIAPMPC =

Data required for

Computation


SI Number of Maintenance Significant Items (MSI) within the overall system (metric) Shared Data

Environment (e.g. TIMS)

AP Number of MSI with an approved and updated Maintenance Plan (metric)

Score computation

An MPC value less than 100% implies that the number of MSI without an approved Maintenance Plan is greater than zero. Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title MPR

Maintenance Plan Correctness

Service MM

Ref. 2.1.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

Disparity (%) between theoretical (at t=t0) and measured (t=t1) Preven-tive Mean Labour Hours per Operating Hour 100% is best value.

MEAS

MEAS

THEO

THEO

MHLOP

OPMHLMPR *=

Data required for

Computation


MHLTHEO Mean Preventive/corrective Labour Hours statistically defined (theoretical) (metric)


OPTHEO Operating Hours statistically defined (theoretical)

(metric)

MHLMEAS Measured Mean Preventive/corrective Labour Hours (metric)

OPMEAS Measured Operating Hours (metric)

Score computation

An MPR value less than 0 implies hitches in the maintenance planning process. Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title DEMR(tx)

Disparity MTTR

Service MM

Ref. 2.2.1

Unit Decimal number

Owner OCCAR-PD

Freq. Semester

Description &

Formula

Disparity between Mean Time To Repair expected considering the contrac-tual “Learning curve” (Ebbinghaus Law) (2.3) and measured at time tx. It means to accept that the MTTR value can be subject to variation during the transition period (TT) contractually defined. Value is between 0 and 1, 0 is best value.

)()(

)(xMEAS

xEXPxR tMTTR

tMTTRtDEM =

Data required for

Computation


MTTREXP(tx) Mean Time To Repair expected for t=tx (see 2.2.A) Shared Data


MTTRMEAS(tx) Mean Time To Repair measured for t=tx (metric)

Score computation

See 2.2.A




Indicator Title DEMP(tx)

Disparity MPMT

Service MM

Ref. 2.2.2

Unit Decimal number

Owner OCCAR-PD

Freq. Semester

Description &

Formula

Disparity between Mean Preventive Maintenance Time expected consider-ing the contractual “Learning curve” (Ebbinghaus Law) (2.3) and measured at time tx. It means to accept that the MPMT value can be subject to varia-tion during the transition period (TT) contractually defined. Value is between 0 and 1, 0 is best value.

)()(

)(xMEAS

xEXPxP tMPMT

tMPMTtDEM =

Data required for

Computation


MPMTEXP(tx) Mean Preventive Maintenance Time expected for t=tx (see 2.2.A)


MPMTMEAS(tx) Mean Preventive Time measured for t=tx (metric)

Score computation

See 2.2.B



Definition of Performance Parameter 2.2.A

Indicator Title

MTTRexp(tx)

MTTR Expected

Service MM

Ref. 2.2.A

Unit Hours

Owner OCCAR-PD

Freq. Semester

Description &

Formula

The Mean Time To Repair expected for t=tx is a projection of the actual measured value MTTR(t0) at a generic time t= tx considering the “Learning curve” (Ebbinghaus Law) obtained for the contractual learning factor.

)(log 02

**

*)()(t

xoLTHEORETICAxEXPECTED SIMTBF

UTILFtMTBFtMTTRtMTTR

β

+=

Data re-quired for

Computation


β(t0)

Learning factor: - β(t0) is the statistical value assumed during the transition period (between 0.7 and 0.9 best value). This parameter should be contractually defined (otherwise it is possible to assume it equal to 0.7).

Shared Data Environment (e.g. TIMS) MTTRTHEO(to)

Mean Time To Repair theoretical: 02log

. **/)()(

β

+=

SIMTBFUTILFTTMTBFTTMTTRtMTTR REQoTH

MTBF Mean Time Between Failure

Score computation

For the score computation the following data must be contractually defined: TT= Admitted transition period for activities optimization MTTRREQ (TT) = MTTR required at the end of the transition period UTILF= System utilization factor SI= Number of MSI

Environments validity

The utilisation of the above formula is needed to link PPs and Ao, otherwise it is possible to consider the MTTREXP equal to the theoretical one (see De-rived Performance Parameter A1)



Definition of Performance Parameter 2.2.B

Indicator Title

MPMTexp(tx)

MPMT expected

Service MM

Ref. 2.2.B

Unit Hours

Owner OCCAR-PD

Freq. Semester

Description &

Formula

The Mean Preventive Maintenance Time expected for t=tx is a projection of the actual measured value MPMT(t0) at a generic time t= tx considering the “Learning curve” (Ebbinghaus Law) obtained for the contractual learning factor.

)(log 02

**

*)()(t

xoLTHEORETICAxEXPECTED SIMTBPM

UTILFtMTBPMtMPMTtMPMT

β

+=

Data re-quired for

Computation


β(t0)

Learning factor: β(t0) is the statistical value assumed during the transition period (between 0.7 and 0.9 best value). This parameter should be contrac-tually defined (otherwise it is possible to as-sume it equal to 0.7).

Shared Data Environment (e.g. TIMS) MPMTTHEO(to)

Mean Time To do Preventive Maintenance theoretical:

02log

. **/)()(

β

+=

SIMTBPMUTILFTTMTBPMTTMPMTtMPMT REQoTH

MTBPM Mean Time Between Preventive Maintenance

Score computation

For the score computation the fallowing data must be contractually defined: TT= Admitted transition period for activities optimization MPMTREQ (TT) = MPMT required at the end of the transition period UTILF= System utilization factor SI= Number of MSI

Environments validity The utilisation of the above formula is needed to link PPs and Ao, otherwise it

is possible to consider the MPMTEXP equal to the theoretical one (see Derived Performance Parameter A1)




Indicator Title ADTδ

Administrative delay

Service MM

Ref. 2.2.3

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

Disparity between theoretical (at t=t0) and measured (t=t1) Administrative Delay Time (ADT) before work order execution (maintenance action). If [ADTt1 > 2*ADTt0] then it will be considered in the process that δADT = 1. Value is between -1 and 1, -1 is best value.

t0

t0t1(tx) ADT

ADT-ADT ADT =δ

Data required for

Computation


ADT(t0) Contractual Administrative Delay Time or agency proc-essing time (metric)


ADT(tx)

Measured Administrative De-lay Time or agency process-ing time for a generic time period (metric)

Score computation

A δADT value greater than zero implies hitches in the corrective/preventive maintenance process. Overcoming a predefined value shall set off problem identification and corrective actions.

Environments validity

The Administrative Delay Time or agency processing time is an average time (system level ) from when an item is initially received for mainte-nance (or Industry is called for maintenance) to the point when active maintenance actually begins




Indicator Title MCR

Maintenance Data Completeness

Service MM

Ref. 2.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It measures the percentage of Maintenance Significant Items within the Maintenance Plan that can rely on updated maintainability data. 100% is best value.

100*SI

MCMCR =

Data required for

Computation


SI Number of Maintenance Significant Items (MSI) within the overall system (metric) Shared Data


MC

Number of MSI within the Maintenance Plan that can rely on updated maintenance Data (to be contractually defined) (metric)

Score computation

A MCR value less than 100% implies that the number of items without up-dated maintainability data and maintainability evaluation (to be contractu-ally defined) is greater than zero. Overcoming a predefined percent value shall set off problem identification and corrective actions.



Link between MME and relative second and third level PPs.

ADTDEMMCRMPRMPCMME δ−++= *

3 (2)

MME is the Maintenance Management Effectiveness. It takes into account the average sum of:

• Maintenance Plan Completeness: 100*SIAPMPC = (2.1.1), fraction number of Most

Significant Items with maintenance data approved and this number of items,

• Maintenance Plan Correctness: MEAS

MEAS

THEO

THEO

MHLOP

OPMHLMPR *= (2.1.2), to evaluate differ-

ence between measured and theoretical times of operating hours and maintenance hours,

• Maintenance Data Completeness: 100*SI

MCMCR = (2.3) considers the number of most

significant items that can rely on updated maintenance data. The more correct and complete are Maintenance Plan and data, the more MME is close to 1. In order to consider that MTTR real is not the theoretical one, DEM is included. This correction fac-tor contains element that describes the learning maintenance curve. Advancing in time, main-tainers are getting more and more trained and able to carry on maintenance so DEM will slowly get close to 1. So DEM is defined as multiplication of DEM for preventive maintenance and DEM for corrective maintenance.



)()(

)(xMEAS

xEXPxR tMTTR

tMTTRtDEM = (2.2.1)

)()(

)(xMEAS

xEXPxP tMPMT

tMPMTtDEM = (2.2.2)

Where:

)(log 02

**

*)()(t

xoLTHEORETICAxEXPECTED SIMTBF


β

+= (2.2.A)

02log

. **/)()(

β

+=

SIMTBFUTILFTTMTBFTTMTTRtMTTR REQoTH

)(log 02

**

*)()(t

xoLTHEORETICAxEXPECTED SIMTBPM

UTILFtMTBPMtMPMTtMPMT

β

+= (2.2.B)

02log

. **/)()(

β

+=

SIMTBPMUTILFTTMTBPMTTMPMTtMPMT REQoTH

• β(t0) is the factor which takes into account learning • MTTR Mean Time To Repair for corrective maintenance • MPMT Mean Time to do Preventive Maintenance • UTILF: frequency of operational use for Defence System • TT: period of time for which is considered activity optimization, for example duration of ISS contract • Tx: time

ADTδ is a penalty to consider administrative delay before maintenance actions.

t0

t0t1(tx) ADT

ADT-ADT ADT =δ (2.2.3)

t1ADT is the administrative delay measured and t0ADT the contractual one. It is assumed

that if t1ADT >2* t0ADT then 1 ADT(tx) =δ .



OperationalAvailability

1.ConfigurationConfidence

Supply Support Management Performance Parameters Breakdown Structure

Major Performance Parameter

DerivedPerformanceParameters

Technical SupportCapability

3. Supply SupportEffectiveness

MaintenanceEffectiveness

ObsolescenceConfidence

Skill Factor

Tech. DataEffectiveness

Training Services EffectivenessREST

First LevelPerformanceParameters

Second LevelPerformanceParameters

Third LevelPerformanceParameters

3.2.1Spares/repair

Provisioning Plan

First level

Second Level

Third Level

Derived PPS


3.1.1Spare utilization

rate

3.2 Spare Pool level

3.2.2Spares/repair

Procurement Plan

3.2.3Delay time for spares

3.3 Turn around

time

3.aDelay time forspares/repairs

3.1 PNSS

3.4Percentage of

mishandling items

3.4.1Delay time fortransportation

3.5Supportability Data

completeness

3.3.1Repairs into

Customer price list




Indicator Title

SSE

Supply Support Effectiveness

Service SSM

Ref. 3

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the level of effectiveness reached in the management of supply support activity at any given time. It is influenced by the effectiveness of all the other sub-activities in which SSM can be spread. Value is between 0 and 1, 1 is best value.

))100

1(100

1(*)](*)1()(*[

)(*)(*)1()()( 000

SDCMIPtDTPNSStDTPNSS

tDTROStDTROStMLDTtMLDT

SSExSRxT

SRT

x −++−+

+−==

Data re-quired for

Computation


ROS Initial contractual Risk of Shortage (t =t0)


DTT Delay time for transportation (3.4.1)

DTSR

Delay time for spares not available in the stock pool or repairs under repair cycle (3.2.3)

PNSS Probability of Not short Storage (equal to 1-ROS) (3.1)

MIP Percentage of mishandling items (3.4)

SDC Supportability data Completeness (3.5)

Score computation

The score computation is obtained from the evaluation of sub-level parame-ters. Overcoming a predefined value shall set off problem identification and corrective actions. Conventionally it is possible to link this performance pa-rameter to the System Operational Availability as following:

)/1(*)(

SSEMLDTMTTRMTBFMTBFTA++

=




Indicator Title PNSS

Probability of Not Short Storage

Service SSM

Determination of requirements

Ref. 3.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

The mean PNSS for the inventory is obtained by the ratio between the number of Purchase Orders satisfied vs total number of Purchase Orders. For t=t0 (initial time) it is assumed to be PNSS= 1-ROS, statistical risk of shortage (contractual). 100% is best value.

When t=t0 ROSPNSS −= 1

When t= tx 100*PO

POSPNSS =

Data required for

Computation


ROS Initial or contractual Risk of shortage (metric)


POS Number of satisfied purchase orders (metric)

PO Total number of purchase orders (metric)

Score computation

The score computation can be done thorough the metrics measurement.

Each Item must be considered multiplied for its own “criticality factor”

A PNSS value less than the contractual one implies lack on “Determination of requirements” activity

Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title UTR

Spare Utilization Rate

Service SSM

Determination of requirements

Ref. 3.1.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

UTR monitors the number of utilised items vs total number of items in the pool inventory. It could be possible to measure this parameter excluding Long Lead Item or/and insurance items. 100% is best value.

100*SRUSUTR =

Data required for

Computation


US Total number of utilised spares/repairs parts within a defined period (metric)


SR Total number of spares/repairs parts in the inventory (metric)

Score computation


Each Item must be considered multiplied for its own “criticality factor”.

A value less than 100 signals the presence of lacks in the “Determination of requirements” activities. Overcoming a predefined value shall set off prob-lem identification and corrective actions.

This parameter is not considered on the evaluation of system op-erational availability.




Indicator Title SPL

Spares Pools Level

Service

SSM Material

provisioning & acquisition

Ref. 3.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

SPL monitors the percentage of items in the spares pools vs total items in the inventory (total quantity of items that should be present) 100% is best value.

100*1

SR

KSPL

IT

n

IT∑==

Data required for

Computation


k Existing stock: number of parts carried in stock of any given spare/repair typology (IT) at time tx(metric) Shared Data


SR Total number of spares/repairs parts in the inventory (metric)

Score computation


Overcoming a predefined value signals the presence of lacks in the “mate-rial provisioning” tasks shall set off problem identification and corrective ac-tions.

This parameter is not considered on the evaluation of system op-erational availability.




Indicator Title

SPC

Percentage of spares/repairs with approved Procurement Plan

Service SSM

Material procurement

Ref. 3.2.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

SPC monitors the percentage of spares/repairs included on the Procurement Plan. 100% is best value.

100*ITSPSPC =

Data required for

Computation


SP Number of spares/repairs typology with approved Procurement Plan (metric)


IT Total number of spares/repairs typology (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “material procure-ment” sub-activity. Overcoming a predefined value shall set off problem identification and corrective actions. This parameter is not considered on the evaluation of system op-erational availability.




Indicator Title

SPP

Percentage of spares/repairs with approved Provisioning Plan

Service SSM

Material provisioning

Ref. 3.2.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

SPP monitors the percentage of spares/repairs included on the Provisioning Plan. 100% is best value.

100*ITPISPP =

Data required for

Computation


PI Number of spare/repair typology with ap-proved Provisioning Plan (metric) Shared Data


IT Total number of spare/repair typology (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “material provision-ing” task. Overcoming a predefined value shall set off problem identifica-tion and corrective actions. This parameter is not considered on the evaluation of system op-erational availability.



Definition of Derived Performance Parameter 3a

Indicator Title DTSR

Delay time for spares and repairs

Service

SSM Material

provisioning & acquisition /

Repairs Administration

Ref. 3a

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

DTSR represents the mean time required to obtain spares not available in the stock pool or repairs under repair cycle.

RS

RSSSR

TATDTDT

λλλλ

++

=**

Data required for

Computation


DTS Delivering time for spares (LEADT, OPUS10) 3.2.3


TAT Turn around time for repairs, 3.3

λS

Medium failure rate for spares (metric): number of failure occurrences for non-repairable items within a specific time frame

λR Medium failure rate for repairs (metric): number of failure occurrences for repair-able items within a specific time frame

Score computation

It is a Derived Performance Parameter: the score computation can be done thorough evaluation of lower level of PPs and the metrics measurement that belong to different activities (Material provisioning and Repair admini-stration). Each Item must be considered multiplied for its own “criticality factor”





Indicator Title DTS

Delivering Time for spares

Service SSM

Material acquisition

Ref. 3.2.3

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

DTS represents the mean time required to obtain spares not available in the stock pools.

DU

DTDT

DU

DUi

S

∑= 1

Data required for

Computation


DT DUi Spare replenishment time: Delivering time required to obtain spare/discardable unit not available in the stock pool (metric) Shared Data


DU Managed spares/ Discardable units: Number of spares/ Discardable units man-aged on PHST activity (metric)

Score computation

The score computation can be done thorough the metrics measurement. Each Item must be considered multiplied for its own “criticality factor”

Overcoming a predefined value signals the presence of lacks in the trans-portation task and shall set off problem identification and corrective ac-tions on “Acquisition” sub-activity.




Indicator Title TAT

Turn Around Time

Service SSM

Repair administration

Ref. 3.3

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

TAT measures the mean time for a repairable item to go through the com-plete cycle, from the operational installation to the maintenance shop and back to the spares inventory, ready for use.

LRU

TATTAT

LRU

i∑= 1

Data required for

Computation


TATi Time for a single repairable item to go through the complete repairing cycle (metric) Shared Data


LRU Number of repairable items managed on PHST activity (metric)

Score computation

The score computation can be done thorough the metrics measurement. Each Item must be considered multiplied for its own “criticality factor”

Overcoming a predefined value signals the presence of lacks on Repair administration and shall set off problem identification and corrective ac-tions.




Indicator Title

RCP

Percentage of repairs into approved “Customer Price List”

Service

SSM Repair &

procurement plan

Ref. 3.3.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

RCP monitors the percentage of repairs with an approved customer price. 100% is best value.

100*LRUCPRPC =

Data required for

Computation


CP Number of spares/repairs typology with approved customer price (metric)


LRU Number of repairable items (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “repair & pro-curement plan” sub-activity. Overcoming a predefined value shall set off problem identification and corrective actions.

This parameter is not considered on the evaluation of system operational availability.




Indicator Title MIP

Percentage of mishandling items

Service SSM

PHS&T

Ref. 3.4

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

MIP monitors the percentage of spares/repairs damaged during PHST tasks. 100% is best value.

100*USDRMIP =

Data required for

Computation


DR Number of items subject to discrepancies reports due to PHST tasks (metric)



Score computation

The score computation can be used for PBL contracts

Each Item must be considered multiplied for its own “criticality factor” Overcoming a predefined value shall set off problem identification and corrective actions on “PHST” activity.

Conventionally it is possible to link this performance parameter to specific system requirements (e.g. Operational Availability)





Indicator Title

DTT

Delay Time for transportation for items available in the pools

Service SSM

Transportation

Ref. 3.4.1

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

DTT is the average transportation time from the storing site to the place where the spares need (for items available in the stock pool). The contrac-tual value could be different according to the item priority level. (Order and shipping time, OPUS10)

100*1

US

DTDT

US

T

T

∑=

Data required for

Computation


DTT Measured Time required for each spare transportation for items available in the pools (metric) Shared Data



Score computation

The score computation can be used for PBL contracts

Each Item must be considered multiplied for its own “criticality factor” Overcoming a predefined value shall set off problem identification and corrective actions on “PHST” activity.

Conventionally it is possible to link this performance parameter to spe-cific system requirements (e.g. Operational Availability)





Indicator Title SDC

Supportability data completeness

Service SSM

Inventory Management

Ref. 3.5

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

SDC monitors the percentage of MSI fulfilled with updated logistic supportability data. This set of data must be contractually defined. 100% is best value.

100*ITLISDC =

Data required for

Computation


LI Number of spares/repairs typology with logistic supportability data available (metric) Shared Data


IT Total number of spares/repairs typology (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “inventory man-agement” activity. Each Item must be considered multiplied for its own “criticality factor” Overcoming a predefined value shall set off problem identification and cor-rective actions.



Link between SSM and relative second and third level PPs.

))100

1(100

1(*)](*)1()(*[

)(*)(*)1()()( 000

SDCMIPtDTPNSStDTPNSS

tDTROStDTROStMLDTtMLDT

SSExSRxT

SRT

x −++−+

+−== (3)

Supply Support Effectiveness is the fraction between Mean Logistic Down Time (MLDT) initial and MLDT at time considered. PNSS is:

• When t=t0 ROSPNSS −= 1 (3.1)

• When t= tx 100*PO

POSPNSS = (3.1) to consider no more an initial objective ROS

but the Purchase Orders Satisfied MLDT at to is combination of:

• Delay Time for transportation when the spare is in stock [ )(*)1( 0tDTROS T− ]

• plus Delay Time for spares not in stock or in repair [ )(* 0tDTROS SR ]. MLDT at tx is combination of:

• Delay Time for transportation when the spare is in stock [ )(* xT tDTPNSS ]

• plus Delay Time for spares not in stock or in repair [ )(*)1( xSR tDTPNSS− ]

OperationalAvailability

1.ConfigurationConfidence

Supply Support Management Performance Parameters Breakdown Structure

Major Performance Parameter


Technical SupportCapability

3. Supply SupportEffectiveness

MaintenanceEffectiveness

ObsolescenceConfidence

Skill Factor

Tech. DataEffectiveness

Training Services EffectivenessREST

First LevelPerformanceParameters

Second LevelPerformanceParameters

Third LevelPerformanceParameters

3.2.1Spares/repair

Provisioning Plan

First level

Second Level

Third Level

Derived PPS


3.1.1Spare utilization

rate

3.2 Spare Pool level

3.2.2Spares/repair

Procurement Plan

3.2.3Delay time for spares

3.3 Turn around

time

3.aDelay time forspares/repairs

3.1 PNSS

3.4Percentage of

mishandling items

3.4.1Delay time fortransportation

3.5Supportability Data

completeness

3.3.1Repairs into

Customer price list



• the previous sum is then multiplied by a factor ))100

1(100

1( SDCMIP−++ , which tends

to decrease SSE as MIP ( 100*USDRMIP = (3.4), Utilized Spare (US) subject to Dis-

crepancies Report (DR) during PHST operations) increases and SDC (

100*ITLISDC = (3.5), Logistic Information updated for Total number of ITems) de-

creases (so ]100

1[ SDC− increases).

Calculation of Delay Time for Spare/Discard unit not available in stock is

RS

RSSSR

TATDTDT

λλλλ

++

=**

(3a), where:

• DTs is the average delivering time for spares, DU

DTDT

DU

DUi

S

∑= 1 (3.2.3)

• TAT, Turn Around Time, LRU

TATTAT

LRU

i∑= 1

(3.3), average Time required to repair spares.

Calculation of Delay Time for items available in stock is 100*1

US

DTDT

US

T

T

∑= (3.4.1), aver-

age time observed in a period for items transported from Stock to System.




Indicator Title TSC

Technical Support Services Capability

Service TSS

Ref. 4

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the level of capability reached in the management of technical support activities at any given time. It is defined as the ratio between achievable MTBF in a defined period T, and the correspondent MTBF value required in the same time period (contractual parameter). It means to assume a system subject to “reliability growth” due to technical support services. Value is between 0 and 1, 1 is best value.

)()(

TMTBFTMTBF

TSCREQ

ACH=

Data required for

Computation


MTBFACH

Mean Time Between Failures achievable in a defined period T due to technical sup-port services (see Derived Performance Parameter 4a). Shared Data


MTBFREQ Contractual value of MTBF required within the same period of time.

Score computation

The score computation is obtained from the evaluation of sub-level pa-rameters. Overcoming a predefined value shall set off problem identifica-tion and corrective actions. Conventionally it is possible to link this per-formance parameter to the System Operational Availability as following:

MLDTMTTRTSCMTBFTSCMTBFTA

++=

**)(




Indicator Title

MTBFACH

Mean Time Between Failures achiev-able

Service TSS

Ref. 4a

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

Mean Time Between Failures achievable in a defined period T, following the reliability growth due to technical support services.

SEtMTBFTMTBFtMTBFTMTBF xEXPxACH *)]()([)()( −+=

Data required for

Computation


MTBF(tx) Mean Time Between Failures measured for

t = tx.


MTBFEXP(T)

MTBF expected is the theoretical MTBF value at time T, obtained by the application

of the Duane Model considering the reliability growth rate (α) at time tx. (4c)

)(

00 *)()(

xt

THEOEXP tTtMTBFTMTBF

α

=

SE Technical support effectiveness (4b)

Score computation

The time considered is “operating time” (obtained from the calendar time through the utilization factor). The score computation can be done through the evaluation of lower level performance parameters. Overcoming a prede-fined value signals the presence of lacks in the “Technical support services” sub-activities and shall set off problem identification and corrective actions.




Indicator Title SE

Technical Support Effectiveness

Service TSS

Ref. 4b

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

The SE parameter clusters all PIs linked with sub-activities of TSS and shows the level of the formal fulfilment of all tasks. 100% is best value.

PRRPTIPRMPEASE *3

100/100/100/

++

=

Data required for

Computation


PRM Percentage of ISER / Data reports with reliability and maintainability evaluation vs their total number (4.1)


PEA Percentage of accounted events/data re-ports vs total number of In Service Events Reports (ISER) and data reports (4.2.1)

PRR Percentage of root causes removed vs total number of ISER (4.2.2)

PTI Percentage of technical investigations vs total number of Requests for Contractor assistance (4.3)

Score computation

- The score computation is obtained from the evaluation of sub-level pa-rameters and can be used for PBL contracts

- A value less than 100 signals the presence of lacks in the “Technical support services” activities

- Overcoming a predefined value shall set off problem identification and corrective actions

- Conventionally it is possible to link this performance parameter to specific system requirements (e.g. Operational Availability)





Indicator Title

PRM

Percentage of ISER / Data reports with reliability and maintainability

evaluation

Service

TSS In service

monitoring of RM&T

performances

Ref. 4.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of “In service monitoring of RM&T performance” activity. It represents the percentage of ISER / Data reports with reliability and maintainability evaluation vs their total accounted number. 100% is best value.

100*ISERRMPRM =

Data required for

Computation


ISER Total number of In Service Events Reports and Data Reports on system utilization (metric) Shared Data


RM Number of ISER and Data reports utilised for Reliability & Maintainability evaluations (metric)

Score computation

- The score computation can be used for PBL contracts

- A value less than 100 implies lacks on “In service monitoring of RM&T performances” activity







Indicator Title

PEA

Percentage of accounted events/data reports

Service TSS

Ref. 4.2.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of data accounting task. It represents the percentage of accounted events/data reports vs total number of In Service Events Reports (ISER) and data reports. 100% is best value.

100*ISER

IRPEA =

Data required for

Computation




IR Number of accounted ISER and Data re-ports (metric)

Score computation


- The score computation can be done through the metrics measurement.

- A value less than 100 signals the presence of lacks in the “Technical events accounting” sub-activity







Indicator Title PRR

Percentage of root causes removed

Service TSS

Technical investigation

Ref. 4.2.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of “Technical Investigation” sub-activity. It represents the percentage of root causes removed vs total number of ISER. 100% is best value.

100*ISERRRPRR =

Data required for

Computation




RR Number of ISER with approved conclu-sions (root causes removed) (metric)

Score computation



- A value less than 100 signals the presence of lacks in the “Technical Investigation” tasks.





Indicator Title PTI

Percentage of technical Investigations

Service TSS

Post design services

Ref. 4.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of “Technical Assistance” activ-ity (Post Design). It represents the percentage of approved technical in-vestigations vs total number of “Requests for Contractor assistance” 100% is best value.

100*RCARIPTI =

Data required for

Computation


RCA Total number of request for Contractor technical assistance (Post Design) (metric) Shared Data


RI Number of Report Investigations approved by the customer (metric)

Score computation


- A value less than 100 signals the presence of lacks in the “Post Design service” activity







Indicator Title

α(tx)

Reliability Growth rate for a specific time tx,

Service TSS

Ref. 4.2

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

The reliability growth rate α (tx) (Duane Model) is index able to show the effectiveness of adopted technical solutions. It is calculated from t0 and tx, considering the measured MTBF at the generic time (tx), taking into account the embodied modifications, and the theoretical initial value of MTBF (to) at TSS starting point. Value is between 0.01 and 0.03

=

)()(

log)(00

tMTBFtMTBF

tTHEO

x

ttx x

α

Data required for

Computation


MTBF(tx) Mean Time Between Failures measured for t = tx (metric)


MTBFTHEO(t0)

The initial MTBF(to) value (if it is not stated in the Contract like minimum admissible value of MTBF) is derived by the Duane Model formula,

)(

00

0

*)()(t

REQTHEO tTTMTBFtMTBF

α

=

• MTBFREQ(T), value required at the end of TSS (T);

• α(t0) minimum provided by Contract (as-sumed equal to 0.01) (metric)

t

Operating time under test conditions, obtainable from the calendar time through the utilization factor (t0 initial time, tx generic time, T contrac-tual extension of TSS) (metric)

Score computation

- The score computation can be used for PBL contracts - A value less than 100 signals the presence of lacks in the “technical sup-

port services” activities (using the other PPs it is possible to define the faulty activity)







Indicator Title DIR

Dispatch Interruption Rate

Service TSS

Technical Event Management

Ref. 4.4

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

Ratio of the number of delays and cancellations, whose imputation is tech-nical and intrinsic to the product, on the number of scheduled sorties (%). 100% is best value.

NSSNDC

DIR ∑=

Data required for

Computation


NDC Total number of delay and cancellation for scheduled sorties (metric) Shared Data


NSS Number of scheduled sorties (metric)

Score computation



- A value less than 100 signals the presence of lacks in “technical event management” activity.

- Overcoming a predefined shall set off problem identification and correc-tive actions.




Indicator Title MTI

Mean Time for processing ISER

Service TSS

Technical Event investigation

Ref. 4.4.1

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of technical investigation tasks. It represents the elapsed time between the accounting of an ISER and the issuing of the Decision form concerning the Investigation report (final ap-proval).

ISER

TRMTI

ISER

∑= 1

Data required for

Computation


ISER Total number of In Service Events Reports (metric) Shared Data


TR Time for processing ISER (metric)

Score computation



- Overcoming a predefined value signals the presence of lacks in the TAS service and shall set off problem identification and corrective actions.




Indicator Title

TAS

Mean Time to Technical Assistance Service investigation

Service

TSS Safety event and

warranty management

Ref. 4.4.2

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of technical assistance service (TAS) for safety and/or warranty events. It represents the elapsed time between the accounting of a Request for TAS and the real intervention of the technical team.

NRT

TTITAS

NRT

∑= 1

Data required for

Computation


NRT Total number of Request for TAS (metric) Shared Data Environment (e.g. TIMS)

TTI Elapsed time for TAS intervention (metric)

Score computation



- Overcoming a predefined value signals the presence of lacks in the TAS service and shall set off problem identification and corrective actions.



Link between TSS and relative second and third level PPs.

)()(

TMTBFTMTBF

TSCREQ

ACH= (4)

Technical Support Capability is the fraction between:

- SEtMTBFTMTBFtMTBFTMTBF xEXPxACH *)]()([)()( −+= where: o MTBF(tx) is MTBF measured at tx

o

)(

00 *)()(

xt


α

= , where

=

)()(

log)(00

tMTBFtMTBF

tTHEO

x

ttx x

α

(4.2) illustrates the reliability growth rate

o )(

00 *)()(

xt


α

=

o PRRPTIPRMPEASE *3

100/100/100/

++

= (4.b), where PEA, PRM and

PTI are percentages evaluating effectiveness of Technical Services for main-tainability, accounting events and technical investigations. PRR decreases SE by considering the number of In Service Events Report that do not have con-clusion. As PEA, PRM, PTI and PRR are percentages, their basic calculation (classical “partial number”/”total number”) is described in Annex B.

- MTBFREQ(T) which is the MTBF requested within period T, for example duration of the ISS contract.




Indicator Title OMC

Obsolescence Management Confidence

Service OM

Ref. 5

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter measures, for a specific time tx, the capability to minimise the obsolescence risks within the system. Value is between 0 and 1, 1 is best value.

)*1(*1 OACOSCOBSOMC −−=

Data required for

Computation


OBS (tx) Obsolescence curve (5.a) Shared Data Environment (e.g. TIMS)

OSC System obsolescence status confidence (5.1)

OAC System obsolescence analysis confidence (5.2)

Score computation

- The score computation is obtained from the evaluation of sub-level parameters.

- Together with OMC admissible (OMCADM), it might be necessary to define a maximum time during which this lower value can be admit-ted (instantaneous OMC value of 1 at all times is statistically not achievable). Overcoming these ceilings signals the presence of lacks in the “Obsolescence management” and shall set off problem identifi-cation and corrective actions.

- Conventionally it is possible to link this performance parameter to the System Operational Availability as following:

MDTMTMBMTBMAo

+=

MLDTMMTMDT +=

SkMTTRMMT *=

]*))1(1[(*)]1([ SDTOMCPNSSMATOMCPNSSMLDT −+−+−−=




Indicator Title OBS

Obsolescence curve

Service OM

Ref. 5a

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

OBS represents the Life cycle curve, evaluated only for COTS items or items subject to obsolescence. The punctual value is the percentage of obsolete items. Value is between 0 and 1, 0 is best value.

SIOIetOBS

x

x *)( 2

2

2σ−

=

or : SIOIetOBS MTBU

t

x

x

*)( )01.0ln/( 2

2−

=

Data required for

Computation


tx Generic time tx


MTBU

Mean Time between systems upgrading (change of item that can be subject to obsolescence). Gener-ally it is assumed to be equal to LIFEL, life cycle period for obsolescent items, 5-7 years.

σ Standard deviation. Percentage of “critical” and “not critical” item considered not obsolete at the end of Obsolescence life cycle (assumed 0.01)

OI Total number of critical and not critical items (items designed for obsolescence management)

SI Maintenance Significant Items

Score computation

The score computation can be done through the metrics evaluation.




Indicator Title OSC

System Obsolescence status confidence

Service

OM Monitoring & Identification Obsolescence

accounting

Ref. 5.1

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter measures the capability of monitoring and accounting ob-solescence data. Value is between 0 and 1, 1 is best value.

)1(*)1(* OAEPOEPIOOSC −−=

Data required for

Computation


PIO Percentage of identified critical/not critical items with associated obsolescence data (5.1.1) Shared Data

Environment (e.g. TIMS) POE Percentage of obsolescence data errors

(5.1.2)

OAE Percentage of accounting errors (5.1.3)

Score computation

- The score computation can be done through the evaluation of lower level performance parameters and used for PBL contracts

- A value less than 1 implies lacks on related services







Indicator Title

PIO

Percentage of identified critical/not critical items with associ-

ated obsolescence data

Service OM

Obsolescence monitoring

Ref. 5.1.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of obsolescence data acquisition task. It represents the percentage of accounted item with completed and updated obsolescence data vs total number of items designed for obsoles-cence management. 100% is best value.

100*OIODPIO =

Data required for

Computation


OI Total number of critical/not critical items designed for obsolescence monitoring (metric) Shared Data


OD Number of items with complete and up-dated obs. Data (metric)

Score computation

- The score computation can be done through the metrics measurement and used for PBL contracts

- A value less than 100 signals the presence of lacks in the Obsolescence Identification







Indicator Title

POE

Percentage of obsolescence data subject to errors

Service OM

Ref. 5.1.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of obsolescence data aggrega-tion task. It represents the percentage of items with completed and up-dated obsolescence data subject to errors vs total number of accounted items. 100% is best value.

100*ODOEPOE =

Data required for

Computation


OE Total number of items with incorrect obso-lescence data (metric)


OD Number of items with complete and up-dated obs. Data (metric)

Score computation









Indicator Title OAE

Percentage of accounting errors

Service OM

Obsolescence accounting

Ref. 5.1.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of obsolescence data account-ing task. It represents the percentage of items subject to accounting errors vs total number of accounted items. 100% is best value.

100*ITLISDC =

Data required for

Computation


AE Total number of items subject to account-ing errors. Shared Data

Environment (e.g. TIMS) OD Number of items with complete and up-

dated obs. Data.

Score computation









Indicator Title OAC

Effectiveness of Obsolescence solutions

Service OM

Ref. 5.2

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter measures the capability to provide effective obsolescence solutions. Value is between 0 and 1, 1 is best value.

)1(*)1( APAPONOAC −−=

Data required for

Computation


PON Percentage of obsolescence issues for items not included into the Obsolescence List (5.2.1) Shared Data


APA Percentage of approved proposed actions (5.2.2)

Score computation









Indicator Title

PON

Percentage of obsolescence issues for items not included into the

Obsolescence List

Service

OM Asses

obsolescence issues

Ref. 5.2.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of obsolescence monitoring sub-activity. It represents the percentage of items become obsolescent or ob-solete not included into Critical/ Not-Critical items list. 100% is best value.

100*OOONPON =

Data required for

Computation


ON Total of obsolescent and/or obsolescence issues for items not included into Critical/ Not-Critical items list (metric) Shared Data


OO Total number of obsolete and/or obsoles-cent items (metric)

Score computation









Indicator Title

APA

Percentage of approved proposed actions

Service OM Derive strategy

Ref. 5.2.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

This parameter monitors the effectiveness of obsolescence resolution tasks. It represents the percentage of approved proposals for obsoles-cence resolution. 100% is best value.

100*OOORAPA =

Data required for

Computation


OR Number of approved proposals for obso-lescence resolution (metric) Shared Data


OO Total number of obsolete and/or obsoles-cent items (metric)

Score computation









Indicator Title PWO

Obsolescence rate for inventory

Service

OM Data

aggregation Data

management

Ref. 5.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of obsolete items on the inventory and un-serviceable for the system. 100% is best value.

100*SR

WOPWO =

Data required for

Computation


WO Number of wasted items in warehouse (metric) Shared Data

Environment (e.g. TIMS) SR Total parts number of spare/repair parts

in inventory (metric)

Score computation









Indicator Title

MTO

Mean time to process obsolescence issues

Service OM

Obsolescence resolution

Ref. 5.4

Unit Hours

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the mean elapsed time for delivering out obsolescence analy-sis (it should be specify how to evaluate this period).

OO

TpaMTO

OO

∑= 1

Data required for

Computation


Tpa Time for processing obsolescence issues (metric) Shared Data

Environment (e.g. TIMS) OO Total number of obsolete and/or obsoles-

cent items (metric)

Score computation








Indicator Title

PSA

Supportability analysis vs. total items subject to OM

Service OM

Data management

Ref. 5.5

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of carried out supportability analysis. 100% is best value.

100*OISAPSA =

Data required for

Computation


SA Number of supportability analysis (metric) Shared Data Environment (e.g. TIMS)

OI Total number of critical/not critical items designed for obsolescence monitoring (metric)

Score computation







Link between OM and relative second and third level PPs.

)*1(*1 OACOSCOBSOMC −−= (5) Obsolescence Management Confidence is decreased from 1 by [ )*1(* OACOSCOBS − ], where:

o SIOIetOBS MTBU

t

x

x

*)( )01.0ln/( 2

2−

= (5a), called obsolescence curve taking into

account number of items designed for OM and Maintenance Significant Items SI

o Decreasing OMC by OBS is then minimized by OSC*OAC, where:

)1(*)1(* OAEPOEPIOOSC −−= , percentage of items with obsolescence data, PIO (5.1.1), but decreased by percentages of obsolescence data errors (POE 5.1.2) and accounting errors (OAE 5.1.3)

)1(*)1( APAPONOAC −−= (5.2), the effectiveness of obsolescence solu-tions decreased by obsolescence issues not included in the obsolescence list (PON 5.2.1) and percentage of proposed actions (APA 5.2.2)

PIO, POE, OAE, PON and APA are basic calculations (classical “partial number”/”total num-ber”).




Indicator Title TDE

Technical Data Effectiveness

Service TID

Ref. 6

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It monitors the level of effectiveness reached on Technical Information and Data Services. This parameter represents the possibility that a techni-cal Information and/or Data is available and correct when required from the final user. Value is between 0 and 1, 1 is best value.

TDUTEDDCODMCTDE ***=

Data required for

Computation


TED Technical Documentation Completeness (6.1)

Shared Data


DMC Data Module Coherence (6.2)

DCO Tech. Documentation Correctness (6.3)

TDU Technical Documentation updating level (6.4)

Score computation

- The score computation is obtained from the evaluation of sub-level pa-rameters and can be used for PBL contracts

- A value less than 1 signals the presence of lacks in the “Technical documentation management” activities


- Conventionally it is possible to link this performance parameter to spe-cific system requirements (e.g. Operational Availability) through the usage of a derived performance parameter called “Skill factor” (Sk, see derived Performance Parameter A).





Indicator Title

TED

Technical Documentation Completeness

Service

TID Data

development process

Ref. 6.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It monitors the Percentage of Technical Documentation Discrepancies Re-ports due to incomplete or not available Technical Information / Data into DM Repository. 100% is best value.

100*1DMA

IITED −=

Data required for

Computation


II Number of discrepancies reports due to incomplete or not available information (metric)


DMA Total number of Data Module accepted by the customer (metric)

Score computation


- A value less than 100% signals the presence of lacks in the related ser-vice






Indicator Title DMC

Data Module Coherence

Service

TID Data

development process

Ref. 6.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of Data Modules accepted by the customer vs the total number of Data Module contractually produced and presented for validation. 100% is best value.

100*DMDMADMC =

Data required for

Computation


DM Total number of Data Module presented for validation (metric) Shared Data



Score computation








Indicator Title DCO

Technical Documentation Correctness

Service TID

Ref. 6.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

DCO monitors the Percentage of Technical Documentation Discrepancies Reports due to incorrect Technical Information or incorrect Data into DM Repository. 100% is best value,

100*1DMA

IDDCO −=

Data required for

Computation


ID Number of discrepancies reports due to incorrect and/or incoherent information (metric) Shared Data



Score computation








Indicator Title

TDU

Technical Documentation updating level

Service TID

Ref. 6.4

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

TDU monitors the Percentage of Technical Documentation Discrepancies Reports due to not updated documentation (i.e. including inputs coming from ECPs). 100% is best value.

100*1DMA

NUTDU −=

Data required for

Computation


NU Number of discrepancies reports due to not updated documentation (metric)



Score computation







Link between TID and relative second and third level PPs.

TDUTEDDCODMCTDE ***= (6)

TDE is multiplication of percentages DMC, Data Module Coherence (6.2), Technical Docu-mentation Correctness DCO (6.3), Technical Documentation Completeness TED (6.1) and Technical Documentation Updating Level TDU (6.4). DMC, DCO, TED and TDU are basic calculations (classical “partial number”/”total number”).




Indicator Title TSE

Training Services Effectiveness

Service TRS

Ref. Le monde7

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the level of effectiveness reached on Training Services man-agement. This parameters clusters the lower level performances parame-ters related to Objectives identification, Gap management, Training pro-curement and Implementation. Value is between 0 and 1, 1 is best value.

PTRTPEGMEOTCTSE ***=

Data required for

Computation


OTC Operational tasks analysis completeness


GME Gap management effectiveness

TPE Training Procurement effectiveness

PTR Disparity of trained personnel per period

Score computation

- The score computation is obtained from the evaluation of sub-level pa-rameters. Overcoming a predefined value shall set off problem identifi-cation and corrective actions.

- Each metric must be considered multiplied by its priority factor accord-ing to the DIF (Difficult, Importance, Frequency) analysis associated with the corresponding task

- Conventionally it is possible to link this performance parameter to the System Operational Availability through the usage of a derived per-formance parameter called “Skill factor” (Sk, see derived Performance Parameter A).




Indicator Title OTC

Operational task analysis completeness

Service TRS

Objective identification

Ref. 7.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It represents the percentage of Maintenance Significant items that has been subjected to Requirement Tasks, DIF and Functional Requirements Specification. 100% is best value.

)1(*)*(RDFORFFRSTACOTC −=

Data required for

Computation


TAC Tasks Analysis Completeness (7.1.1)


FRS Functional Requirements specification completeness (7.1.2)

RDF Total Number of Remarks/Discrepancies on RTA specification or FR Specification (metric)

ORF Total Number of Open Remarks/Discrepancies on RTA specifica-tion or FR Specification (metric)

Score computation

The score computation can be done thorough the measurement of lower level parameters. A value less than 100% implies lacks on Training tasks analysis process. Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title TAC

Tasks Identification Completeness

Service

TRS Requirement task analysis


Ref. 7.1.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

TAC monitors the Percentage of MSI with associated Requirements tasks, DIF analysis and Operational Performance statement (if applicable). 100% is best value.

100*SI

RTATAC =

Data required for

Computation


RTA Total number of MSI subjected to Requirement Tasks Analysis (metric) Shared Data

Environment (e.g. TIMS) SI Total number of MSI within the system

breakdown structure (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of errors in the requirements tasks analysis process. Overcoming a predefined value shall set off prob-lem identification and corrective actions.

Each item and associated task, FR, TO, TOA, CTO and/or remark, must be considered multiplied by its own “priority factor” accord-ing to DIF analysis.




Indicator Title FRS

Functional Requirements Specification

Service TRS


Ref. 7.1.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

FRS monitors the Percentage of MSI with associated Functional Require-ments (if applicable). 100% is best value.

100*RTAFRFRS =

Data required for

Computation


RTA Total number of MSI subjected to Requirement Tasks Analysis (metric) Shared Data

Environment (e.g. TIMS) FR Total number of Functional Requirements

linked to different RTA (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of errors in the requirements tasks analysis process. Overcoming a predefined value shall set off prob-lem identification and corrective actions.





Indicator Title GME

Gap Management Effectiveness

Service TRS

Training Gap Management

Ref. 7.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It determines if all training objectives have been correctly considered on the Training Catalogue. 100% is best value.

CTCTOCGACGME **=

Data required for

Computation


GAC Training gap analysis completeness (7.2.1)


TOC Training options analysis completeness (7.2.2)

CTC Catalogue of trainings completeness (7.2.3)

Score computation

The score computation can be done thorough the measurement of lower level parameters. A value less than 100% implies lacks on training gap management process. Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title GAC

Training Gap Analysis Completeness

Service TRS


Ref. 7.2.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

GAC monitors the Percentage of requirement tasks with gap analysis asso-ciated (or training objectives). 100% is best value.

100*RTATOGAC =

Data required for

Computation


RTA Total number of MSI subjected to Re-quirement Tasks Analysis (metric) Shared Data


TO Total number of tasks with completed Gap analysis process (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the gap analysis proc-ess. Overcoming a predefined value shall set off problem identification and corrective actions. Each item and associated task, FR, TO, TOA, CTO and/or remark, must be considered multiplied by its own “priority factor” accord-ing to DIF analysis.




Indicator Title TOC

Training Option analysis Completeness

Service TRS


Ref. 7.2.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

TOC monitors the percentage of Training Objectives with completed op-tions analysis. 100% is best value.

100*TO

TOATOC =

Data required for

Computation


TO Total number of tasks with completed Gap analysis process (metric) Shared Data


TOA Total number of TO completed with the Options analysis (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the training options description and options analysis processes. Overcoming a predefined value shall set off problem identification and corrective actions.





Indicator Title CTC

Catalogue of Trainings Completeness

Service TRS


Ref. 7.2.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It monitors the percentage of training catalogue remarks (or customer re-marks) not satisfied. 100% is best value.

100*RDCORDCTC =

Data required for

Computation


ORD Total number of tasks with completed Gap analysis process (metric) Shared Data


RDC Total number of TO completed with the Options analysis (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “training gap over-coming” sub-activity. Overcoming a predefined value shall set off problem identification and corrective actions.





Indicator Title TPE

Training Procurement Effectiveness

Service TRS


Ref. 7.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

It determines if training objectives have been effectively satisfied on Training Procurement Process. 100% is best value.

DRETSCCADTPE **=

Data required for

Computation


CAD Contractual adherence (7.3.1)


TSC Technical Specification Completeness (7.3.2)

DRE Acceptance Discrepancy Report evaluation (7.3.3)

Score computation

The score computation can be done thorough the measurement of lower level parameters. A value less than 100% implies lacks on Training Pro-curement activities. Overcoming a predefined value shall set off problem identification and corrective actions.




Indicator Title CAD

Contract Adherence

Service TRS


Ref. 7.3.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

CAD monitors the percentage of training objectives included on the SoW (contract). 100% is best value.

100*TO

CTOCAD =

Data required for

Computation


CTO Number of training Objectives fulfilled within the Contract placement (metric) Shared Data


TO Total number of tasks with completed Gap analysis process (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the contracting activi-ties. Overcoming a predefined value shall set off problem identification and corrective actions. Each item and associated task, FR, TO, TOA, CTO and/or remark, must be considered multiplied by its own “priority factor” accord-ing to DIF analysis.




Indicator Title TSC

Technical Specification Completeness

Service TRS


Ref. 7.3.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

TSC monitors the percentage of training specification remarks not satisfied concerning the Training Support Specifications. 100% is best value.

100*)1(RDSTSRTSC −=

Data required for

Computation


TSR

Total number of Training Objectives affected by remarks/discrepancies on training support specifications not yet solved (metric) Shared Data


RDS Total number Training Objects affected by of remarks or discrepancies on training support specifications (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the training contracting tasks. Overcoming a predefined value shall set off problem identification and corrective actions.





Indicator Title DRE

Discrepancy Report evaluation

Service TRS


Ref. 7.3.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

DRE monitors the percentage of training unaccepted tests. 100% is best value.

100*)1(QTDRDRE −=

Data required for

Computation


DR

Number of opened “Remarks/discrepancies” on the qualifica-tion tests (Acceptance Discrepancies Record) (metric) Shared Data


QT Total number of qualification tests established on the Qualification Plan (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “qualification and certification” sub-activities. Overcoming a predefined value shall set off problem identification and corrective actions.





Indicator Title

PTR

Personnel successfully trained per period

Service TRS


Ref. 7.4.1

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

PTR monitors the percentage trainees successfully trained per period vs the number of scheduled personnel for training. 100% is best value.

)1(*100*)(SR

OSRSP

NQTPTPTR −−

=

Data required for

Computation


PT Total number of personnel trained on the evaluation period (metric)


SP Total number of personnel scheduled for training in the evaluation period (metric)

NQT Number of Not qualified trainees per period (metric)

SR

Number of student’s “Course Feedback ques-tionnaires” containing remarks on inconsis-tencies between training objectives and de-livered contents (metric)

OSR

Number of “Course Feedback questionnaires” with open student’s remarks. A remark is considered open when the solu-tion proposed by the Seller has not been ac-cepted by the Buyer (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “training planning delivering” sub-activity. Overcoming a predefined value shall set off prob-lem identification and corrective actions.




Indicator Title TES

Training Evaluation Summary Accuracy

Service TRS


Ref. 7.4.2

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

PTR monitors the level of accuracy concerning the training evaluation tasks. It represents the percentage of data utilised for the training evalua-tion summary vs the total number of data collected on training monitoring tasks. 100% is best value.

100*DTDSTES =

Data required for

Computation


DS Total number of data utilised on issuing the “training evaluation summary” (metric)


DT Total number of data requested and collected on training monitoring tasks (mertric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “training monitor-ing and performance analysis” sub-activities. Overcoming a predefined value shall set off problem identification and corrective actions. This parameter is not considered on the evaluation of system op-erational availability.




Indicator Title

PAC

Percentage of approved conclusions and recommendations

Service TRS


Ref. 7.4.3

Unit Percentage

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

PAC monitors the percentage of approved conclusions and recommenda-tions (Reporting and upgrading services) on the continuous improvement process. 100% is best value.

100*CRCAPAC =

Data required for

Computation


CR Total number of conclusions and recommendations found on the continuous improvement process (metric) Shared Data


CA Total number of conclusions and recommendations approved by the buyer (metric)

Score computation

The score computation can be done thorough the metrics measurement. A value less than 100 signals the presence of lacks in the “Reporting and up-grading” sub-activities. Overcoming a predefined value shall set off prob-lem identification and corrective actions. This parameter is not considered on the evaluation of system op-erational availability.



Link between TRS and relative second and third level PPs.

PTRTPEGMEOTCTSE ***= (7) TSE is multiplication of 4 factors:

o Operational tasks analysis completeness )1(*)*(RDFORFFRSTACOTC −= (7.1)

o Gap management effectiveness CTCTOCGACGME **= (7.2)

o Training Procurement effectiveness DRETSCCADTPE **= (7.3)

o Disparity of trained personnel per period )1(*100*)(SR

OSRSP

NQTPTPTR −−

= ,

where SP is total number of people scheduled for training, PT number of people trained and NQT number of people non qualified after training. OSR takes into ac-count the number of trainees remark that are still not considered.

TAC, FRS, ORF, RDF, GAC, TOC, CTC, CAD, TSC and DRE are basic calculation (classical “partial number”/”total number”).



Definition of Derived Performance Parameter A

Indicator Title

Sk

Skill factor

Service MM TID TRS

Ref. A

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

The skill factor, evaluated for a generic time tx, represents the disparity between the theoretical and real personnel required skills and knowledge to perform an assigned task due to training, documentation and maintenance lacks. This Sk defines the link between the MTTR value ex-pected (MTTREXP) for a defined period T, following the Learning Curve ob-tained using β(tx) (2.3.1) and the achievable MTTR (MTTRACH, 2.3.1) in the same time period due to Training Service Mgt., Maintenance Mgt. & Data & Info Management lacks. Value is between 0 and 1, 1 is best value.

3TSETDEMMESk ++

=

Data required for

Computation


MME Maintenance Management Effectiveness


TDE

Technical data and Information Effectiveness (see apposite tables)

TSE

Training Services Management (see apposite tables)

Score computation

This logistic mathematic is conventionally used to link the performances of MM, TID and TRS with the System Operational Availability:

ADTMTTRMTMFMTBFAo

+++=

..

where

MTTRACH(T)= MTTREXP(T)+(MTTRMEA(tx)-MTTREXP(T))*(1-Sk)

MTBFACH(T)= MTBFEXP(T)+(MTBFMEAS(tx)-MTBFEXP(T))*(1-Sk)

)1( ADTADTMTTRMTBFMTBF

AotoACHACH

ACH

δ+++=

Annex C: Personal Notes


Definition of Derived Performance Parameter A.1

Indicator Title

MTTREXP(T) (or MTBPMEXP)

Mean Time To Repair expected

Service MM TID TRS

Ref. A1

Unit Decimal number

Owner OCCAR-PD

Freq. Monthly

Description &

Formula

The Mean Time To Repair expected is a projection of the actual measured value MTTR(tx) at the end of a contractual period T considering the “Learning curve” (Ebbinghaus Law).

)(log2

***)()(

xt

EXP

EXPoTHEOEXPECTED SIMTBF

UTILFTMTBFtMTTRTMTTRβ

+=

Data required

for Computation


β(t0), β(tx)

Learning factor: - β(t0) is the statistical value assumed during the

transition period (between 0.7 and 0.9). - β(tx) calculated by the Learning curve:

)()(

*log0*

)(

2)(tMTTRtMTTR

xTHE

xMEAS

SIEXPMTBFxtEXPMTBF

t+

=β Shared Data Environment (e.g. TIMS)

MTTRTHEO(to)

Mean Time To Repair theoretical:

max2log

. **/)()(

β

+=

SIMTBFUTILFTTMTBFTTMTTRtMTTR

EXP

EXPREQoTH

MTTREXP(tx)

Mean Time To Repair expected )(log2

**

*)()(xt

EXP

xEXPoLTHEORETICAxEXPECTED SIMTBF


β

+=

Score computa-

tion

For the score computation the fallowing data must be contractually defined: • TT= Admitted transition period for activities optimization • MTTRREQ = MTTR required at the end of the transition period • β(t0) = Learning factor during the transition period • T= Contract duration • UTIL= System utilization factor • SI= Number of MSI



Annex C: About the formulas and their link with Ao…

Intentionally Blank

Please contact author for more information



Annex D: Your Notes