Register

Product data & how to get the knots out of your enterprise architecture

 

knot

The domicile of product data is a commonly unresolved problem faced by enterprise architects in companies across all industries. Product data is consumed by almost every function of their organisations, but it is typically implemented in a way that encourages duplicated activity, confusion and becomes a magnet for complexity.

I have regularly seen organisations that are unconsciously eroding value away from their businesses due to flawed data architectures. Most recently, a company asked us for help when they found gaps between the pricing information on the data sheet used by the sales force, their call centre and internet store. Imagine the confusion when the customer was presented with three different prices for the same product/SKU from different channels!

This is a quick post on how to detect problems in this area and provide commentary on what you can do about it.

So what are some of the symptoms there is something wrong

Not an exhaustive list of symptoms, but the following items were present in the last couple of discussions I had with clients:

  • Emails are circulated between teams asking where data resides and in some cases to get access to the data.
  • There are flurries of communication to arbitrate over data quality issues (for example, what price is correct).
  • An authoritative product catalog is not available or if it does exist, the right stakeholders do not have access
  • Systems that are deemed “authoritative” hold conflicting versions of the same attribute.
  • Data is being re-keyed between systems, often triggering inconsistencies and data quality issues

What is the ideal situation for managing product data?

Stakeholders should know where to find core immutable product data items such as product name, description, SKU and key design attributes like Features. This doesn’t have to be the same repository for all stakeholders, but the most important consideration is attaining consistency of data between systems.

There should be a place in the architecture where deep product analytics can happen – bringing together immutables, real-time data and historical data to develop, test and confirm hypotheses for decision making. Again, the computation doesn’t have to be done on the same platform, but knowing how to source and manipulate the data is the challenge.

Importantly, there should be a way of linking product immutables to the deliverables of the product management / product development activities, for example ideas, problem statements and decisions. This linkage is useful in discovering the wider impacts and insights for products.

The things we learned about transforming the data landscape for a recent client

Understand the product lifecycle for the organisation

This is probably the most important part of the discussion, as it will differ for every company. A good first step is to map out the design product lifecycle (for example: idea, concept, design, marketing, production, end of life, retired ) and for every step understand who is involved and what processes intersect. It is important to identify the other critical lifecycles, such as the product sales lifecycle (quote, order, manufactured product, delivered product). You will probably each lifecycle stage, a business function “owns” that step – e.g. Product Management owns the concept lifecycle phase.

Find the immutable characteristics of your products

Immutables are things like Product SKU, Product Name and other indisputable aspects of your product. Determining at what point in your processes they are determined, who determines them and why they are are important to the following processes. Do a quick assessment to ensure your immutables are really indeed immutables and are universally recognised across all groups.

Get to the point where you have identified all uses and users of product data

All producers and consumers of product data should be identified to visualise the intersection of product data and project. A great visualisation for this is to chart the uses of product data (on an intensity basis) against the stakeholder.

Find a software platform to provide coverage for immutables and gives opportunity to grow outwards

A platform that hosts the immutables and gives the opportunity to extend integration outwards should be found. The most common set of extensions found in our work with clients is not unexpected:

Give the sales force accurate and rich data to give precise answers to customer queries and give the rich seam for Analytics.
Hang lifecycle events and decisions onto the immutable data, so meaningful analysis can happen.

Conclusions

Product data is one of the most important data set possessed by any organisation, but is almost certainly a problematic aspect for architects. Many poor decisions, lost sales or compliance issues have root causes firmly rooted in ineffective data management practices. It is important to understand how the organisation works – particularly how product data intersects with the business process. Effective tooling, such as innovatenow.co can provide the core functions required and become the glue in an enterprise architecture that keeps product data intact.