MASTER SLIDE WTITLE PAGE

1
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)
2

• IF I HAD KNOWN THAT I HAD TO SUPPORT
• THIS THING, I WOULD HAVE DESIGNED IT
• DIFFERENTLY

Whining
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 ___ ___ ___ Saf
ety ___ ___ ___
7 Indicators Outcome based Report issues by
exception Relevant to warfighter

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

4
What was wrong with Ao??

• Ao addressed RM 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 IOTE
  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.

5
Whats the difference between Ao and Ma?

• Three big factors influence Operational
  Availability
• Reliability, Maintainability and ALDT
  (Administrative Logistics Down Time)
• RM 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.

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)

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.

8
New PBL Paradigm

• We have to reduce system downtimes and reduce OS
  costs through deliberate systems engineering to
  get rid of the logistics infrastructure
• And apply PBL criteria to what infrastructure is
  left

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

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

11
How do we meet that need with PBL?
PBS-72

• 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

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)

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 maintenance
• 3) Corrective maintenance
• 4) Resource consideration
• 5) Personnel requirements
• 6) Support equipment and facilities

14
WHAT ARE SUPPORTABILITY DESIGN CRITERIA?
PBS-58

• 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?

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)

16
IPT ROLE IN PBL
PBS-96

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

17
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

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

19
IPT must determine Performance Metrics
PBS-40

• 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
20
Pareto Analysis
PBS-58

• 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 TO
• CLEARLY IDENTIFY WHAT WAS WRONG AND WHERE WE NEED
  TO PLACE DESIGN EMPHASIS

21
Performance Requirement Sample
PBS-80

• 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

22
PRIMARY SUPPORTABILITY DRIVERS
PBS-32

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

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.

24
SYSTEMS ENGINEERING APPROACH
PBS-16b
1
Requirements
Definition
2
6
Performance
Evaluation
Metrics
Improvement
Product
Support
Product
Support
Customer
Needs
3
Design in
5
Product
Criteria
4
Product
Production
Design
Product
Support
Support
Support
System
System
Production
Design
Supportability and Producibility are designed
in, not analyzed in.
25
A NEW LOGISTICS PARADIGM
PBS-2

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

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

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

28

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