Reducing the Logistics Footprint within the PBL Construct - A Winning Strategy

SYSTEM ENGINEERING AND DESIGN TEAM

PRODUCIBILITY ENGINEER

SUPPORTABILITY ENGINEER

Mike Osborne, CPL, CCDM CAS Inc., VP Education Council of Logistics Engineering Professionals (CLEP)
Slide 0

IF I HAD KNOWN THAT I HAD TO SUPPORT

THIS THING, I WOULD HAVE DESIGNED IT

DIFFERENTLY

Whining

Slide 1

Proposed Defense Acquisition Executive Summary (DAES-S) Metrics

Part A Narrative
Overall Program Health Any Operational Impacts Implementing Program Strategy Addresses TLCSM and PBL

Part B Outcome Based Assessment Focused on Goals and Variance from Goals
Goal Forecast/ Actual Rating

Operational Availability
* ALT: Materiel Availability Mission Reliability * ALT: Materiel Reliability Logistics Response Time * ALT: Mean Down Time Program Funding Status Cost per Unit of Usage Reduction in TOC Safety

___
___ ___ ___ ___ ___ ___

___
___ ___ ___ ___ ___ ___

___
___ ___ ___ ___ ___ ___

7 Indicators Outcome based Report issues by exception Relevant to warfighter

Goals determined by Services for legacy systems Established as KPPs for new systems
Slide 2

What was wrong with Ao??

Ao addressed R&M and ALDT, and really equates to peacetime as opposed to wartime The Ao is typically calculated annually and reflects an average or specifically, a snap shot in time.because the math is so simple it does not address the dynamics of varying operational tempos or operations

As a support planning baseline, it has been used in that context for eonsits been a comfort zone that if the Ao is good then everything is fine.but so much is missing in the equation that it actually ADVERSELY affects war fighting capability.
The result of Ao measurement in an IOT&E environment is always near to 1.0 ---- its perfect but meaningless. Because in the real world while the techs are refueling, rearming, reconfiguring the aircraft/tank/ship, it is NOT really availablewe need to shorten the DURATION and FREQUENCY of all support events to make the System TRULY Available..and the Ao equation does not support this.
Slide 3

Whats the difference between Ao and Ma? Three big factors influence Operational Availability: Reliability, Maintainability and ALDT (Administrative Logistics Down Time)
R&M are fixed values in a given point in time, but ALDT is never, ever, constant The resultant Ao value has no goodness since it totally hinges on the debatable average ALDT used in the Ao equation

Ma is influenced by measurement of System Downtime, both planned and unplanned; Inventory metrics plus Material Reliability and Total Ownership Costs associated with material readiness.
Slide 4

MATERIAL AVAILABILITY AS A KEY PERFORMANCE PARAMETER EXAMPLE OF COMPUTATION OF SYSTEM LEVEL Ma Threshold MTBF= 226 hr Threshold MTTR= 2.83 hr MLDT = 4 days = 96 hr

Ma = ____MTBF_____ MTBF + MTTR +MLDT

226 _____ 226 + 2.83 + 96

___226__ 324.83

Ma = 0.695749 (0.70)

Slide 5

MATERIAL AVAILABILITY AS A KEY PERFORMANCE PARAMETER

EXAMPLE OF COMPUTATION OF SYSTEM LEVEL Ma USING OBJECTIVE PARAMETERS AND REDUCED LOGISTICS RESPONSE TIME Objective MTBF= 350 hr (from 226; up 55% - high expense) Objective MTTR= 2.25 hr (from 2.83; down 20% - high expense)

Reduction in MLDT by one day =3 days= 72 hr (down 25% moderate expense)

Ma = 0.82499 (0.82) from 0.695749

Increasing MTBF only, results in an Ma of 0.7798

Decreasing MTTR only, results in an Ma of 0.6969 Decreasing MTTR and increasing MTBF results in an Ma of 0.7804

Conclusion: Mean Logistics Down Time (MLDT) is the most critical metric in increasing Ma. Increase of Ma from 0.70 to 0.82 is predominantly due to streamlining Logistics Response.
Slide 6

New PBL Paradigm

We have to reduce system downtimes and reduce O&S costs through deliberate systems engineering to get rid of the logistics infrastructure

And apply PBL criteria to what infrastructure is left

Slide 7

So How do we reduce Mean Logistics Down Time?

OSD Guidance document Designing and Assessing Supportability in DOD Weapons Systems, October 24, 2003:
Designing for support and supporting the design Designing-in the critical aspects of supportability through application of the System Operational Effectiveness model, and Inclusion of logistics support considerations in detailed design reviews to includecharacteristics such as openness of design, upgradeability, modularity, and testability, and designing for producibility BUT That is not strong enough PMs and Systems Engineers still dont get it - the stool now has three legs, Hardware, Software and Logistics (sustainment) designed-in requirements.

Our logisticians either dont know how to do this, or dont have the detailed backing in directives and policy.
Slide 8

What is missing from all this is Needs of the Maintainer

We discuss everything about PBL EXCEPT how to design-in supportability and producibility; therefore: If we are ever to reduce the logistics infrastructure, we must definitize the Logistics requirements to the Systems Engineers prior to product design start, and enforce equal design consideration with hardware and software requirements. Our PMs must understand that, our systems engineers must do that, and logisticians need to insist on it. SYSTEMS ENGINEERS ARE STILL FOCUSED PRIMARILY ON HARDWARE AND SOFTWARE, NOT SUPPORTABILITY AND PRODUCIBILITY. Logisticians must drive themselves into the process early as part of the design team to define the requirements that may affect the design in a PBL product support/sustainment environment. PBL has yet to integrate into the Systems Engineering function
Slide 9

PBS-72

How do we meet that need with PBL?

We apply analysis to meet system performance objectives Do the homework We formally interface with design via calculated Supportability-Design-to-Requirements (SDTR) and Producibility-Design-To-Requirements (PDTR) We, logisticians, must design the support system to meet allocated Operational Requirements We must design the support system into the end item design We, Logisticians, must test and evaluate against our design criteria
Slide 10

Definition of Supportability
Supportability elements - major
Operational suitability Readiness In-flight and Operational sustainability Survivability Mobility/transportability Reliability and maintainability Human Factors System Safety

Energy Management
Standardization Interoperability Vulnerability Affordability Life-cycle cost, and lest we forget Availability (AO)

Slide 11

And This
Subordinate Supportability elements : 01- 09 support general codes - Work Unit Code reflects system data definition for historical data collection or for new systems 2) Preventive maintenance 3) Corrective maintenance 4) Resource consideration 5) Personnel requirements 6) Support equipment and facilities

Slide 12

PBS-58

WHAT ARE SUPPORTABILITY DESIGN CRITERIA?

Guidance says that success will be achieved if supportability and producibility requirements are embedded in the design for example:
Unit cost/weight MTBF/MTTR Maintainability Skill level Reduction Preventive maintenance reduction Hardware and Software documentation levels Reduced Training requirements Automated Testability/diagnostics/prognostics criteria Reparability at least cost - actually best value Designing Support equipment using Aircraft Standards, ETC.

BUT WHERE DO WE START?

Slide 13

Availability

Availability is a measure of the degree to which an item is in an operable state and can be committed at the start of a mission when the mission is called for at an unknown (random) point in time. Availability as measured by the USER is a function of: how often failures occur and corrective maintenance is required, how often preventative maintenance is performed,

how quickly indicated failures can be isolated and repaired,

how quickly preventive maintenance tasks can be performed, and how long logistics support delays contribute to down time. (DoD Guide for Achieving Reliability, Availability and Maintainability, August 3, 2005)

Slide 14

PBS-96

IPT ROLE IN PBL

Develop a Design that is Independent of the Logistics Infrastructure SELF-SUFFICIENCY

Establish Logistics Infrastructure Performance Requirements in initial Requirements Definition Establish performance metrics that provide a knowledge base for process, training, hardware and software Improvements

Provide a Contractor incentive program that is acceptable and do-able, such that the contractor has a profit incentive to improve readiness.

Slide 15

Requirements are Fundamental

For any Program: Development or Legacy (via ECPs) Development of Supportability and Producibility requirements must focus on reducing the logistics infrastructure (performance at best value) and should be: Substantive Understandable Feasible and rational Traceable and testable Timely and integrated early with design tools (CAD,CAM,CAE) Relevant to Cost as an Independent Variable (CAIV)
Requirements are NOT metrics, metrics are derived from

the specifications, as legacy systems discovered

The PBL IPT does this

Slide 16

PBL IPT
Establishing an IPT leadership role for the supportability and producibility engineers ensures each of the support disciplines and considerations for Support are balanced and cost effective before Systems Engineering and Design are involved.
This significantly reduces possible requirement contentions between disciplines. Empowered by decision support models, the supportability and producibility engineers can quickly ascertain the potential of proposed design improvements before stimulating a design response. The result of this process is a supportable design that enhances the prime mission system or equipments mission capability, but is also quite cost effective in reducing the support system and its infrastructure with increased capabilities. An additional and non-trivial benefit is that the producibility and supportability engineer can synergize their requirements in areas of mutual interest.

Slide 17

PBS-40

IPT must determine Performance Metrics

Evaluate existing and potential system/product option
operation at intended level, i.e., whats wrong and how to improve performance?

Decompose requirements to establish system design

parameters

Determine which design parameters drive supportability

and producibility metrics, based on an objective analysis of existing issues Establish objective and threshold values for each critical design parameter A Systems Engineering Activity
Slide 18

PBS-58

Pareto Analysis
A Pareto analysis of existing supportability and maintainability data on the system/product/service we are replacing or improving gives us definition of logistics down time high drivers Weighted or relative importance of elements for system being replaced or modified - Comparison Baseline Weighted or relative importance of elements that we want to see in the new systemThe New Project
THE PRIMARY FOCUS OF THE PBL IPT, THEN, IS TO

CLEARLY IDENTIFY WHAT WAS WRONG AND WHERE WE NEED TO PLACE DESIGN EMPHASIS

Slide 19

PBS-80

Performance Requirement Sample

Old design criteria resulted in removal and replacement of an aircraft break assembly to take 18 hours to accomplish. Pareto Analysis shows this to be one of the heavy hitters weighted criteria PBL IPT establishes a requirement to accomplish this same task on the new aircraft in six hours with four tools Customer bias provides input to do better Final requirement (design criteria) established is for the task to take only three hours with two tools Design criteria catalogued and provided formally to the Systems Engineer

Slide 20

PBS-32

PRIMARY SUPPORTABILITY DRIVERS

Reduce TOC: By reducing the cost to acquire, operate, sustain, and dispose of the system Increase REAL Equipment/System Availability:
By increasing the percent of time that the end item is available (Ma KPP) to perform its intended function while accomplishing a reduction in Support Event Frequency (f), Duration (d) and Cost (c)

Slide 21

Supportability (S) defined

Supportability must be optimized for maximum availability (KPP), reliability (KSA) and minimum Total Ownership Costs (KSA). Supportability is defined as :

The frequency of the support event where f = support event frequency (also includes reliability); i.e., how often will it occur?

The duration of the event where d = support event duration (also includes maintainability); i.e., how long is the event?

The cost of the event where c = support event cost (support system costs per event, e.g. all ILS elements); i.e., how much will it cost? SUPPORTABILITY IS AT ITS OPTIMUM WHEN S IS MINIMIZED, I.E., AS FREQUENCY, DURATION AND COST APPROACH ZERO.

Slide 22

PBS-16b

SYSTEMS ENGINEERING APPROACH

1

Requirements Definition

Evaluation & Improvement Product

Performance Metrics Product

Support

Support

Customer Needs
Product Production Support System Production
5

Product Design

Design in Criteria Product

Support

Support System Design

Supportability and Producibility are designed in, not analyzed in.

Slide 23

PBS-2

A NEW LOGISTICS PARADIGM Supportability is now defined (a shift in the paradigm): A metric that addresses every support event within the domain of the Integrated Logistics Support Elements, with respect to support event frequency, event duration, and event cost. Reflected in a composite, quantitative and qualitative characteristic of the supported system (project) to meet specified operational requirements for its intended life cycle, and is optimized for Total Ownership (TOC).
Slide 24

Design-to Data Base for STDR and PDTR is Pivotal to Success

Traceable
Data base captures SDTR and PTDR requirements as coded elements Each element tracks with each specific STDR and PDTR and must be traceable from concept through fielding and sustainment Coded elements are tracked and assessed at system design reviews along with, and equal to, hardware and software requirements SRR PDR DRR CDR TRR Assessment of design status to meet SDTRs and PDTRs is considered as Entry and Exit criteria for the design review Failure to meet anticipated status is grounds to delay design reviews or to result in unacceptable design reviews
Slide 25

Design-to Data Base for SDTR and PDTR is Pivotal to Success

Testable STDRs and PDTRs are included in the Test and Evaluation Master Plan (TEMP) and Supportability Strategy (SS) Assessment of development status to meet SDTRs and PDTRs should be considered as Entry and Exit criteria for any test event or evaluation:
Life Cycle Cost Evaluations Reliability Demonstration Tests Maintainability (BIT/Prognostics) Demonstrations Supportability/Logistics Demonstrations Initial Operational Test and Evaluation

Each coded element is evaluated for acceptable performance in development, test and evaluation, and operational assessment Failure to meet anticipated status is grounds to delay test events or to result in unacceptable and unsuccessful testing

Slide 26

THE SYSTEM ENGINEERING APPROACH

Enhanced IPT Interaction to integrate producibility

and supportability into the design - the PBL IPT function

System performance and cost are typically driven by a few

subsystems and components - the Pareto Analysis

Uniform Design Metrics are now embedded to evaluate

relationships between performance, design and cost - using Supportability Design-to requirements (SDTR) and Producibility Design-to requirements (PDTR) algorithms

Integrated Information to reduce support and production event

drivers - the design data base

Slide 27