Published in TDAN.com April 2004
Consider this scenario: There is a large company, let’s call it NBM Corporation, which sells many products, but doesn’t actually build any of them. Instead, NBM has arrangements with a
large number of parts suppliers and a large number of manufacturers. Each parts supplier publishes its parts catalog to NBM, and NBM brokers sales of parts to the manufacturers, who buy parts to
make their respective products. Each manufacturer is obliged to purchase parts from NBM’s suppliers, and agree to notify NBM of their inventory of necessary parts. Finally, NBM provides a
catalog of products to the public, and brokers sales between the public and each manufacturer.
NBM asks each parts supplier to provide information about each part that is sold – the product identifier as it is represented within the supplier’s database, the name of the part, the
specifications, etc. NBM asks each manufacturer to provide details about each product offered – the product identifier, the part identifiers that compose it, the specifications, etc. –
exactly as it is represented in the manufacturer’s database.
In fact, the senior managers of NBM have a great desire to be very smart and efficient in the way they do business, so in fact they never maintain any kind of inventory. Instead, any product sold
to a customer is built to order. NBM has therefore made a large investment in developing a just-in-time supply chain application. When a product is ordered by a customer, the manufacturer of that
product is notified that an order has been placed. At the same, the manufacturer’s parts inventory is checked, and if any are not in stock, order(s) to the necessary parts suppliers(s) are
immediately issued for purchase and delivery. NBM can predict the time it will take for the product to be assembled based on delivery times for missing parts, the assembly time for the ordered
product, and the shipping time to the customer.
The parts suppliers are happy with this arrangement, because it means increased sales – the manufacturers are obliged to buy their products, and the sales and fulfillment actions take place
automatically, which reduces their process overhead. The manufacturers are happy with this arrangement because they can reduce their inventory stock requirements and reduce their inventory risk,
leading to increased margins, higher profits, and lower resource investments. NBM is happy because they have eliminated all aspects of building products from their business plan, and in effect they
make nothing but money (“NBM,” get it?).
Everything appears to be all set when the application goes into production. That is, of course, until some orders start coming in and suppliers are instructed to ship parts to manufacturers with
large inventories already in stock. Parts are refused, costs are incurred, extra work needs to be done in restocking, revenue bookings need to be modified. Instead of costs going down and profits
going up, the exact opposite occurs. What went wrong?
A frantic analysis uncovered this problem: NBM’s insistence of providing part identifiers exactly as they were represented within each company’s database did not account for two simple
problems:
- There was no insistence on standardization of format representation for part identifiers in the disparate systems, and
- There were no safeguards to validate that the part identifiers provided to NBM were really exactly the same as represented within each party’s own data systems.
What really happened was this: even though the part numbers published by the supplier and required by a manufacturer looked the same in manual inspection, the actual formats may have differed. For
example, alphanumeric fields may have had digits left-justified and right-padded with spaces, while numeric fields may have been right-justified and left-padded with spaces, and while NBM’s
application favored alphanumeric, there was no standard transformation between numeric identifiers and alphanumeric. In addition, sometimes the partners attempted to conform to the alphanumeric
format, but instead of left-justifying their numeric identifiers, they left-padded them with zeroes. The result: when the manufacturer’s parts inventory was checked, the part identifiers did
not match, which in turn triggered the automatic orders.
While this example may seem a bit contrived, it actually describes a potential data standardization and data quality issue that will arise more frequently as business partners move toward
straight-through processing, improved supply chain management, and web services. The issue boils down to focusing on how information is shared and the framework in which information is exchanged,
and how data standards are defined, agreed to, and how compliance is ensured.
This is more complex than defining an XML schema for exchanging messages. This process of resolving interaction and exchange issues begins at the business level. Before agreeing to the structure of
a data exchange, the involved parties must first enumerate the business terms that are in use, and provide concrete definitions to which all parties agree. Then there must be a well-defined mapping
between the used business terms and the data elements used to represent them. At the same time, an agreement as to physical format of data element type representations must be discussed. Then, the
data elements representing business terms must be mapped in turn to their corresponding data element types.
Lastly, all participants must agree to abide by the standard. This last part is the one that may have the most impact – agreeing to comply with a standard may affect numerous applications
that have been in production for a long time, and upgrading those applications may require a large investment of time and money.
It is interesting to take a step back and look at the definition of data standards and their relation to XML. Many organizations are quick to adopt XML as a framework for data standardization.
However, the results of a quick set of web searches intended to find documented “reasons” or “value” of defining data standards were surprisingly meager. I know why some of
my clients want to use data standards – to increase automation, to reduce manual intervention, and to enable greater information sharing are some of the top reasons. But I have some concern
that in many cases the tail is wagging the dog, and the existence of a framework like XML is driving the definition of data standards without clearly defined expectations of what uses will be made
of that standard.
Consider your own organizations’ data standards efforts. Are the business drivers clearly stated? Are all participants ready to agree to standard definitions? Are the expectations of the
effects of complying with a data standard understood? If those questions don’t have satisfactory answers, some additional organization retrospection might be in order.
Copyright © 2004 Knowledge Integrity, Inc.
