Wednesday, October 10, 2018

Finding the proper ‘center’ of your master data management capability

When frequently asked for my top ‘lessons learned’ from the dozens of serialization deployments I have supported my answer is always the same:
  • Serialization is not a ‘project’ because it’s not something that ends.  When done properly serialization must be structured so that it becomes ingrained in your everyday business operations
  • Initial serialization deployments always take longer than people expect them to
  • Serialization will expose the need for more formal master data management- almost always to the point it becomes its own program/project
This article focuses on item #3 and attempts to provide some critical points as companies recognize the need for more formal master data management.  Additionally, I’ll highlight some misconceptions regarding vendor offerings in the master data management space.

To start- a quick mention as to the intended audience of this post.   Those at big pharma/biotech likely already have formal master data strategies, systems and processes not to mention entire teams dedicated to the practice.    This article is geared towards the small to medium pharma/biotech who often have no formal master data management prior to their serialization journey.  Many of these companies have recognized (or will soon) the need for such capabilities- even companies that have just a single SKU.
Recognizing the need for formal master data management often comes as a result of feeling the pain from:
  • An increase in the number of product SKUs and/or locations a company must manage (the obvious one)
  • An increase in the number or geographic disbursement of internal teams which require access to master data.
  • An increase in the frequency which master data must be shared with partners/ customers, industry groups and government agencies
The reason serialization is so often the catalyst for further master data efforts is because it touches on at least 2, if not all 3, of the items above.
  • Serialization can be directly attributed to an increase of SKUs managed within an organization, most commonly, as a result of needing to re-organize SKU’s association to the markets they can be distributed into (see EU FMD as an example)
  • Serialization requires the need for consistent master data to be shared across supply chain, planning, manufacturing, trade/distribution, techOps, quality and other internal teams
  • Serialization requires master data to be shared with partner organizations (CMO, 3PL), customers (DSCSA T3s and others), industry groups (HDA Origin) and government agencies (EU EMVS and others).
It’s not surprising then when companies recognize the need and are looking for a quick fix- they often turn to their serialization providers.    I completely understand the mindset and thus will cut right to the key point of this post (if you take nothing else away from this article remember this)- Your serialization system, at any level L3/4/5, should NEVER be your master data management system.   While I applaud organizations which have taken on master data activities I too often see them lean on their serialization systems and think they “are good.”

Here are the long-term problems with that approach:
  • Serialization solutions serve the narrow need of serialization compliance for (often) a subset of a pharma/biotech’s commercial products.
  • The breadth of master data elements managed by serialization solutions are directly tied to serialization compliance requirements which again is a subset of the total master data elements needed to support internal and external business operations.
  • Serialization solutions are not built to be master data managers- often lacking the basic ability to perform data validations, data look-ups and version control.
Said another way, serialization solutions should always be a consumer of master data which originates from some other source(s) of truth (A ‘source of truth’ is simply a system, document or process which is recognized as being responsible for managing a piece of data).   These sources of truth represent the center of your master data management strategy from which data can be consistently shared to other systems, teams and processes.

The other challenge for small/medium organizations is often master data capabilities are tied to enterprise systems like ERPs which can be prohibitively expensive and require extensive implementations.  While ERPs are well suited for providing master data management- having visibility across functional areas within an organization- they just simply are not an option for many small companies.   

Seemingly out of options companies turn to a myriad of manual processes and the dreaded spreadsheet.    Over time data gets siloed among the various functional teams and, even worse, data fields are duplicated across teams but with different values.   I’ve seen pharmas have 4 different product descriptions for the same item- finance uses one value, supply chain creates its own, then planning modifies to reflect target market and finally regulatory pulls from the FDA NDC database. 

These challenges are also not things that present themselves but eventually go away on their own- instead they compound over time as more products/teams/regulations are introduced.   I don’t believe every small/medium pharma needs a full-blown master data management team- but if you fall into that bucket I do believe there is merit in looking at your current processes and capabilities (or lack thereof) and identifying some quick wins.  The first goal should always be to identify a centralized master data management solution upon which standardized processes for adding/maintaining the master data can be developed.  Shameless plug- one easy quick win could be this:  Jennason Master Data Manager.

While nobody likes to add projects at the end of the year and so many will be heads-down over the coming months ensuring US and EU compliance my suggestion is don’t let master data fall too far out of focus.   The reality is there are opportunities to instill robust systems and processes in a short time which can then serve as your long-term solution or can act as a proof of concept for a more formal master data strategy down the road.

Hope everyone enjoys the HDA Traceability Forum next week where I'm sure master data will be a big topic.

Popular Posts