The first fundamental rule is that the customer business doesn’t stop. For all you data purists out there that believe that one day a switch to turn on the cleansed database is in the near future, please include me, I would like to see it. Most master data management projects included years and years of legacy data; therefore there is an acceptance to draw a line in the database by last used date. When I design a data cleansing project, I will have a new item setup process referenced to legacy items, this way the client business continues and as the new items are analyzed and setup, we can reference and update the legacy item information. Independently, we will always have the legacy data cleansing parallel the new set up process.

As the data cleansing project is designed, let’s start to explore the data elements and classifications. Every client will have their material types and material status set up but generally during the data / systems assessment there should be a thorough review of industry standards vs. company processes. I find that our clients appreciate the opportunity to bench mark their processes and data structure elements such as material types and status.  We will start with material type and material status.

Material Type

Material types can be as simple as goods and services or as complicated as service, critical spare, spare part, commodity, generic, blueprint, etc. The material type is a critical element to classify which template is used for setup in the downstream legacy systems with an inventory stocking strategy applied.

Obviously a service can be standardized by the class type to describe the service where a cost for the service can be standardized. The definition of the service is described by the properties, for instance a service class of CLEANING, OFFICE can be set up with descriptive elements such as 10,000 square feet, light cleansing (dusting / vacuuming), etc. From a purchasing perspective, the buyer can run the reports globally to determine how much is spent for office cleaning then evaluate the costs and utilize best practice sourcing strategies and other global supply chain processes to lower costs. The purpose of the standard naming conventions of classes and property are to provide enough standardize information to provide the ability to compare and cost services or products.

If a critical spare is being set up for sourcing and inventory, then the part has been evaluated by maintenance or engineering and determined that the spare is critical for production uptime. An inventory plan is developed for stocking the critical spare including an initial buy quantity, plan for stores (inventory) setup of item’s unit of measure (each, assembly, package, etc.), min / max, reorder quality, stocking location, etc.

Material Status

In addition to applying a “material type” to the item records, due to the longevity of materials used in the manufacturing operation, a material status should be utilized as a long term data maintenance process. In dealing with component manufacturers and suppliers, a component may be active from a plant use perspective; however the component manufacturer no longer manufactures the item. How is that possible? A piece of equipment can have a 10 year or a 50 year life span, to maintain a piece of equipment, a list of recommended spare parts is identified and set up for equipment maintenance. If the spare part component is obsolete by the manufacturer but the piece of equipment is still in use on the production line, the material status would be “obsolete active”. A different buy / stock strategy would be implemented, such as purchase all available stock from the manufacturer or another alternative is to source with unconventional methods such as through eBay or maybe contract the item to be built by a local shop.

Typical material statuses that I have experienced are active, inactive item referenced to an active item, obsolete active, obsolete inactive (typically the status to start the disposal process) and archive. The archive status is a classification used by the analysts to allow the viewing of the item information but is not visible to the client or the item record is not exported to the client systems.

I would appreciate any input or better yet a discussion of the different material types and material status used in Product Information Management (PIM) or Master Data Management (MDM). As an industry we inherited material types and material status used in a purchasing system or maintenance systems designed to meet business function but not from the data quality or master data management perspective. What are the proper data requirements for a material type or material status? The MDM or PIM software companies and data quality consultants need to provide input from the data management perspective to provide long term data management functionality.

PROGRAM OF EVENTS  

Tuesday October 12, 2010

• Pre-conference ISO 8000-110:2009 Master Data Quality Certification Workshop 
• Welcome Reception (includes open bar and hors d’ oeuvres)

Wednesday October 13, 2010

• Opening Address
  Overview: The critical need to maintain the quality of master data.
• Panel PresentationsFundamental updates on the progress of the practical application of the eOTD (ECCMA Open Technical Dictionary), ISO 22745 and ISO 8000 for the collection, validation, and distribution of master data in support of the procurement of goods and services as well as inventory and asset management initiatives. The panels will address the importance to using the standards to define and manage data requirements as well as the latest trends in spend analysis, cataloguing at source and data cleansing and rendering.
• Exhibition
  A unique opportunity to see the latest offerings from leading data service and software application providers.
• Annual Awards Dinner
  Celebrate and share achievements with colleagues and friends.

Thursday October 14, 2010

• Workshops

Workshops will cover new technology and practical examples of vendor specific data quality application software and data cleaning services.

*Content subject to change.

I am a very detail oriented person; I have to be as one of my largest accounts requires me to participate in the day to day deployment of global MDM processes for one the largest automotive manufacturers! I am very interested to learn how businesses in other industries manage their data. I would hope that sharing of information and best practices among industry partners will be a win-win situation. At a minimum the discussion will be refreshing; the sharing of innovative information the will spawn the creative improvement needed to create truly efficient knowledge driven business processes, data classifications, metadata and definitions and translation. . . is anyone interested in discussing the logistics of managing translation as part of Master Data Management?

Is anyone interested in discussing my struggles and sharing yours trying to find standard global translations for ISO UOM (Unit of Measures)?

Is anyone interested in discussing what fields should be included in a MDM Data Governance Program for MRO data; UNSPSC, warranty, term of warranty, lead time, estimated price, ECCN, etc.

What Schema or classification structures are you using for spare parts and maintenance items? What about a discussion on using a public vs. priority classification system?

What are some best practices for migrating, profiling, structuring, mismatching and re-verifying legacy system data?

We have a nifty data mismatch process for manufacturer contact information; will this be easily implemented for a CRM data project? What about patient contact information in the healthcare industry?

There are a few bloggers out there that continually add content to their writings but it is starting to appear to be a small group, anyone out there interested in achieving data quality want to discuss “real” life best practices, lesson learned or discuss HOW of MDM, data quality or data cleansing.

If we’re talking about a large company then inevitably with this new system comes the monolith project with whole organizations of people and processes, projects and documentation. The compulsion is to be sure that everyone, everywhere who has any relationship to it has their input and their needs accounted for. Along the way, the cost of implementation and other peripheral indirect costs have likely negated a great deal of at least any short term savings. Not to mention the potential increase in continuous maintenance costs and loss in performance. These are a few things I’ve learned from experience and I welcome yours.

Always have a specific objective when planning for development or evaluating software to purchase that overrides all others. Start with something like a mission statement, “We need this new system for….”

Determine the Real Needs. Try to separate the “must haves” from the “nice to haves”. Bells and whistles are great but there needs to be a true benefit. Seek a balance between development time, software performance, hardware performance and user experience. I always try to put special emphasis on the user group which stands to benefit the most. Having many users who can do their job faster and more efficiently can add up to real savings versus the few users who have a special need which bogs down the project and performance.

Change is inevitable. If some requests for additional features come along, evaluate them against the mission objective. There is nothing wrong with listening and investigating ideas for project add-ons as long as the benefits outweigh the costs in time and money, but there needs to be a limit or you’ll never complete the project. Good ideas can always be implemented later if it makes sense then you’ll have the benefit of the research already done, but be quick with the research. Evaluate the impact for doing it now or waiting. Here are some good questions to start with: 1) How much more money?  2) Would this be faster/cheaper for programming to do it now versus waiting and doing a more complicated enhancement?  3) Is the impact to the users great enough to warrant it?

Know the roles. Good ideas can come from anyone. Every project must have a project champion who makes the final decisions (and live with them) and also eliminate roadblocks. You need a user advocate who has done the job and knows what it takes. Have programmers who possess both talent and vision, not just code crunchers, and listen to them.

Have good documentation, and “Good” is subject to interpretation. This is another area where the KISS principle is very often not utilized. If you have to hire ten people to sit in meetings just to maintain your documentation you’ve probably overcomplicated it and certainly increased your project cost. I try to start with these principles:

1. Document the people on the project and their responsibilities. Let there be no question as to who does what.
2. Everyone who has a job to do needs to understand what they need to do and have the documentation to reference.
3. Keep the language simple. Focus on getting the point across. If it takes a rocket scientist to understand it you’ve failed.
4. Of course, document the issues, decisions made, by whom etc. but be sensible. Document enough to cover for the “he said/she said” but content is most important. No bonus points for flash.
5. Know who is supposed to have what done and when. Another obvious one here but I see too often where target dates are determined top down with little or no thought to cost or the tasks. Don’t let the tail wag the dog. Pushing hard to get the job done is fine but be realistic. Listen to the people who know before making bold predictions.

I have had experience working with single business home-grown classification structures and third party developed structures for purchase, currently I have chosen an open and public classification structure provided by ECCMA (www.eccma.org). This is beneficial to the customers that I support ensuring that they will always have access to the classification structure sometime referred to as the schema used to classify their data.

Implementing a classification requires setting up Identification Guide (IG) to establish the template definition to technically describe the product or service with enough information to support engineering, maintenance or purchasing while recognizing the limitation of software short and long description required character lengths. The IG template supports and simplifies the required information request to the manufacturer and suppliers to verify all information by our analysts to standardize the description.

To create an IG, we search the ECCMA class list; fortunately many of the classes are established. As the IG is set up we will use the ECCMA established class name convention; this will ensure that every item will be setup with the same name and format, every ball bearing item submitted will be classified as a BEARING, BALL.

The next step is to set up the properties required to describe the BEARING, BALL and for each property designated the data type requirements such as numeric, text string or designated unit of measure. The property value requirements for a BEARING, BALL might include TYPE, BORE DIAMETER, OUTSIDE DIAMETER, WIDTH, DYNAMIC LOAD CAPACITY, STATIC LOAD CAPACITY, MATERIAL and so forth. Our analysts will verify the data to the original manufacturer sometimes using xml to exchange the product information referred to as “Cataloging at Source”, the information requests are standardized and remove much of the quality issues commonly found in a non-standardized data verification or description process.

The property value description build is controlled by the sequence number of each property Item data that will make it’s way into a length restricted description field we place the most important information in the begin of the auto generated description.

Setting up the Identification Guides requires upfront strategic planning and detailed work, as you can imagine that a classification schema can be up to 10,000 classes depending on the industry but it provides a multitude of benefits including standardized requirements, a road map for our analysts to facilitate the process, improved data management reporting / metrics and enhances language translation for the global organization.

The first step is to develop the Identification Guide (IG) in order to baseline the properties needed to best describe the class. For example, let’s take the class of SCREW, SHOULDER and the properties TYPE, MATERIAL, FINISH, THREAD SIZE, DRIVE SIZE, SHOULDER DIAMETER, SHOULDER LENGTH, THREAD LENGTH, HEAD DIAMETER, HEAD HEIGHT, SHOULDER LENGTH TOLERANCE, MINIMUM TENSILE STRENGTH, CLASS, HARDNESS RATING and PACKAGE QUANTITY. The IG also provides the information needed for our analysts to acquire properties and our applications to sequence the properties within the short and long descriptions that are built:

SCREW,SHOULDER – | TYPE: HEX HEAD | MATERIAL: 18-8 STAINLESS STEEL | FINISH: PLAIN | HEAD STYLE: HEX | THREAD SIZE: 3/8-16 INCHES | DRIVE SIZE: 3/4 INCHES | SHOULDER DIAMETER: 1/2 INCHES | SHOULDER LENGTH: 2-1/2 INCHES | THREAD LENGTH: 3/4 INCHES | HEAD DIAMETER: 3/4 INCHES | HEAD HEIGHT: 1/4 INCHES | SHOULDER LENGTH TOLERANCE: ±0.005 INCHES | MINIMUM TENSILE STRENGTH: 80.000 POUND-FORCE PER SQUARE INCH | CLASS: 2A | HARDNESS RATING: B85 TO B95 ROCKWELL A | PACKAGE QUANTITY: 2

Each time an item is submitted for coding or processing the item is imported into a master database. Through intervention by our data analysts, the item navigates its way through a number of checkpoints including an auto-suggest to propose a class. The class and properties via the IG are the requirements our coding analysts use to verify the accuracy of the information submitted, to verify the completeness and to acquire the additional information needed to enhance and build an item or spare part description for our clients to base real business decisions.

The implementation of the eOTD is a two process scenario when working with our clients. First, the legacy data is mapped to the class, the item data is profiled, cleansed and enhanced to meet the requirements of eOTD IG, ensuring the client’s data quality goals are met. The updated item information needs to be applied to existing client item data. It is critical that all changes to data be tracked and logged. A properly planned and executed update to legacy ERP and CMMS systems should be initiated to incorporate the enhanced and corrected item information into the user facing systems. This is an extremely critical step as the downstream information flow will affect systems and uses such as inventory re-distribution, purchasing and contract management, engineering bills of materials and maintenance schedules. A thorough and complete mapping of data through the enterprise should be used to understand data flow across all business units. The mapping should include data entry points and data use points through all departments which set up all of the cost saving pay points as the data processing is streamlined.

The second process is an on-going data maintenance plan for new items that are introduced into the organization. This process should start at the introduction of item information into the system. All items and spare part information should be verified with the manufacturer and classified to the eOTD before setup or use in any system. The length of time the coding process requires is a critical element as the item or spare part information should be as complete as possible while at the same time be ready and waiting for the buyer to put the item on a contact or a maintenance employee to setup the tasking information in the CMMS for a piece of equipment. The only requirement for the employees who use the information after its initial entry into the system is to perform the actual requirement of their job and not to decipher a cryptic unstructured description.

If the items are pre-processed using the eOTD and the associated ISO standards, every item and spare part will be structured and standardized. The engineering, purchasing and maintenance departments will focus on the core of their day to day specialized responsibilities instead of searching for parts or dealing with trying to purchase items that a supplier does not recognize or have to acquire the missing information.

We all agree on some of the basic benefits both in process and cost such as reducing inventory with the identification of duplicate items, facilitation of inventory sharing and internal purchasing programs, reduced employee time searching for parts, common spare part usage strategies, reduced downtime in manufacturing equipment due to lack of information availability and ability to manage using a just in-time inventory model. The eOTD and its Identification guides are the building blocks and the roadmap to achieving structured and accurate data that can be reliably used to base real world decisions.

For more information on the eOTD please visit www.eccma.org.

Here is the million dollar question, this is one scenario: Over a million records in a year, legacy and new records submitted for processing from 2,500 different users and two different business processes (single submit and BOM extract). What technology would be required to intelligently automate the processing of these records to a Master Data Quality Standard?

Remember this is an on-going maintenance process, not a one time migration of non-cleansed data to a new ERP or maintenance system, nor am I referring to parsing the records into different fields of the new ERP system but ensuring that the records are verified, structured, properly attributed with full descriptions and additional information to support the business needs.

First, let’s look at the Wikipedia definition of Product Information Management (PIM) “PIM systems generally need to support multiple geographic locations, multi-lingual data, and maintenance and modification of product information within a centralized catalog to provide consistently accurate information to multiple channels in a cost-effective manner.”

Future PIM software purchasers, what evaluation methods are you using to ensure that your PIM software purchase will support the continuous update and flow of data for your entire enterprise system? Here are some items to take into consideration during your evaluation, these are all items that I ask about and would recommend that you request the answers in writing:

1. How is the change history of the data stored in the system and how easily can it be retrieved?
2. Has the performance of all modules of the software been tested and what is the base line?
3. Request references (at least three) for each module of the software.
4. What is the software product work flow and how is the data processing assigned to employees?
5. Ask to review the documentation and take the time to review; this should be a window into the complexity of the system.
6. Request the design process model and how the software company incorporates customer feedback?
7. What is the bug fix process? What is the quality system to implement a bug fix?
8. What is the software company’s philosophy on customizations at your cost?
9. How is language handled? Translations referenced to a master record?
10. If the software solution is multi module system, how are the master records referenced through
the entire solution?
11. What are the long term design strategies or road maps for each module of the software solution? Ask for the earlier road maps and the software release note to evaluate the how well the software company plans and implement updates to the systems.

And I can go on and on, the licensing; customizing and implementing software in your environment can be extremely costly and time consuming, does Caveat emptor “Let the buyer beware” work in the business world or is there a “Lemon Law” when purchasing software?

Here are a few data management tips:

1. Data needs a simple way to be imported into the system. Data comes from a number of sources so a dynamic mapping and import procedure to an internal processing area is useful for data analysis.
2. Yes, there needs to be an area to work on data before it is promoted to a Master Data Status. Software developers need to understand that data is never in a pristine state ready to be entered as a Master Data Record. Never!
3. Data processing requires a managed work flow through the system. Imagine the issue to have thousands of records for analyzing and many employees trying to manage who has what records outside the system. Just not functional work scenario.
4. Never copy data from one software module or grid to another, always reference. Cost per record to manage the data is increased every time a person needs to manually update an aspect of a record more than once.
5. Performance of the software is imperative. To really capitalize on software and technology reporting and analysis need to be done on thousands of records at a time. Time is money.
6. Provenance tracking is extremely imperative especially when “Cataloging @ Source” is the foundation to the quality of the record. Data should be identified with history: where the data originated, contact information, data and time, a revision level, file name, all associated records on the file, etc. MDM system developers, can you start to see the importance of this information?
7. Data needs to be cleansed and profiled; it is important that the software processing tools understand all aspects of the data. For instance search rules should not be so rigid that it takes an analyst manual actions to find a duplicate record because of an extra space or a slash. A worse case scenario is to take the data out of the system to work the data in excel, I am not going to even comment any more on that scenario except that it is totally unacceptable to remove data from a system to try to normalize it. Remember there is a lot of data brought into the business and the cost to manage the data is not core to the primary business, it is an indirect cost. The solution is not outsourcing to a “low cost, low skilled” worker in another country when much of the preprocessing can be done at the expense of CPU time.
8. Data changes, if you have a number of different modules in your software package what is the strategy to support aggregation of the changes to the different business units using the data? Does your software only update in one module and the other modules are in an out of sync situation? Again remember software should be designed to simplify the processes to support the business needs.
9. We live in a global economy language translation and localization of data is more important now than ever. What are the methods translate and maintain localized data?
10. Reporting and exporting of information is critical. It is a requirement to export a segment data set to send to a business customer or run a report of the activities of the work. A MDM system must be able audit data activities through the complete process of import through promotion to a master record.

I am a firm believer that software should not dictate a business process but should be designed to streamline and add efficiency to lower the cost the activity. If you are designing MDM systems, your team should include experts in data management, data quality and business process expertise with applicable experience. Businesses should not be paying for customizations to your software to be support basic 101 management of data.

What is your Life Cycle Data Management Strategy?

1) Drawing Libraries – The items in the library need to be cleansed and profiled to a classification schema. The schema requires standard naming conventions and technical descriptions. The schema can be designed within your company, priority purchased from another vendor or you can opt for using an open classification dictionary for public use such as the ECCMA eOTD.

2) Common Component Listing – provides a listing of preferred components that support the inventory management strategies for your organization. All equipment designers and builder are required to use the common components identified. Note: common components are set up in the drawing libraries.

3) Spare Part Acquisition – Place the components on purchasing contacts at the beginning of design, this will facilitate the ease of spare parts planning and purchasing. An item on contract provides purchasing the data needed to run analytical algorithms in order to better negotiate pricing organization wide. If the item is set up accurately to a standardized classification dictionary with technical descriptions only one time the whole organization can realize the benefits of the Life Cycle Data Management Strategy.

4) Inventory – supports optimal inventory management by promoting the ability to plan stocking levels and strategies with nearby facilities. Think about the implementation of spare parts sharing or an internal purchase first program. The most important requirement is the standardization or normalization of the data; the part needs to be classified only one-way and should be shown in every system the same way.

5) Maintenance –The use of standardized components coupled with a data management strategy allows the organization to streamline the number of different components used to serve the same function on different equipment. Also reducing the number of parts in inventory and maintenance management tasks.

Life Cycle Data Management Plans starts with component standardization and cleansing the data in your equipment drawing libraries and all downward systems including maintenance. This strategy avoids duplicate inventory items and at the same time promotes an internal purchase philosophy that puts a priority on inventory sharing before issuing supplier purchase orders. Standardizing inventory with information elements such as predefined stocking levels, identification of critical inventory, functionally equivalent item identification and purchasing analytics as well as enhanced vendor management are all necessary steps for a manufacturing business to remain competitive in today’s world of lean low overhead manufacturing.

The data quality issues that industries around the world are experiencing have occurred as a result of many years of manual inventory and purchasing record maintenance, through mergers and acquisitions of companies and business units as well as data migrations from various legacy systems into new fangled ERP black holes. There are a number of reasons why.

A common data trap frequently fallen into is assuming that just because you are implementing a new ERP system your organization will now have quality data. Remember the old computer motto – “Garbage In, Garbage Out”. Let me tell you based on first hand experience that there is nothing “sexy” about bad data when the production line is down or any other time.

Data Cleansing and Data Profiling is a very tedious and detailed oriented service. There are a number of key rules to follow whether the profiling and cleansing work is done internally or outsourced to someone who specializes in data cleansing. Here are some rules to consider before a project is started:

1) Conduct a detailed and comprehensive data mapping through all internal systems including engineering, purchasing, asset management, plant inventory management, etc. The goal is to standardize and document all data sources within the enterprise one time and ensure that each department is accounted for and determines what data elements are required to complete their business required tasks.

2) Build a central data cleansing database and make sure all locations using each item are referenced. This ensures that updated information will be passed back to the various legacy systems. You will need old information and updated information for this stage of the process.

3) The data cleansing database should include a balance of electronic scripting for data corrections and manual auditing. A solid process for answering questions needs to be set up. My preference is that the system should use a web utility that tracks data change history and other data related information such as contact information, issue resolution status, classification, questions and answers, etc.

4) The data needs to be referenced to a classification schema and a standard implemented for descriptions and properties. The schema can be designed within your company, priority purchased from another vendor or you can opt for using an open classification dictionary for public use such as the ECCMA eOTD.

5) Free text is not our friend in the data standardization world. If all possible use a system that has built in data rules and ensure anyone entering data into the system understands the standards and the importance of quality data in addition to the high cost to businesses using bad data.

6) Data Cleansing and Profiling the proper way is not “cheap”, but the cost of cleaning the bad data is always less than the expenditures incurred by cleansing your data multiple times or continuing to operate your organization based on erroneous information generated from one or multiple dirty databases.

Cleansed data permits the removal of duplicated inventory items, an internal purchase philosophy that puts a priority on inventory sharing before issuing supplier purchase orders, standardizing inventory with predefined stocking levels, identifying critical pieces of inventory, identifying functionally equivalent items, use of engineering component standardization libraries and facilitates purchasing analytics as well as enhanced vendor management.

To realize cost savings from new process efficiencies, these separate legal entities need to integrate the information flow and internal groups within each entity such as purchasing, manufacturing engineering, plant maintenance, facilities management, warehousing, commodity management, and asset recovery. Each area must share the mission-critical master data related to the spare parts. Truly integrating the information flow within the conceivably 50-plus business units that indirectly work together across the automotive supply chain to deliver just one item to an OEM sounds literally impossible and cost prohibitive. However, your opinion may change when you read the next couple sentences.

It is estimated that process failures and bad information cost business $1.5 trillion or more in the U.S. alone (Larry English, 2007). A study of large companies, a majority of which have revenues of more than $1 billion, found that 31 percent believe that their costs for incorrect data are $1 million or more per year (Dave Waddington, 2008). The most common element needed by (and from) all involved in the supply chain of the spare parts that keep our lines running is data quality and content as information is transmitted from one organization to another.

Figure 1. Typical Supply Chain Spare Part Data and Information Flow

There is a lot of activity and even more information available around Master Data Management (MDM). MDM and data quality initiatives have become an industry trend these days. To champion a successful MDM effort, formal strategies regarding data standardization in content and structure, as well as import, storage, display, and transmission from your enterprise resource planning (ERP) systems to industry partners are mandatory.

Every supplier, OEM, and manufacturer is using a unique set of data standards to attempt to achieve true “quality” for their data. But how powerful, efficient and beneficial to the automotive industry can the use of silo developed standards be? If all partners were using the same data standards, naming conventions, and requirements to describe spare parts, we can greatly streamline the process needed to exchange the information and at the same time reduce the number of physical and business process failures resulting from the low-quality descriptions contained in our legacy systems, and in most cases, new state of the art ERP systems.

The elements required to achieve a symbiotic information flow for the automotive industry are the same:

A common understanding of what data is needed for a particular class or type of item;
A common method to store the data;
A common method to display the data; and
A common method to transmit the data to those entities that do business together.
The answer is to simplify and standardize the methods used for the exchange of structured, accurate, and efficient data-sharing in an automated fashion, rather than manually sharing as it has traditionally been done. The Electronic Commerce Code Management Association (ECCMA) and DATAForge LLC have formed the Automotive Industry Content Standardization Council (AICSC). The purpose of the council is to facilitate the addition of automotive industry specific terminology to the electronic Open Technical Dictionary (eOTD), create identification guides for quality descriptions, or data requirement statements for individuals, organizations, locations, goods and services.

This also helps develop an automotive supply chain specific spend analysis classification. The dictionary being maintained by ECCMA and the AICSC is ISO standard and public domain; any organization can benefit from its use. ECCMA and the AICSC work with automotive-centric businesses to standardize the way data and information is stored, viewed, and exchanged.

Figure 2. Quality Description:

ECCMA has brought together thousands of experts from around the world and provides them a means of working together in the fair, open, and extremely fast environment of the Internet to build and maintain the global, open-standard dictionaries that are used to unambiguously label information. ISO 22745 spare parts data is capable of being used in any ISO 8000 computer application (neutral exchange), is easily translated, and must stand the test of time (long-term data retention) by using a public domain concept identifier.

Jacqueline Roberts is vice president of DATAForge LLC. For more information about ECCMA, visit the ECCMA Web site.

View web publication:

 http://aiag.informz.net/admin31/content/template.asp?ps=4683&sid=4683&brandid=4002&ptid=406&uid=0&mi=390242

Typically, maintenance or inventory information is not given any due diligence until it is needed. For instance, a bill of material (BOM) is received, all the parts are set up in your ERP system, and the item record sits untouched until you need to place an order or set the item up in your maintenance system. Then you find that the part number is inaccurate and the supplier doesn’t recognize it, or there is an essential piece of information missing from the description needed to complete the order and bring the line back up. There is a solution: ISO-22745.

The ISO-22745 standard provides the framework needed for any organization to conduct business with internationally recognized data quality. Its most basic purpose is to provide a means to realize the benefits of ISO-8000, which is the ability to specify syntax, semantic encoding, and specification of data requirements for messages containing master data that is exchanged between organizations in the supply chain. Once an organization begins to standardize the descriptions it uses to describe materials, the organization can also begin to see cost savings and cost avoidance by implementing business intelligence algorithms to identify conditions such as duplicate items in inventory, purchase price disparities between facilities, vendor reductions, and identification of functional equivalent items.

ISO-22745’s primary facilitator is the open technical dictionary (OTD), a database of concept IDs and associated descriptive words used to “tag” individual data elements. Once each element is tagged with the concept ID from the OTD, the descriptive elements can be stored, sent, received, and displayed by different organizations without losing any meaning. This is done for multiple languages at once, with no need to translate into multiple languages independently.

ISO-22745 also includes guidelines for the use of identification guides (IG). An identification guide is a statement of requirements describing what data is needed about an item. If all elements are included in the description, this IG facilitates the machine-aided analysis of data quality because we have a clear understanding of what data is required without a person having to review the data.

ISO-22745 describes XML formats that can be used to automate the exchange of ISO-8000 master data.

i-xml is used to specify the data requirements or IG.
q-xml is used to query another organization for the data elements specified in the IG.
r-xml is used to reply to requests for specific data elements.
Together, these formats allow for the machine aided exchange of master data.

The Electronic Commerce Code Management Association (ECCMA) provides a very mature OTD, known as eOTD, which contains more than 440,000 terms that can be used to generate descriptions. ECCMA and DATAForge have also formed the Automotive Industry Content Standardization Council (AICSC). The AICSC is here to help organizations move from proprietary methods of managing descriptions to an ISO method that includes working together as an industry to meet the common goal of lowering operating overhead related to catalog maintenance.

Chris Roberts is an associate product manager at DATAForge™ LLC

For more information on AIAG’s activities and initiatives in electronic commerce, visit the AIAG Web Site or contact Mohammad Abidi.

View web publication:
http://aiag.informz.net/admin31/content/template.asp?sid=4762&brandid=4002&uid=0&mi=396973&ptid=415

To realize cost saving from new process efficiencies, these separate legal entities need to “integrate” the information flow to manufacturers and within each manufacturer to internal groups such as purchasing, manufacturing engineering, plant maintenance, facilities management, warehousing, commodity management, and asset sharing / recovery need to share the mission critical master data related to the spare parts. A truly integrated information flow could conceivably touch a number of business units that indirectly work together across the supply chain to deliver just one item to a manufacturer. The most common element needed by (and from) all involved in the supply chain of the spare parts that keeps the equipment running is data standardization, data quality and an electronic method of transmittal. A study of large companies, a majority of which have revenues of more than $1 billion, found that 31% believe that their costs for incorrect data are $1 million or more per year.1

Data standardization and data cleansing cost should be covered with cost saving initiatives. In addition to the initial data cleanup; strong data governance processes should be implemented for on-going data setups.

1Dave Waddington, “Growing Adoption of Master Data Management by Business?” citing an Information Difference survey of 112 companies, 65% of which had revenues of more than $1 billion, IT-Director.com, IT Analysis Communications Ltd., June 23, 2008.

Buyer/supplier information synergy to me means that at any given time, if a piece of data is needed to complete a product description or a piece of data is needed to place a product or service order that is not available in your ERP applications, your suppliers are willing and able to provide the piece of data automatically without human intervention.

That probably sounds ridiculous.

This situation probably sounds more familiar:

1.) New equipment is installed
2.) The recommended spares list is loaded directly into ERP
3.) The new equipment malfunctions, goes down
4.) Production stops
5.) The maintenance department attempts to replace failed component only to find there is no inventory
6.) Maintenance frantically calling machine builder/suppliers/plant engineering to identify the failed component

This may be an over simplification or might not be something your organization can relate to, but, there are several types of technology and business process that enable prevention of this scenario and other problems that plague the large manufacturers supply chain.
—a common unified schema or dictionary used by all commercial organizations to label product information (eOTD)
—a common method of transmitting this information directly into ERP prior to the need arising to replace a component (xml)
—develop a supporting business process to ensure the needed information is requested (people)

As manufacturers/suppliers/BPO providers we all need to work together to move to a common method of requesting, transmitting and receiving the information we need to keep our operations running.

How would a buyer know that these are the same parts? Two different manufacturer names and two different part numbers; this scenario will cause duplication in a purchasing system. The result is the additional work of creating and maintaining two contracts but also cause downstream effects such as excess inventory with more than 1 stocking location, lack of a volume purchase or a global view.

 Question: Is the answer to always to confirm the actual manufacturer and set up supplier references?