I spend a lot of time analyzing the product data quality, missing data elements, system accessibility because the data elements are impossible to pull out of the system or not collected to support our clients’ enterprise requirements for purchasing, engineering and maintenance decisions. I have to admit, I am always astonished by what I see (or don’t see) and the time and cost to pull data from a system. The reality is the data entered in these systems and the systems themselves are considered a support function (indirect or non-product activity) and not the core revenue generating stream for the business however the data is the life support of BI, accurate and available data is critical for smart and efficient business decisions. The missing gap in most business intelligence programs is a foundational flaw, referred to as data integrity and data quality or the lack thereof.

A business has two options, augment their BI decisions with a data quality scoring model, IDHS, a simple example “I am confident that our inventory budget should be 1 million dollars this year, based on the IDHS (+/- 30%) the actual budget could range from 700,000 to 1.3 million.”  The easiest reality is to budget the 1.3 million, with the plan to come in under budget, .3 million provides a safe cushion. This also alleviates the over budget spending and the tedious tasks of re-budgeting or canceling other important initiatives mid quarter / year.

The other option is to incorporate a structured and standardized Master Data Management process with Data Governance to collect, manage, cleanse (legacy / new data), enrich and disseminate information to the various systems. The goal is to create one master record set to ensure that decisions are based on accurate and complete data sets to implement meaningful BI reporting and analytics.

The results of data quality improvements are because of the requirements and processes of MDM. My definition is “An MDM program includes the Data Governance to define data requirements (structure, format and content), and the data processes to manage data activities such as collecting (extraction of BOM data or the data request web form), evaluating, matching (auto and mismatch), structuring, verifying and enriching to minimum data requirements, tracking history of change and data use, quality-assurance, reporting and distributing data (MAXIMO, ORACLE, SAP or another client’s systems) throughout an enterprise to ensure consistency and control. The MDM program will also include an on-going data maintenance process to manage data updates for this information.”

The following elements of data quality should be part of the governance program for your master data. This is critical to support a global enterprise. The discussions and metrics should include:

Accuracy: We intellectually understand the meaning of accuracy. An email address is either right or wrong, however in the product information world it can be a little more complex, this is where data governance is instrumental. The same spare part can be purchase from the manufacturer (one part number) or maybe a supplier (another part number)? A part number can be many different versions; for instance, a master org record is setup with a part number to purchase safety gloves, except one part number can’t buy you safety gloves; you must include the size as a description element in order to purchase. The result of an inaccurate glove record is you may receive all small gloves, but you really wanted large or you may not receive any gloves. Different manufacturers and suppliers have different ordering and purchasing rules.

Standardization: Is absolutely critical to BI reporting. Standardization is the map to how data is entered, referenced and stored to support ease of data access. The data elements should include classification naming, attributes, part numbers including formats, unit of measures, manufacturer and supplier names, addresses, web urls, relationships to parent companies and so forth.

Structured to support multiple uses: If you have one master organization and are only concerned with purchasing systems then structure may not be a concern, but to a global enterprise with multi-systems, the structure of use is extremely important as the data is disseminated to maintenance or inventory systems. In a purchasing system a ’Bearing, Ball’, part number ‘12345’ should only be set up once but in an “end use” structured environment, that ’Bearing, Ball’ is referenced to many pieces of equipment located  and used on other equipment and in other plants, it is also listed in engineering drawings, etc. If the multiple use structure is set up correct you can report “where used” for inventory sharing, internal purchasing programs supporting reduction in inventory.

Completeness: Having all data elements entered into the system required for the safe and efficient use of each item. If your data set has some missing prices and a report is provided the value of the inventory, obviously the report is inaccurate. The governance requirements include minimum required data elements. In the world of product data, the process may require a special speedy set up for a critical item that is urgent, however the MDM processes includes going back to acquire the missing information.

Accessibility: The ability to pull information from a system is the foundation of reporting. This is a continual struggle when I am working with a new client. I often ask the questions, “Is the expertise available to be able to query and pull data as needed from existing systems?”, “Is the data stored parametrically or as concatenated text fields?”, “is the table structure extremely complicated?” Accessing the businesses information and providing the ability to slice / dice the information critical to BI.

In this fast moving, big data intense world of collecting and storing information for businesses, the reporting and analytics to enable meaningful decision making is critical, so I ask the question “What does data have to do with business intelligence? EVERYTHING”

In the perfect MDM world, naturally not only does the data (product, services, spare parts) adhere to governance, structure of classification, quality and content but also a data structure of location of use. An example of structure could incorporate naming standards for location of use, for example plant or office. Within the plant, the use could be referenced to a department, referenced to a piece of equipment and to a specific location within the department. This type of structure is preset in a MDM plan and will benefit the maintenance data structure. The MDM data plan and structure meets the requirements of the complete enterprise, the purchasing department may only require 5 or 6 data elements but the maintenance department will require 10 or more. This is why Master Data Management requires a complete view of all data concepts and use.

Think of how powerful the analytics are if the enterprise is set up with established standards through governance for plant / facilities location structure, location names, equipment location structure and equipment naming standards. The benefits include the ability to view equipment and spare parts enterprise wide enabling the initiation of common spare parts strategies, spare parts sharing programs supporting inventory planning and reduction.

This type of MDM planning also supports equipment moves or disposals with the view of spare parts associated to the equipment. The spare parts can be packaged and moved or disposed of at the time of the disposition of the equipment. I can’t count the number of times that I have been told that I am not even sure if we still have this piece of equipment that these inventoried spare parts are used on.

Now the beauty, yes I said beauty, is that the required data structure can be set up with templates, written into requirements and contracts to equipment suppliers and when the bill of material data deliverables are sent to the engineering department of the enterprise (entry point) ensuring the data location governance structure is audited and at that point accepted to start the data cleansing and purchasing setup or rejected to fix the data structure errors. Other key data elements are classification, verification, enrichment and translation before the data is setup in any of the enterprise systems.

The by-product of the well executed MDM governance plan is that once the spare parts data is processed, the cleansed record is then propagated into the purchasing system, engineering library and maintenance system. The maintenance system is fully loaded with spare parts information associated to equipment and locations of use ready for the maintenance staff to set up their tasks for the equipment maintenance and planning strategies.

A flawed philosophy is to migrate the legacy data, meet the deadline, call the project green and successful while the users must figure out to how to correct and update the data. These ERP systems are not designed to handle the volume of change to data, provide a simple method to track change, obsolete a record with history view and archive functionality is non-existent.  Another reason this is a flawed philosophy is that purchasing contracts are set up based on the “bad” data, a unit of measure, part number or manufacturer change will void a contract resulting in wasted time of valuable resources and at the end of the day an inability to source the item, this could set in motion a critical manufacturing line shut down. Let face it, an ERP system is designed store a product or service record providing the business a method to transact, not to cleanse a record to a single master version of an accurate classified, verified and technically described Master Record. Therefore the activity of migrating data to a new system is not Master Data Management.

Master Data Management needs to be independently structured and separately managed in the organization not through IT. It is critical that within the Master Data Management organization to properly represent the business assets of the data (engineering, purchasing, customer, etc). The data is the core information used as the foundation to run the operations, sometimes referred to as the BI for the analytics of sound decision making processes. If the data is incorrect in the new systems, how is the BI improved? How is the business case ever calculated and successfully achieved? I can’t even imagine trying to tally up the potential “cost savings” when bad data is migrated to a new system.

Establishing a MDM program will need to have clear and well defined ownership, stake in the end user organizations and representation in the design and schedule of the software roll outs with full participation in all the projects with data involved. They should also participate in the project design strategy for systematically cleansing, classifying and migration of the data to the new system. Strategy should include an audit of data in the legacy system, let’s face it there maybe 20 year old records with no transactional history or balance on hand in inventory. Should this data be moved to the new system? The answer is NO.

An MDM data strategy to support the IT team can encompass a number of options. A simple option is the publishing of a long term schedule establishing adequate time for the data group to meet the data cleansing and classification requirements. This is not always possible, so what about a phased strategy? Some of the possible steps should include

• Evaluation of data to review transactional use 
• Evaluation of the stock on the shelf and confirm that none of the inventory should be obsolete and disposed of.
• Review of data related to the equipment but is not inventoried
• Identify data that should not be moved to the new system
• Establish data priorities for cleansing starting with high transaction use and stock items classified and cleansed first.

An ongoing maintenance and new set up process is imperative to be established with an easy method to request an urgent record during the data migration to support the day to day operations of the business.

We need to get out of the mindset that MDM is simply a data migration to a new system. MDM is a business process to establish the single version of accurate information which is then propagated throughout the organization, part of which is the proper migration of data from legacy systems.

 A key component for Master Data Management (MDM) is data cleansing which has multiple disciplines such as address cleansing or PIM (product information management). My expertise is in PIM, therefore my meetings have been focusing on data in the ERP and Inventory system.

My latest meeting was with an informed Material Manager, he understood the concepts of master data management, after the introduction meeting, he stated that “We had a data cleansing project and it did not work, I ended up going back and correcting the data.” Through the discussion, I came to believe that the data cleansing company, extracted the data and attempted to auto classify a half million records. As a purchaser of these types of services, I asked what was the process for mapping and quality checks?

The business issue is the buying team’s inability to utilize spend analytics and the solution is that the data needs to be referenced to the UNSPSC^® (The United Nations Standard Products and Services Code^®). The scope of the project is mapping the purchasing data to the UNSPSC^®. In my experience, I have identified four general levels of PIM data cleansing, 1) auto mapping 2) auto mapping with a manual review 3) verification and 4) enrichment. The cold hard facts are “buyer beware”.

The detail of the levels are:

1. Auto mapping: if you have a large collection of data, automation is a requirement however there are some issues. First, auto mapping incorrect, incomplete and inconsistent data will result in a system that will still have incorrect, incomplete and inconsistent data. The quality of the auto mapping is dependent on the structure of the data. If the data is structured to a noun or class, the auto mapping process will have high quality rate. If the data is set up as “free text”, the results will be dismal. This method will not address duplication or data quality in your system.
2. Auto mapping with a manual review: this process will take the results of the auto-mapping process and add a step of a manual review of the data. The question of the review, will all records be audited in the review, or is the process to review just the records that when the auto mapping just failed? How will consistency of the audit be managed? Again there are still the inherent issues as described in the auto mapping process.
3. Verification: In order to improve data quality, the data cleansing process requires verification with the manufacturer (service or product). The verification process assures that the purchasing record is set up to the correct manufacturer (referenced to the supplier via the contract), part number for restock ordering, UOM (Purchasing Unit of Measure), description with correctly classified i.e. BEARING, TAPER and the UNSPSC^®. Our process is to request the manufacturer to provide the UNSPSC^®. If the manufacturer cannot provide the UNSPSC^®, the item is correctly classified; the auto map to the UNSPSC^® will be successful. The verification process positions the data to identify duplication, manufacturer obsolescence and inaccurate data requiring additional information from the business to reconcile.
   
4. Enrichment: The fourth level of data cleansing quality, in addition to verifying, the data is enriched, this can be obtaining a price, warranty with the terms, additional description attributes, ECCN (Export Control Classification Number), recommended repair spare part information, eCl@ss, NSN (National Stock Number) or any other data element your business requires.

The conclusion is asking the right questions of how my data cleansing project will be implemented and managed are essential to making it a successful data cleansing project.

My first question is “how you would get information when it’s not in your system”? Does your supplier manage inventory for all of your plants and facilities resulting in a global view of spend? Does your supplier manage your data to the OEM or to suppliers so you have duplicate inventory costs?

Just considering the MRO items, the information could come from engineering or the integrated supplier. Logically, the integrated supplier would have been provided the part information from your company in order to setup and purchase the items in the first place. It is likely that they have the records as they were given them and they are linked to item setup in the purchasing system. The top level source would have been engineering who would have either had the equipment constructed or been responsible for the equipment purchase and the parts along with them. If after or during the purchasing activity the “key” item record is setup in the purchasing system using the part supplier information versus the OEM information, this will lead to item duplication. Duplication then will create overstock, variant pricing, variant lead times and other inconsistencies that add unnecessary cost.

Based on what you are saying it sounds like items in your system are based on either the part supplier data or specifically identified by the integrated supplier (their item number). The best scenario is when the OEM part is what is setup as the key item, having the purchase action to the OEM directly (OEM setup as a supplier) removing the “middle man” cost. Second after that is having the OEM part as the item, linked to the specific supplier(s) for purchase. Local purchase suppliers are still linked to the same item also. Having the same item record used across the enterprise is optimum.

I would also add that there should be a means to discover OEM part information as a reactive purchase need comes from maintenance. Parts are typically identified physically with OEM information. For example an Allen Bradley/Rockwell module with have the Allen Bradley part number physically stenciled on it. If a part breaks and maintenance needs one, there must be a way to find out if that part is in stock and a way to buy it if is not.  We believe that enterprise wide viewable, verified and standardized OEM part information will reduce the cost for maintenance by eliminating the time consuming discovery of part information in your systems and the correct parts are stocked. This approach also enables part sharing between facilities that is limited without common data. Part sharing in turn reduces overall cost through reduction of inventory.  With plants here in the U.S. and worldwide, this type of advanced planning is where the true brunt of the savings come through.

Obviously, much depends on the specific agreements with your integrated supplier. But consider the following questions. If the data stored in your system is not the OEM information then it’s logical to assume that it is data created by the integrated supplier from the OEM data.

    1) How does your company know that the information is accurate? Are there any checks between the data given to the integrated supplier and what you have in your system?

    2) How does your company know if they have the correct parts setup in the system and stocked appropriately? It seems that there is an opportunity for the integrated supplier to setup and stock items which aren’t necessary and would only be discovered through data transparency.

    3) How does your company know that you are getting the best price on parts? Even if there is a cost savings agreement with the integrated supplier, if there are duplicates the opportunity for piece cost reduction is lost when the true usage is not known because of part duplication. 

My second question in this. It seems from your response that everything is running quite smoothly. But is that true in Manufacturing? Do they ever experience loss of production because a vital part could not be found or was out of stock? How about Maintenance? Inventory management? Engineering? These are the departments that should be surveyed because there is a benefit for them too.

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.

Speaker submission guidelines can be found here: Online Proposal Form.

All questions regarding speaking may be directed to Wilshire Conferences at maya@wilshireconferences.com. The deadline for submitting your proposal is June 4, 2010, and we anticipate being able to notify accepted speakers by June 14, 2010.

Thanks and we look forward to hearing from you!