Your PFEP Database = A Plan For Every Part

The most critical thing that any reader can learn from this site is the value of developing a PFEP system comes as much from the development process itself as it does than the final PFEP database program.  Obviously, much of this is just a part of the normal Kaizen / Continuous Improvement / conversion to Lean Manufacturing process itself.  What's not obvious is the sort of questions that expert technology, database and user interface people bring to the table.  Yes, we are easily frustrated that people don't perform as consistently and predictably as computers, but that is what leads us to discover what it takes to enable people to perform that well.  Likewise, a "tech guy" without a strong background in efficiency is all too likely to passively ask "what do you need the computer to do" and "how should it do it".  Good logistics does not violate the laws of physics.  (Parts don't magically fly from the warehouse to the Assembly Line all on their own.)  Likewise, good logistics does not violate the rules of database design.  In my experience, every request of "can't the computer just do things this way even though it isn't really the way databases are supposed to work" have been able to be traced back to much more serious material flow issues that sooner or later needed to be solved.  Quite often the company's manufacturing experts didn't even see the problem at first, because it was a part of a process that evolved over years and seemed like that was how they always did it.  Companies will also start to develop their own set of definitions for common words that are used to describe the process which helps them communicate in the short term, but also adds a layer of legitimacy to the process over time.

As software developers, at the end of the day we are responsible for implementing what the client wants.  The first part of that responsibility is determining what the client really needs.  Of course, we need to start with exactly what they are asking for, but we must ask "Why" and do our best to go on and try to understand how our piece of the system fits into the big picture.  At that point, we are ethically obligated to make sure that our client understands what we have discovered and that what they ultimately say that they want is an informed choice that they made after weighing the costs and value of doing things "the proper way".

If things aren't nicely fitting into a properly normalized database, then ask "Why?".  Whenever there's information that appears to be redundant, ask "Why".  See if the legitimate differences come in groups.  Rather than tracking the dimensions of each individual box for thousands of Parts, see if all of the Parts always arrive in one of six sizes of box.  It may seem like you are helping by allowing each box to be a different size, but in reality you are creating an error-prone data entry nightmare and an obstacle to future standardizations.

Likewise for special handling instructions.  Buy a Lamp.  I bet that it came with at least 8 pages of instructions.  Read them all.  I expect that you'll see great things like:

• Do not use near flamable materials.
• Never drape clothes over the lamp.
• Never leave the lamp on when you leave a room or are not at home.
• To reduce the likelihood of tipover, keep children and pets away from the lamp.
• Do not eat.
• Do not insert anally.
• To activate, place switch into the "ON" position.
• To deactivate, place switch into the "OFF" position.

Did you learn anything from those instructions?  The odds are if there were one or two important things that you did not already know, you missed them because they were buried in a pile of obvious legalese.

When your group designs it's material flow system, it needs to strive for something like this:

• Most material should not require any special instructions - your company's default procedures should already cover everything your material handlers need to know.☻
• Some of your material will need some standardized special instructions.☻
• Very rarely, a few Parts will require some non-standard handling instructions.☻

An experienced software developer knows how much a PFEP user is willing to (accurately) type and how much a label reader is willing to read.  Since the material handling instructions will probably be maintained in PFEP, it will be up to you, the PFEP developer, to raise these issues if your team is going off in the wrong direction.  The solution might be what is shown in my list above, possibly color-coded to "Traffic Light" standards.  Leave off the obvious instructions (and possibly print a light Green background in their place).  Let the PFEP user choose the "standard special cases" from a list and print them with a Yellow background.  Finally, let your PFEP users type in the truely unusual special handling instructions and print them on a Red background.  This allows all of the material handlers, from the most experienced to the temporary fill-ins, to know when it's important to double check the instructions.  (As one example of "standard special cases", some Parts arrive individually wrapped.  If possible, it's more efficient for a material handler to unwrap the Parts and throw away the packaging material before sending the Container of Parts on to the Assembly Line.  Unfortunately, some Parts are fragile or static-sensitive, so they need to remain individually wrapped until they are ready to be used.).

This is one of many examples of why PFEP is a process, not just a computer program.  It's also a good example of why your Lean Manufacturing team should always consist of a combination of company insiders and outsiders, in order to insure that everything is questioned.  Likewise, your Lean Manufacturing team needs a combination of "experts" along with the people who do the actual work who can and will explain why great theories don't always work in the real world.  If the workers are correct, then the team needs to find alternatives.  If the workers are wrong, then the team needs to find a better way to present the new procedures to workforce in general, in order to insure a successful roll-out.