Our experience suggests that serialisation programs often set out from one of two places. On the one hand, there is the first group of programs that are very pragmatic and strive to deliver solutions which are focused on meeting hard legislative requirements and nothing more.
On the other hand, there is the second group that strives to deliver a broader capability and benefit to the organisation at the outset. For example, capabilities that can be leveraged to enhance product security, improve customer relationships and provide product movement information and supply chain visibility. Often, senior management is rightly concerned in getting the maximum return for the organization’s significant investment in this area.
Regardless of the starting point, many programs quickly iterate towards the first category as the practical reality of the size of the legislative task alone hits home.
Whilst it is often appropriate for a program to focus in the shorter term on delivering to the hard legislative deadlines, it is unfortunate if this is also done by limiting scope and capability designed into solutions to merely meet these short term needs. If this is allowed to happen, then reaping the broader future benefits from the solutions may prove to be significantly more difficult than it otherwise might have been.
Therefore, we would recommend putting mechanisms in place to monitor the ability of solutions to properly support the broader solution requirements, even when these are not immediate priorities.
I hope you enjoyed this last installment on Things we wish we had known before starting a serialisation program or project.
Should you have any questions about this or any other of my blogs, or would simply like to request a copy of my booklets, please don’t hesitate to contact me at Andrew.firstname.lastname@example.org.
Available for request: