_Reducing the Infrastructure in a PBL Osborne-Part1 -Short Version

7/27/2019 _Reducing the Infrastructure in a PBL Osborne-Part1 -Short Version

1/28

Slide 0

Reducing the Logistics Footprint within the PBLConstruct - A Winning Strategy

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

Council of Logistics EngineeringProfessionals (CLEP)

SYSTEM ENGINEERING ANDDESIGN TEAM

PRODUCIBILITY ENGINEER SUPPORTABILITY ENGINEER


2/28

Slide 1

IF I HAD KNOWN THAT I HAD TO SUPPORT

THIS THING, I WOULD HAVE DESIGNED IT

DIFFERENTLY

hining


3/28

Slide 2

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 Goalsand 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 based

Report issues by exception

Relevant to warfighter


4/28

Slide 3

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

What was wrong with Ao??


5/28

Slide 4

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 SystemDowntime, both planned and unplanned; Inventory

metrics plus Material Reliability and Total Ownership

Costs associated with material readiness.


6/28

Slide 5

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)


7/28Slide 6

MATERIAL AVAILABILITY AS A

KEY PERFORMANCE PARAMETER

EXAMPLE OF COMPUTATION OF SYSTEM LEVEL Ma USING OBJECTIVEPARAMETERS 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

Conclus ion: Mean Log ist ics Down Time (MLDT) is th e most cr i t ica lmetr ic in inc reasing Ma. Inc rease of Ma from 0.70 to 0.82 ispredom inant ly due to stream l in ing Log ist ics Respon se.


8/28Slide 7

New PBL Paradigm

We have to reduce system downt imes and

reduce O&S costs through deliberate

systems eng ineer ing to get r id of the

logistics infrastructure

And apply PBL c r i ter ia to what infrastructureis left


9/28Slide 8

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 ofsupportability through

application of the System Operational Effectiveness model, and

Inclusion of logistics support considerations in detailed designreviews 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- inrequirements.

Our logisticians either dont know how to do this, or dont have

the detailed backing in directives and policy.


10/28Slide 9

What is missing from all this is

Needs of the Maintainer

We discuss everything about PBL EXCEPT how to design-insupportability and producibility; therefore:

If we are ever to reduce the logist ics in frastructu re, we must

def in i t ize the Log ist ics requ irements to the Systems Engineers

pr iorto pro duct design start , and enforce equal design

con siderat ion w ith hardware and softw are requirements.

Our PMs must understand that, our systems engineers mustdo that, and logisticians need to insist on it.

SYSTEMS ENGINEERS ARE STILL FOCUSED PRIMARILY ONHARDWARE AND SOFTWARE, NOT SUPPORTABILITY AND

PRODUCIBILITY.

Logisticians must drive themselves into the process early as partof the design team to define the requirements that may affect thedesign in a PBL product support/sustainment environment.

PBL has yet to integrate into the Systems Engineering function


11/28Slide 10

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, mustdesign 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

ourdesign criteria

PBS-72


12/28Slide 11

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)


13/28Slide 12

And This

Subordinate Supportability elements :

01- 09 support general codes - Work Unit Code reflectssystem 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


14/28Slide 13

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?

PBS-58


15/28Slide 14

Availability

Availability is a measure of the degree to which an item is in anoperable state and can be committed at the start of a missionwhen the mission is called for at an unknown (random) point intime. Availability as measured by the USERis 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 andMaintainability, August 3, 2005)

P


16/28Slide 15

IPT ROLE IN PBL

Develop a Design that is Independent of the

Logistics Infrastructure SELF-SUFFICIENCY

Establish Logistics Infrastructure Performance

Requirements in initial Requirements DefinitionEstablish performance metrics that provide a

knowledge base for process, training, hardware

and software Improvements

Provide a Contractor incentive program that isacceptable and do-able, such that the contractor

has a profit incentive to improve readiness.

PBS-96


17/28Slide 16

ForanyProgram: Development or Legacy (via ECPs)

Development of Supportability and Producibilityrequirements must focuson reducing the logistics

infrastructure (performance at best value) and should be:Substantive

UnderstandableFeasible and rational

Traceable and tes table

Timely and integrated earlywith design tools(CAD,CAM,CAE)

Relevant to Cost as an Independent Variable (CAIV)

Requirements are NOT metrics, metrics are derived fromthe specifications, as legacy systems discovered

The PBL IPT does this

Requirements are Fundamental


18/28Slide 17

PBL IPT

Establishing an IPT leadership role for the supportability and

producibility engineers ensures each of the support disciplinesand considerations for Support are balanced and cost effectivebefore Systems Engineering and Design are involved.

This significantly reduces possible requirement contentions betweendisciplines.

Empowered by decision support models, the supportability andproducibility engineers can quickly ascertain the potential ofproposed design improvements before stimulating a design response.

The result of this process is a supportable design that enhances theprime mission system or equipments mission capability, but is alsoquite cost effective in reducing the support system and its

infrastructure with increased capabilities.

An additional and non-trivial benefit is that the producibility andsupportability engineer can synergize their requirements in areas ofmutual interest.

P


19/28Slide 18

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 Engineer ing Ac t iv i ty

PBS-40

P


20/28Slide 19

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

PBS-58

P


21/28Slide 20

Performance Requirement Sample

Old design criteria resulted in removal and replacement ofan 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 sametask 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

PBS-80

P


22/28Slide 21

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) toperform its intended function whileaccomplishing a reduction in Support Event Frequency (f ),

Duration (d )and Cost (c )

PBS-32


23/28

Slide 22

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 of ten w i l l i t 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 w i ll

i t cost?

SUPPORTAB ILITY IS AT ITS OPTIMUM WHEN S IS MINIMIZED,

I.E., AS FREQUENCY, DURATION AND COST APPROACH ZERO.

PB


24/28

Slide 23

SYSTEMS ENGINEERING APPROACH

1Requirements

Definition

ProductProduction

SupportSystem

Production

ProductDesignSupportSystemDesign

Design inCriteria

Product Support

PerformanceMetrics

Product Support

Evaluation &Improvement

Product Support

CustomerNeeds

2

35

4

6

Supportability and Producibility

are designedin, not analyzedin.

BS-16b

PB


25/28

Slide 24

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 LogisticsSupport Elements, with respect to support event

frequency, event duration, and event cost.

Reflected in a composite, quantitative and

qualitative characteristic of the supportedsystem (project) to meet specified operational

requirements for its intended life cycle, and is

optimized for Total Ownership (TOC).

BS-2


26/28

Slide 25

Design-to Data Base for STDR and PDTR is Pivotal

to SuccessTraceable

Data base captures SDTR and PTDR requirements as codedelements

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 softwarerequirements

SRR

PDR

DRR

CDRTRR

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


27/28

Slide 26

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 indevelopment, 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


28/28

Enhanced IPT Interaction to integrate producibility

and supportability into the design - the PBL IPT funct io n

System performance and cost are typically driven by a few

subsystems and components - the Pareto An alysis

Uniform Design Metrics are now embedded to evaluate

relationships between performance, design and cost - us ing

Supportabi l i ty Design-to requirements (SDTR) and Producibi l i tyDesign-to requirements (PDTR) algor i thm s

Integrated Information to reduce support and production event

drivers - the design data base

THE SYSTEM ENGINEERINGAPPROACH

_Reducing the Infrastructure in a PBL Osborne-Part1 -Short Version

Documents

Transcript of _Reducing the Infrastructure in a PBL Osborne-Part1 -Short Version