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 example. 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 consider initial data entry for the creation of a new item master record. The magical disappearing record trick can happen to anyone, but it is especially 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 remember 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 difference—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 description 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 system 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 "commodity" 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 regenerated 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?