on this article, email Chris Gray at cgr...@grayresearch.com
S&OP Instructor's Manual
MPS Instructor's Manual
Consulting and Research
Class A Certification
Software Evaluation and Selection
MRP II Standard System
Software Supplier Directory (140K)
eSOP - S&OP Software
The Right Choice by Chris Gray
MRP II Standard System by Chris Gray and Darryl Landvater
and Operations Planning Handbook by Don Rice and John Civerolo
and Related Companies
Partners for Excellence
Graham Barton (New Zealand)
Belt Excellence (French language)
Who We Are
Chris Gray Biography
Books by Chris Gray
Books Articles Affiliates
We caused quite a commotion in the software industry in the early '80's. That's when we
first started to advocate simple software packages. The way most software suppliers
reacted to our position, you'd have thought we'd attacked their firstborn.
We see several serious problems with the big bloated, complex MRP II/ERP software
packages available today. These problems all end up adding to the implementation effort
and expense and time required to get the system on the air:
The number of features, codes, switches, options, etc. in a typical software package is
mind boggling. Someone, usually many people, on the implementation team need to
them all, even though many will never be used.
The learning curve for the users of the system is still way too long, generally because
of the extra features, codes, capabilities, etc.
Complex systems are way too difficult to modify, and the effort to interface to
existing systems may be overwhelming.
MRP II has gotten a bad name because of overly complex software implementations of
simple, straightforward concepts.
Some software suppliers say that additional functions and options are an advantage.
"It's like equipping the cockpit of an airplane with more instruments", they
say. "How can you argue against giving a pilot more capability to see where he is in
three dimensional space? And after all, if he doesn't want to use the new instruments, he
doesn't have to."
But unfortunately, it's not like equipping the cockpit of an airplane with more
instruments. It's more like equipping every passenger's seat with controls. Then, at the
beginning of each flight, the flight attendants announce, "Ladies and
me direct your attention to the two green buttons, the red button, and the yellow joystick
located on your right armrest. Please do not touch the red button during takeoff. If you
In most cases, additional features are a liability, not an asset. Someone must
understand them well enough to choose which to use and which not to. Someone must be
capable of explaining them to the users, and telling them why certain features shouldn't
be used. Saying "Never put a '3' in the XXX field" without explaining why, is an
open invitation for experimentation. And then, someone must know how to recognize the
symptoms, or the consequences, of these features being used, and how to reverse any
problems that might occur. Anything less means that the users will not accept
accountability for results from the system.
All the extra features, codes, options, capabilities, etc. inflate the education and
training effort required to implement a typical software package by factors ranging from 2
to 10 times what what they should be. In a recent situation with a client, the recommended
software training exceeded the general MRP II education by a factor of 10. In other words,
for every hour spent talking about the principles of MRP II and how to manage using these
tools, ten hours have to be spent discussing how to make the software work. Sadly, this is
backward. For every ten hours discussing the principles of MRP II, one hour should be
spent discussing how to implement those concepts in the software.
And there are big problems on the systems and data processing side of the house as
well. The fact is that interfacing complex software packages to existing, working
manufacturing systems (inventory transaction systems, bill of material systems, etc.) is
generally not possible. Even interfacing with financial and order processing systems can
be daunting. As an old friend of mine once observed: "Interfacing two different
pieces of software is like brain surgery. It isn't the cutting that takes the time. It's
all the preparation, analysis, and figuring out where to cut that's time consuming."
The more complex the software, the less likely that there's a simple, easy, fast way to
interface it with something else.
Perhaps worst of all, because software is so complicated, it's giving MRP II a bad
name. Many people implementing for the first time are using these complicated packages and
assuming that the complexity is a function of MRP II, rather than being a characteristic
of that particular system.
What's to be done? A good long term approach is to follow a single principle for both
software developed in house and software purchased from software suppliers:
Err on the side of simplicity not complexity.
Principle 2: Understand the core simple logic that makes MRP II work. Insist
that this core functionality be present without a lot of extraneous features.
Principle 3: Don't confuse features with functions, and dont assume that
more features means easier implementation.
If the problems with software are ever to be solved, it will be because the people who
use software, people like you and I, insist that computers and computer software be made
simple. By insisting on simplicity in software, we can make life easier for ourselves and
our companies, and send a clear message to the people developing software. If enough
people insist on simple workable software, that's what will be produced.
We love feedback.
Use the form below to send comments and questions directly to the author.
Just enter your name and email address, and any comments you have, and they will go directly to Chris Gray.
If you have specific questions
about this article or want to discuss it with the author, call Chris Gray at 1 603 778-9211.
Books Articles Affiliates