By David Meyers

Einstein-proof your business

Design to prevent human error
while giving workers
the proper tools

People, processes and technology

long have been considered the three
legs that support any business platform.
Their relative importance can vary from
organization to organization — and
even from department to department.
In all cases, the biggest variable of the
three is the “people” dimension.
Whether you are designing a new
manufacturing process, an assembly
work cell or a distribution operation,
the three factors must be considered in
parallel to ensure efficiency, consistency,
profitability and, most importantly,
satisfied customers. The same holds true
when improving existing operations.
Any changes to the current baseline
must balance the people, processes and
technology “inputs” to the finished
product. Here, we will assume that mate-
rial quality is a given and constant to
focus more on the organizational aspects
of this debate.
Balancing and tying together the three
legs of people, process and technology
give your business a stable platform.
When any one of these three legs is cut • Mergers and acquisitions that one leg always carries more weight
short, the other two must compensate. • New product introductions than others or that all three are equally
When two legs lack sufficient length • Noncompliant materials important. In reality, different legs have
or strength, it is even more difficult to • Equipment failures different levels of importance depend-
balance your business platform. • Special customer requests ing upon the situation, and no correct
Ideally, you have enough length on all • Variability in operator and/or end-user answer exists for all operations or busi-
three legs with sufficient strength and understanding and comprehension nesses. For example, in a labor-intensive
with sufficient capacity to expand (think • Unforecasted spikes in business volume operation in which technology cannot be
tripod) so that you can adjust to the highly leveraged, people and processes
following fluctuations and remain stable: One could argue this analogy and insist are more important. In a construction

30 Industrial Engineer
operation, your technology may consist
of a level, a tape measure, a backhoe or
even just a shovel. Proper construction
processes and skilled tradesmen are the
primary keys to a well-built structure.
In pharmaceutical manufacturing, tech-
nology is central — with many pieces of
equipment and an operation guided by
meticulously defined processes where
temporary labor often can be used.
Another truth is that the most variable
of all three is the “people leg.” Processes
can be well-defined and established to
provide sufficient stability. Technology
can be implemented to ensure low vari-
ability in expected outcomes based upon
known inputs. However, although “all
men are created equal,” no two people
are the same in outcome. Two similar
individuals (even identical twins) may
react to the same environment and situ-
ations in entirely different ways. Plug in
the infinite amount of things that can
affect the human brain and our physical
condition and variability is guaranteed.
Ties that bind
Given the variability of the human
condition, we need to understand what
ties the three legs of people, process and
December 2010 31
Einstein-proof your business
technology together and determine how
to strengthen the stool and reduce vari-
ability in outcomes.
As illustrated in Figure 1, consider the
following premises:
• The rungs that connect people and
process are training and operational
best practices.
• The rungs that connect process and
technology are operational best prac-
tices and design.
• The rungs that connect technology
and people are design and training.
The best practices rung
Any new business process or attempt to
improve existing operations must have
“best practices” as its foundation. The
term best practices may mean differ-
ent things to different people because
a stable platform
Figure 1. Training, design and best practices link together a stable business platform’s
three legs of people, processes and technology.
32 Industrial Engineer
a best practice for one organization
may not be a best practice for another.
Any process that your business defines
as a best practice consistently achieves
better outcomes than other applicable
processes.
To define what your best practices
are, the processes that deliver those
superior results must specify and link
together the people and the technology
that support the consistent provision
of those high quality deliverables —
whether they be goods or services. To
develop policies, standard operat-
ing procedures, work instructions or
preferred methods without considering
how the people and technology support
the process is an exercise in futility, an
exercise that you will perform over and
over until you find the best practice for
your business.
The design rung
When implementing or upgrading
any technology or tool, the primary
consideration must be: How will this
solution be used by your people while
they perform a certain process that has
been defined as best practice for your
business? It does not matter whether the
application or technology solution is off-
the-shelf commercial, a custom solution
or a hybrid of custom and commercial.
The people using the software and the
processes being used to support them
must be at the forefront of the team that
is tasked with implementing the tech-
nology or application.
All systems’ implementation proj-
ects should begin with the definition
of your functional requirements. Those
requirements, which explain how your
people will do their jobs, then are used
to flow into the detailed design stage of
the project. The other side of the “busi-
ness process coin” is the detailed design
of any interface from one or more appli-
cations to other applications through
each and every affected or necessary
layer of application. Examples include
from end user to and from the process
control software, to and from a manu-
facturing execution system, and to and
from the manufacturing resource plan-
ning module of your enterprise resource
planning software.
The design of the solution and how
that solution is integrated, not only with
other applications but with any user
interface and data collection device as
well, must be detailed and documented
enough that there is no ambiguity in
how each business scenario and excep-
tion condition will be handled. For this
process, the end-user will see “A,” be
required to perform “B” operation and
enter “C” in order to deliver “D” result —
if not then “E” will happen.
The ideal method to communicate
these details is to use swim lane flows.
These diagrams show a lane for each
application, and each box represents
any function that triggers any data
event, either a manipulation of the data
or a transaction that sends information
to another application. The lines that
connect the boxes identify any relation-
ship between different processes and
demonstrate the flow of operations.
Of course, any decision point showing
all possible alternate decision points
should be documented as well. So it is
this design and the integration plan that
serve as the rung that ties technology to
people as well as from technology to the
process.
The training rung
The last rung that stabilizes your busi-
ness platform fully ties people to the
process and also ties people to the tech-
nology. We do this through training. You
can have the best practices for your busi-
ness processes and the right technology
solution with the right configuration to
support those processes, including full
integration with your larger technology
portfolio (and even with your trading
partners). But if your people have not
been trained effectively, your investment
will see suboptimal yields.
The challenge is preventing human
error from hurting your business while
giving workers the tools to achieve your
business’s goals. It is said that “people
are our most important asset,” but it
is debatable whether people are the
“most important.” They are definitely
the most variable; therefore, you must
devote a significant effort toward ensur-
ing compliance with your processes and
competency in the technology they use.
So your business processes are
founded in best practices, and you
want the design of your systems to
support those practices and ensure that
your people properly use the tools to
support those processes. How can you
“idiot-proof” the system to eliminate
or significantly reduce variability in the
desired outcome so the quality product
or service is delivered on time?
You can’t realistically idiot-proof
any system, but you must design it to
prevent people from doing something
that can have negative or catastrophic
effects downstream.
An attempt at idiot-proofing Designing away human error
In May 2010, a market plunge of nearly
1,000 points was first blamed on “user
error” — an error that occurs between
the chair and the keyboard.
Supposedly, a trader entered a “b” for
billion instead of an “m” for million in
a transaction that likely involved a Dow
component, which triggered the plunge.
A typo could have cost investors thou-
sands or even millions of dollars. That
event is a prime example of how some
Wall Street “Einstein” either didn’t know
how to use the system or that sufficient
effort was not made to Einstein-proof
that system’s design. This event should
cause you to devote deep thought and
significant effort in Einstein-proofing
any systems implementation.
Supply chain planning systems by
their nature depend on user input and
integration with other systems. To go
down another level and apply more real
world analogies, consider supply chain
execution systems, which are even more
dependent upon real-time user input
and typically have operators most would
not deem “Einsteins.” In a single facil-
ity or distribution center, hundreds of
Einsteins may receive hundreds of trail-
ers, loaded with thousands of pallets,
and ship hundreds of orders with thou-
sands of cases through more thousands
of transactions and end-user steps that
are distributed to hundreds of custom-
ers — each with hundreds of stores. And
this is just in one of your facilities. What
would happen if you double or quadru-
ple that, depending upon your supply
chain network and integration with your
trading partners?
Clearly, this environment is rich in
opportunities to reduce or eliminate user
error by Einstein-proofing the design
and ensuring that your people know how
to do their jobs effectively to boost prof-
itability and satisfy customers.
During the design phase of an imple-
mentation project, you need to consider
the business processes with their foun-
dation in operational best practices. This
design must consider how the technol-
ogy will be used by your people in normal
business scenarios and during all those
ugly exception conditions (inventory
is damaged, a user mis-keys data into a
screen or the lift truck operator scans the
wrong bar code). So keep asking your-
self during the design stage: “What are
all the ways that Einstein could make a
mistake? What can we do to prevent that
mistake? If there is no way to prevent
that mistake, what can we do to keep it
from damaging quality or service while
also giving Einstein direction to correct
that mistake?”
Most best-of-breed supply chain
execution systems are highly configu-
rable and can accommodate the majority
of your operational best practices. Where
base functionality and configuration fail
to meet your requirements, some base
code enhancements may be needed and
should follow the 80-20 rule. In this
context, expect that at least 80 percent
of your operational best practices will
be base functionality with some level
of configuration, while no more than
20 percent of your business model will
require changes in the software provid-
er’s base code. Measurement of the
80-20 relationship is subject to some
level of interpretation, but consider the
total cost of ownership as a baseline.
December 2010 33
Einstein-proof your business
Total cost of ownership comprises
several components, including but not
limited to license fees and maintenance
fees (from the software provider), imple-
mentation and support costs (from your
internal IT and operations staff), inte-
gration costs (making all the software in
you technology portfolio “talk” to each
other and across your trading partners),
upgrade costs (porting old modifica-
tions forward to a new version when base
functionality in that release would not
likely be able to support your operation),
training and change management costs,
limitations on host systems, hardware
and other system architecture constraints
and so on. Those cost components
should be offset to some degree by reduc-
tion in labor costs, lower transportation
costs, higher inventory accuracy and
lower inventory carrying cost.
There are other measures of how
implementations and upgrades measure
up to the 80-20 rule. But total cost of
ownership and ROI are the most critical
measures since all modifications require
different levels of effort to develop,
making the money component the most
objective measure. If the business case
for your implementation or upgrade
does not meet these criteria, you might
rethink your software provider or your
business processes unless you have
subjective reasons to go forward. Other
factors may be soft benefits or costs,
such as competitive advantage, cultural
shifts, customer satisfaction, increased
sales and reduced returns. It’s possible
to assign a dollar value to these, but they
are highly subjective, speculative — and
worse, political. Estimating those soft
costs requires a separate discussion and
heated debate.
With that said, consider how to
comply with your best practices and
accommodate the business case for your
implementation. The two most important
areas of focus are where the system allows
34 Industrial Engineer
Einstein to perform work outside of the
prescribed process and where the system
allows him to enter invalid information.
If either of the above happens, ensure
that error messages can be ignored
or overridden in a limited amount of
special situations and log all overrides
and exceptions for potential process
improvement and operator coaching.
For example, one pharmaceutical
operation that did not have sufficient
controls faced significant issues after a
user entry error. Here is what happened:
Einstein was trained to scan the GS1-128
carton number bar code that he was pack-
ing. The next step was to scan the item
number bar code on the product pack-
age (this would be the “NDC” in pharma
terminology). The next step was to scan
the lot number bar code and then key in
the quantity being packed into the carton.
These steps were to be repeated for every
customer order line being packed into the
outbound shipping carton.
But in this case, Einstein scanned
the carton number, scanned the item
number, scanned the lot number bar code
and then inadvertently rescanned the lot
number when the system was expecting
a quantity entry. He didn’t catch the mis-
scan and confirmed that this carton was
packed correctly. Nobody was the wiser
until the shipping confirmations went
to the host and to financials, where the
sales report showed that just one carton
on that customer’s order was worth in
excess of $1 million. The lot number
happened to be 370001, and the quan-
tity expected was 12. This was a simple
and “honest” mistake that could have
been avoided if field-level validations
were in place, such as no more than “X”
bytes, or quantity entered, should exceed
more than ordered, etc.
In this example, Einstein performed
work outside of the prescribed process,
and the system allowed him to enter
invalid data.
So in addition to having well-defined
and approved processes in place and field-
level validations, pay close attention to
options that can limit the likely Einstein-
caused disasters through proper training.
Competency-based
performance improvement
Supply chain execution systems (trans-
portation, warehouse, yard, slotting and
labor management systems) implemented
successfully and integrated with comple-
mentary systems can optimize your
operation’s efficiency, reduce operating
costs and increase customer satisfaction.
Despite popular belief, a design flaw often
is not the main cause of unsuccessful
implementations. Rather, operators who
do not use them as designed and the wide
variability in people cause most go-live
and post go-live issues. Despite our best
design efforts, we still need to ensure that
Einsteins use the system as designed.
Incorporating a comprehensive and
strategic training program can ensure
successful supply chain execution imple-
mentation projects. One of the best
methods is using a strategy based in
competency definition and modeling.
To demonstrate another real-life
example, here is what happened recently
at the grocery store. The clerk was scan-
ning items before coming to the bargain
purchase — 10 advertised hot items.
Unfortunately, the first would not scan.
Einstein tried to scan it again — and
again — and again — and again. She
then tried the second package of the same
item.
The second verse was the same as
the first — scan, rescan, rescan, rescan.
The system did not know what the
bar-coded item number was supposed
to be or what it was supposed to cost.
These factors are important because the
grocery store was expecting to collect
money for products that had moved
through its supply chain.
 It was evident that the UPC bar code
could not be scanned or the item was
not in the master database in the point
of sale system.
At this point, I suggested to Einstein
that she hand-key the UPC, then press
<enter>, press the <QTY> key, then key in
“10” and then press <enter>. She looked
at one of my 12 heads and said, “This
register won’t do that, sir.” I replied that
“when I worked as a cashier and bag boy
25 years ago, my old register could do it.”
There was another sigh and another long,
uncomfortable pause while we waited for
the manager. The manager ran virtually
the same operation I had suggested. Voila.
The register recorded the sale, and I was
on my way after an encouraging word to
the dumbfounded Einstein and Einstein’s
manager. It is critical that the people in
our business are competent not only in
the processes but in the technology used
to support our business platform.
That said, there are two objectives to
defining competencies. The first is to
provide sufficient information to indi-
viduals about their work and preferred
methods so that they can succeed. The
second is to provide a tool for both
the organization and the individual to
measure this success or competency.
Competency models are a set of effective
tools to help win in today’s marketplace,
but to be effective, they must be designed
well. Incorporating a competency-based
model into projects can ensure success-
ful implementation by ensuring that
people know how best to use the system
in pursuit of best practices.
Developing a competency model is the
first step toward successful supply chain
execution systems training. The imple-
mentation team should create a matrix
to document the job titles, or prefer-
ably the job roles, the skill levels and the
primary responsibilities of the employ-
ees managing and using the supply
chain execution application according to
each functional area within the distribu-
tion operation. These areas can include
receiving, put away, picking, packing,
shipping, inventory control, quality
audit, order management, returns or
customer service. By segregating these
functional areas, the team can develop
focused training material and compe-
tency-based questions and assessments
within each group.
After the competency matrix is drafted,
levels of competence are assigned to each
user/operator for each functional area,
depending upon the level of proficiency
needed for that person’s role within the
organization.
For most applications, the definitions
for the levels are:
• Not aware (or not applicable): Has no
clue or needs no context related to the
process or technology for that func-
tional area
• Aware: Has some general knowledge,
enough to converse about and not be
confused by the topic
• Competent: Able to perform this job
function when needed, understands
the process and technology involved
• Proficient: More than competent (an
expert), also able to teach, coach and
troubleshoot any issue when some-
thing is not aligned with processes or
causes any technical issues
These categories should suffice to
define the level of competency for each
operator in each process and each compo-
nent of the system’s functionality
The resulting matrix, when finished,
then acts as your playbook for which
people who perform certain roles need
to be trained in which functional areas
and to what level of proficiency.
It is also important to include
nonsystems-related competencies when
implementing a new system or upgrade,
especially when dealing with a startup
operation. Being too systems-centric
can exclude other critical pieces of the
operation, thereby creating gaps in the
overall process. Competency in corporate
culture, company policies, safety, effec-
tive leadership and other areas will help
provide the keys to long-term success.
Instruction in preferred methods is also
critical and definitely impacts operators
being able to perform up to “standard”
in operations where engineered labor
standards are used. Meeting the stan-
dard is highly dependent upon how that
standard was developed by the engineer-
ing group and how compliant they are in
other nonsystem-related processes and
physical movements.
Only when your people have been
trained in how to use the technology
properly in support of the best practices
for your business processes can they
provide the strong, stable “people” leg of
the business platform. Your projects can
have a smoother transition from design
to implementation to steady state while
quickly reaching and surpassing pre-
project productivity. Your project also
will realize a quicker ROI with a proven
and effective training program. d
David Meyers is a principal in the supply
chain information technology practice at
Tompkins Associates. His practical experi-
ence has helped several companies improve
their operations and implement supply chain
execution and visibility systems. He has
worked most recently with industry leading
companies such as Teva Pharmaceuticals,
Restoration Hardware and The Hershey Co.
Prior to joining Tompkins, he served for more
than 10 years as a senior leader in distribution
operations and technology. Meyers received
his bachelor's degree in mathematics from
North Carolina State University.
December 2010 35
Copyright of Industrial Engineer: IE is the property of Institute of Industrial Engineers and its content may not
be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written
permission. However, users may print, download, or email articles for individual use.