How much rich item data should be provided?  It’s important to consider not only the information required identifying the item but also the data elements required to support your information systems infrastructure.
Classification and Normalization are fundamental elements to your data quality decisions.  If you elect to use simple content with a very high-level classification structure, you lose the ability for spend analysis at the item level.

For example, if all office supplies are mapped to a UNSCPSC code of 44120000, you classify all of these items at a second tier level and thereby lump together distinct product categories—such as pens and printer cartridges.  Your ability to identify your spend in either of these two distinct commodities is limited as they are blended together with hundreds of other commodities. While the effort associated with sub-dividing this category make little sense in the procurement transaction itself, it could be critical to your spend analysis and future strategic sourcing efforts. 

Normalized content or data is just as important for certain commodities, although it is simple to select the correct ink pen from a description and a picture, selecting the correct 2000 PSI pump becomes a challenge. 
Normalized data not only allows users to compare items from a fit, form, and function perspective, it also enables important business processes such as asset tracking and management.

Although it may seem that a simple catalog with a nice picture and a marketing description meets basic user’s discovery needs, without the appropriate data quality for your content you could be diminishing your enterprise automation potential in other areas of the business.

-Raul Rom

• Ability to analyze data in any Entity Data Container (Analysis Services)
• Ability to normalize, standardize data (Transformation Services)
• Ability to have a workbench environment with the right checks and approvals while working with data quality issues

Some of the key components of the DQM module will be:
• Data Quality Dashboard
• Data Quality Profiles Configuration
• Data Quality Workbench
• Service Jobs
• Data Quality Administration

-Raul Rom

A good PIM system needs to provide an easy integration environment for the master data to move in and out of the PIM application. A Unified Data Model (UDM) intends to provide a core data model framework to achieve this. This Data Model is a logical representation and need not have a direct co-relation with the underlying database table structure.

What is your PIM Data Model?

1. Expertise
PIM would be one of the cornerstones of your SOA strategy.  You need PIM experts who can help you integrate the PIM solution into your overall architecture to derive maximum benefit.

2. Ability to Adapt To Your Business Model
Is the Vendor Solution based on a flexible and extensible Object and Data Model? Companies should look for a solution that is able to map their business model  with the flexibility to change to meet changing business requirements.

3. Proprietary Vs. Open
Could you extend the solution by yourself or are you tied-in to the vendor? Your needs will change over time – make sure you have the ability to customize and create a PIM solution  that meets your needs.

4. Understanding Your Data Sources
Data migration and integration constitute the biggest challenges in a PIM implementation. Size  and complexity of data and integration requirements are the key factors that might cause project delays. You should select a Vendor that has robust Data Migration and Integration Tools.

5. Speed Of Implementation
How quickly can you deploy the vendor solution? How easy is it to configure the solution? How easy is it to build custom enhancements? These factors could make a difference of weeks or months and significantly impact project ROI.

6. Willingness to Prove Value
Is the vendor ready for a quick pilot?

7. Risk Mitigation
Is the Vendor willing to work on a pricing model that will help you mitigate your risks and ensure ongoing positive ROI?

-Upen Varanasi

MDM is concerned with creating repositories of master data for use across the enterprise. Business workflows and processes should be handled by other applications and not by the MDM system. Let me give a couple of examples:

1. In the retail industry, you have the scenario where you have one or more master catalogs but you could have multiple slave catalogs for each geography or customer segment. Sometimes you wish to use a different taxonomy for the different catalogs and also want to specify different marketing information. The product bundling and configuration could be completely different. So it is not just a case of different hierarchy management but you could have complex data reuse and customization scenarios built in. Now is this the domain of MDM or PIM? I would say PIM.

2. In the buy side of an oil & gas enterprise, you have to deal with master data regarding plants, equipments, bill-of-materials etc. The data aspect of managing this is not too complex. The complexity lies in managing the process that would lead to effectively and accurately capturing the master data. Are these processes to be coded in the MDM environment?

Our belief is that MDM systems need to maintain information needed to accurately identify the entity and to have cross-reference information to other entities. If you start going deeper than that, you will have a case where you end up building a monolithic architecture that handles data and processes regarding all the master entities. This would lead to a nightmare scenario of most enterprises as they would get locked in at both the data and application level logic layer to a single monolithic architecture.

More on this next week.
-Upen Varanasi

Stay Tuned for the article next week.

-Raul Rom 

-Upen Varanasi