Slide 1

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

Mike Osborne, CPL, CCDM – CAS Inc.,VP Education

Council of Logistics Engineering Professionals (CLEP)

SYSTEM ENGINEERING ANDDESIGN TEAM

PRODUCIBILITY ENGINEER SUPPORTABILITY ENGINEER

Slide 2

“IF I HAD KNOWN THAT I HAD TO SUPPORT

THIS THING, I WOULD HAVE DESIGNED IT

DIFFERENTLY”

Whining

Slide 3

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

Forecast/ Goal 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 ___ ___ ___

− Goals determined by Services for legacy systems− Established as KPPs for new systems

7 IndicatorsOutcome basedReport issues by exceptionRelevant to warfighter

Slide 4

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 eons…it’s 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 available…we 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.

What was wrong with Ao??

Slide 5

What’s 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 6

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_____ = 226 _____ = ___226__

MTBF + MTTR +MLDT 226 + 2.83 + 96 324.83

Ma = 0.695749 (0.70)

Slide 7

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 8

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 9

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 include…characteristics such as ‘openness of design, upgradeability, modularity, and testability’, and ‘designing for producibility’

BUT

That is not strong enough – PMs and Systems Engineers still don’t get it - the stool now has three legs, Hardware, Software and Logistics (sustainment) designed-in requirements.

Our logisticians either don’t know how to do this, or don’t have

the detailed backing in directives and policy.

Slide 10

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 11

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

PB

S-72

Slide 12

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 13

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 maintenance3) Corrective maintenance4) Resource consideration5) Personnel requirements6) Support equipment and facilities

Slide 14

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?

PB

S-58

Slide 15

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 16

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.

PB

S-96

Slide 17

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

Requirements are Fundamental

Slide 18

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 equipment’s 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 19

IPT must determine Performance Metrics

• Evaluate existing and potential system/product option operation at intended level, i.e., what’s 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

PB

S-40

Slide 20

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 system- The New Project

THE PRIMARY FOCUS OF THE PBL IPT, THEN, IS TOCLEARLY IDENTIFY WHAT WAS WRONG AND WHERE WE NEED

TO PLACE DESIGN EMPHASIS

PB

S-58

Slide 21

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

PB

S-80

Slide 22

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)

PB

S-32

Slide 23

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 24

SYSTEMS ENGINEERING APPROACH

1Requirements

Definition

ProductProduction

SupportSystem

Production

ProductDesign

SupportSystemDesign

Design inCriteria

Product Support

PerformanceMetrics

Product Support

Evaluation &Improvement

Product Support

CustomerNeeds

2

35

4

6

Supportability and Producibility are designed in, not analyzed in.

PB

S-16b

Slide 25

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).

PB

S-2

Slide 26

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 27

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 28

•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

THE SYSTEM ENGINEERING APPROACH