<div dir="ltr">John,<div><br></div><div>Thanks so much for this fascinating email, which led to several conversations in circles I run in. </div><div><br></div><div>There are a few different threads in your message, but the one that stood out most to me is about education. <a href="https://static1.squarespace.com/static/56a8e2fca12f446482d67a7a/t/5a0dc2cc24a694de8ecb0077/1510851277228/Making+Maintainers+Preprint.pdf">Andy Russell and I have written a paper for a forthcoming volume</a> 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)?</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Thanks again for your interesting note. </div><div><br></div><div>Lee</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 11, 2019 at 10:56 AM Burns, John J CIV NAVAIR, AIR-6.7.5.3 <<a href="mailto:john.j.burns@navy.mil">john.j.burns@navy.mil</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
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!<br>
<br>
Background:<br>
<br>
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.<br>
<br>
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. <br>
<br>
Current Situation:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
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:<br>
<br>
- Product Support Management<br>
- Supply Support<br>
- Training & Training Support<br>
- Computer Resources<br>
- Facilities & Infrastructure<br>
- Maintenance Planning & Management<br>
- Packaging, Handling, Storage, and Transportation (PHS&T)<br>
- Technical Data (think manuals)<br>
- Manpower (how many) & Personnel (what type of people)<br>
- Support Equipment<br>
<br>
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:<br>
<br>
Activity 1 - Product Support Strategy, Establish the initial maintenance concept<br>
Activity 2 - Product Support Planning, Develop the Product Support Analysis Plan (PSAP) <br>
Activity 3 - Program & Design Reviews, Establish requirements for SETRs and PSA TIMs<br>
Activity 4 - Application, Develop the Use Study<br>
Activity 5 - Support System Standardization, Establish requirements for Hardware/ Software Standardization <br>
Activity 6 - Comparative Analysis, Develop the BCS and conduct Comparative Analysis <br>
Activity 7 - Technological Opportunities, Identify Potential New Technology <br>
Activity 8 - Supportability & Supportability-Related Design Factors, Identify impact on operations and support capabilities, risks and data rights issues<br>
Activity 9 - Functional Requirements, FMECA, RCM , FTA, Task Inventory, Design Alternatives <br>
Activity 10 - Support System Alternatives, Alternatives and Plans<br>
Activity 11 - Evaluation of Alternatives and Tradeoff Analysis, Level of Repair Analysis <br>
Activity 12 - Task Analysis, Maintenance Task Analysis results<br>
Activity 13 - Early Distribution Analysis, Readiness Impacts <br>
Activity 14 - Diminishing Manufacturing Sources & Material Shortages Management (DMSMS)/Obsolescence System Support Analysis Plan <br>
Activity 15 - Field Feedback, Supportability and Supportability related data from the Fleet<br>
Activity 16 - Disposal Analysis, Disposal Plan <br>
Activity 17 - Operational Suitability Test, Evaluation, Verification & Validation, Test Strategy<br>
<br>
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:<br>
<br>
- The Council of Logistics Engineering Professionals (CLEP): <a href="http://logisticsengineers.org" rel="noreferrer" target="_blank">http://logisticsengineers.org</a><br>
- The International Society of Logistics--SOLE: <a href="http://www.sole.org/" rel="noreferrer" target="_blank">http://www.sole.org/</a><br>
<br>
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". <br>
<br>
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. <br>
<br>
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. <br>
<br>
Standing by for feedback. V/r--John<br>
<br>
John Burns<br>
Fleet Maintenance and Training Systems Support Division<br>
(301) 342-6292<br>
47013 Hinkle Circle<br>
Patuxent River, MD 20670-2942<br>
<br>
**** 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.<br>
<br>
<br>
_______________________________________________<br>
Themaintainers mailing list<br>
<a href="mailto:Themaintainers@lists.stevens.edu" target="_blank">Themaintainers@lists.stevens.edu</a><br>
<a href="https://lists.stevens.edu/mailman/listinfo/themaintainers" rel="noreferrer" target="_blank">https://lists.stevens.edu/mailman/listinfo/themaintainers</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Assistant Professor <br>Department of Science, Technology, and Society<br></div><div>Virginia Tech<br></div><div><a href="http://leevinsel.com" target="_blank">leevinsel.com</a><br>Twitter: @STS_News<br></div></div></div></div></div></div></div></div></div></div></div></div></div>