[Themaintainers] Whither the field of life cycle logistics?

Lee Vinsel lee.vinsel at gmail.com
Thu Jan 17 13:40:58 EST 2019


John,

Thanks so much for this fascinating email, which led to several
conversations in circles I run in.

There are a few different threads in your message, but the one that stood
out most to me is about education. Andy Russell and I have written a paper
for a forthcoming volume
<https://static1.squarespace.com/static/56a8e2fca12f446482d67a7a/t/5a0dc2cc24a694de8ecb0077/1510851277228/Making+Maintainers+Preprint.pdf>
that
explores some related issues with maintenance, I think. We start with a
fact that David Edgerton and others have emphasized: that engineering
professional bodies tend to trumpet instances of invention and innovation,
but in fact something like 70% of graduating engineers will go into jobs
where they will oversee and maintain existing systems. Are engineering
students being taught how to handle operations and maintenance? Not very
often actually. Indeed, some engineering programs, including Stevens
Institute of Technology where I used to teach, focus on innovation and
entrepreneurship. So the question is: how can we align the education system
with what students will actually be doing in the world (including showing
students how valuable that work is for society)?

There is one confounding factor, which has to do with specialization. That
is, engineers and others graduate and go into all kinds of jobs that
require all kinds of specialized knowledge. Logistics, maintenance, and
standardization (another topic I've thought and worked on a lot) are things
young people learn on the job. BUT, first, we could, probably should,
expect engineering programs to move further towards these kinds of
operational skills. And, second, we could ask real questions about whether
there are enough of the right kinds of post-college training programs to
get these specialized knowledges taught.

One final thought about R&D: it's interesting to think about R&D in
logistics and where it is(n't) happening. My naive instinct is that Amazon,
for example, is doing a lot of R&D in logistics - probably a great deal
more D than R - but that knowledge is proprietary and probably isn't
traveling far. So again, there seem to be real questions about
organizational infrastructure and knowledge sharing.

We are bumping into these same questions ALL THE TIME when thinking about
maintenance. And the grant we recently got from the Alfred P. Sloan
Foundation is enabling us to START working towards answers/solutions. We
have a long way to go.

Thanks again for your interesting note.

Lee

On Fri, Jan 11, 2019 at 10:56 AM Burns, John J CIV NAVAIR, AIR-6.7.5.3 <
john.j.burns at navy.mil> wrote:

> All,
>
> Firing one for effect...that is to say, I'm keen to get feedback from
> members of this group.  I'm going to say some things here that reflect what
> I'm experiencing and what I know.  I acknowledge my experience is limited
> and my knowledge similarly so.  I can (I believe) be educated!
>
> Background:
>
> I was trained as a developmental psychologist and have spent my entire
> career working for the United States Navy and in the field of training
> (25+years).  Starting out in R&D, I moved over time to acquisition of
> training.  I currently work as a Department of the Navy civil servant in a
> logistics department for the Naval Aviation System Command.  My views, are
> of course, my own.
>
> The DoD acquisition system is a complicated business.  In the interest of
> writing a post here and not a novel, I'll simplify things a bit to say that
> with respect to our systems (e.g., aircraft, ships, submarines, radars,
> etc.) we in the Naval Aviation Enterprise, assign technical responsibility
> for acquisition of the system to one group--call this the "Engineering
> Department"--while technical responsibility for the "stuff and things that
> will support the system" are assigned to another group--call this one the
> Logistics Department.
>
> Current Situation:
>
> With respect to capabilities, we have some amazing systems.  This speaks
> to the quality of our engineers and our engineering department.  If time,
> budget, sustainment, and sustainability were not of concern, I'd suggest
> that the "Engineering Department" is doing fine.  Of course, these factors
> are of great concern and so I can say with confidence that the "Engineering
> Department" is keenly aware that they need to improve upon their processes
> & products.
>
> However, I am not in the Engineering Department, I'm in the Logistics
> Department.  How are we doing?  Since you asked...Not well.  Across the
> Navy we're having difficulty sustaining our systems.  The most acute
> manifestation of this challenge is expressed in terms of readiness.  Are we
> ready with the systems that I have described?  Suffice to say that this is
> a significant challenge across the Navy.
>
> How can this be you ask?  Don't we have a "process" or a "set of
> process".  Indeed, we do.  There are a number of "terms/constructs" that
> describe what we do but, here's the essence as I have come to understand
> it.  "Design the support and support the design."  I can break this down a
> bit more...
>
> A weapon system requires many things to enable us to realize its
> capabilities.  We can characterize these as "support" elements.  In fact,
> DoD has broken this down (see MILHDBK-502A Product Support Analysis) into
> 12 "Integrated Product Support" (IPS) elements:
>
>         - Product Support Management
>         - Supply Support
>         - Training & Training Support
>         - Computer Resources
>         - Facilities & Infrastructure
>         - Maintenance Planning & Management
>         - Packaging, Handling, Storage, and Transportation (PHS&T)
>         - Technical Data (think manuals)
>         - Manpower (how many) & Personnel (what type of people)
>         - Support Equipment
>
> What makes these elements "integrated"?  Bit of an over-simplification
> but, true I think--these elements "interact" such that changes in one, will
> impact one or more of the others.  As for processes, as noted, we've got
> those.  I'll copy 'em in from MILHDBK-502A below for the sake of
> completeness:
>
> Activity 1 - Product Support Strategy, Establish the initial maintenance
> concept
> Activity 2 - Product Support Planning, Develop the Product Support
> Analysis Plan (PSAP)
> Activity 3 - Program & Design Reviews, Establish requirements for SETRs
> and PSA TIMs
> Activity 4 - Application, Develop the Use Study
> Activity 5 - Support System Standardization, Establish requirements for
> Hardware/ Software Standardization
> Activity 6 - Comparative Analysis, Develop the BCS and conduct Comparative
> Analysis
> Activity 7 - Technological Opportunities, Identify Potential New
> Technology
> Activity 8 - Supportability & Supportability-Related Design Factors,
> Identify impact on operations and support capabilities, risks and data
> rights issues
> Activity 9 - Functional Requirements, FMECA, RCM , FTA, Task Inventory,
> Design          Alternatives
> Activity 10 - Support System Alternatives, Alternatives and Plans
> Activity 11 - Evaluation of Alternatives and Tradeoff Analysis, Level of
> Repair Analysis
> Activity 12 - Task Analysis, Maintenance Task Analysis results
> Activity 13 - Early Distribution Analysis, Readiness Impacts
> Activity 14 - Diminishing Manufacturing Sources & Material Shortages
> Management (DMSMS)/Obsolescence System Support Analysis Plan
> Activity 15 - Field Feedback, Supportability and Supportability related
> data from the Fleet
> Activity 16 - Disposal Analysis, Disposal Plan
> Activity 17 - Operational Suitability Test, Evaluation, Verification &
> Validation, Test Strategy
>
> But, the particulars of these processes are not what I'm soliciting
> feedback on, rather, I've noted I'm in the "Logistics Department" and that
> we have defined set of processes (the MILHDBK 502A).  So too do our
> colleagues over in the Engineering Department.  However, they also have a
> professional infrastructure that it seems to me is sadly lacking in
> logistics.   What I mean by infrastructure here is... Departments at
> colleges and universities that train engineers and systems engineers,
> professional societies that encourage active empirical work to advance the
> field (e.g., INCOSE and The Journal of Systems Engineering along w/IEEE and
> other organizations and publications).  My reading of our field (logistics)
> is we lack this.  Bit of digging turns up:
>
>         - The Council of Logistics Engineering Professionals (CLEP):
> http://logisticsengineers.org
>         - The International Society of Logistics--SOLE:
> http://www.sole.org/
>
> But a visit to the websites above indicates that these are not "beehives
> of professional activity" and I don't see the professional journals.  And
> while I understand that "Supply Chain Management" and other undergrad and
> graduate-level programs are offered, these seem to be in business schools
> and/or in engineering schools.  I ask, is there a field of logistics if we
> lack a professional infrastructure?  As noted, while we have defined
> processes and a real need to develop and support systems, we're not doing
> this well.  Thus, I think we need one.  Further, and this is a completely
> parochial observation, I'd suggest that we re-brand ourselves as "Product
> Support Engineers" and our discipline as "Product Support Engineering".
>
> I make this bold assertion because it seems clear that we are in fact,
> engineers.  That is, our charge is to conceptualize, design, test,
> implement, and modify product support.  Moreover, this isn't a "point in
> time" challenge, it's about engineering socio-technical systems that will
> interact w/other socio-technical systems.  Finally, if our processes are
> connected, at the level of data, with what our colleagues over in the
> Engineering Department are doing, then, well, we're doing it wrong.
>
> When I look back for the R&D that supports my discipline...I "hear
> crickets".  Far as I can tell, we're flat out not training anybody to do
> this in our engineering schools or in any universities.
>
> Standing by for feedback.  V/r--John
>
> John Burns
> Fleet Maintenance and Training Systems Support Division
> (301) 342-6292
> 47013 Hinkle Circle
> Patuxent River, MD 20670-2942
>
> **** NOTICE: This email may contain SENSITIVE Unclassified DoD information
> that has not been approved for public release.  It is intended only for the
> use of the individual or entity to which it is addressed. If you received
> this communication in error, please delete the message.  Thank you.
>
>
> _______________________________________________
> Themaintainers mailing list
> Themaintainers at lists.stevens.edu
> https://lists.stevens.edu/mailman/listinfo/themaintainers
>


-- 
Assistant Professor
Department of Science, Technology, and Society
Virginia Tech
leevinsel.com
Twitter: @STS_News
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20190117/fd3c4da2/attachment.html>


More information about the Themaintainers mailing list