the logista - ale.com dec 2017.pdf · vides tips for avoiding the five biggest pitfalls in...
TRANSCRIPT
1
The LogistaVolume 7, Issue 4 | December 2017
CONTENTS
Pitfalls of Developing Logistics Product Data [& how to avoid them] (P. 2)
Warning: Confirmation Bias at Work (P. 6)
Staff Member Spotlight: W. Ben McKenzie (P. 7)
Dear Readers,
It’s hard to believe we are approaching the end of another year. We have had the privilege this
past year to work on many exciting projects with customers across the United States – including
developing Logistics Product Data on Navy radar systems, performing product support analysis for
a prominent Army engine program, and accomplishing reliability analyses on a Coast Guard C4
system. What makes ALE such a unique company is the variety of projects, scope, and valuable
experience gained on each program which allows us to better integrate processes and identify
synergies. We are thankful and honored that you continue to think of ALE to fill your life cycle and
specialty engineering needs.
This issue of The Logista includes two articles on very different but practical topics. The first pro-
vides tips for avoiding the five biggest pitfalls in developing Logistics Product Data. The second ar-
ticle discusses the human factors issue of confirmation bias, which is present in everything from
reading the local newspaper to reading system requirements.
We wish you and your families a wonderful holiday season and a new year filled with peace and
happiness. Thank you for your continued readership and business.
Happy Holidays,
Renee and Joe Coogan
CAGE code: 1Z220 | Dun & Bradstreet: 16-125-2218 | NAICS: 541330, 541614, 541715 | WOSB | Seaport-e Prime Contract Holder
ALE Central Ohio Office: 6797 North High St, Suite 324, Worthington, OH 43085 | P (614) 436-1609 | E [email protected]
ALE Gulf Coast Office: 4850 Gautier-VanCleave Rd, Suite 3, Gautier, MS 39553 | P (228) 522-1522
2
1. CONFIGURATION CHANGES ANYONE?
Every Logistics Analyst knows a system has a configuration which is the basis of their logistic work. The system configu-
ration identifies the systems, sub-systems, and piece parts to be addressed. Imagine performing the majority of an LPD
analysis using a specific configuration only to receive an e-mail from the customer stating that the configuration has
changed. Anyone that has experienced this scenario knows that it can be complicated dealing with reworking your
analysis to develop LPD for the changed entities and update any data indirectly impacted. These configuration changes
can be voluminous or minute – but no matter the size, your analysis must be updated to ensure the proper support
arrangement.
As you know, and as can be expected, the rework involved in updating LPD can get expensive. So how can you stop (or
limit) these negative impacts that system configuration changes have on LPD development?
Communicate with your customer! Come to an agreement on a specific system configuration down to the revision
level of the piece parts. At first this may seem like an obstacle in negotiation, but it’s actually within the best interest of
both your LPD team and the customer. Agreeing on a system configuration for LPD development allows your LPD team
to work uninterrupted on the system as a whole. There will be no reworking of the analysis due to changing system
components or “creep” due to the addition of components. Locking the system configuration for the customer ensures
no extension of deadlines and keeps the project on budget. An agreement on the system configuration should be sold
and viewed as a win-win for you and the customer.
2. KEEP YOUR EYE ON THE MAINTENANCE CONCEPT (AND THOSE SMR CODES)
As an LPD analyst, you live and die by the Maintenance Concept, which defines how and where a system is maintained.
Source, Maintenance, and Recoverability (SMR) codes are standardized codes (contained in the LSA-024 report) that
(Continued on page 3)
Pitfalls of Developing Logistics Product Data [& how to avoid them] By Zach Pusnik
Have you ever had a project you were working on get cancelled? Have you ever received
a revision to a project that you were working on that left gaping omissions? Have you
ever been asked to produce a report with source data that is not sufficient? Have you
ever longed for a different software tool to accomplish a task at hand? Or felt burnt out
scouring through endless engineering drawings for data? Today, my fellow logistics
analysts, I would like to take a couple minutes of your time to explore how to avoid or
mitigate these pitfalls in a Logistics Product Data (LPD) development environment.
3
represent the maintenance concept. It is not uncommon while working an LPD program for a customer to want to make
changes to SMR codes. Changing the SMR code requires changing the maintenance concept too. When the maintenance
concept is changed you are effectively changing every aspect of LPD for that item. Labor tasks, provisioned parts, sup-
port equipment, and tooling are just some examples of LPD entities that need reviewed when a maintenance concept or
SMR code change occurs.
So what’s the best tactic to minimize changes to the maintenance concept and SMR codes when your analysis is under
way? Again, good communication and partnering with the customer during an initial review of the source data and
maintenance concept is a key to solidifying the path forward. It is critical that the maintenance concept is analyzed and
any inconsistencies or suggested changes are surfaced, discussed, and accepted by the customer before proceeding any
further with the LPD analysis. Likewise, SMR codes must always agree with the maintenance concept. You cannot
change one without changing the other. When the maintenance concept is agreed upon so are the SMR codes.
Agreement on the maintenance concept and SMR codes keeps the LPD project on time and on budget for the customer.
Additionally, an agreed upon maintenance concept allows analysts to work more efficiently through their analysis
because they don’t have to back track and rework a previously completed entity due to changes in the maintenance
concept or to SMR codes.
3. THE 4 CERTAINTIES IN AN LPD ANALYST’S LIFE: DEATH, TAXES, CHANGE, AND INADEQUATE SOURCE DATA
LPD can be generated or reviewed on a system at various times during a system’s lifespan. You’ll receive a wide variety
in the type and quality of source data. You can expect to receive engineering drawings, BOMs, technical manuals,
assembly test procedures, even that occasional unofficial “official” assembly procedure or parts list. With all these
sources of data, what revisions or versions of them do you use for analysis? What do you do if you can’t find the infor-
mation you need to complete part of your analysis?
The first thing that you can do to address inconsistencies in source data is to adapt your mindset to the fact that your
analysis is only going to be as accurate and thorough as your source data. Don’t get stressed out over your source data
because it is usually beyond your control. Leverage constant communication between the LPD Team Lead, Project
Manager, and Customer to resolve missing or inconsistent source data. Discussing the impacts that inadequate source
data will have on the timeline or results of a deliverable often motivates the customer to get you the data you need to
complete an accurate analysis.
When dealing with discrepancies between multiple types or revisions of source data, it is best to pick the most current
or latest version of engineering data to shape your analysis. The latest revisions will most accurately display the current
configuration, maintenance concept, and piece part information of the item or system under analysis. Using legacy
versions of LPD data leads to rework so watch revision letters on drawings!
A final suggestion you can use to mitigate source data concerns is to pay attention to notes on engineering drawings and
in technical manuals. These notes often are the source data you are looking for. Drawing notes, in particular, provide
(Continued from page 2)
(Continued on page 4)
4
information on attaching hardware, repair equipment, repair standards, part numbers and even describe repair or
assembly procedures! The devil is in the details, and those details are the drawing notes.
4. FINDING A BETTER WAY THROUGH LOGISTICS PRODUCT DATA TOOLS
For every task there is a best tool for the job. In the world of LPD development, there are many adequate free and sub-
scription-based tools. A couple of the free tools include PowerLOGJ-2, an LPD database software system managed by
the U.S. Army’s Logistic Support Activity, and an online search system for piece part information called “PubLogFLIS,”
which is managed by the Defense Logistics Agency and the Federal Logistics Information Service. Free tools can be ade-
quate for your LPD needs but may not be the most efficient tool for the job. Free services often lack configurability,
stability, and ease of use which leads to inefficiency when researching and documenting LPD data.
There are a couple of subscription-based commercial LPD tools that provide benefits not available in their freeware
counterparts. Many commercial database systems feature modules that allow you to configure your data to different
logistic standards like GEIA-STD-0007 and MIL-STD-1388-2B. This benefits data importation as you can set up excel
spreadsheets with logistics data in 2B and 0007 format, load it into the database, and have the data stored and dis-
played correctly in the database. The database interface also allows you to simultaneously enter LPD information for
an item while entering item repair tasks. This is accomplished by providing multiple linked windows for simultaneous
data entry. This means you can enter support equipment information, and spare part information much more effi-
ciently than by manually navigating to each of these LPD database entities and then manually entering the correspond-
ing information as you have to do with the free tools.
Subscription based defense parts and management systems contain a wealth of logistics and provisioning information
for piece part items. One of the subscription-based system’s main advantages over free tools is that you can import a
list of items into the software to be looked up all at once. Most free tools can only look up items on an item by item
basis. Subscription-based systems typically offer more comprehensive information about piece part items than their
free counterparts. While there is a cost associated with subscription-based tools, the increased efficiency and im-
proved quality can quickly help the systems pay for themselves.
5. FLAT OUT, BURNT OUT.
Experiencing periods of burnout is common for a logistics professional in such a detailed analysis environment. Consist-
ently spending full days visually traversing engineering drawings, technical manuals, BOMs, and computer screens for
months on end will have an impact on your accuracy and your efficiency. With all that black and white it’s easy to mis-
read a part number or SMR code. This feeling of “burn out” can also negatively affect the morale of your LPD team. So
how can you stay fresh when slugging through the information jungle of an LPD project?
Combat LPD burn out by giving your eyes a couple breaks during the day. Take 5 minutes to focus on a newspaper,
magazine, or digital article on your smart phone. A change of topic, some screen color, or a different screen size can
help your mind and eyes feel refreshed. Get up out of your seat and take a quick stroll around your floor, up and down
some stairs, or outside (if the weather permits). Walking gets your heart rate up, the blood flowing, and helps combat
(Continued from page 3)
(Continued on page 5)
5
that feeling of sleepiness that seems to sneak up on you after a good lunch. Last but not least, go out to eat. (Or see if
you can get your LPD team together for a lunch outing.) A change of scenery with some teammates is a good way to
get people smiling again and gets you away from your desk for an hour. Just don’t get too greedy utilizing these
strategies…
BONUS TIP: SKILLS TO LOOK FOR IN LPD ANALYST CANDIDATES
LPD is a unique and peculiar field. Most colleges don’t have a major for it, in fact they don’t teach it at all. So where do
you go to find LPD Analysts? One strategy to finding solid LPD Analyst candidates is to look to the skilled trades or
mechanical engineers. Having a mechanical background coupled with hands on experience building or repairing
mechanical systems are strong assets that an LPD candidate should possess in their work history. Often candidates
with this type of experience can read engineering drawings, understand diagnostic flow charts, are experienced with
assembly and technical manuals, are familiar with hand tools, and have a developed mechanical aptitude. Pursuing
candidates with a skilled trade background also allows you to customize and diversify your LPD team. For example in
the Aerospace and Defense industry you’ll need a wide range of analysts with experience working on “air frames to
powertrains,” and that’s nothing but “the hull truth.” Look to ship yards, Army depots, and Air Force depots for techni-
cians that have repaired the systems, or similar systems, that your LPD team is tasked with analyzing.
Don’t forget to look at civilian maintainers either, as aerospace and defense systems often closely resemble their
commercial counter parts. Finding the right person to become an LPD analyst is not an easy task, but looking for indi-
viduals that have repair experience or design knowledge commensurate with the systems your team regularly
performs LPD analysis on will give you an edge in producing efficient and accurate LPD analysis.
(Continued from page 4)
Efficiently producing an accurate LPD analysis can be tedious and exacting work. Chang-
ing system configurations, maintenance concepts, inadequate source data, inefficient
logistics tools and associate burnout are constant enemies in the LPD development envi-
ronment. I hope this article has provided a basic but entertaining look at some of the
most common pitfalls facing LPD development teams and has provided some common
actionable solutions to mitigate them. Keep logging!
ABOUT ALE’S LOGISTICS PRODUCT DATA EXPERIENCE:
ALE has an excellent reputation for providing deliverables that exceed the expectations of our customers and leader-
ship of the critical programs they support. Our PSA and LPD deliverables consistently display an exceptional under-
standing of the application of TA-STD-0017 and GEIA-STD-0007, and their MIL-STD-1388-1A and MIL-STD-1388-2B
predecessors. We were one of the first users of Integrated Support Systems (ISS) SLIC and SLICwave® logistic data-
base software and led the implementation of the MIL-STD-1388-2B version on the USAF F-22 program (which was the
first major program to implement the -2B standard). We have developed comprehensive logistic databases for over
20 programs and have trained Government and industry in PSA and logistic database development.
6
Two news headlines from different sources on a single
political story: One screams of scandal, trouble, and the
end of the world; the other paints a completely different
picture – it’s hard to believe they are talking about the
same thing. How does this happen? Well, we can blame
outright advocacy journalism for some of it. But as one
who has relatives in that profession, I’m convinced that
most journalists genuinely believe themselves to be ob-
jective purveyors of information. Instead, I think that the
political polarization so prevalent these days can actually
be quite instructive as an example of one of the most
potent foibles we humans possess: Confirmation Bias.
Confirmation Bias is the tendency of a person to (1)
search for, (2) interpret, and (3) recall information in a
way that confirms one’s preexisting beliefs. In school, we
were cautioned about this when learning how to deal
with information. But most of us have long since for-
gotten about it, now that we are older and theoretically
wiser. However, it is important to be reminded of confir-
mation bias’s existence because its effect has very real
impacts. On the business side, it influences how we re-
view requirements, how evaluators assess deliverables,
and how the end customer makes business decisions. At
the user and maintainer level, it influences how technical
manuals and user interfaces are perceived and how fail-
ure causes are identified.
Let’s break down the three main confirmation bias types:
(1) Selective Exposure, or Search Bias. This is a pref-
erence for seeking out information that confirms one’s
hypothesis. Our bias affects our search – where we look,
what sources we consult, what we consider worthy of
investigating or talking about. We look for what we want
to find, and we don’t look for what we don’t want to
find. But are we trying to build a court case? Or do we
seek objective information? If so, do we limit ourselves
to just those information sources that see things as we
do? Peer review of technical papers exists for a reason.
(2) Selective Interpretation, or Interpretation Bias.
Confirmation bias affects how we perceive and interpret
information. Two people can come away with very differ-
ent takes on the same information or situation. Are we
able to understand how a reasonable person can come
to a different conclusion than our own? Do we even try
to see it? We should be most wary of things that appear
to feed our preconceived notions because we are already
eager to accept them unchallenged. This is especially
true when we read and interpret program specifications.
We immediately come to the conclusion that we “know”
what the customer wants.
(3) Selective Memory, or Memory Bias. Confirmation
bias affects what we consider worthy of remembering. I
can barely recall what I ate for breakfast, but my wife can
remember what clothes I wore to an event a decade ago.
Some things are more important to her than to me. That
goes for other things as well. Do we recall more readily
facts that support our beliefs? Of course we do. Are we
less tolerant of defects in an opposing theory than we
are of defects in the theories we support? You bet!
Confirmation bias can also lead to tendencies like:
Polarization of opinion
The persistence of discredited beliefs
A preference for early information
Illusory association between events (Continued on page 7)
Warning: Confirmation Bias at Work
By David Aurand, Quality Manager and Human Factors Sr. Systems Analyst
7
Now, I can’t say that biases are always bad. One’s bias
may be what allows a person to see opportunities where
others see only problems. Here’s a quote from LtGen
Lewis B Puller, the most decorated Marine in US history:
“Alright, they’re on our left, they’re on our right, they’re
in front of us, they’re behind us. They can’t get away this
time.”
But one could just as easily imagine a scenario where an
overly optimistic bias might lead to disaster (paging Gen-
eral Custer . . .).
And there is a difference between Bias and Convention.
There is no objective reason why an Australian couldn’t
view the world like this if he or she wants to:
Fortunately, there are conventions in place that facilitate
how information is communicated.
There is no cure for confirmation bias. As humans, we are
stuck with it. The best we can do is to be aware that it
exists, and do our best to compensate.
(Continued from page 6)
To learn more about any of the articles or the topics
discussed in The Logista, please contact us directly at
[email protected] and connect with us through social
media!
WWW.ALE.COM
S TAF F M EM B ER S P OT L IG H T
W. Ben McKenzie
Mr. Ben McKenzie is
a Logistics Analyst,
Technical Writer and
a certified NAVSEA
Reliability-Centered
Maintenance (RCM)
Level II developer in
Acquisition Logistics
Engineering’s Gau-
tier, Mississippi office. Before joining ALE over six
years ago, Ben served in the US Navy operating and
maintaining gas turbine propulsion systems on Navy
ships, including hydrofoils, destroyers, cruisers, and
hovercraft, and as a certified instructor. This exten-
sive hands-on experience with Navy ship programs
has benefited ALE and our customers through incor-
porating operator and maintainer perspectives into
our logistics products.
Among Ben’s areas of expertise within ALE are
Maintenance Planning, Logistics Product Data (LPD)
database development, provisioning, and technical
manual development. Recent projects that he has
made significant contribution to include RCM and
Technical Writing for a landing craft and mainte-
nance task analysis on a distress C4 system. Ben is
also certified as a NAVSEA Reliability-Centered
Maintenance (RCM) Level II developer.
Ben resides in Ocean Springs, MS and enjoys golfing,
camping, fishing, and garage tinkering.