OCCAR-EA ISS GuideISS Guide issue 2 – May 2013 - Page 2 of 275 1. OCCAR-EA is a European Armament...
Transcript of 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
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
Configuration Management
Maintenance Management
RM&T Analysis
Security Management (DS)
Organisation Update
History & Lessons Process
Concept & Doctrine Review
ST&E Management
Disposal Management
Safety Management
Software Support
System Engineering
Manpower & Human Factors Analysis
Life Cycle Costing
Environmental Impact Management
Facilities & Infra Management
General Support of PD
Information Management
Contract & Legal Support Risk
Management
Financial, Budget Management
Security Management (PD)
General Programme Management Activities
ILS related and Domain Specific Activities
Main ISS Activities
Supply Support Management
Obsolescence Management
Technical Info & Data Services
Training Support Services
Planning & Reporting Management
Quality Management
Technical Support Services
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.
ISS Guide issue 2 – May 2013 - Page 2 of 275
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
ISS Guide issue 2 – May 2013 - Page 3 of 275
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
ISS Guide issue 2 – May 2013 - Page 4 of 275
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
ISS Guide issue 2 – May 2013 - Page 5 of 275
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
ISS Guide issue 2 – May 2013 - Page 6 of 275
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
ISS Guide issue 2 – May 2013 - Page 7 of 275
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.
ISS Guide issue 2 – May 2013 - Page 8 of 275
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
ISS Guide issue 2 – May 2013 - Page 9 of 275
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
Obsolescence Management
Maintenance Management
Technical Support Services
Configuration Management
Supply Support Management
OCCAR TLM
ISS Tailoring Performance Parameters
Programme Division Contract Inclusions
ILS input
ISS Guide issue 2 – May 2013 - Page 10 of 275
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.
ISS Guide issue 2 – May 2013 - Page 11 of 275
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.
ISS Guide issue 2 – May 2013 - Page 12 of 275
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
ISS Guide issue 2 – May 2013 - Page 13 of 275
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.
ISS Guide issue 2 – May 2013 - Page 14 of 275
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
OCCAR conventional Programme Management Model
HAP, UHTHAP, UHTHAP, UHTDefinitionDefinitionPreparationPreparation DevelopmentDevelopmentDevelopmentDevelopment ProductionProduction In ServiceIn Service
DisposalDisposal
DisposalDisposal
OCCAR conventional Programme Management Model
OCCAR use-centric Through Life
Programme Management Model
from discrete
linear
to continuoususe-centric
ISS Guide issue 2 – May 2013 - Page 15 of 275
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.
ISS Guide issue 2 – May 2013 - Page 16 of 275
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
ISS Guide issue 2 – May 2013 - Page 17 of 275
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).
ISS Guide issue 2 – May 2013 - Page 18 of 275
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).
ISS Guide issue 2 – May 2013 - Page 19 of 275
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).
ISS Guide issue 2 – May 2013 - Page 20 of 275
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.
ISS Guide issue 2 – May 2013 - Page 21 of 275
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.
ISS Guide issue 2 – May 2013 - Page 22 of 275
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
ISS Guide issue 2 – May 2013 - Page 23 of 275
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.
The ILS Manager should also provide inputs and
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.
The ILS Manager should also provide inputs and
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
ISS Guide issue 2 – May 2013 - Page 24 of 275
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.
ISS Guide issue 2 – May 2013 - Page 25 of 275
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)
ISS Guide issue 2 – May 2013 - Page 26 of 275
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
Configuration Management
Maintenance Management
RM&T Analysis
Security Management (DS)
Organisation Update
History & Lessons Process
Concept & Doc-trine Review
ST&E Management
Disposal Management
Safety Management
Software Sup-port
System Engi-neering
Manpower & Human Factors Analysis
Life Cycle Cost-ing
Environmental Impact Management
Facilities & Infra Management
General Support of PD
Information Management
Contract & Le-gal Support Risk
Management
Financial, Budget Management
Planning & Reporting Management
Quality Management
Security Management (PD)
General Programme Man-agement Activities
ILS related and Domain Spe-cific Activities
Main ISS Elements
Supply Support Management
Technical Support Services
Obsolescence Management
Technical Info & Data Services
Training Support Services
ISS Guide issue 2 – May 2013 - Page 27 of 275
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.
ISS Guide issue 2 – May 2013 - Page 28 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 29 of 275
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
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).
ISS Guide issue 2 – May 2013 - Page 30 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 31 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 32 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 33 of 275
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
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
ISS Guide issue 2 – May 2013 - Page 34 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 35 of 275
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
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
ISS Guide issue 2 – May 2013 - Page 36 of 275
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
ISS Guide issue 2 – May 2013 - Page 37 of 275
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.
ISS Guide issue 2 – May 2013 - Page 38 of 275
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.
ISS Guide issue 2 – May 2013 - Page 39 of 275
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 +
==_
__
ISS Guide issue 2 – May 2013 - Page 40 of 275
• 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;
ISS Guide issue 2 – May 2013 - Page 41 of 275
• 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.
ISS Guide issue 2 – May 2013 - Page 42 of 275
Figure 5: ISS Process Model - Overall elements breakdow n
ISS Guide issue 2 – May 2013 - Page 43 of 275
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.
ISS Guide issue 2 – May 2013 - Page 44 of 275
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
ISS Guide issue 2 – May 2013 - Page 45 of 275
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.
ISS Guide issue 2 – May 2013 - Page 46 of 275
Figure 6: Navigation Map for the Configuration Management element
ISS Guide issue 2 – May 2013 - Page 47 of 275
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
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 the process of ‘Identify and Manage Lessons’.
No Contract for this task
OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mails…
ISS Guide issue 2 – May 2013 - Page 48 of 275
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
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.
ISS Guide issue 2 – May 2013 - Page 49 of 275
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
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
Configuration Management
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
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
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
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
ISS Guide issue 2 – May 2013 - Page 50 of 275
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
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
Depending on the specifics of the Programme this task could be contracted to the Industry
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
No Contract for this task
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.
Depending on the specifics of the Programme this task could be contracted to the Industry
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)
ISS Guide issue 2 – May 2013 - Page 51 of 275
Configuration Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
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.
ISS Guide issue 2 – May 2013 - Page 52 of 275
Table 8: Configuration Management sub-activit ies
Configuration Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
managed by OCCAR-EA
Managed by OCCAR-EA
Configuration Control
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
No Contract for this task
OCCAR-EA will inform the PSs on the implementation of changes. A processing time should be agreed with the PSs
ISS Guide issue 2 – May 2013 - Page 53 of 275
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
Within the ISS organisation, the objective of PSs and OCCAR-EA will be:
• 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.
ISS Guide issue 2 – May 2013 - Page 54 of 275
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.
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.2.4 Stakeholders in Maintenance Management
Along with OCCAR-EA, the main actors who participate in maintenance ac-tivities could be:
• Individual PSs’ User and associated support organisations;
• National maintenance organisations - maintenance and technical staff working as a central service on behalf of all PSs;
• Industry - the Design Authority and/or 3rd party Industry service providers;
• 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.
ISS Guide issue 2 – May 2013 - Page 55 of 275
Figure 7: Navigation Map for the Maintenance Management Element
ISS Guide issue 2 – May 2013 - Page 56 of 275
Maintenance Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
managed by OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
Establish and maintain organisa-tional interfaces with all stake-holders.
No Contract for this task
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).
No Contract for this task
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…
ISS Guide issue 2 – May 2013 - Page 57 of 275
Maintenance Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
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.
No Contract for this task
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
ISS Guide issue 2 – May 2013 - Page 58 of 275
Maintenance Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
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.
ISS Guide issue 2 – May 2013 - Page 59 of 275
Maintenance 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
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
ISS Guide issue 2 – May 2013 - Page 60 of 275
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).
ISS Guide issue 2 – May 2013 - Page 61 of 275
Supply Support Services involve six conceptual “second levels” of activities:
1. Coordination 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.
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.3.4 Stakeholders in Supply Support Management
Along with OCCAR-EA, the main actors who participate in supply support activities could be:
• Individual PSs’ User and associated support organisations;
• National support organisations and technical staff working as a cen-tral service on behalf of all PSs;
• Industry - the Design Authority and/or 3rd party Industry service providers;
• Designated Agency such as NAMSA.
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.
ISS Guide issue 2 – May 2013 - Page 62 of 275
Figure 8: Navigation Map for the Supply Support Management element
ISS Guide issue 2 – May 2013 - Page 63 of 275
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
managed by OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
Establish and maintain organisational interfaces with all stakeholders.
No Contract for this task
OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-mails…
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.
No Contract for this task
OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-mails…
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
OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, workspaces, e-mails…
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…
ISS Guide issue 2 – May 2013 - Page 64 of 275
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
Spare Utilization Rate (second level, only
contractual PP)
ISS Guide issue 2 – May 2013 - Page 65 of 275
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
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
ISS Guide issue 2 – May 2013 - Page 66 of 275
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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.
No Contract for this task
OCCAR-EA is performing the task in accordance with the defined scope and the PSs.
ISS Guide issue 2 – May 2013 - Page 67 of 275
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
OCCAR-EA is performing the task in accordance with the defined scope and the PSs.
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.
These PHS&T activities are part of other contract
No role for OCCAR-EA except for Contract man-agement
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.
These PHS&T activities are part of other contract
No role for OCCAR-EA except for Contract man-agement
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.
These PHS&T activities are part of other contract
No role for OCCAR-EA except for Contract man-agement
Mean Delay Time for transportation (third
level)
ISS Guide issue 2 – May 2013 - Page 68 of 275
Table 10: Supply Support Management sub-activities
Supply Support Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
Depending on the spe-cifics of the Programme this task could be con-tracted to the Industry
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).
No Contract for this task
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.
No Contract for this task
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
ISS Guide issue 2 – May 2013 - Page 69 of 275
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
ISS Guide issue 2 – May 2013 - Page 70 of 275
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).
ISS Guide issue 2 – May 2013 - Page 71 of 275
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;
• Industry - the Design Authority and/or 3rd party Industry service providers;
• Designated Agency such as NAMSA.
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.
ISS Guide issue 2 – May 2013 - Page 72 of 275
Figure 9: Navigation Map for the Technical Support Services element
ISS Guide issue 2 – May 2013 - Page 73 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
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.
No Contract for this task
OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mails…
Organise & Chair the PDS Working Group to manage Users PDS require-ments and respond to critical PDS is-sues
No Contract for this task
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
No Contract for this task
OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mails…
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
OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces, e-mails…
Establish and maintain the process of ‘Identify and Manage Lessons’.
No Contract for this task
OCCAR-EA has the responsibil-ity to maintain communica-tions by means of Expert Working Groups, workspaces,
ISS Guide issue 2 – May 2013 - Page 74 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
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)
No Contract for this task
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
Depending on the specifics of the Programme this task could be undertaken by OCCAR-EA, Nations or 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…)
ISS Guide issue 2 – May 2013 - Page 75 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
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.
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 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
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
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)
ISS Guide issue 2 – May 2013 - Page 76 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
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
No Contract for this task
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.
No Contract for this task
OCCAR-EA will enforce the terms and conditions of con-tract when warranties, guaran-tees and examinations apply
ISS Guide issue 2 – May 2013 - Page 77 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
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...
No Contract for this task
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
No Contract for this task
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
ISS Guide issue 2 – May 2013 - Page 78 of 275
Technical Support Services – Element Table
Second Level: activ-
ity
Third Level: Sub-activity
Performance Parameters
Name Definition
Performed by Indus-try through a Con-tract managed by
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
No Contract for this task
OCCAR-EA will manage the Contract and ensure that the deliverables and services com-ply with the PSs Requirements
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
No Contract for this task
OCCAR-EA will manage the Contract and ensure that the deliverables and services com-ply with the PSs Requirements
Table 11: Technical Support Services activities and sub-activities
ISS Guide issue 2 – May 2013 - Page 79 of 275
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.
ISS Guide issue 2 – May 2013 - Page 80 of 275
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:
1. Coordination activities,
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.
ISS Guide issue 2 – May 2013 - Page 81 of 275
12.5.4 Stakeholders in Obsolescence Management
Along with OCCAR-EA, the main actors who participate in Obsolescence Management activities could be:
• Individual PSs’ User and associated support organisations;
• National support organisations and technical staff working as a cen-tral service on behalf of all PSs;
• Industry - the Design Authority and/or 3rd party Industry service providers;
• Designated Agency such as NAMSA.
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.
ISS Guide issue 2 – May 2013 - Page 82 of 275
igure 10: Navigation Map for Obsolescence Management element
ISS Guide issue 2 – May 2013 - Page 83 of 275
Obsolescence Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract managed
by OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
Establish and maintain organisational inter-faces with all stakeholders (including aca-demic and industrial accessible networks).
No Contract for this task
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
OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, work-spaces, e-mails…
Establish and maintain the process of ‘Iden-tify and Manage Lessons’.
No Contract for this task
OCCAR-EA has the responsibility to maintain communications by means of Expert Working Groups, work-spaces, e-mails…
ISS Guide issue 2 – May 2013 - Page 84 of 275
Obsolescence Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Industry through a Contract
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.
No Contract for this task
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)
OCCAR-EA will place a Contract with Industry with incentives linked to efficiency and constant improvement
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
OCCAR-EA is perform-ing the task in accor-dance with the defined scope.
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.
No Contract for this task
OCCAR-EA is perform-ing the task in accor-dance with the defined scope.
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
No Contract for this task
OCCAR-EA is perform-ing the task in accor-dance with the defined scope.
ISS Guide issue 2 – May 2013 - Page 85 of 275
Obsolescence Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
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 spe-cifics of the Programme this task could be con-tracted to the Industry
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
ISS Guide issue 2 – May 2013 - Page 86 of 275
Obsolescence Management – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
ISS Guide issue 2 – May 2013 - Page 87 of 275
Table 12: Obsolescence Management sub-activities
Obsolescence Management – Element Table
Second Level:
Activity
Third Level: Sub-activity Performance Parameters Name Definition
Performed by Industry through a Contract
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.
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 Industry
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.
Depending on the specifics 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 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)
Obsolescence Management
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.
No Contract for this task OCCAR-EA is performing the task in accordance with the defined scope.
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
ISS Guide issue 2 – May 2013 - Page 88 of 275
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).
ISS Guide issue 2 – May 2013 - Page 89 of 275
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:
1. Coordination 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;
• Industry - the Design Authority and/or 3rd party Industry service providers;
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.
ISS Guide issue 2 – May 2013 - Page 90 of 275
Figure 11: Navigation Map for Technical Information and Data Services element
ISS Guide issue 2 – May 2013 - Page 91 of 275
Technical Information & Data Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
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…
ISS Guide issue 2 – May 2013 - Page 92 of 275
Technical Information & Data Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
ISS Guide issue 2 – May 2013 - Page 93 of 275
Technical Information & Data Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
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
ISS Guide issue 2 – May 2013 - Page 94 of 275
Table 13:Technical Information & Data Services sub-activit ies
Technical Information & Data Services – Element Table
Second Level: Activity
Third Level: Sub-activity Performance Parameters Name Definition
Performed by Industry through a Contract
managed by OCCAR-EA Managed by OCCAR-EA
Configuration Management
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
OCCAR-EA will ensure that the Industry meets the per-formance metrics that will be set up for this activity
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
ISS Guide issue 2 – May 2013 - Page 95 of 275
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
Within the ISS organisation, the objective of PSs and OCCAR-EA will be:
• 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.
ISS Guide issue 2 – May 2013 - Page 96 of 275
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:
1. Coordination activities,
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,
ISS Guide issue 2 – May 2013 - Page 97 of 275
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:
• Individual PSs’ User and associated support organisations;
• 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.
ISS Guide issue 2 – May 2013 - Page 98 of 275
Figure 12: Navigation Map for the Training Support Services element
ISS Guide issue 2 – May 2013 - Page 99 of 275
Training Support Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
OCCAR-EA
Managed by OCCAR-EA
Coordination Activities
Establish and maintain organisational in-terfaces with all stakeholders.
No Contract for this task
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).
No Contract for this task
OCCAR-EA has the respon-sibility to maintain communi-cations by means of Expert Working Groups, work-spaces, e-mails…
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 has the respon-sibility to maintain communi-cations by means of Expert Working Groups, work-spaces, e-mails…
ISS Guide issue 2 – May 2013 - Page 100 of 275
Training Support Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
OCCAR-EA will ensure that the Industry meets the per-formance metrics that will be set up for this activity
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
OCCAR-EA will ensure that the Industry meets the per-formance metrics that will be set up for this activity
Functional Require-ments specification
(third level)
ISS Guide issue 2 – May 2013 - Page 101 of 275
Training Support Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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
ISS Guide issue 2 – May 2013 - Page 102 of 275
Training Support Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
Performed by Indus-try through a Con-tract managed by
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).
OCCAR-EA will place a Contract with Industry with incentives linked to efficiency and constant improvement
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.
OCCAR-EA will place a Contract with Industry with incentives linked to efficiency and constant improvement
If this task is not done by the Nation, OCCAR-EA will monitor the Contract fulfil-ment
Discrepancy Report evaluation (third level)
ISS Guide issue 2 – May 2013 - Page 103 of 275
Table 14: Training support Services sub-activities
Training Support Services – Element Table
Second Level: Activity
Third Level: Sub-activity
Performance Parameters Name Definition
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
No Contract for this task
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)
Training Implementation
& Evaluation
Training Evaluation
To monitor the compliance between Training Data Products and Data Item Description.
No Contract for this task
OCCAR-EA is performing the task in accordance with the defined scope and the PSs.
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)
ISS Guide issue 2 – May 2013 - Page 104 of 275
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.
ISS Guide issue 2 – May 2013 - Page 105 of 275
S&TE Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
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
Depending on the specifics of the Programme this task could be contracted to the Industry
Depending on the specif-ics of the Programme this task could be undertaken by OCCAR-EA, Nations or Industry
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.
Maintenance Monitoring and
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
Maintenance Monitoring and
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
Depending on the specifics of the Programme this task could be contracted (in full or partially) to the Industry
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
ISS Guide issue 2 – May 2013 - Page 106 of 275
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.
ISS Guide issue 2 – May 2013 - Page 107 of 275
Table 16: Facilities and Infrastructure Management sub-activities
Facilities and Infrastructure Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
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
PSs might place a Contract to Industry
No role for OCCAR-EA
Sub-activities related to
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)
PSs might place a Contract to Industry or ask OCCAR-EA to place the contract
OCCAR-EA could provide support
Configuration Control Training Support Ser-vices
Define Requirements for
Maintenance Facilities
Identify requirements for Maintenance facilities for the new modification (if ap-plicable)
PSs might place a Contract to Industry or ask OCCAR-EA to place the contract
OCCAR-EA could provide support
Configuration Control Maintenance Planning
Procure Facilities Procure if applicable storage, training and maintenance facilities
PSs might place a Contract to Industry
No role for OCCAR-EA
ISS Guide issue 2 – May 2013 - Page 108 of 275
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.
ISS Guide issue 2 – May 2013 - Page 109 of 275
Life Cycle Costing - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities) associated
Recurrent Sub-activities
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
Sub-activities related to
Studies and Implementation
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
ISS Guide issue 2 – May 2013 - Page 110 of 275
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.
ISS Guide issue 2 – May 2013 - Page 111 of 275
Manpower and Human Factors analysis - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA Main Activities (or re-lated sub-activities)
associated
Recurrent Sub-activities
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
Depending on the specif-ics of the Programme this task could be undertaken by OCCAR-EA, Nations or Industry
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.
Maintenance Monitoring and Control / In Service Monitoring of Logistic Performances / TSS
Reports on Manpower and Human factors
This would be part of Maintainability Re-port, Logistic Performance Report and Training Evaluation Reports
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 the reports
Maintenance Monitoring and Control / In Service Monitoring of Logistic Performances / TSS
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
Sub-activities related to
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
ISS Guide issue 2 – May 2013 - Page 112 of 275
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.
ISS Guide issue 2 – May 2013 - Page 113 of 275
Software Support - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
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
Depending on the specif-ics of the Programme this task could be undertaken by OCCAR-EA, Nations or 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
Technical Events Management
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
ISS Guide issue 2 – May 2013 - Page 114 of 275
Software Support - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA Main Activities
(or related sub-activities)
associated
Activities related to
Studies and Implementation
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
Configuration Control
Software Support Analysis that con-sists of identifying maintenance relevant events for software, identify-ing Support tasks, performing FMECA, Schedule Maintenance Analysis and LORA
Configuration Control
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
ISS Guide issue 2 – May 2013 - Page 115 of 275
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.
ISS Guide issue 2 – May 2013 - Page 116 of 275
Reliability, Maintainability and Testability Analyses - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA Main Activities (or
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
Configuration Control
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
OCCAR-EA will manage the performances associ-ated to the contract
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
OCCAR-EA will manage the performances associ-ated to the contract
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
OCCAR-EA will manage the performances associ-ated to the contract
Configuration Control
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
OCCAR-EA will manage the performances associ-ated to the contract
Configuration Control
Table 20: Reliability, Maintainabil ity and Testability (RM&T) Analyses
ISS Guide issue 2 – May 2013 - Page 117 of 275
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.
ISS Guide issue 2 – May 2013 - Page 118 of 275
Security Management of the Defence System - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA Main Activities (or
related sub-activities) associated
Recurrent Activities
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
ISS Guide issue 2 – May 2013 - Page 119 of 275
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).
ISS Guide issue 2 – May 2013 - Page 120 of 275
Organisation update - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
associated
Recurrent Activities
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 Contract through OCCAR-EA
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 Contract through OCCAR-EA
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
Configuration Control
Implement Update
Implement organisational update through new recruiting, new re-location…
No Contract through OCCAR-EA
No role for OCCAR-EA (but information would be provided)
Table 22: Organisation update sub-activities
ISS Guide issue 2 – May 2013 - Page 121 of 275
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.
ISS Guide issue 2 – May 2013 - Page 122 of 275
Concept and Doctrine Review - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
Recurrent Activities
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
No role for Industry No role for OCCAR-EA
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
Activities related to
Studies and Implementation
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
No role for Industry No role for OCCAR-EA
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
ISS Guide issue 2 – May 2013 - Page 123 of 275
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).
ISS Guide issue 2 – May 2013 - Page 124 of 275
Environment Impact Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
No role for OCCAR-EA
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
Activities related to
Studies and Implementation
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
Configuration Control
Table 24: Environmental Impact Management sub-activities
ISS Guide issue 2 – May 2013 - Page 125 of 275
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.
ISS Guide issue 2 – May 2013 - Page 126 of 275
Disposal Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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.
Activities related to
Studies and Implementation
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.
ISS Guide issue 2 – May 2013 - Page 127 of 275
Table 25: Disposal management sub-activities
Disposal Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OC-CAR-EA
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.
OCCAR-EA in very close cooperation with PS if en-trusted.
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
OCCAR-EA in very close cooperation with PS if en-trusted.
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.
ISS Guide issue 2 – May 2013 - Page 128 of 275
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.
ISS Guide issue 2 – May 2013 - Page 129 of 275
Systems Engineering - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-
activities) associated
Activities related to
Studies and Implementation
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
Configuration Control
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
Configuration Control
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
ISS Guide issue 2 – May 2013 - Page 130 of 275
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.
ISS Guide issue 2 – May 2013 - Page 131 of 275
Safety Management - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by
Industry through a Contract managed
by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
associated
Recurrent Activities
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
Technical Events Management
Report on Safety Issues
Whenever a safety issue occurs during In Ser-vice a Report is provided to all stakeholders for information and action
Contract might be placed to Industry
OCCAR-EA will en-sure the Report is pro-vided to all stake-holders
Technical Events Management
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
Technical Events Management
Report on Safety
Performance
Defined in the Safety Management System, Safety Performance will be reported periodi-cally
Contract might be placed to Industry
OCCAR-EA will en-sure the Report is pro-vided to all stake-holders
Technical Events Management
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
Contract might be placed to Industry
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
ISS Guide issue 2 – May 2013 - Page 132 of 275
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.
ISS Guide issue 2 – May 2013 - Page 133 of 275
Information Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OC-CAR-EA
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
ISS Guide issue 2 – May 2013 - Page 134 of 275
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.
ISS Guide issue 2 – May 2013 - Page 135 of 275
Contract and Legal Support – Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
ISS Guide issue 2 – May 2013 - Page 136 of 275
Contract and Legal Support – Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
Manage Contract
Control Work Execution Authorize Contractor's work at the appropriate time
No Contract to Industry
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
ISS Guide issue 2 – May 2013 - Page 137 of 275
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.
ISS Guide issue 2 – May 2013 - Page 138 of 275
Risk Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
OCCAR-EA might contract Industry to identify risks re-
lated to its activities
OCCAR-EA will manage the coordination of the
risk identification
Populate Risk Register
Populate OCCAR-EA Risk Register in the Risk Management System
OCCAR-EA might contract Industry to identify risks re-
lated to its activities
OCCAR-EA will manage the coordination of the
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-
lated to its activities
OCCAR-EA will manage the coordination of the
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
OCCAR-EA might contract Industry to analyse risks re-
lated to its activities
OCCAR-EA will manage the coordination of the
risk analysis
Populate Risk Register
Populate OCCAR-EA Risk Register in the Risk Management System
OCCAR-EA might contract Industry to analyse risks re-
lated to its activities
OCCAR-EA will manage the coordination of the
risk analysis
ISS Guide issue 2 – May 2013 - Page 139 of 275
Risk Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract man-aged by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
OCCAR-EA will manage the coordination of the
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
OCCAR-EA might contract Industry to set up Response
Plan related to its risks
OCCAR-EA will manage the coordination of the
risk response plans
Populate Risk Register
Populate OCCAR-EA Risk Register in the Risk Management System
OCCAR-EA might contract Industry to set up Response
Plan related to its risks
OCCAR-EA will manage the coordination of the
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
OCCAR-EA will manage the coordination of the
risk monitoring
Manage Changes on the Response Plan
If changes are necessary update the Re-sponse Plan accordingly
OCCAR-EA might contract Industry to report on risk
monitoring for its activities
OCCAR-EA will manage the coordination of the
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
OCCAR-EA might contract Industry to report on risk
monitoring for its activities
OCCAR-EA will manage the coordination of the
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
ISS Guide issue 2 – May 2013 - Page 140 of 275
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.
ISS Guide issue 2 – May 2013 - Page 141 of 275
Finance and Budget Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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)
No Contract to Industry
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)
Task managed by OCCAR-EA with the
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)
Task managed by OCCAR-EA
Commitments Initiate and approve commitments and undertake legal commitments (such as contract) within the lim-its of OCCAR rules (see OMP10 for details)
Task managed by OCCAR-EA
Financial Control
Financial scrutiny on the day-to-day budget execu-tion (see OMP10 for details)
Task managed by OCCAR-EA
ISS Guide issue 2 – May 2013 - Page 142 of 275
Finance and Budget Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
Financial Data Management: Restitutions, Reports and Budget Scorecards - Forecast of Outturn exer-cise (see OMP10 for details)
No Contract to Industry
Task managed by OCCAR-EA with the
PSs
Payment and Banking Management
Revenue Management
Call for Funds to the PSs for Operational and Admin-istrative Budget (see OMP10 for details)
Task managed by OCCAR-EA with the
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)
Task managed by OCCAR-EA through a
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)
Task managed by OCCAR-EA through a
bank
Table 31: Finance and Budget Management sub-activities
ISS Guide issue 2 – May 2013 - Page 143 of 275
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.
ISS Guide issue 2 – May 2013 - Page 144 of 275
Quality Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Indus-try through a Con-tract managed by
OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
No Contract to Industry
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
This task might be contracted to Industry
Establish and maintain Quality
Management Plan
Describe how the Quality Requirements will be fulfilled
This task might be contracted to Industry
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
No Contract to Industry
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
ISS Guide issue 2 – May 2013 - Page 145 of 275
Quality Management - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by Indus-try through a Con-tract managed by
OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
Follow-up Audit Outcome
Implement agreed actions from the Audit and close audit findings upon completion of correc-tive actions
No Contract to Industry
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.
This task might be contracted to Industry
OCCAR-EA will manage this task with the PSs
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
This task might be contracted to Industry
OCCAR-EA will manage this task with the PSs
Table 32: Quality Management sub-activities
ISS Guide issue 2 – May 2013 - Page 146 of 275
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).
ISS Guide issue 2 – May 2013 - Page 147 of 275
Planning and Reporting including Performance Management - Element Table
Second Level: activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
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
All activities for which a plan has to be set up
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.
No Contract for this task OCCAR-EA will manage this task with the PSs
All activities for which a plan has to be set up
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
OCCAR-EA will manage this task and the delivered
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
No Contract for this task OCCAR-EA will manage this task with the PSs
All activities for which a performance measure
is defined
Manage Deviations
Measure deviations from baseline and provide explanations and corrective actions
Part of this task might be contracted to Industry
OCCAR-EA will manage this task and the delivered
data from the Industry
All activities for which a performance measure
is defined
Update Baseline
Update Performance measurement baseline according to the PSs requirements and other factors that have to be defined
No Contract for this task OCCAR-EA will manage this task with the PSs
All activities for which a performance measure
is defined
ISS Guide issue 2 – May 2013 - Page 148 of 275
Planning and Reporting including Performance Management - Element Table
Second Level: activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
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
Part of this task might be contracted to Industry
OCCAR-EA will manage this task and the delivered
data from the Industry
All activities for which a performance measure
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
Part of this task might be contracted to Industry
OCCAR-EA will manage this task and the delivered
data from the Industry
All activities for which a performance measure
is defined
Table 33: P lanning and Reporting including Performance Management sub-activities
ISS Guide issue 2 – May 2013 - Page 149 of 275
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.
ISS Guide issue 2 – May 2013 - Page 150 of 275
Security Management related to the Programme Division - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by
Industry through a Contract managed
by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
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
No Contract to Industry
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
ISS Guide issue 2 – May 2013 - Page 151 of 275
Security Management related to the Programme Division - Element Table
Second Level:
Activity
Third Level: Sub-activity
Name Definition Performed by
Industry through a Contract managed
by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related
sub-activities) associated
Breaches for Security
Report on Breach of Security
Report could be provided through event or ad hoc and peri-odic checks
No Contract to Industry
OCCAR-EA will manage this task
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
ISS Guide issue 2 – May 2013 - Page 152 of 275
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.
ISS Guide issue 2 – May 2013 - Page 153 of 275
Programme History and Lessons Process - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by In-dustry through a
Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
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
No Contract to Industry
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
ISS Guide issue 2 – May 2013 - Page 154 of 275
Programme History and Lessons Process - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by In-dustry through a
Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-activities)
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
No Contract to Industry
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
ISS Guide issue 2 – May 2013 - Page 155 of 275
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).
ISS Guide issue 2 – May 2013 - Page 156 of 275
General Support of the Programme Division - Element Table
Second Level: Activity
Third Level: Sub-activity
Name Definition Performed by Industry
through a Contract managed by OCCAR-EA
Managed by OCCAR-EA
Main Activities (or related sub-
activities) associated
Human Resources
Management
Staff Recruitment Recruit the necessary staff according to OMP9 (planning, advertisement, selection and appointment)
No Contract to Industry
OCCAR-EA will manage this task
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.
OCCAR-EA will manage this task
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
Contract might be placed to Industry
OCCAR-EA will manage this task and the contracts
Manage Administra-tive Procurement
Procure supplies and services funded under the OCCAR-EA administrative budget
Contract might be placed to Industry
OCCAR-EA will manage this task and the contracts
Table 36: General support of the Programme division sub-activities
ISS Guide issue 2 – May 2013 - Page 157 of 275
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:
ISS Guide issue 2 – May 2013 - Page 158 of 275
• 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).
.
ISS Guide issue 2 – May 2013 - Page 159 of 275
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.
ISS Guide issue 2 – May 2013 - Page 160 of 275
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.
ISS Guide issue 2 – May 2013 - Page 161 of 275
Figure 13: Functional Generic Programme Division Structure during ISS Phase (pure ISS)
ISS Guide issue 2 – May 2013 - Page 162 of 275
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
ISS Guide issue 2 – May 2013 - Page 163 of 275
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.
ISS Guide issue 2 – May 2013 - Page 164 of 275
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
ISS Guide issue 2 – May 2013 - Page 165 of 275
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
ISS Guide issue 2 – May 2013 - Page 166 of 275
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)
Annex A: Related Documents, Acronyms, Definitions and Explanations
ISS Guide issue 2 – May 2013 - Page 167 of 275
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)
ISS Guide issue 2 – May 2013 - Page 168 of 275
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.
Cat of ISS Ser-vices
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.
Cat of ISS Ser-vices
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.
Cat of ISS Ser-vices
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
ISS Guide issue 2 – May 2013 - Page 169 of 275
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.
Cat of ISS Ser-vices
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
ISS Guide issue 2 – May 2013 - Page 170 of 275
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
ISS Guide issue 2 – May 2013 - Page 171 of 275
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
ISS Guide issue 2 – May 2013 - Page 172 of 275
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
ISS Guide issue 2 – May 2013 - Page 173 of 275
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.
ISS Guide issue 2 – May 2013 - Page 174 of 275
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-
ISS Guide issue 2 – May 2013 - Page 175 of 275
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
ISS Guide issue 2 – May 2013 - Page 176 of 275
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
ISS Guide issue 2 – May 2013 - Page 177 of 275
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
ISS Guide issue 2 – May 2013 - Page 178 of 275
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 179 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 180 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 181 of 275
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 182 of 275
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”.
Ref. Data Description
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 183 of 275
Definition of Performance Parameter 1.2
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”.
Ref. Data Description
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
Overcoming a predefined value shall set off problem identification and cor-rective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 184 of 275
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
NB: Each Item must be con-sidered multi-plied for its
own “criticality factor”
Ref. Data Description
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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 185 of 275
Definition of Performance Parameter 1.1.2
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”
Ref. Data Description
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
Overcoming a predefined value shall set off problem identification and cor-rective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 186 of 275
Definition of Performance Parameter 1.2.1
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
NB: Each Item must be con-sidered multi-plied for its
own “criticality factor”
Ref. Data Description
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 187 of 275
Definition of Performance Parameter 1.2.2
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
NB: Each Item must be con-sidered multi-plied for its
own “criticality factor”
Ref. Data Description
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 188 of 275
Definition of Performance Parameter 1.2.3
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
NB: Each Item must be con-sidered multi-plied for its
own “criticality factor”
Ref. Data Description
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
- 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 specific system requirements (e.g. Operational Availability)
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 189 of 275
Definition of Performance Parameter 1.2.4
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”
Ref. Data Description
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 190 of 275
Definition of Performance Parameter 1.2.5
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”
Ref. Data Description
TE Time for processing ECP (metric)
Shared Data Environment
NE Total number of approved/disapproved ECP (metric)
Score computation
- The score computation can be used for PBL contracts.
- Overcoming a predefined time shall set off problem identification and corrective actions.
- This parameter is not considered on the evaluation of system operational availability.
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 191 of 275
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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 192 of 275
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”).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 193 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 194 of 275
Definition of Performance Parameter 2
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
Ref. Data Description
MPC Maintenance Plan Completeness, it measures completeness of Maintenance Plan (2.1.1)
Shared Data Environment (e.g. TIMS)
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).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 195 of 275
Definition of Performance Parameter 2.1.1
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
Ref. Data Description
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 196 of 275
Definition of Performance Parameter 2.1.2
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
Ref. Data Description
MHLTHEO Mean Preventive/corrective Labour Hours statistically defined (theoretical) (metric)
Shared Data Environment
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 197 of 275
Definition of Performance Parameter 2.2.1
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
Ref. Data Description
MTTREXP(tx) Mean Time To Repair expected for t=tx (see 2.2.A) Shared Data
Environment (e.g. TIMS)
MTTRMEAS(tx) Mean Time To Repair measured for t=tx (metric)
Score computation
See 2.2.A
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 198 of 275
Definition of Performance Parameter 2.2.2
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
Ref. Data Description
MPMTEXP(tx) Mean Preventive Maintenance Time expected for t=tx (see 2.2.A)
Shared Data Environment (e.g. TIMS)
MPMTMEAS(tx) Mean Preventive Time measured for t=tx (metric)
Score computation
See 2.2.B
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 199 of 275
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
Ref. Data Description
β(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)
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 200 of 275
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
Ref. Data Description
β(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)
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 201 of 275
Definition of Performance Parameter 2.2.3
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
Ref. Data Description
ADT(t0) Contractual Administrative Delay Time or agency proc-essing time (metric)
Shared Data Environment
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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 202 of 275
Definition of Performance Parameter 2.3
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
Ref. Data Description
SI Number of Maintenance Significant Items (MSI) within the overall system (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 203 of 275
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 204 of 275
)()(
)(xMEAS
xEXPxR tMTTR
tMTTRtDEM = (2.2.1)
)()(
)(xMEAS
xEXPxP tMPMT
tMPMTtDEM = (2.2.2)
Where:
)(log 02
**
*)()(t
xoLTHEORETICAxEXPECTED SIMTBF
UTILFtMTBFtMTTRtMTTR
β
+= (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) =δ .
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 205 of 275
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
DerivedPerformanceParameters
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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 206 of 275
Definition of Performance Parameter 3
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
Ref. Data Description
ROS Initial contractual Risk of Shortage (t =t0)
Shared Data Environment (e.g. TIMS)
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++
=
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 207 of 275
Definition of Performance Parameter 3.1
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
Ref. Data Description
ROS Initial or contractual Risk of shortage (metric)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 208 of 275
Definition of Performance Parameter 3.1.1
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
Ref. Data Description
US Total number of utilised spares/repairs parts within a defined period (metric)
Shared Data Environment (e.g. TIMS)
SR Total number of spares/repairs parts in the inventory (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 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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 209 of 275
Definition of Performance Parameter 3.2
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
Ref. Data Description
k Existing stock: number of parts carried in stock of any given spare/repair typology (IT) at time tx(metric) Shared Data
Environment (e.g. TIMS)
SR Total number of spares/repairs parts in the inventory (metric)
Score computation
The score computation can be done thorough the metrics measurement.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 210 of 275
Definition of Performance Parameter 3.2.1
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
Ref. Data Description
SP Number of spares/repairs typology with approved Procurement Plan (metric)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 211 of 275
Definition of Performance Parameter 3.2.2
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
Ref. Data Description
PI Number of spare/repair typology with ap-proved Provisioning Plan (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 212 of 275
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
Ref. Data Description
DTS Delivering time for spares (LEADT, OPUS10) 3.2.3
Shared Data Environment (e.g. TIMS)
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”
Overcoming a predefined value shall set off problem identification and cor-rective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 213 of 275
Definition of Performance Parameter 3.2.3
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
Ref. Data Description
DT DUi Spare replenishment time: Delivering time required to obtain spare/discardable unit not available in the stock pool (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 214 of 275
Definition of Performance Parameter 3.3
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
Ref. Data Description
TATi Time for a single repairable item to go through the complete repairing cycle (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 215 of 275
Definition of Performance Parameter 3.3.1
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
Ref. Data Description
CP Number of spares/repairs typology with approved customer price (metric)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 216 of 275
Definition of Performance Parameter 3.4
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
Ref. Data Description
DR Number of items subject to discrepancies reports due to PHST tasks (metric)
Shared Data Environment (e.g. TIMS)
US Total number of utilised spares/repairs parts within a defined period (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)
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 217 of 275
Definition of Performance Parameter 3.4.1
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
Ref. Data Description
DTT Measured Time required for each spare transportation for items available in the pools (metric) Shared Data
Environment (e.g. TIMS)
US Total number of utilised spares/repairs parts within a defined period (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 spe-cific system requirements (e.g. Operational Availability)
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 218 of 275
Definition of Performance Parameter 3.5
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
Ref. Data Description
LI Number of spares/repairs typology with logistic supportability data available (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 219 of 275
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
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
DerivedPerformanceParameters
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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 220 of 275
• 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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 221 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 222 of 275
Definition of Performance Parameter 4
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
Ref. Data Description
MTBFACH
Mean Time Between Failures achievable in a defined period T due to technical sup-port services (see Derived Performance Parameter 4a). Shared Data
Environment (e.g. TIMS)
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
++=
**)(
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 223 of 275
Definition of Derived Performance Parameter 4a
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
Ref. Data Description
MTBF(tx) Mean Time Between Failures measured for
t = tx.
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 224 of 275
Definition of Performance Parameter 4.1
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
Ref. Data Description
PRM Percentage of ISER / Data reports with reliability and maintainability evaluation vs their total number (4.1)
Shared Data Environment (e.g. TIMS)
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)
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 225 of 275
Definition of Performance Parameter 4.1
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
Ref. Data Description
ISER Total number of In Service Events Reports and Data Reports on system utilization (metric) Shared Data
Environment (e.g. TIMS)
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 226 of 275
Definition of Performance Parameter 4.2.1
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
Ref. Data Description
ISER Total number of In Service Events Reports and Data Reports on system utilization (metric) Shared Data
Environment (e.g. TIMS)
IR Number of accounted ISER and Data re-ports (metric)
Score computation
- The score computation can be used for PBL contracts
- 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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 227 of 275
Definition of Performance Parameter 4.2.2
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
Ref. Data Description
ISER Total number of In Service Events Reports and Data Reports on system utilization (metric) Shared Data
Environment (e.g. TIMS)
RR Number of ISER with approved conclu-sions (root causes removed) (metric)
Score computation
- The score computation can be used for PBL contracts
- The score computation can be done through the metrics measurement.
- A value less than 100 signals the presence of lacks in the “Technical Investigation” tasks.
- Overcoming a predefined value shall set off problem identification and corrective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 228 of 275
Definition of Performance Parameter 4.3
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
Ref. Data Description
RCA Total number of request for Contractor technical assistance (Post Design) (metric) Shared Data
Environment (e.g. TIMS)
RI Number of Report Investigations approved by the customer (metric)
Score computation
- The score computation can be used for PBL contracts
- A value less than 100 signals the presence of lacks in the “Post Design service” activity
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 229 of 275
Definition of Performance Parameter 4.2
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
Ref. Data Description
MTBF(tx) Mean Time Between Failures measured for t = tx (metric)
Shared Data Environment (e.g. TIMS)
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)
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 230 of 275
Definition of Performance Parameter 4.4
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
Ref. Data Description
NDC Total number of delay and cancellation for scheduled sorties (metric) Shared Data
Environment (e.g. TIMS)
NSS Number of scheduled sorties (metric)
Score computation
- The score computation can be used for PBL contracts
- The score computation can be done through the metrics measurement.
- 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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 231 of 275
Definition of Performance Parameter 4.4.1
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
Ref. Data Description
ISER Total number of In Service Events Reports (metric) Shared Data
Environment (e.g. TIMS)
TR Time for processing ISER (metric)
Score computation
- The score computation can be used for PBL contracts
- The score computation can be done through the metrics measurement.
- Overcoming a predefined value signals the presence of lacks in the TAS service and shall set off problem identification and corrective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 232 of 275
Definition of Performance Parameter 4.4.2
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
Ref. Data Description
NRT Total number of Request for TAS (metric) Shared Data Environment (e.g. TIMS)
TTI Elapsed time for TAS intervention (metric)
Score computation
- The score computation can be used for PBL contracts
- The score computation can be done through the metrics measurement.
- Overcoming a predefined value signals the presence of lacks in the TAS service and shall set off problem identification and corrective actions.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 233 of 275
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
THEOEXP tTtMTBFTMTBF
α
= , where
=
)()(
log)(00
tMTBFtMTBF
tTHEO
x
ttx x
α
(4.2) illustrates the reliability growth rate
o )(
00 *)()(
xt
THEOEXP tTtMTBFTMTBF
α
=
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 234 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 235 of 275
Definition of Performance Parameter 5
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
Ref. Data Description
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 −+−+−−=
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 236 of 275
Definition of Derived Performance Parameter 5a
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
Ref. Data Description
tx Generic time tx
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 237 of 275
Definition of Performance Parameter 5.1
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
Ref. Data Description
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 238 of 275
Definition of Performance Parameter 5.1.1
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
Ref. Data Description
OI Total number of critical/not critical items designed for obsolescence monitoring (metric) Shared Data
Environment (e.g. TIMS)
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 239 of 275
Definition of Performance Parameter 5.1.2
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
Ref. Data Description
OE Total number of items with incorrect obso-lescence data (metric)
Shared Data Environment (e.g. TIMS)
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 240 of 275
Definition of Performance Parameter 5.1.3
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
Ref. Data Description
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
- 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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 241 of 275
Definition of Performance Parameter 5.2
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
Ref. Data Description
PON Percentage of obsolescence issues for items not included into the Obsolescence List (5.2.1) Shared Data
Environment (e.g. TIMS)
APA Percentage of approved proposed actions (5.2.2)
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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 242 of 275
Definition of Performance Parameter 5.2.1
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
Ref. Data Description
ON Total of obsolescent and/or obsolescence issues for items not included into Critical/ Not-Critical items list (metric) Shared Data
Environment (e.g. TIMS)
OO Total number of obsolete and/or obsoles-cent items (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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 243 of 275
Definition of Performance Parameter 5.2.2
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
Ref. Data Description
OR Number of approved proposals for obso-lescence resolution (metric) Shared Data
Environment (e.g. TIMS)
OO Total number of obsolete and/or obsoles-cent items (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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 244 of 275
Definition of Performance Parameter 5.3
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
Ref. Data Description
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
- 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
- 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
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 245 of 275
Definition of Performance Parameter 5.4
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
Ref. Data Description
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
- 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
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 246 of 275
Definition of Performance Parameter 5.5
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
Ref. Data Description
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
- 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
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 247 of 275
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”).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 248 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 249 of 275
Definition of Performance Parameter 6
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
Ref. Data Description
TED Technical Documentation Completeness (6.1)
Shared Data
Environment (e.g. TIMS)
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
- 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) through the usage of a derived performance parameter called “Skill factor” (Sk, see derived Performance Parameter A).
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 250 of 275
Definition of Performance Parameter 6.1
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
Ref. Data Description
II Number of discrepancies reports due to incomplete or not available information (metric)
Shared Data Environment (e.g. TIMS)
DMA Total number of Data Module accepted by the customer (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 related ser-vice
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 251 of 275
Definition of Performance Parameter 6.2
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
Ref. Data Description
DM Total number of Data Module presented for validation (metric) Shared Data
Environment (e.g. TIMS)
DMA Total number of Data Module accepted by the customer (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 related ser-vice
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 252 of 275
Definition of Performance Parameter 6.3
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
Ref. Data Description
ID Number of discrepancies reports due to incorrect and/or incoherent information (metric) Shared Data
Environment (e.g. TIMS)
DMA Total number of Data Module accepted by the customer (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 related ser-vice
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 253 of 275
Definition of Performance Parameter 6.4
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
Ref. Data Description
NU Number of discrepancies reports due to not updated documentation (metric)
Shared Data Environment (e.g. TIMS)
DMA Total number of Data Module accepted by the customer (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 related ser-vice
- Overcoming a predefined value shall set off problem identification and corrective actions
Other contractual specifications
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 254 of 275
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”).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 255 of 275
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 256 of 275
Definition of Performance Parameter 7
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
Ref. Data Description
OTC Operational tasks analysis completeness
Shared Data Environment (e.g. TIMS)
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).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 257 of 275
Definition of Performance Parameter 7.1
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
Ref. Data Description
TAC Tasks Analysis Completeness (7.1.1)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 258 of 275
Definition of Performance Parameter 7.1.1
Indicator Title TAC
Tasks Identification Completeness
Service
TRS Requirement task analysis
Objective identification
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
Ref. Data Description
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 259 of 275
Definition of Performance Parameter 7.1.2
Indicator Title FRS
Functional Requirements Specification
Service TRS
Objective identification
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
Ref. Data Description
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.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 260 of 275
Definition of Performance Parameter 7.2
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
Ref. Data Description
GAC Training gap analysis completeness (7.2.1)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 261 of 275
Definition of Performance Parameter 7.2.1
Indicator Title GAC
Training Gap Analysis Completeness
Service TRS
Training Gap Management
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
Ref. Data Description
RTA Total number of MSI subjected to Re-quirement Tasks Analysis (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 262 of 275
Definition of Performance Parameter 7.2.2
Indicator Title TOC
Training Option analysis Completeness
Service TRS
Training Gap Management
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
Ref. Data Description
TO Total number of tasks with completed Gap analysis process (metric) Shared Data
Environment (e.g. TIMS)
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.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 263 of 275
Definition of Performance Parameter 7.2.3
Indicator Title CTC
Catalogue of Trainings Completeness
Service TRS
Training Gap Management
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
Ref. Data Description
ORD Total number of tasks with completed Gap analysis process (metric) Shared Data
Environment (e.g. TIMS)
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.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 264 of 275
Definition of Performance Parameter 7.3
Indicator Title TPE
Training Procurement Effectiveness
Service TRS
Training Procurement
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
Ref. Data Description
CAD Contractual adherence (7.3.1)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 265 of 275
Definition of Performance Parameter 7.3.1
Indicator Title CAD
Contract Adherence
Service TRS
Training Procurement
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
Ref. Data Description
CTO Number of training Objectives fulfilled within the Contract placement (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 266 of 275
Definition of Performance Parameter 7.3.2
Indicator Title TSC
Technical Specification Completeness
Service TRS
Training Procurement
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
Ref. Data Description
TSR
Total number of Training Objectives affected by remarks/discrepancies on training support specifications not yet solved (metric) Shared Data
Environment (e.g. TIMS)
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.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 267 of 275
Definition of Performance Parameter 7.3.3
Indicator Title DRE
Discrepancy Report evaluation
Service TRS
Training Procurement
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
Ref. Data Description
DR
Number of opened “Remarks/discrepancies” on the qualifica-tion tests (Acceptance Discrepancies Record) (metric) Shared Data
Environment (e.g. TIMS)
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.
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 268 of 275
Definition of Performance Parameter 7.4.1
Indicator Title
PTR
Personnel successfully trained per period
Service TRS
Training Implementation
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
Ref. Data Description
PT Total number of personnel trained on the evaluation period (metric)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 269 of 275
Definition of Performance Parameter 7.4.2
Indicator Title TES
Training Evaluation Summary Accuracy
Service TRS
Training Implementation
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
Ref. Data Description
DS Total number of data utilised on issuing the “training evaluation summary” (metric)
Shared Data Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 270 of 275
Definition of Performance Parameter 7.4.3
Indicator Title
PAC
Percentage of approved conclusions and recommendations
Service TRS
Training Implementation
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
Ref. Data Description
CR Total number of conclusions and recommendations found on the continuous improvement process (metric) Shared Data
Environment (e.g. TIMS)
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.
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 271 of 275
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”).
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 272 of 275
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
Ref. Data Description
MME Maintenance Management Effectiveness
Shared Data Environment (e.g. TIMS)
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
ISS Guide issue 2 – May 2013 - Page 273 of 275
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
Ref. Data Description
β(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
UTILFtMTBFtMTTRtMTTR
β
+=
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 B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 274 of 275
Annex C: About the formulas and their link with Ao…
Intentionally Blank
Please contact author for more information
Annex B: Performance Parameter Definitions
ISS Guide issue 2 – May 2013 - Page 275 of 275
Annex D: Your Notes