Product Supportability across the Life Cycle · Web viewSupportability measures the degree to which a system can be supported both in terms of its inherent design characteristics

LOG 211 Supportability Analysis Student Guide

Lesson 2: Product Supportability across the Life Cycle

Content

Slide 2-1. Lesson 2: Product Supportability across the Life Cycle

Welcome to Lesson 2: Product Supportability across the Life Cycle.

Supportability Analysis is a structured methodology to ensure the system is designed for Supportability and the Integrated Product Support (IPS) Elements are identified and available to the user. The Affordable System Operational Effectiveness (ASOE) model addresses the contributions of both system design (quality) and logistics footprint.

Supportability measures the degree to which a system can be supported both in terms of its inherent design characteristics of Reliability and Maintainability and the efficacy of the various elements of product support, to include the spare parts, tools, and training required to operate and maintain it.

January 2013Final v1.3

1 of 41


Topic 1: Introduction

Content

Slide 2-2. Introduction

2 of 41 January 2013Final v1.3


Content

Slide 2-3. Topics and Objectives


3 of 41


Topic 2: The Relationship of ASOE to Supportability and Sustainment

Content

Slide 2-4. Topic 2: The Relationship of ASOE to Supportability and Sustainment

This topic provides a general overview of ASOE and its relationship to Supportability and Sustainment.



Content

Slide 2-5. Supportability Analysis Life Cycle Framework: Continous Assessment and Improvement for Affordability

Supportability is the capability of a total system design to support operations and readiness needs throughout the total life cycle at an affordable cost.

Supportability Analysis identifies and justifies the logistics support requirements (e.g., people, parts, publications, tools, and test equipment) in support of the corrective and preventative maintenance tasks identified to safely maintain a system at the required readiness level.

The Supportability Analysis Life Cycle Framework illustrates the iterative Supportability Analysis process.


5 of 41


Content

Slide 2-6. Supportability Analysis Life Cycle Framework: Continous Assessment and Improvement for Affordability (cont.)

The Supportability Analysis Life Cycle Framework encompasses three broad areas:

Language - user requirements, Measures of Effectiveness (MOEs), and Logistics Product Data

Framework - Supportability analyses and the Product Support Package Evaluation - the Supportability test (e.g., M-Demo Evaluation) at

Milestone C that determines whether the program achieves Supportability/Suitability requirements during Developmental Test & Evaluation (DT&E) and Operational Test & Evaluation (OT&E)



Content

Slide 2-7. Affordable System Operational Effectiveness Model

Designing for optimal ASOE requires balancing Mission Effectiveness (i.e., can the system do it) and Life Cycle Cost/Total Ownership Cost (i.e., can the program afford it) and Process Efficiency (i.e., are the processes responsive to the equipment and user needs). The ASOE Model illustrates the dependency and interrelationship between Technical Performance, Availability (i.e., Reliability, Maintainability, and Supportability), Process Efficiency (i.e., system operations, maintenance, and logistics support), and Life Cycle Cost/Total Ownership Cost. This overarching framework provides context for the trade space available to a Program Manager to maximize a system’s operational effectiveness.

ASOE is achieved through influencing early design and architecture and through focusing on Supportability outputs. Reliability, reduced logistics footprint, and reduced system Life Cycle Cost are achieved by their being included from the very beginning of a program – starting with the definition of required capabilities. ASOE requires proactive, coordinated involvement of organizations and individuals from the requirements, acquisition, logistics, user communities, and industry.

The ASOE process applies equally to new weapon systems as well as to major modifications and upgrades of existing, fielded systems. In all cases, full stakeholder participation is required in activities related to designing for support, designing the support, and supporting the design.


7 of 41


Content

Note: The ASOE model has been updated following the update to the MANUAL FOR THE OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM (JCIDS Manual) 19 January 2012.



Content

Slide 2-8. ASOE and Language

Language sets up the structure to communicate user goals and objectives and defines the MOEs used to establish the Logistics Product Database.

An MOE is a mission-oriented qualitative or quantitative measure of operational success closely related to the mission objective or operation being evaluated. They enable testing feedback to assess whether design meets user needs. MOEs link user needs to design, design to support, and enable trade-offs to achieve the best balance of capability for acquisition and support costs. This traceable path to user needs is supported through Technical Performance Measures (TPMs).

The Logistics Product Database is generated by iterative Supportability Analysis updates and serves as both the input and output environment in which all Supportability analyses are conducted.

Together, the MOEs and Logistics Product Data provide the foundational language which enables the Life Cycle Logistician (LCL) and Systems Engineer (SE) professionals to communicate and organically foster a collaborative working relationship.


9 of 41


Content

Slide 2-9. ASOE and Framework

Framework is the area where the iterative Supportability analyses are performed and the Product Support Package is developed.

The following Supportability analyses define ASOE functional nodes:

Reliability & Maintainability Allocation, Modeling, Prediction and Analysis - is performed on an ongoing and iterative basis throughout the life cycle

Failure Mode Effects and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) - address the root causes of failures and drive design changes and corrective/preventive maintenance recommendations

Software Supportability Analysis - is an iterative process that emphasizes how software, hardware, and networks interconnect

Reliability Centered Maintenance (RCM) Analysis - determines maintenance tasks and frequencies for critical failures identified by the FMECA and FTA

Maintenance Task Analysis (MTA) – integrates people (skills), equipment (tools), methodology (tasks) and environment (facility) while populating the Logistics Product Database and verifying the accuracy and compliance of that data with the Maintenance Concept and Capability Development Document (CDD)



Content Level of Repair Analysis (LORA) – provides economically optimal

maintenance policy which is not always consistent with the Maintenance Concept

Trade-off Analysis – is about achieving balance among competing priorities to get the best outcome possible

Product Support Analysis - is an active process that identifies resources required to define and aid in the procurement of an effective Product Support Package


11 of 41


Content

Slide 2-10. ASOE and Evaluation

Evaluation is the area of the Supportability Analysis Life Cycle Framework where pre-fielded and post-fielded testing and evaluation occurs:

Pre-fielding includes the Developmental Test & Evaluation (DT&E) and Operational Test & Evaluation (OT&E) to ensure traceable requirements flow down to complete an effective, supportable, and affordable system.

Post-fielding involves Failure Reporting, Analysis, and Corrective Action System (FRACAS), which is a closed loop process for reporting, classifying, and analyzing failures to determine their root causes and to plan corrective actions.



Content

Slide 2-11. Should-Cost Management

The graph shown in this slide illustrates that the cost of Reliability and Sustainment Cycle time are inversely related (i.e., spending more money on Reliability during system design, generally results in decreased Sustainment costs). The emphasis in this graph is on balancing the cost of Reliability to the cost of Sustainment.

Should-Cost Management is an extension of the ASOE Model with particular focus on finding efficiencies and savings opportunities. Subsequent Supportability Analysis lessons, and their exercises and simulations, are all geared toward the ASOE Framework. Many of the analyses demonstrate what to look for (i.e., the opportunity) and how to make an impact (through the Integrated Product Team (IPT)) on design, Supportability, and process efficiencies to bring Affordability to the design and to the support strategy.

Should-Cost Management specifically begins with the verb scrutinize. The FMECA and RCM Analysis for example, seek out critical and potentially high cost failure issues. Reliability engineers scrutinize these risks by either designing out potentially catastrophic and costly outcomes or by finding savings by delaying costly procedures until the science (i.e., prognostics or diagnostics) dictates repair action. This is real savings designed-in up-front with global and long-term cost savings impacts.


13 of 41


Content

Other Should-Cost verbs that translate well into Supportability Analysis are:

Look for repetitive savings – in the Maintenance Task Analysis (MTA), the LCL examines the area that consumes about 80% of the maintainer’s time and budget. Here, the LCL examines the cornerstones of Maintainability - accessibility, modularity, and testability. Testability translates into reducing false positives (e.g., shipping perfectly good items to depot only to be shipped back with No Fault Found). Designing-in ways to reduce the No Fault Found rate into the equipment itself saves procurement dollars – no expensive special test equipment needed at every location – and even more savings by having only truly failed components inducted into the supply chain – a savings “win-win.”

Leverage engineering trade space. The LCL conducts both Level of Repair Analysis (LORA) and Trade-off Analysis to support the Product Support Manager’s (PSM) investigation of characteristics such as Reliability and factors such as manpower that drive up cost. These analyses evaluate ways to eliminate or significantly reduce these cost drivers. Trade-off outcomes feed important program decision and planning documents such as the Business Case Analysis (BCA) and the Life Cycle Sustainment Plan (LCSP).

The following references may be helpful for understanding Should-Cost Management:

Interim DoD Instruction 5000.02, “Operation of the Defense Acquisition System” November 25, 2013(http://www.dtic.mil/whs/directives/corres/pdf/500002_interim.pdf)

Table 2. Milestone and Phase Information Requirements, page 56.USD(AT&L) Memorandum, Should-Cost and Affordability dated August 24, 2011 (http://www.acq.osd.mil/docs/Should-cost%20and%20Affordability.pdf)

USD(AT&L) memorandum Implementation of Will-Cost and Should-Cost Management memorandum dated April 22, 2011 (http://www.acq.osd.mil/docs/USD(ATL)_Memorandum_on_Implementation_of_Will-Cost_and_Should-Cost_Management_042211.pdf)

Note: Lesson 11: A Trade-off Analysis addresses Affordability and Should-Cost in greater detail.


http://www.acq.osd.mil/docs/USD(ATL)_Memorandum_on_Implementation_of_Will-Cost_and_Should-Cost_Management_042211.pdf)

http://www.acq.osd.mil/docs/USD(ATL)_Memorandum_on_Implementation_of_Will-Cost_and_Should-Cost_Management_042211.pdf)

http://www.acq.osd.mil/docs/Should-cost%20and%20Affordability.pdf

http://www.acq.osd.mil/docs/Should-cost%20and%20Affordability.pdf

http://www.dtic.mil/whs/directives/corres/pdf/500002_interim.pdf


Content

Slide 2-12. Product Support

Life Cycle Sustainment planning and execution seamlessly span a system’s entire life cycle. They translate user capability and performance requirements/needs into tailored Product Support to achieve the evolving Life Cycle Product Support Availability, Reliability, and Affordability parameters.

The Life Cycle Product Support approach to Sustainment relies on understanding and integrating all of the functional components available to comprise the required Product Support infrastructure. These functional components are grouped into twelve categories called the Integrated Product Support (IPS) Elements. As illustrated in this slide, three of the IPS Elements are very broad in scope:

Product Support Management - plans, manages, and funds system Product Support across all IPS Elements

Design Interface - integrates the quantitative design characteristics of Systems Engineering (e.g., Reliability, Maintainability, etc.) with the functional IPS Elements and reflects the driving relationship of system design parameters to Product Support resource requirements

Sustaining Engineering - ensures continued system operation and maintenance with managed (i.e., known) risk


15 of 41

Technology Maturation & Risk Reduction


Content

Slide 2-13. Traceability of ASOE to User Needs

User needs must be defined and traceable throughout the life cycle such that they are verifiable and testable in the operational environment envisioned for the system. They are first captured and refined in user capability and product production documents. These documents act as a lens to focus the Supportability analyses on achieving Sustainment performance outcomes. The outcomes also are used to populate the ASOE model for trade-offs and then used to validate the trade-offs through an evaluation filter.

Once evaluated, the outcomes are open to scrutiny through traceable paths to each analysis through the Sustainment Key Performance Parameter (KPP), Availability.

Product Support is the execution of IPS Elements geared to sustaining a system’s readiness and operational capability. The ASOE model integrates readiness, capability with effectiveness and Affordability. The IPS Elements, through the ASOE model, are the path to building and achieving the optimum Product Support Package.



Content

The Life-Cycle Sustainment Plan (LCSP) is the program’s primary management tool for satisfying the Sustainment KPP through the delivery of a Product Support Package. Developing Life Cycle Product Support Plans are critical to delivering the best possible Product Support Package. The LCSP:

Articulates the Product Support Strategy as the program evolves through the life cycle and into Sustainment

Emphasizes early-phase Sustainment requirements development and planning

Requires that IPT members collaborate and communicate Highlights key Sustainment surveillance and contract development and

management processes

The LCSP remains an active management tool throughout system operations and Sustainment. The program must continually update the LCSP to ensure Sustainment performance satisfies the users’ needs and accomplishes ASOE.

You have just completed Topic 2: The Relationship of ASOE to Supportability and Sustainment. Next, you will learn how user needs influence Design for Support.


17 of 41


Topic 3: User Needs’ Influence on Design for Support

Content

Slide 2-14. Topic 3: User Needs’ Influence on Design for Support

This topic provides an overview of how user needs influence design for support.



Content

Slide 2-15. Life Cycle Management Framework: Where Are You? What Influence Do You Have?

The Life Cycle Management Framework is comprised of five phases as illustrated. While this framework appears linear, the supporting processes and activities are overlapping and iterative. In an effort to provide you with a point of reference to this framework, each phase will be introduced as this course progresses. This lesson introduces the first phase of the Life Cycle Management Framework: Materiel Solution Analysis (MSA). The purpose of this phase is to assess potential materiel solutions and satisfy the phase-specific entrance criteria for the next program milestone as designated by the Milestone Decision Authority (MDA).

While considered pre-system acquisition, MSA is the first opportunity to influence a system’s Supportability and Affordability by balancing technology opportunities with operational and Sustainment requirements. The phase provides the widest latitude for considering requirement alternatives and has the greatest impact on Life Cycle Cost. In determining the optimally balanced requirements, emphasis is not only on the Reliability and Maintainability of potential materiel solutions, but also focuses on assessing cost-effective responsiveness and the relevance of support system and supply chain alternatives.


19 of 41



Content

The MSA phase begins with a successful Materiel Development Decision (MDD) and an approved Initial Capabilities Document (ICD). The MDD is the formal entry point into the acquisition process and is mandatory for all programs. The primary objectives of this phase are to:

Establish support costs, readiness objectives, risk, and support and support-related design constraints

Identify support characteristics of operational concepts and interoperability constraints (local and international)

Initialize the Logistics Product Data (LPD) database (Lesson 4)



Content

Slide 2-16. Materiel Solution Analysis Phase: Milestone A Activities

The Materiel Solution Analysis phase has Entry and Exit criteria/documentation and corresponding activities that reflect user requirements and incorporate or address Supportability and logistics considerations. Entry Documents are completed when the phase is initiated (i.e., MDD) and Exit Documents/Activities are completed or updated during the phase, prior to exit (i.e., Milestone A).Entry Documents include the following:

Initial Capabilities Document (ICD) Analysis of Alternatives (AoA) Plan Alternative Maintenance and Sustainment Concept of Operations

Exit Documents/Activities include, but are not limited to the following: Analysis of Alternatives (AoA) to include:

o Market Research resultso Initial Reliability, Availability and Maintainability – Cost (RAM-C)

Rationale Report Draft Capability Development Document (CDD) Test and Evaluation Strategy (TES) Acquisition Strategy (AS) Systems Engineering Plan (SEP) High-level draft Life Cycle Support Plan (LCSP) Initialized SAE GEIA-STD-0007 Logistics Product Database and Logistics

Product Data


21 of 41

SAE GEIA-STD-0007


Content

Content

Slide 2-17. LCL and SE Roles and Responsibilities

Historically, the LCL’s role was not emphasized until Milestone B. Now the LCL is an active participant from the beginning, Pre-Milestone A, so that Supportability is emphasized within the design and the context of the Maintenance Concept.

Working collaboratively through IPTs, LCL and SE professionals have a tremendous opportunity to make major contributions to build and deploy an effective and affordable system. Additionally, building the support strategy within the ASOE model ensures that focus on Affordability throughout the life cycle. Building Sustainment efficiencies into the design and into the support systems early and often amplifies downstream savings and brings a disciplined Systems Engineering approach to the entire acquisition as a unified affordable solution.




Content

Slide 2-18. LCL/SE and Product Support

LCL and SE professionals have integral roles throughout the life cycle. It is through the IPS Elements and TPMs that they are able to work and communicate toward the program’s ASOE goal. The IPS Elements define the specific roles, responsibilities, and activities of IPT members. TPMs quantify success in each applicable IPS Element. As this slide illustrates, the Supportability Analysis (SA) outcomes shape how the IPS elements are deployed in the Logistics Product Database and the LCSP.

You have just completed Topic 3: User Needs’ Influence on Design for Support. Next, you will learn about Supportability Analysis and the Product Support Strategy.


23 of 41


SAE GEIA-STD-0007


Topic 4: Influence of Supportability on Design the Support and Support the Design

Content

Slide 2-19. Topic 4: Influence of Supportability on Design the Support and Support the Design

This topic introduces foundational concepts regarding how Supportability influences Design the Support and Support the Design.



Content

Slide 2-20. Closed-loop Systems Engineering

Closed-loop Systems Engineering is:

A logical sequence of activities and decisions that transform an operational need into a description of system performance parameters and a preferred system configuration

An interdisciplinary engineering management process that evolves and is used to verify an integrated, life cycle balanced set of solutions that satisfy fleet requirements

The Closed-loop Systems Engineering process fosters a sense of responsibility in IPT members as they are always asking the question, what impact does “this” action have on something else? This process ensures IPT members are aware that every action has a reaction. The Closed-loop Systems Engineering process is comprised of four phases:

Requirements to Design:o Gather Data to quantify achievement of the Key Performance

Parameter(KPP)/Key System Attributes (KSAs)o Allocate, Model, Predict and Analyze Reliability & Maintainability

(R&M)o Publish Reliability Growth Plano Conduct RAM trade-off analyses


25 of 41


Content Design to Fielding:

o Maintain and analyze FRACASo Update FMECA, Fault Tree, and Reliability Block Diagram (RBD) with

T&E datao Conduct RCM Analysiso Update Reliability Growth Plano Conduct Maintenance Task Analysis (MTA) and Maintainability

Demonstration (M-Demo)o Evaluate KPP and KSAs achievemento Update LCSP with trade-offs

Fielding to Sustainment:o Maintain and analyze FRACAS datao Establish triggers (e.g., frequency, duration, and cost) for system

logistics degraders identified and captured in the baseline assessment during the initial Supportability Analysis

o Update models and simulationso Provide traceable analyses: trends, LORA, and trade-offs

Sustainment to Disposal:o Maintain and analyze FRACAS datao Evaluate KPP/KSAs achievemento Identify R&M shortfallso Update the BCAo Perform Sustaining Engineering to incorporate Materiel and Non-

Materiel changes as appropriateo Identify/institutionalize lessons learned at national levelo Identify/institutionalize LCSP best practices



Content

Slide 2-21. Design the Support and Support the Design

The output of the Supportability analyses is what LCLs use to build an efficient and effective Product Support Package. LCLs take this Logistics Product Data and use it in the Maintenance Planning process to formulate a system maintenance plan. Maintenance Planning is the translation of engineering data and analysis into executable maintenance actions and the identification of the required IPS Elements required to conduct maintenance.

Supportability analyses are the basis for Product Support decisions to ensure:

Supportability is included as a system performance requirement An optimal support system design and infrastructure Support elements are acquired and provided to the user Product Support decisions are traceable and defendable

As this slide illustrates, there are three overarching activities which relate life cycle phases, program artifacts, and requirements:

1. Understand the user needs as documented in the ICD.2. Measure whether the program is meeting the user needs using

CDD/Capability Production Document (CPD)/KPPs/KSAs/TPMs.3. Monitor the metric performance with the CDD.


27 of 41



Content

The program creates and maintains documentation in parallel with JCIDS requirements:

At Milestone A, develop:o Program Management Plan (PMP)o RAM-C Rationale Reporto Systems Engineering Plan (SEP)o High-level draft LCSP

At Milestone B:o Update the PMP, RAM-C Rationale Report, SEP, and LCSPo Create the Test and Evaluation Master Plan (TEMP)

At Milestone C, update the PMP, RAM-C Rationale Report, SEP, LCSP, and TEMP

Post-Milestone C, update the SEP, LCSP, and TEMP throughout Sustainment



Content

Slide 2-22. Inputs and Outputs: Design the Support

This slide provides a high-level view of Supportability inputs, process, and outputs specific to Design the Support.

Inputs:

The AoA compares the operational effectiveness, Suitability, and Life Cycle Cost of alternatives that satisfy established capability needs.

User needs are captured in the ICD which matures into the draft CDD at Milestone A. Throughout a program’s life cycle, there are checkpoints at each milestone for ensuring user needs are being met. TPMs measure the program’s success of meeting the users’ needs and are the language that is used to visualize and discuss the program’s goals.

The Logistics Product Database is initialized at Milestone A

Process:

Supportability analyses are iterative and performed throughout the life cycle. They empower the IPT and ensure that requirements are being met within cost and schedule.

Outputs:

MOEs refined into TPMs Refined SEP Refined LCSP Refined Logistics Product Data


29 of 41


Content

Content

Slide 2-23. Inputs and Outputs: Support the Design

Supporting the Design includes Human Factors Engineering and the cost-effective responsiveness and relevance of the support infrastructure. The following activities facilitate supporting the design:

Manage the program in the field (e.g., Performance-Based Logistics (PBL) plan, Integrated Product Support (IPS) Elements, obsolescence, technology refresh, Diminishing Manufacturing Sources and Material Shortages (DMSMS), and spares re-procurement)

Apply the Closed-loop Systems Engineering process Analyze product availability (e.g., operational effectiveness, top

degraders, Reliability-Centered Maintenance [RCM], and Condition-Based Maintenance [CBM])

Analyze Affordability (e.g., Operation and Support (O&S) Cost, Depot Level Reparables (DLR) cost and Availability)

Ensure safety Accomplish necessary training Ensure needed access to technical data and publications Determine optimum Configuration Management roles and

responsibilities



Content

This slide provides a high-level view of Supportability inputs, process, and outputs specific to Support the Design.

Inputs:

Requirements document: CDD Program artifacts:

o TEMPo LCSPo Product Support Strategy

Process:

Validate and update the Logistics Product Database Schedule and conduct the Logistics Demonstration Perform the Post-Fielding Sustainment Analysis (PFSA)

Output:

Supportability Analysis Reports Refined program artifacts:

o SEPo LCSPo Product Support Strategy


31 of 41


Content

Slide 2-24. Manage Supportability Analysis Requirements

This slide compares five program areas, which have impact throughout the entire life cycle, across a timeline. Each area has specific requirements due at a specific point in time.

Supportability Analysis iterations are threaded through the Product Support Management process to form the:

Sustainment Performance-based Agreement (PBA)o Establish a negotiated baseline of performance and corresponding

support necessary to achieve that performance, whether provided by commercial or organic support providers. PBAs with the User Command specify the level of operational support and performance required by the User.

Surveillance Process (i.e., FRACAS) Product Support Strategy Product Support Integrator (PSI)/Product Support Provider (PSP) or a

combination of the two



Content

The PSI is an organic or private sector organization that is selected to serve as the single point of accountability for integrating all sources of support necessary to meet the agreed-to support performance metrics.

The PSPs are assigned responsibilities to perform and accomplish the functions represented by the IPS elements which, per the Business Case Analysis (BCA) process and consistent with statute and policy, comprise the range of best value or statutorily assigned workloads that achieve the Warfighter support outcomes.


33 of 41


Content

Slide 2-25. Integrated Product and Process Development

The Integrated Product and Process Development (IPPD) management process is set up to assure the program achieves its goals throughout the life cycle. The IPPD:

Integrates all activities from product concept through production/field support

Uses a cross-functional team to optimize the product and its manufacturing and Sustainment processes simultaneously to meet cost and performance objectives

Basic IPPD principles include the following:

Focus on the customer Concurrently develop products and processes Plan early in and throughout the life cycle Ensure maximum flexibility in order to optimize contractor approaches Ensure a robust design and improve process capability Create and maintain an event-driven schedule Support multi-disciplinary teamwork Instill empowerment




Content

The IPTs are instrumental in the IPPD process, they are:

The fundamental building blocks of the IPPD management process Cross-functional teams put together to deliver a product to an internal

or external customer Composed of members who are committed to a common purpose,

common performance objectives, and a common approach for which they are mutually accountable

Specific to different parts of a project based upon required subject matter expertise

There are three categories of IPTs in the DoD acquisition program:

Overarching IPTo Oversees the program through the life cycleo Is at the Office of the Secretary of Defense (OSD) or component

levelo Includes the program manager, program executive officer, and

appropriate staff Working-level IPTs (WIPTs)

o Include the functional practitionerso Provide staff-level program functional knowledge and expertiseo Include the Program Manager or his representative and staffo For large programs, focus on a discipline or functional area (e.g.,

Supportability, testing, cost/performance, or contracting)o For small projects, focus on the whole effort

Program IPTso Are at the program levelo Manage and execute the different parts of the program (e.g.,

human systems integration, test and evaluation, etc.)

IPT members:

Include all functional disciplines that will influence the program throughout its full life cycleo Human Systems Integrationo Test and Evaluationo Product Support managemento Configuration Managemento Systems Engineeringo Risk Managemento Requirements Management

Must have a clear understanding of the team’s goals, responsibilities, and authority

Must understand and respect the expertise of other team members


35 of 41


Content

Slide 2-26. IPTs and IPS Elements

As the design matures, the IPTs are the custodians of Logistics Product Data and interpret the Supportability Analysis outcomes for major product and Product Support design decisions. The IPT must ensure all of the IPS Elements are considered, incorporated as part of the system infrastructure, and fully integrated to achieve maximum Availability and Reliability while optimizing Life Cycle Cost.

LCLs and SEs need to use a common language and have an understanding of the other’s roles and responsibilities as members of an IPT(s) so they are able to productive work relationship. They need to provide leadership in Design Interface to accomplish, execute, and infuse the Supportability Analysis and Product Support Strategy.


SAE GEIA-STD-0007


Content

Slide 2-27. LCLs and SE

Sustaining Engineering ensures continued operation and maintenance of a system. It consists of a combination of engineering and Product Support life cycle management strategies to achieve the program’s desired Sustainment metric outcomes (e.g., KPPs, KSAs).

A common language (through MOEs, IPS Elements, and Logistics Product Data) connects the analyses and the LCL/SE roles to enable understanding, communication, and validation of the Product Support Strategy. This common language enables LCLs, SEs, and Product Support Managers to:

Lead and assess Supportability Analysis activities Engage the design agent in clear and concise terms to meet user needs Work toward Sustainment outcomes as a cohesive team Clearly articulate and act upon system and product life cycle

management objectives


37 of 41


Content

Slide 2-28. Exercise

When you are done with the exercise, you have completed Topic 4: Supportability Analysis and the Product Support Strategy. Next, you will conclude the lesson.



Topic 5: Summary

Content

Slide 2-29. Topic 5: Summary


39 of 41


Content

Slide 2-30. Takeaways



Content

Slide 2-31. Summary

Congratulations! You have completed Lesson 2: Product Supportability across the Life Cycle.


41 of 41