How to de-risk serialization programs involving CMOs
Add bookmarkImplementing a track and trace program that involves a Contract Manufacturing Organization (CMO) can be hazardous. Andrew Love discusses how to create an airtight roadmap to avoid costly mistakes within serialization.
Make sure everyone understands the roadmap
As with all projects, there are two principle aspects of CMO integration that need to be worked out:
- The ‘To-Be’ design: How is the end-to-end final result going to work?
- The project design: How are the team going to get from where they are to the end result?
An example of a critical area would be the integration of your quality system to those in each of your CMOs.
A small number of key individuals in any project need to understand how both aspects are going to work.
All too often, we see situations where nobody understands the overall picture at a sufficient level of detail, but many members of the team can identify unresolved issues. In these cases, projects typically fail, or at best, are late and over budget.
Ensure there is a clear data and messaging model
Ultimately, serialization is about maintaining an information view of what is happening in the physical (product packaging, movement and consumption) supply chain.
Furthermore, this information typically needs to be shared across several locations, organizations and IT systems to work correctly. To work at all, this information and the way it is communicated needs to be entirely consistent to the finest level of detail across the end-to-end supply chain.
You may also be interested in our serialized guide to serialization.
This is not to say that individual data items or message methods need to be exactly the same across the end-to-end supply chain, as the likes of middleware can accommodate a degree of data and message format transformation.
However, in order for this transformation to work successfully, the underlying data needs to be consistent and transformable using simple rules, across the end-to-end supply chain.
Unfortunately, whilst standards exist for a significant portion of information and messaging requirements, several issues arise, including:
- Legislation requirements that are not consistent across countries.
- Standards, when applicable, that do not cover the full scope of the problem.
- Standards, where they exist, that sometimes leave many options as to how specific processes and information communication can be done.
- Different equipment and IT solutions that have different constraints placed on the way in which information can be represented and communicated. This is particularly true in the relatively immature area of serialization.
Therefore, defining an organization’s data and information communication model across the end-to-end supply chain can help considerably in understanding inconsistencies and designing effective solutions in a timely manner.
 |
|
Have repeatable test protocols in place
Not only are there many system connections and product implementations to perform in a typical serialization program, but there are also many changes needed along the way.
These changes will involve a numerous amount of systems and the amends will have to be replicated across every environment the systems are associated with, e.g. development, testing and production environments.
Given the relatively immature nature of serialization and the over-stretched nature of the supply base, the opportunity for error in coordinating all these changes is plentiful.
The use of standard test protocols can go a long way to ensure that new changes function correctly and do not have any unintended effects.
Dividing the responsibilities for serialization capability implementation and individual pack change cut-over can serve to ease the political tensions that are often seen in serialization programs.
Separate capability implementation from product cut-over
For many organisations, there are many individual products that need to be serialized, but a much smaller number of capabilities (e.g. packing lines, CMOs, 3PLs) that need to be serialization enabled.
Furthermore, organisations are normally well set up for implementing packaging changes on products and recognise that this, in itself, is a relatively complicated coordination activity of many moving parts.
On the other hand, serialization capability implementation is typically the realm of the serialization program/project teams, with an emphasis on one-off changes to significant capabilities and establishing new organisation and systems integrations. This would typically include any changes to the ongoing pack change implementation processes in an organisation.
Once these new capabilities have been established, implementing the individual pack changes should be very much ‘business as usual’ for an organization, typically managed and coordinated from the supply chain and planning teams in an organization.
It can be very effective to divide the responsibilities for serialization capability implementation and subsequent individual pack change serialization cut-over to different teams. This frees the serialization capability implementation to focus on what they should be good at, whilst leaving the individual pack change implementation activity to the existing teams in the business with the required expertise.
It can also serve to ease the political tensions that are often seen in serialization programs at this organizational interface.
Treat this as a program
Each specific CMO integration will be different in a number of ways, as each CMO is a unique organization, with its own:
- Governance
- Organization and people
- Serialization solutions and vendors
- Quality system(s)
- Contractual and finance requirements
- Timelines and constraints
- Culture.
Therefore, each implementation is at least one project, if not several, if a phased implementation is required.
It is sensible to treat the overall CMO integration activity as a program, ensuring that the appropriate level of program management capabilities are applied to the problem.
Furthermore, successful programs tend to be those that recognise that program management skills are distinct and different to project management skills.
Recognise and cater for ongoing change
What is implemented initially in a serialization project will need to be amended over time. Examples of these change drivers include, but are not limited to:
- Changing legislation and standards
- Changing product portfolio
- Changing product supply chains
- Changing or evolving supply chain partner capabilities.
Any serialization program therefore needs to recognise these drivers and have a way to understand and manage their impact and adapt accordingly.
Avoiding the supply risk from serialization with CMOs is complex and I hope that this series has been helpful in pointing to the key areas to consider. Implementing these learnings will certainly reduce the risks involved.
