Our recent webinar “Accelerating Your Digital Journey: Best Practices for Digital Transformation in Life Sciences” spawned lots of ideas and discussion. Here are answers to three questions we were unable to answer during the session. Thank you to our experts — Tony Saldanha, David Williamson, and Chris Monchinski — for your participation, insights, and guidance.
Q: One pain point with the agile approach in life sciences, is the documentation validation lifecycle forces you into some stage of the waterfall approach. For Life Sciences, do you have any tips on how to be a company that continues to innovate + move quickly? – Amy Williams
David Williamson: While the regulators (FDA) have fully embraced a risk-based approach often the risk assessment has minimal impact on the validation approach. I feel this is an area of great opportunity for companies to better define their risk-based approaches and focus the majority of attention on the few areas that truly are risky. The Computer System Assurance (CSA) approach put forth by the FDA offers a very different approach compared to traditional computer system validation (CSV). I recommend reviewing that.
Chris Monchinski: I think it’s important to make decisions in context. Certainly, you are not going to advocate csv for these edge projects. Once you believe the edge project has merit then you need to decide when to bring in validation and discuss “how” this new WoW would be validated. In reviewing our SDLC against GAMP 5.2 which tries to address Agile, I came across this article and tutorial that does a good job explaining how each Agile “sprint” is a mini-waterfall exercise: https://aiotplaybook.org/index.php?title=Agile_V-Model.
Q: How do destructive technologies work in a regulated industry? Are companies really willing for projects to fail? – Karl Koch
David Williamson: Culture plays a big part in how ‘fail fast’ is embraced in a company. In my experience, setting up proofs of concepts (POCs) and pilots is the best way to hedge against a failure. The project is portrayed as an experiment and the costs are well defined (time, money and resources). The challenge is more with we sign up for a large effort and as the project moves forward, more is discovered, timelines shift, etc. This will surely receive a negative reaction.
Q: Is there any evidence that indicates whether an operational level DT effort can proceed in parallel with an enterprise-level ERP effort?
Chris Monchinski: Certainly, all projects compete for capital and resource attention and there is nothing like an ERP rollout to suck the oxygen out of the room. Tony was advocating for a program where you have special edge projects to give it visibility and fund it potentially separately so that this is protected from the big ERP standard projects. This of course means that you need leadership like Tony at the helm, making those declarations. But the mindset is that these edge projects may in fact, completely flip the needs requirements and implementation of your ERP.
Arlene Weichert (EVP at InflexionPoint): We’ve seen instances where an operational-level DT effort is stalled, because the organization has embarked on a business-level initiative to implement a new ERP / ERP migration. I have personal experience where the two ran in parallel with each other. First, the scope of the ERP system was well defined, the operational level DT was outside of that scope. If the two intersect then most likely there will be conflict and they must be serially sequenced.
