Welcome to part 3 of my Key Learnings on Avoiding The Supply Risk From Serialisation With CMOs. In part 2, I looked at processes and resource within the Pharma company. Here in part 3 I consider the final six learnings, focusing on internal teams, template models and protocols, programme management and preparing for future change.
Key learning 13: Make sure everyone understands how this is going to work
As with all projects, there are two principle aspects of a CMO integration that need to be worked out:
• How is the end-to-end final result going to work? — the ‘To-Be’ design
• How are the team going to get from where they are to the end result? — the Project design
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.
Key learning 14: Ensure there is a clear data and messaging model in place
Ultimately, serialisation 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, organisations 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. 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 these information and messaging requirements, several issues arise including:
• Legislation requirements that are not all 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 carried out
• 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 serialisation
Key learning 15: Ensure there are repeatable test protocols in place
Not only are there many system connections and product implementations to perform in a typical serialisation programme, but there are also many changes that will be needed along the way as well.
There are not only many systems involved, but each of these systems will typically have a number of environments through which any changes need to be propagated, e.g. development, testing and production environments.
Given the relatively immature nature of serialisation 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 not only new changes function correctly, but also that any changes do not have unintended effects.
Key learning 16: Separate capability implementation from product cut-over
For many organisations, there are many individual products that need to be serialised, but a much smaller number of capabilities (e.g. packing lines, CMOs, 3PLs) that need to be serialisation 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, serialisation capability implementation is typically the realm of the serialisation programme / 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 organisation, typically managed and coordinated from the supply chain and planning teams in an organisation.
It can be very effective to divide the responsibilities for serialisation capability implementation and subsequent individual pack change serialisation cut-over to different teams. This frees the serialisation 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 who best know how to do this. It can also serve to ease some of the political tensions that are often seen in serialisation programmes at this organisational interface.
Key learning 17: Treat this as a program (unless you only have one CMO)
Each specific CMO integration will be different in a number of ways, as each CMO is a unique organisation, with its own:
• Organisation and people
• Serialisation solutions and vendors
• Quality system(s)
• Contractual and finance requirements
• Timelines and constraints
Therefore, each implementation is at least one project, if not several, if a phased implementation is required. Therefore, 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.
Key learning 18: Recognise and cater for ongoing change
There are many reasons in the serialisation area, why what is implemented initially will need to be changed 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 serialisation programme therefore needs to recognise these drivers, and have a way to understand and manage their impact and adapt accordingly.
For more information on serialisation, go to our free download section.