One of the key issues in the implementation of any enterprise management system is the definition of the item master record. The values and codes entered into the various item master data fields, individually and in combination, affect how items/materials are planned, bought, stocked, issued, produced, and/or sold.
This session examines common errors in item master data, their effects on contemporary enterprise resource management systems, and their correction and prevention. This data set is linked to inventory, bills of material, routings/processes, work orders/production schedules, engineering design, sales, purchasing, forecasting, and material planning. The accuracy and integrity of this data set is crucial to the effective utilization of contemporary automated management systems.
What are the common (and not so common) errors found in the item master? How do they affect the system? How do we correct them? Where do they come from? How do we keep them from happening? Knowing the answers to these questions can help jump-start a new system implementation or enhance the efficiency of an existing system's operation.
THE ITEM MASTER FILE
Collectively, the item master file is a super-set of records. There is a record in the file for every part. These records identify, define, specify, and otherwise tell people and the computer system everything we would ever want or need to know about the goods, materials, logical constructs, and documentation that we might ever conceive, plan, buy, sell, stock, make, repair, draw, or write about.
The record set for a given part can tell us what it is (description), how many we have on hand, where they are stocked, what they cost, what they should have cost, what their selling price is, and what discounts apply. It probably also includes, where relevant, information such as what the vendor's part number is, who the prime vendor is, what the customer's part number is, and who the prime customer is.
In addition, we may find what other items can be substituted for this part, and for what items it may be a substitute. The record may also show in what unit of measure we buy it, stock it, issue it, make it, and sell it. Finally we should see how we plan it, and when in its life cycle is it relieved from inventory (preflush, manual issue, backflush).
Depending on your software system, the item master could "live" in your engineering module, your "materials" module, or a stand-alone database that is accessible by the various applications modules, or it may even be "distributed" throughout your system.
COMMON ERRORS Item Numbers
One of the first decisions that you will have to make concerns the item numbering scheme. At the simplest level, as items are added to the system, they are sequentially numbered. This unique numeric designator, because it is combined with the other data elements in that data record, is sufficient to identify and specify the item to the system. By itself, the number has no coding, no significance, and no intelligence that indicates anything about the item. This system, however, is all that the computer needs. It allows for very quick data entry using the nine-key number pad on the keyboard and permits relatively short item numbers.
At the next level of complexity, we can introduce some "intelligence" into the part numbers. Typically, we start with "blocks" of numbers, with all of the items within a certain block sharing some specific characteristic. Now the part numbers become "significant." Certain characters have meaning if they occupy certain positions in the part number. Of course we can "nest" subblocks with the blocks. The net effect is to make the part numbers longer because we have to allow room within the blocks for new items with the common characteristic, but blocks may not fill before we have to move to the next characteristic.
One way to keep the part numbers from becoming excessively long is to introduce alpha characters. That allows 26 more values before we have to add another digit. Of course, with either scheme, if we don't make the blocks large enough and a block fills, we may lose our significance scheme, or we may embark on a major renumbering effort.
In the extreme, I have seen 25-character part numbers with every character significant, such that a manufactured component's part number would indicate the end-item, major system, subsystem, assembly, subassembly, and so on for which it was designed. Data entry was now all over the keyboard, with many more keystrokes and increased opportunity for error.
If the part number included six or seven consecutive identical characters, typically zeros, data entry would sometimes key an extra digit, or leave one out, with the resultant failure of the system to recognize the keyed number. When numbers were handwritten, people were not always scrupulous to differentiate between numeric Os and alpha Os, and sometimes people confused numeric Is with lowercase Ls, with similar failures.
The lesson here is to keep the numbering scheme as simple as possible and let the other data elements in the item master record specify most if not all of the significance.