Presentation is loading. Please wait.

Presentation is loading. Please wait.

Slide 0 Reducing the Logistics Footprint within the PBL Construct - A Winning Strategy Mike Osborne, CPL, CCDM – CAS Inc., VP Education Council of Logistics.

Similar presentations

Presentation on theme: "Slide 0 Reducing the Logistics Footprint within the PBL Construct - A Winning Strategy Mike Osborne, CPL, CCDM – CAS Inc., VP Education Council of Logistics."— Presentation transcript:

1 Slide 0 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 AND DESIGN TEAM PRODUCIBILITY ENGINEER SUPPORTABILITY ENGINEER


3 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 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 Indicators Outcome based Report issues by exception Relevant to warfighter

4 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 eons…its 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 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??

5 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 System Downtime, both planned and unplanned; Inventory metrics plus Material Reliability and Total Ownership Costs associated with material readiness.

6 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 Ma = (0.70)

7 Slide 6 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.82) from Increasing MTBF only, results in an Ma of Decreasing MTTR only, results in an Ma of Decreasing MTTR and increasing MTBF results in an Ma of 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 Slide 7 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 …

9 Slide 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 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 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 Slide 9 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 Slide 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, 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 PBS-72

12 Slide 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 Slide 12 And This Subordinate Supportability elements : 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 Slide 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 Slide 14 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 Slide 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 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. PBS-96

17 Slide 16 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

18 Slide 17 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 Slide 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 Engineering Activity PBS-40

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

21 Slide 20 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 PBS-80

22 Slide 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) to perform its intended function while accomplishing a reduction in Support Event Frequency (f), Duration (d) and Cost (c) PBS-32

23 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 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 Slide 23 SYSTEMS ENGINEERING APPROACH 1 Requirements Definition Product Production Support System Production Product Design Support System Design Design in Criteria ProductSupport Performance Metrics ProductSupport Evaluation & Improvement ProductSupport Customer Needs Supportability and Producibility are designed in, not analyzed in. PBS-16b

25 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 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). PBS-2

26 Slide 25 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 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 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 Slide 27 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

Download ppt "Slide 0 Reducing the Logistics Footprint within the PBL Construct - A Winning Strategy Mike Osborne, CPL, CCDM – CAS Inc., VP Education Council of Logistics."

Similar presentations

Ads by Google