Whatever numbering scheme we use, eventually we come to situations where we don't know the item number and have to look it up. The various users (sales, purchasing, engineering, manufacturing, stock-keeping, etc.) have to agree on a naming (description) and/or search text convention/protocol. One scheme for description is to use noun, adjective, adjective, etc., in a major-to-minor sort sequence. For example, "marker, permanent, red, felt tip, fine." With some forethought, you can even define a scheme in which the search text can be more generic than the description. After all, we do want to see a (short) list so we can make an appropriate choice.
What we do not want is to enter a search text for a threaded fastener and get, for example, a list of 15, 20, or more items, each with a description of "screw, 2." For any given line, we cannot tell if it is a wood screw or a machine screw. Is it round head, flat head, or pan head? Steel, brass, copper, aluminum, plated? Body diameter 1/4", 3/16", #10, #8? We should be able to immediately select our desired part number from the list because the description is truly descriptive. Try to keep a focus that part numbers are for computers, and descriptions are for people.
Unit of Measure
Some systems allow us to carry items in multiple units of measure. There are standard conversion factors, or we may be able to define item-unique conversions. For example, a case of flavor-concentrate syrup for use on a soda fountain may be four gallons, but a case of motor oil is 12 quarts, and a case of soft drinks is 24 cans. The basic price of steel is based on weight, but after we buy it we typically stock
it in coils, sheets, bars, tubes, or, in the case of bar stock and tubing, linear inches or centimeters. The various units of measure for buying, stocking, and consumption may be different. We will see below how failure to appreciate this fact can lead to problems.
There are two issues related to units of measure. The first has to do with partial units and decimal representations. In many data systems, the field length for "quantity" cannot carry very many positions to the right on the decimal point. The obvious solution is to select a smaller unit of measure. This brings up the second issue: unit of measure conversion. There is a common solution to both issues. This solution is especially relevant as we move ever closer to a global economy. That solution is the metric system. With metrics, all quantities can be expressed in whole number, nondecimal units, unit conversions are simple factors of 10, and this is the system used by most of the world.
In converting from an existing system to a new "standard" system, it is unreasonable to assume that all the data elements will have a one-to-one correspondence from one data system to the other. One has to look both at the names of the data fields, and at the functionality that uses those fields, to be sure the systems are using them the same way.
Once the data fields are mapped to each other, and determination is made of what will be converted to where, what will drop out, and what new data elements will be used, the next step is to verify that the data elements themselves, the field values, are compatible. One cannot force a three-character alpha code into a two-digit numeric field. Data value codes may require "translation" as part of the data conversion/migration process. We will revisit this topic near the end of this paper.
A common error here is not to specify conversion codes for each field. In one recent situation, for example, (primary) unit of measure (uom) was allowed to default from the system-setup predefined value of "each" rather than carry over the old uom, or specify a "convert to" uom. We then found the bills of material specifying, for example, 25 each of a certain profile steel bar, rather that 25 centimeters, or .375 each of fabric rather than .375 (3/8) linear yard.
The kinds of conversion program errors just discussed are relatively easy to spot and correct if a carefully selected, truly representative sample of data is selected for conversion testing, and then scrupulously audited after the conversion test. It is far more difficult to detect conversion errors in data elements like planning codes, which affect the way the material planning system attempts to balance demand with supply. For these data elements, we usually run the various software programs to verify that the codes are providing the correct "signals" for the data to be manipulated correctly.
Whenever conversion errors are detected and the conversion programs are "corrected," they should be tested again using the same sample data set. If this front-end design and testing is not conducted carefully, data conversion may become a highly iterative process, data base "scrubbing" may become excessive and tedious, or the "go live" decision will be made with less data integrity than desirable. All result in long-term negative impacts on system effectiveness.
The various planning codes tell the system how to handle each item. Will this item be excluded from requirements planning? If not, will we order it in quantities exactly as required (lot-for-lot), in multiples of certain batch quantities, as the aggregate of some predetermined number of day's requirements, or using some other quantifying rule? Does DRP plan it, or MPS or MRP? If MRP plans it, does this dependent demand item have some independent demand? Is there a maximum order quantity or a minimum quantity or dollar value? Is there a safety stock quantity? Do we make this part or do we buy it?
What is the lead time to make this parent part if all the first-generation children are available? What is the lead time if all the purchased pieces and raw materials are available but none of the lower-level items have been fabricated or assembled? What is the lead time if there are no lower-level items on hand and we have to buy all parts and materials and build the end item from scratch?
These are not just "nice to know" bits of information. Rather they are essential if the planning system is to be effective in helping us manage our activities.