One is that you go in knowing it’s a 100% disposable test, for pure R&D purposes, and that you have no expectations about reusing the equipment or software in that test as you scale up for real production. The second school of thought says, quite simply, there ain’t time for that! Do your homework, make your plan, write your playbook, pick your technology, and pick one real line running one real product as your pilot test. Most importantly, link up with one real trading partner to see if they can read your codes and understand your e-pedigree data. Your “pilot” should be a real implementation from which you can scale, not an academic exercise.
Before you jump into a specific pilot, however, you should know what the goals of the pilot test are. Here are some goals to consider:
1. Understand the potential organizational impacts. This could mean gaining a better understanding of the implementation process, the impact on company resources to roll out serialization, the need for external support, and the costs, or assessing the feasibility of the requirements and timelines. Developing experiential knowledge on the installation process, testing, and verification of actual installation time should be some of the main desired outcomes for the pilot.
2. Assess the impacts on line efficiency and uptime. This breaks down into several sub-areas:
• Identify impacts to line efficiency stemming from process or equipment changes
• Measure and record impacts to line efficiency
• Define mitigation plans to reduce line efficiency impacts
• Define inventory build-up plans to mitigate risk of inventory stock-outs during serialization implementation
• Define actual timeline for the implementation of serialization on the packaging line (hardware installation, IQ, OQ, and PQ)
• Define assignments of backup lines for serialized SKUs
3. Identify and develop new packaging-related documentation and processes necessary to support and implement a serialization project, such as:
• Use cases and functional specifications
• Standard operating procedures
• Bills of specifications
• Artwork documentation
• Validation documentation
• Process mappings
• Project plans
4. Assess serial number coding and aggregation capabilities. This involves gaining insight into your ability to accurately print serial number information onto the package. But more importantly, this is where you can learn how to build aggregated hierarchies of item-to-case and case-to-pallet. Doing so consistently with a high degree of accuracy is the challenge. Don’t forget to involve an actual downstream trading partner such as a wholesaler/distributor. This is necessary to help test the readability of your serial number encoding at the item, case, and pallet levels on their equipment, as well as test the accuracy of aggregation e-pedigree data you are sending to them.
5. Assess how trading partners prefer to receive serialization and aggregation data. Some may prefer ASN, though the industry is moving toward EPCIS.
6. Test your ability to successfully send and receive e-pedigree event information electronically. This one breaks down into several sub-goals:
• Identify the communication channels your trading partners prefer (web services, subscribe-push, query-pull, etc.).
• Test your ability to exchange EPCIS event data using GS1 US Rx Guideline.
• Understand how to use extension data as documented in the GS1 US guideline.
• Decide what to communicate regarding your supply chain master data.
7. Test your trading partners’ ability to send and receive e-pedigree event information electronically. This includes direct trading partners such as wholesaler/distributors, and ideally indirect trading partners such as pharmacies. The further down the chain you go, the tougher it will be to find trading partners that are able to actually receive your data, since the e-pedigree deadlines are a year later for wholesaler/distributors and two years later for pharmacies.
8. Identify exceptions and best practices for handling exceptions. Currently not all supply chain events can be depicted in EPCIS. These exceptions tend to consist of reverse logistics such as returns (possibly due to shipping errors) or recalls (for a complete list. This is an area that’s in flux, so over time, these exceptions should be fewer and fewer. Consider contributing your findings to GS1 to inform its exception handling usage guidelines.
9. Assess network-centric pedigree models as they are defined. There are several models defined by GS1 that consist of variations on centralized, semi-centralized, or distributed. You may want to try different models to assess the pros and cons of each approach.
10. Test failure scenerios. Develop a pilot script to test various “what if” failure scenerios and to help with the development of Risk Evaluation and Mitigation Strategy (REMS) and SOP.
Liked this article? Download the entire playbook here.
