Business Basics
Home Page


Who is Bill Gaw?
And why should we
listen to him?

 

lean manufacturing principles and techniques training

How to implement, optimize and sustain
a lean manufacturing program
The Lean Manufacturing Toolbox

Add pizzazz to your lean training
program with participative exercises.

Manufacturing Simulation Game-Plus

Manufacturing Planning Data
Part 3 of 4


privacy policy

To review our training
packages, simply click
on any of the links below:

Training Materials and Options

Lean Manufacturing Solutions

Lean Manufacturing Toolbox

Performance Measurement Training

Poka-Yoke and
Process Improvement Training

Lean Manufacturing -
Small and Medium
Sized Businesses

Supply Chain
Inventory Management

Lean Six Sigma
Implementation

Strategic Planning Training

World Class Manufacturing

Continuous Process Improvement

Kaizen Training

Kaizen Blitz Event

Thinking-Outside-
the-Box

Best-In-Class Manufacturers

Best of Gaw Lean Management Articles

Golf Training Program

IMPACTS AND RECOVERY

There are many additional codes and data elements, and space does not permit dwelling on each. Let us move on and consider a simple example, based on one coding decision, and then a more complex ex­ample. These examples illustrate how the various codes can work with or against each other.

 

For the first example, let us go back to the item number and con­sider initial data entry for the creation of a new item master record. The magical disappearing record trick can happen to anyone, but it is espe­cially common with new users. For the item master, record creation involves rolling through a succession of screen displays as we key the values into the various data fields. At the end of the data entry for that item we press "enter" and the screen clears for the next record entry. Later we try to access the record so we can use it, but we cannot find it.

 

We know we entered the data. Why can't we find it? Why isn't it there?

Oh, it's there. Most assuredly it is there. Usually it is just hiding behind a different ID than the one we think it should be. Do you re­member all those successive zeroes that we discussed above? Well, maybe we lost count. Or that numeric "1" was really a lowercase "L". Or maybe we just "fumble fingered" the keyboard. It makes no differ­ence—user frustration builds rapidly. Personal error or initial lack of skill very quickly transforms itself into frustration, nonacceptance, and eventually even hostility toward the system. But the record is there! Maybe we can recover it.

If we have established a reasonable protocol for search text format, we should be able to key in a search string and have the system bring back a list of items. One of the displayed lines will contain a descrip­tion or part number close enough to what we think we remember that the wayward item is found. In many systems we can verify that it is the correct record because the system automatically records on each record the userid, terminal ID, date, and time. Once we are sure we have found the right record, we can access it and correct it.

 

Now consider the complex example. A client team was testing sys­tem functionality. They were past the initial hurdles, or so they thought. They entered three similar sales orders for a specific end item. The BOM for that item specified 350 fasteners. The fasteners were a "com­modity" item, and they had set the system to purchase those fasteners in multiples of 1,000.

 

They had also told the system that these fasteners were to be ordered "lot for lot." In that particular system, "lot-for-lot" means "satisfy each demand independently." There was another code for that particular data field that meant "aggregate the demand for this time period and order it all at once," but this client initially chose not to use that other code. They had preloaded no on-hand inventory for these fasteners.

So, after they entered the sales orders, they executed an MPS/MRP generation and, as expected, got three action messages telling them to order fasteners. Without thinking about what they were doing, they said "OK" to each of the messages, and the system generated purchase orders to satisfy the demands. Great! Everything seemed to be working.

Next, the client reran MPS/MRP to verify that now there should be no action/exception messages. Imagine their surprise when this MPS/MRP regeneration provided three entirely different messages. These messages, one per purchase order, advised them to reduce the fastener quantity to 350 ea. OK, that made sense. So, again, without thinking, they approved the three messages, and, again, they regen­erated MPS/MRP. When the same "reduce" messages reappeared they

 

were convinced that the software was not working properly because the purchase orders should reflect the reduced quantity. To prove their thesis they reprocessed the "reduce" messages and regenerated MPS/ MRP yet again, with the same result as the previous time.

Actually, the system was working just fine under the circumstances. So, what was the real problem? Consider the following combination of factors:

1.        First and foremost, they didn't understand the theory and concepts
of MRP. Without that understanding of what the software was de­
signed to do, it was difficult for them to absorb why the system was
generating those messages.

2.   The purchasing unit of measure constrained the system to order
these fasteners in multiples of 1,000. The lot-for-lot planning code
was saying "buy just what you need" (350 ea.) but the purchasing
system had to buy them in lots of 1,000. The system was getting
conflicting instructions: each of the various programs was trying to
obey the instructions specifically relevant to it.

3.        The recommended solution was to change the planning code for
that item from lot-for-lot to "satisfy the requirements for this time
period." That would tell the system to aggregate the day's demand
and order 2,000 fasteners (3 x 350 = 1,050). Now they could satisfy
the demand, and put the excess (950) in inventory, where it would
be available to satisfy the next demand.

4.   The alternate solution was to consider the messages, drop out two
orders, and combine their requirements into the remaining order by
simply changing that order's quantity to 2,000.

5.        The client's proposed solution was to change the purchasing unit of
measure to "each." We pointed out that these were low-cost, com­
modity-type items. The administrative cost of recognizing the de­
mand, processing the order, receiving the parts, vouchering the or­
der, and processing the payable was probably greater, by some con­
siderable margin, than the face value of the order. Why absorb that
overhead three times when once will suffice?

To Be Continued

For balance of this article, click on the below link:

Lean Manufacturing Articles and click on Series 11


A Gift for You

Need help in bringing this training to your company, may I suggest that you forward this Web page to your leader. If you do, we'll send you our Power-Point presentation, "7-Rules for Surviving in an Entirely New Economy."
 


To open the
"Forward to" form:

 


STAY CONNECTED

To stay current on Lean Management Basics and Best Practices, subscribe to our weekly MBBP Bulletin... and we'll send you our PowerPoint presentation, "Introduction to Kaizen Based Lean Manufacturing™." All at no cost of course. 

 

First Name:
Your E-Mail:

 Your personal information will never 
be disclosed to any third party.


privacy policy

Here's what one of our 13,000 plus subscribers
wrote about the MBBP Newsletter:

"Great manufacturing articles. Thanks for the insights. I often share portions of your articles with my staff and they too enjoy them and fine aspects where they can integrate points into their individual areas of responsibilities. Thanks again."

               Kerry B. Stephenson. President. KALCO Lighting, LLC


"Back to Basics" Training for anyone ... anywhere ... anytime

Business Basics, LLC
6003 Dassia Way, Oceanside, CA 92056
West Coast: 760-945-5596 

© 2001-2009 Business Basics, LLC