Software and Simplicity

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 understand 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 gentlemen, let 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 do...."

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:

Principle 1: 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 don’t 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.

Chris Gray

_______________________________________________

FEEDBACK

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.

Name:

Email address:

Indicate that you are a human and not a webbot by keying "yes"

Comments:

If you have specific questions about this article or want to discuss it with the author, call Chris Gray at 1 603 778-9211.

Home Education Consulting Software Books Articles Affiliates Gray Research