Increasing Logistical Speed and Agility

Written by Mike Osborne

MLF 2010 Volume: 4 Issue: 2 (March)

 

In the last 20 years there have been numerous policies formulated that can be viewed as an attempt to increase the speed and agility of logistics to meet warfighter needs as fighting forces experience a shift from conventional to non-conventional warfare, while at the same time reducing life cycle costs/total ownership costs (TOC) of weapons systems. Program structures have changed to embrace total life cycle systems management (TLCSM), which designates the PM as the single point of accountability for the weapons system from cradle to grave. Performance based logistics (PBL) has become the preferred support strategy within TLCSM, requiring programs to buy weapons systems support as an integrated package rather than segmented functions. PBL is intended to take logistics from a transactional based strategy (repairs, spares, etc.) to an outcomes-based requirement for mission effectiveness through higher reliability and availability at an affordable cost.

PBL is progressing through various stages of development to meet warfighter needs. These stages are: delivery speed (supply chain services and distribution performance); materiel availability (logistics chain services and performance); operational availability (weapons system performance and whole systems availability); and mission assurance (mission performance and mission success). Multiple audits of programs that use a PBL strategy have revealed a mixed story of success in achieving the original performance objectives, but the most criticism has been levied against PBL cost effectiveness.

Many legacy programs under an initial PBL reporting mandate simply applied Lean Six Sigma techniques to already existing support structures and incentivized contractor logistics support providers with monetary awards for achieved performance, and reported success under limited PBL metrics. The need for improved product design to meet sustainment needs was hardly considered during this phase and was not readily apparent.

New acquisition programs have to live with a whole different set of circumstances, not the least of which is developing PBL strategies at a very early program milestone to meet all public-private partnership statutory requirements and constantly evolving regulatory policy and guidance. Indeed, the new DODI 5000.02 seems to recognize this and currently has two definitions for PBL—performance based logistics, and performance based life cycle product support (PBLCPS).

At this point, a short analogy on what might constitute the “L” in PBL and PBLCPS is warranted. Most folks have, at one time or another decided to make a large investment towards, trade in, or purchase a new automobile. At the core of this decision is a set of features, consciously or unconsciously arrived at, that drive the final acquisition: First, what was liked and disliked about the previous vehicle, how much scheduled and unscheduled maintenance did it require and why, how much time was tied up in the maintenance cycle, how simple was the unscheduled maintenance, etc. Major attention and thought, then, is given to the infrastructure, the footprint and the maintenance burden, while a set of requirements is developed towards the acquisition of the new vehicle.

Added to these requirements is the data gathering done by the manufacturer’s service departments as a result of reported malfunctions, and the corrective actions applied. These data and the customer purchases become a set of “degraders” and “enablers” that form the core of new vehicle design requirements. In other words, there is an understanding by the consumer and the manufacturer that each vehicle support event has three attributes—frequency, duration and cost— that must be considered, tracked, documented and analyzed in order to develop a set of coherent design requirements for performance and sustainment. This paradigm is just as pertinent to the majority of commercial product developers (aircraft, watercraft, trucks, motorcycles, etc.). This is a paradigm that DoD must emulate if there is to be any success with PBL and TLCSM.

The Weapon Systems Acquisition Reform Act of 2009 includes language to address problems with unreasonable performance requirements, by requiring DOD to reestablish systems engineering organizations and developmental testing capabilities; make trade-offs between cost, schedule and performance early in the program cycle; and conduct preliminary design reviews before giving approval to new acquisition programs. Lacking the profit incentive inherent in commercial enterprises, DoD has recently begun re-emphasizing the need for the systems engineering discipline. Language appears in the Defense Acquisition Guide which states: “The PM should reduce system downtimes and reduce total ownership costs through deliberate use of systems engineering analysis during the design phase to design out the maintenance burden, reduce the supply chain, minimize mission impacts and reduce the logistics footprint.”

The Department of Defense Reliability, Availability, Maintainability, and Cost Rationale Report Manual states in section 2-5 that “The PM should ensure that the frequency of occurrence (f), duration (d), and cost (c) elements of each degrader has been identified and captured in the baseline assessment, which should occur during the initial supportability analysis (S). The frequency of the degrader occurring is, of course, driven [to a great extent] by its reliability, by the duration of its maintainability attributes, and the cost of required labor/tools/test equipment to affect repair. This assessment, (S) = f x d x c, provides not only a realistic value to each disabler, but also provides the PM the visibility as to what the major cost drivers were in the system being base-lined.”

The Office of the Secretary of Defense Logistics & Materiel Readiness in 2008 established a group of senior government and industry personnel, the Product Support Assessment Team (PSAT), to assess and offer opportunities for improving product life cycle support. One finding declared “the logistics community fails to achieve effectively integrated and affordable warfighter operational readiness and instead remains focused on managing commodities, parts, and services.”

In summary, there is a push for systems engineering to step up to the “sustainment” plate early in program development, but no commensurate push to address the well-founded assertion that logisticians are still focused on post fielding infrastructure (publications, provisioning, training, spares, supply chain efficiencies, etc.) This is a significant disconnect. User-driven requirements are still focused on hardware and software performance and schedule. Systems engineering naturally concentrates on these during development, design reviews and tests—including a functional configuration audit (FCA)— whereas logistics support needs come along as a sort of afterthought. As the PSAT report also observes:

“Acquisition processes pay too little attention to supportability and consistently trade down-stream sustainability for required capability or program survival. Some program managers assert that logistics is their only discretionary account.” Governance of TLCSM is in reality split in half and becomes almost dysfunctional.

This article makes the assertion that due to the way the design requirements are developed and approved (capability development documentand specification), and support needs are requested (for the most part statement of work and contract data requirement list there can be no result other than a split program—it is inevitable given that process.

The PM will place emphasis and resources around the system design specification, and that is how the systems engineer will establish the engineering organization. There can be no effective sustainment at minimal cost unless there are deliberate sustainment design requirements levied on acquisition programs that are given the same focus and oversight as hardware and software design requirements (to include a systems engineering FCA). Critical to meeting this need, significant effort must be applied to a supportability analysis very early in the program pre-milestone A. That is key to developing sustainment design-to requirements, or, stated another way, a set of requirements for sustainment, that when presented to the design engineers through the requirements specification, becomes integrated (not “interfaced”) with the total system design.

Logisticians and systems engineers alike must be clear on the distinction between product support (publications, provisioning, training, spares, supply chain efficiencies, etc.) and product sustainment (infrastructure, footprint, and maintenance burden, each directly attributable to design features and characteristics). They are different and require different resources. Product support necessarily evolves and matures somewhat concurrently with the hardware and software design, as evidenced in the technical data package, but sustainment has to be an integral part of the hardware and software design. What follows next is a way to develop appropriate sustainment requirements that will drive TOC to a measureable minimum, and a process that will establish strong oversight of a program’s progress towards an optimal performance based sustainment solution throughout the program’s life cycle.

The supportability analysis should be performed against the system being replaced or modified using all available maintenance data. This data must be mined using the work unit code structure of the item being replaced or modified, with particular emphasis on gathering ‘when discovered,’ ‘how malfunctioned,’ and ‘action taken’ codes to determine the who, what, where, when and why maintenance activities occurred and determine the time recorded for each support event. This data mining will obviously include both failure related and non-failure related data (fueling, mission reconfiguration, calibration, towing, etc.) Sorting the results by applying Pareto techniques will clearly point out the areas of maintenance that require the most attention and will provide a baseline which exposes current ownership costs driven by the support events.

At the heart of the effort to analyze the results of the supportability analysis and develop sustainment requirements from this derived baseline is the supportability integrated process team (SIPT), led by a senior logistician performing the role of supportability engineer, who ensures that supportability concerns, lessons learned and requirements are integrated and balanced, and, when agreed to, are submitted to the design team. Membership of the SIPT must include core competencies in the basic ten integrated logistics support elements, representatives from the user community and an assigned design engineer. Consideration should be given to actually visiting maintenance sites to observe maintenance actions of interest and confirm the results of the Pareto analysis.

The SIPT output is a set of sustainment design-to requirements targeted at a reduction of the maintenance burden, the infrastructure and the logistics footprint. This by default reveals a calculation of a measureable reduction in TOC by comparing the baseline ownership costs against the aggregate of each targeted support event f/d/c components i.e., the new project baseline. The supportability analysis, including the Pareto and the algorithms used to calculate anticipated reductions in ownership costs, should be reportable in the program’s support strategy or life cycle support plan and be included in milestone B required documentation.

These sustainment requirements (supportability design-to requirements or SDTRs) are presented to the systems engineer by the SIPT, after careful deliberations, as design requirements to be integrated with the product design—to be tracked, reported and included in design reviews and audits concurrent with hardware and software requirements. This requires development of two sets of metrics, the first for measurement of systems engineering design success prior to milestone C, through traditional maintenance task analysis, and secondly, a set of sustainment metrics during engineering and manufacturing development and post-fielding.

These metrics are insufficient—the issue of governance remains. A more detailed criteria to measure a program’s progress is needed, now that the PM has a solid set of supportability requirements to meet. Similar to manufacturing readiness levels and technology readiness levels (TRLs), it is clear that the time has come to develop a hard set of requirements for sustainment called sustainment readiness levels (SRLs) that track with program design reviews (not milestones). Each SRL must be defined as to criteria to be met at each design review, and, since sustainment is not mature until significant time beyond milestone C, attainment of SRL criteria must extend all the way through fielding and post-fielding. Programs that fail to meet projected SRLs must elicit the same response from the milestone decision authority as those failing to meet required TRL levels, and must similarly formally respond.

In summary, this article suggests that a major cause of high ownership costs due to logistics, and the traditional “back seat” taken by logisticians and supported by PMs, is a lack of a vigorous DoD policy that requires each program to conduct a meaningful supportability analysis, the output of which is a set of reportable SDTRs that become an integral part of the system specification and are measured and tracked independently at design reviews throughout the program life using requirements-driven SRL criteria. Adoption of the methods outlined in this article will minimize total ownership costs by reducing the maintenance burden and the infrastructure, and by shrinking the logistics footprint. These methods will also eliminate some of the traditional stovepipe PM attitudes towards logistics by driving a longneeded reorganization within systems engineering. ♦

Mike Osborne is a logistics management specialist assigned to the U.S. Army PEO Missiles and Space logistics staff. His logistics career spans 45 years in all life cycle phases with U.S. Air Force, Navy and Army programs, and commercial development and production of military products. He is an advisor to the Council of Logistics Engineering Professionals (CLEP).

The author would like to acknowledge Rich Hausner of Northrop Grumman Corporation for his assistance in the preparation of this article.

Back to Top