In this blog post I’m going to talk about a couple of the likely pain points in your product master data world –places where your product data is far from frictionless against your business processes and goals. Specifically, your world of products (and how they are organized in relation to each other) and your vocabulary standardization rules for re-formatting what your suppliers send to you as product data.
Our experience with clients has resulted in a proprietary methodology for implementing product master data projects – built from common, repeatable process steps. This post is just a tiny snippet from that methodology. I’m planning that future posts from me will call out for conversation other steps and processes in taking a methodology-based approach to these kinds of projects.
Your Village, Your Map and Your Compass
If you are a large retailer embarking upon a product data quality cleansing project you have taken on a large and complex business task. It truly does take a village to implement Oracle PDQ. In fact, it takes an organized, savvy, well-guided (which is where methodology comes in) village. Where, then, to begin?
- First, approach your product data and what you want to do with it (and what you want it to do for you) strategically.
- Second, have a methodology-based approach.
- Third, know your pain points for your product data.
You will likely be in unknown and unfamiliar territory. Without a map? Wide-eyed and map-less, even? Not entirely. Methodology is your map. And your compass? That is your product data strategy.
What is a product data strategy? It is a strategy very similar to a content strategy. In an ideal business world, or in a business world that can be easily modulated, your product data strategy would be a track within your overall corporate content strategy. This post is about the map, not the compass. We will find another time to discuss the compass of content strategy. Just bear in mind that your content and/or product data strategy is the artifact that should govern all your analysis and all that you implement. It is the only compass you should consult. The tactical should always derive from the strategic.
Pain is Information
Business challenges arising from the “quality” of your product data do not solely lie with the product data itself. These challenges lie also in your current artifacts (or lack of them) and your business processes around product data.
Pain is information. Use it wisely. So, where are your pain points? Are they in your existing product data? If you have read this far then “probably”. Perhaps they are in the new product description content flowing—flooding—in from your suppliers? Or, maybe you find them in the organization of your products into “product families” and groups (i.e. into taxonomy)? In your grammar and units of measure standards that define how you want your cleansed supplier content to be outputted and seen/read by your customers?
Inadequate product taxonomy and output standardization rules – or lack of them altogether – are very common pain points in a product data world where the friction of poor data “quality” begins to palpably hurt.
Taxonomy – Organizing Products to Make Your Product Data Processes Frictionless
In Oracle PDQ (and in similar products) how your products are organized into taxonomy is critical. Yes, in Oracle PDQ you can map a completely random collection of products to a true taxonomy – such as a website taxonomy. Clever, yes, but, this would be a solution of zero extensibility (not to mention zero usability), and supremely inefficient. In Oracle PDQ there are true efficiency gains by having a congruent, logical and extensible taxonomy designed by experts.
We carried out a comprehensive taxonomy assessment (with comprehensive recommendations and guidance) for a major online retailer as a key component in implementing Oracle PDQ for them. This retailer’s product universe was a taxonomy of 20 or so product groups. Soup to nuts; “soup” into the Grocery product grouping and “nuts” into the Hardware group. Our solution included all the usual types of taxonomy changes. For example, we moved some products from group to group. And we even advocated an entirely new product group concept for them – Seasonal – capturing all the different holidays and occasions, with all their associated products. Our recommended new taxonomy organization was driven by unique-to-the-client organizing principles as well as all our usual best practices.
Let’s answer the unasked questions. What is “congruence”? What is “extensibility”? How did we create congruence and extensibility in our retailer’s product taxonomy? What business benefits do conceptual congruence and extensibility deliver to our client?
Congruence means organizing by explicit principles. The random, the habitual, the inherited, the familiar are all replaced. Extensibility means having a framework that is straightforward to add products and product families to. Thus, congruence gives to our retailer a clean framework for a data model of products, their attributes and all the required attribute values. In turn, this clean framework enables the retailer to be very surgical with what attributes apply to only one product group and which can be applied across several groups. Taxonomy congruence and extensibility give the benefit of ease of use of adding new products (with likely new attributes and values). Taxonomy congruence and extensibility also results in communicability. You can reveal your product taxonomy to your internal business partners and it will be understood because it is based on principles.
Standardization – what You and Your Suppliers Know as “Green” Must be the Same
Labels – labels – everywhere! Product attribute values are like that. Wordy – and so many of them. Is it to be “green”, “grn” or “G”? Is it to be “2-Quart”, “2 qt”, “two quarts” or even “0.5 gallons”? Of course, the answer is simple. It is what you (you know your customers best, right?) want your website customers to see. Additionally, you will want your customers to ALWAYS see the same output from your product data - always the same green word, always the same unit of measure. Doing this well requires that you have business process artifacts in place such as an output standardization guide, sometimes coupled with (or even replaced by) a controlled vocabulary.
In our product master data methodology we know exactly how to assess the readiness of these standardization artifacts of yours (or, indeed, whether you have them or not) and where in process they need to be.
We Have the Map …
… and are happy to share it. And to improve it since every client is a learning partner for us also. It does take a village to implement Oracle PDQ. And, the village will truly be better off with a map of what to do and in what best order.