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.
