Consulting March 2020
Global systems rollout of SAP and GLIMs at BioPharma giant Seqirus completed by CBE director
Share
Paul Fletcher finalises his role as Business Process, Data and Deployment Lead on Seqirus’ global rollout of SAP & GLIMs IT systems and shares learnings from a successful project.
Charged with leading the Business Process, Data & Deployment areas during a global SAP ECC systems rollout project for Seqirus has been one of the most challenging and rewarding experiences of my career, including tense moments driven by a relentless timeline, a conservative budget, plenty of design complexity and parallel tasks.
Anyone who has ever been involved in the rollout of a global applications project for a Biopharmaceutical company will know how good it feels when you get to the end of the project! It provided a great learning and development experience and I want to share some of those insights.
There is the significant regulation in place (as there should be) in this industry, but above all there is the requirement to ensure the design and final build has the appropriate controls in place throughout all of the relevant business processes so that finished products meet the release specifications and requirements are delivered to patients.
During the project lifecycle, my role evolved from the Process, Data and Deployment Lead, the Business & Deployment Lead and finally the Business Sustain Lead. These roles provided a real perspective on the complexity of these processes.
First though, some background, and then those learnings.
This project was split into 3 main phases across both Northern Hemisphere and Southern Hemisphere sites:
- Phase 1 – Design, update specification documents, build changes to the template (& unit test them) and begin collecting data ready to load for the first system test phase.
- Phase 2 – Testing phases (INT, OQ & UAT)
- Phase 3 – Deployment & Go Live phase
Project delivery focussed on the northern hemisphere (NH) rollout first before commencing the southern hemisphere (SH) rollout. When I joined the SAP delivery part of the project, the NH build was complete and just entering the OQ testing phase (phase 2 of NH rollout). There was an established project team already in place and I’d been engaged for the SH part of the project (not yet started). i.e. the Australian and New Zealand rollout of SAP. Initially working from the Seqirus site in the UK (Liverpool), my job was to support phase 2 and 3 activities – and gather sufficient knowledge which could be transferred and used for the SH part of the project.
My first role was to assist the Test Lead and plan the UAT testing schedules for each of the NH manufacturing sites. This led to an opportunity to lead the UAT testing at Liverpool in the UK. With my background primarily in Pharma manufacturing and operations, it allowed me to get out to the site where I would be working closely with Operations people and execution of the tests.
We moved through the UAT phase successfully and entered the final Production data load and deployment phase. The Site Deployment Lead asked me to return and join the site deployment team and help with execution of readiness activities and Hypercare support.
The SAP & GLIMs projects (for the NH project phase) successfully went live in April 2018 and the SH project team regrouped in Australia to begin ramping up the SH part of the project.
Although the Australian and NZ components of the project were part of a global rollout, there were many localised business process complexities, external/internal interfaced systems and additional manufactured products that were not part of the SAP template (already deployed and live). This additional complexity and scope was what we had to now spec, build, test and deploy for the SH rollout.
These sorts of projects have many moving parts and essentially involve extracting business data and process information from the existing users. This information is then collated in sufficient detail to be able to document and pull together the future business end to end processes.
What is often overlooked (and underestimated) in these projects, is providing sufficient time to work with the business users to fully understand their existing E2E processes and then work with them to determine the agreed “to be” E2E processes which will fit the live SAP template. This is particularly important when moving a complex, regulated business from a legacy ERP platform to a SAP platform.
All of the applications went live successfully in October 2019 – we definitely had some additional “mopping up” to do with understanding the finer detail of some more complex business processes. Importantly though, there was nothing which stopped the overall business operations. But the key learning was to put in more quality effort in initiating the transformation activity much earlier in the project. This would probably have meant less process questions after go live and less reactiveness in fixing things during Hypercare (hindsight is a wonderful thing).
Key Project Learnings
- Get your Project Team structures right and ensure the right people are in the right positions. You want everyone working together to the same, detailed project plan and timeline. A mix of experienced SAP functional and data contractors working alongside a good mix of experienced business people seems to work best in these projects. The right team structures and leadership will drive the collective effort to the execution of the right tasks at the right time.
- Early, upfront input from the business users is very important. It is crucial that strong linkages are agreed between the project and real business people who will answer (and make decisions) on those process questions as they come up. To have unfettered access to real business people who will in turn instantly make those process decisions is a great paradigm.
- Determining the way of working upfront is definitely worth doing. Spend some quality time determining how this is going to work for the project duration and agree this with the Site Leadership. Forecast the “where (and when)” you will need the business user input and into which tasks.
- Make sure all of the detail is in the project plan. It sounds simple, but we found ourselves revisiting some of the tasks and dates in the project plan between each milestone. In other words, more effort up front in putting in the detail to the “as is” and “to be” processes, would have reduced some of the rework to the tasks, documentation and build effort later on. Ensuring the plan is correctly resource loaded through each phase is very important if you want to deliver the project.
- The system build and functional test phases are not that difficult when every key business question is answered and documented early. This was a key take out for me (with a great deal of hindsight).We had many very good functional and technical resources on the project who could solve very complex challenges and essentially get the SAP system operating to meet the design requirements – however you need the business to answer all of the process questions first.
- The need for change management with new systems. It was at times a challenge to work with knowledgeable business users who were not yet familiar with these new applications. We presented them with a different way of working and a system which was going to be more restrictive than before. More effort in the business workshops early on would have mitigated this challenge. If this initial phase is executed without sufficient detail or depth, the phase from UAT to Hypercare will be more challenging than it needs to be. In this case we got to where we needed to on time, but with some process challenges still unresolved
It was a privilege to have been part of the project team alongside such great and talented people. The project deliverables weren’t perfect, but the ongoing transformation is an undoubted success, with the business able to service its customers, meet expectations and most importantly supply live-saving medicines to those that rely on them.
For me, now onto searching for the next big challenge.