4 Mistakes to Avoid in Your Next Serialization Project

 

Serialization was introduced by governments as a mechanism to protect the pharmaceutical supply chain over 10 years ago. Major serialization mandates in the US, EU and other regions are now live. Now is a good time to reflect back on this massive undertaking and review some “lessons learned”.  We say this because serialization isn’t “over” in pharma. 

Enforcement of saleable returns verification starts in November. In the USA, DSCSA-mandated aggregation arrives in 2023. Finally, when companies create new packaging lines, they will need to be equipped for serialization—wouldn’t it be great to avoid common mistakes from the beginning of the project?

Mistake #1. Believing it’s just a serial number

Regulatory requirements go far beyond putting a serial number on a box.

Compliance with serialization regulations is more involved than just putting a serial number on a package. At the Line level, there are complexities around manual versus automated lines, existing versus new lines, and the varied nature of packaging equipment with the various Original Equipment Manufacturer (OEM) solutions in the industry. At the Site & Enterprise level, the electronic serialized product data not only needs to match the physical, but must also be tracked in the supply chain through multiple channels and handle supply chain events like returns, damages, recalls, etc. Serialization is now a four-level software stack. Look for vendors that can provide the full range of bottom-up Device and Line-level software as well as integrated top-down Enterprise and Site-level software. A single-vendor approach to addressing these levels will ensure tight integration of the solution, facilitate data communication, and decrease overall project risk.

Mistake #2. Jumping right in

It pays to remember who won, the tortoise or the hare?

When new lines need to be added, it may be appealing to just try to get this stuff done and jump into a project running.  Diving into a project like this without doing the proper amount of requirements gathering and analysis will set the project up for failure.  Defects discovered in the requirements gathering phases of a project cost anywhere to from 50 to 100 times less to fix than defects that are found closer to rollout.

As projects move along, the cost to change increases dramatically. Having the right stakeholders involved can help discover these design defects much earlier in the project. This extra time reduces the risk of missing compliance deadlines and allows the team to roll out fixes at an efficient cost.  Given the necessary validation of pharmaceutical solutions, fixing defects after validation (which would require a re-validation) is simply unacceptable.

Measure twice, cut once

Equally important to comprehensive requirements gathering is testing.  We cannot emphasize this enough—don’t cut corners when it comes to the testing phases of a serialization project roll-out.

FAT (Factory Acceptance Tests) is an inspection that includes both static and dynamic exhaustive testing of systems or major system components to support the qualification of a serialization system. The tests must verify that all functionality detailed in the User Requirements Specification (URS) is embodied and performs as specified. It is usually written by the manufacturers and executed by the client or client representative.

SAT (Site Acceptance Tests) is related to the FAT and entails inspection and dynamic testing of systems or major system components to support the qualification of the serialization solution. This is written by the client and verifies that the installed functionality of the equipment meets or exceeds the operational requirements as specified in the equipment URS. The SAT is executed on completion of all commissioning tasks; but prior to the start of “go-live” execution.

Proper project time must be devoted to adequately performing FAT and SAT validations, and ensuring a compliant serialization implementation.

Mistake #3. Not reading the fine print

What is the “real” project time? 

Many serialization vendors tout that they can get a customer serialized in a certain number of days – think 45 days, depending on the vendor.  Everybody wants to believe that deploying a solution can be as straightforward as a 45-day project.  It isn’t.  Thinking that you can squeeze all the necessary project elements into that short of a window is a surefire way to not meet the deadline.  The upfront requirements gathering necessary to scope a successful project can take 45 days alone.  Your serialization project is more realistically a 6-9-month journey.  Some of the project phases to think about:

  • Requirements gathering, including understanding individual country serialization nuances of where you go to market
  • RFP’s and Vendor Selection
  • Equipment sourcing, delivery and installation
  • Serialization hardware and software integration
  • Comprehensive testing and training
  • Validation

Systech, for example, has a “Rapid Compliance” program.  This is scoped to specifically call out the serialization-specific project components.  Our program works with the customer to get the serialization project up through FAT and SAT.  It leverages our experience in being deployed on over 1,600 serialized lines, and our knowledge-base of implementations.   It is important to note EXACTLY what a vendor is committing to in serialization programs that call out the number of days to get implemented.

Mistake #4. Believing the price is the price

Not all quotes are created equal.

Serialization has been thrust upon pharmaceutical manufacturers whether they like it or not.  Nobody is a fan of additional costs in the manufacturing and distribution process, and serialization introduces significant new costs.  There are several serialization vendors, all of which will be generating quotes for solutions to make manufacturers compliant with the regulations.  It is important to note that not all quotes are created equal.

Is the quote for one line only?  Does the quote include all services required to go from requirements, through to FAT and SAT, Validation and Go-Live?  Is it a comprehensive multi-line quote?   Are there defined project days identified?  Is data integration with supply chain partners called out and scoped?

Asking for (and receiving) comprehensive project pricing will have multiple benefits.  It will help you create budgetary cost-certainty, enable you to better plan for various stages of this multi-phased project, and establish confidence with your internal team and selected vendor that the project will be delivered on time and on budget.  Most importantly, it will ensure that new lines that need to be serialized will be up, running and compliance-ready on time.

 

Leave A Reply