We opened our session at Aspire with a provocation that got a lot of nods: tech transfer is a problem everybody has, and we need to really start owning it better.
That framing was intentional. Not a rallying cry. More of an honest diagnosis — because in our experience, the reason digital tech transfer keeps stalling is not that people don’t see the value. It’s that the path from “we know this is important” to “someone is actually accountable for moving it forward” is where organizations consistently get stuck.
We spent an hour with a room full of pharma and biotech operations leaders working through why. This is what we heard, and what we think it means.
Tech transfer is a lifecycle issue. Knowledge has to move from discovery to development to transfer to commercial manufacturing — and at every step, that knowledge gets repackaged, reformatted, reinterpreted. Each team captures things in its own way. Process parameters get renamed. Site conventions differ. Risk assessments get rebuilt from the ground up at every new facility. Comparative reviews happen line by line in meeting rooms and workshops, pulling from documents that were never designed to talk to each other.
Sachin puts a number on it: based on industry trends and our own experience, roughly 70% of product and process knowledge is not digitized in a way that makes it portable or reusable. That gap is not academic. It shows up as repeated manual work, slower cycle times, and knowledge loss at every handoff.
The live polling in our session confirmed it: cycle time was the top pain point. Fragmented product and process knowledge came in right behind it. Those two are not separate problems — they’re the same problem. The reason cycle time suffers is that the knowledge required to make transfer decisions isn’t assembled, structured, or accessible when it needs to be.
What exists instead? Spreadsheets. PDFs. PowerPoints. Word documents — that get approved, updated, reapproved, and eventually linked to protocols for PQ and all the other downstream requirements. It works...technically. But it’s slow, it’s lossy, and it’s not reusable. The next time a similar transfer comes around, the organization largely starts from scratch again.
If you look at the categories of friction that slow digital tech transfer down — ownership, technology constraints, resistance, competing priorities — three of the four are not technology problems. They’re people problems. Organizational problems. Culture problems.
Ownership is the clearest one. Tech transfer is inherently cross-functional. It touches MSAT, operations, automation, IT, process development, quality, program management — often all at once. And because it touches everyone, it’s easy for it to be fully owned by no one. One attendee in our session put it plainly: when you have competing project managers with different directives, the work fragments. There’s no single captain of the ship.
Tim’s framing: implementing technology is the easy part. It’s the operational change that has to go along with it.
That’s not a comfortable message for a room full of people who came to talk about digital solutions. But it’s an honest one. We’ve seen organizations buy and deploy the right tools and still not make meaningful progress — because the ownership model was unclear, the cross-functional team wasn’t aligned, and the change management was an afterthought. The technology sat there doing very little, because the organization around it hadn’t changed.
Progress is possible. We see it. But it’s slow, and it tends to happen when organizations treat digital tech transfer as an operating model challenge before they treat it as a software selection challenge.
We think about digital tech transfer as a maturity journey across six interconnected strands — and the important word is interconnected. Think of it like a woven rope: governance and risk management; product knowledge and lifecycle; data knowledge and foundation; digital infrastructure and integration; change management and digital culture; and insights and analytics. Each strand has to progress. If you push hard on digital infrastructure but neglect change management, the work eventually breaks down. If you build a robust knowledge layer but governance is weak, adoption won’t follow.
The realistic near-term target for most organizations isn’t autonomous — it’s integrated. Getting from manual or partially digitized to a place where systems actually communicate, where data models are defined, and where AI and analytics tools can begin to add value on top of a reliable foundation. That’s achievable. It’s not easy, but it’s achievable.
The foundational requirement is something we kept returning to throughout the session: a single digital source of truth for product and process knowledge. Most organizations already have control systems, LIMS, ERP, maybe an MES. They’ve digitized a lot. What most haven’t digitized is the product and process knowledge itself — the thing that currently lives in spreadsheets and approved documents and templates that don’t talk to each other. That’s the root of the problem. And without addressing it, you can’t meaningfully advance the rest.
Sachin’s technical framing: the knowledge management system acts as the source of truth for CMC data — not a document repository, but a structured layer where product, process, quality, and materials knowledge are organized and accessible through APIs. Downstream systems — MES, DCS, SCADA — stay current through event-driven architecture rather than manual synchronization. An intelligent layer sits on top to support retrieval, pattern recognition, and decision support. A single pane of glass gives cross-functional teams a shared view of tech transfer KPIs.
What that changes in practice is worth making concrete. Instead of answering site-selection questions from static documents, teams work from live dashboards and scorecards. Instead of rebuilding FMEAs from scratch at every new site, risk models are defined, populated, and refined over time. Instead of comparing QC files line by line in a workshop, parameters sit side by side in an integrated view.
The key point — and this came up explicitly in the room — is that none of this is about replacing experts. The SME doesn’t go away. What changes is that the SME stops spending most of their time reconstructing context that should already exist, and starts spending more time using live, traceable information to make better decisions. With that architecture, you have the right input at the right moment in the right context — with full traceability for governance and compliance.
An audience member made an observation that stayed with us: over the last three years, their personal life had been fully digitized. They use AI every day. But at work, the environment still feels antiquated. That gap is real, and it’s not going to close on its own.
The industry is beginning to recognize this too — Stellix is a founding member of the Digital CMC Consortium, alongside Novartis, Takeda, Thermo Fisher, and Pioneering, focused on building the shared business and data models for digital tech transfer that the industry currently lacks.
Step one: name the owner. Not the committee. Not the function. One person who is accountable for digital tech transfer from the first handoff to the last. If that person doesn’t exist, stop talking about technology until they do. Every tool you buy before solving this problem will underperform, because no one will be accountable for making it work.
Step two: digitize the knowledge layer before anything else. Not the execution systems — you likely already have MES, LIMS, SCADA. What’s missing is a structured digital home for product and process knowledge: the CPPs, the FMEAs, the site-specific parameters that currently live in spreadsheets and Word documents and PowerPoints. That layer is the foundation. Without it, integration is just connecting broken pipes.
Step three: progress all six strands together. Governance, product knowledge, data foundation, digital infrastructure, change management, and analytics. Not sequentially — in parallel, at roughly the same pace. A company that’s highly mature on digital infrastructure but hasn’t touched change management will fail just as reliably as one that’s invested nothing at all. The strands hold each other up.
None of this is fast. But it is knowable, and it is sequenceable. The organizations making real progress are the ones that stopped waiting for the perfect moment to start and began treating digital tech transfer as a structured operating-model change — not a systems project, not a pilot, not a working group. A change they own, end to end.
Tim Adkins is Director, Digital Life Sciences Operations at Stellix. Sachin Suryawanshi is Senior Solution Architect, Data Solutions at Stellix. Together they work with life sciences and biotech organizations to reduce transfer cycle time and build reusable product and process knowledge infrastructure.
That framing was intentional. Not a rallying cry. More of an honest diagnosis — because in our experience, the reason digital tech transfer keeps stalling is not that people don’t see the value. It’s that the path from “we know this is important” to “someone is actually accountable for moving it forward” is where organizations consistently get stuck.
We spent an hour with a room full of pharma and biotech operations leaders working through why. This is what we heard, and what we think it means.
The knowledge problem is bigger than it looks
Before we can talk about digital solutions, it helps to be precise about what the actual problem is.Tech transfer is a lifecycle issue. Knowledge has to move from discovery to development to transfer to commercial manufacturing — and at every step, that knowledge gets repackaged, reformatted, reinterpreted. Each team captures things in its own way. Process parameters get renamed. Site conventions differ. Risk assessments get rebuilt from the ground up at every new facility. Comparative reviews happen line by line in meeting rooms and workshops, pulling from documents that were never designed to talk to each other.
Sachin puts a number on it: based on industry trends and our own experience, roughly 70% of product and process knowledge is not digitized in a way that makes it portable or reusable. That gap is not academic. It shows up as repeated manual work, slower cycle times, and knowledge loss at every handoff.
The live polling in our session confirmed it: cycle time was the top pain point. Fragmented product and process knowledge came in right behind it. Those two are not separate problems — they’re the same problem. The reason cycle time suffers is that the knowledge required to make transfer decisions isn’t assembled, structured, or accessible when it needs to be.
What exists instead? Spreadsheets. PDFs. PowerPoints. Word documents — that get approved, updated, reapproved, and eventually linked to protocols for PQ and all the other downstream requirements. It works...technically. But it’s slow, it’s lossy, and it’s not reusable. The next time a similar transfer comes around, the organization largely starts from scratch again.
The friction is organizational, not technical
The audience polling surfaced something important about barriers: complexity was the leading answer, with unclear process ownership close behind. That tracks with what we’ve observed. And it points to something we want to be direct about.If you look at the categories of friction that slow digital tech transfer down — ownership, technology constraints, resistance, competing priorities — three of the four are not technology problems. They’re people problems. Organizational problems. Culture problems.
Ownership is the clearest one. Tech transfer is inherently cross-functional. It touches MSAT, operations, automation, IT, process development, quality, program management — often all at once. And because it touches everyone, it’s easy for it to be fully owned by no one. One attendee in our session put it plainly: when you have competing project managers with different directives, the work fragments. There’s no single captain of the ship.
Tim’s framing: implementing technology is the easy part. It’s the operational change that has to go along with it.
That’s not a comfortable message for a room full of people who came to talk about digital solutions. But it’s an honest one. We’ve seen organizations buy and deploy the right tools and still not make meaningful progress — because the ownership model was unclear, the cross-functional team wasn’t aligned, and the change management was an afterthought. The technology sat there doing very little, because the organization around it hadn’t changed.
Progress is possible. We see it. But it’s slow, and it tends to happen when organizations treat digital tech transfer as an operating model challenge before they treat it as a software selection challenge.
What a structured approach actually looks like
Once you accept that the problem is organizational first and technical second, the path forward becomes more navigable.We think about digital tech transfer as a maturity journey across six interconnected strands — and the important word is interconnected. Think of it like a woven rope: governance and risk management; product knowledge and lifecycle; data knowledge and foundation; digital infrastructure and integration; change management and digital culture; and insights and analytics. Each strand has to progress. If you push hard on digital infrastructure but neglect change management, the work eventually breaks down. If you build a robust knowledge layer but governance is weak, adoption won’t follow.
The realistic near-term target for most organizations isn’t autonomous — it’s integrated. Getting from manual or partially digitized to a place where systems actually communicate, where data models are defined, and where AI and analytics tools can begin to add value on top of a reliable foundation. That’s achievable. It’s not easy, but it’s achievable.
The foundational requirement is something we kept returning to throughout the session: a single digital source of truth for product and process knowledge. Most organizations already have control systems, LIMS, ERP, maybe an MES. They’ve digitized a lot. What most haven’t digitized is the product and process knowledge itself — the thing that currently lives in spreadsheets and approved documents and templates that don’t talk to each other. That’s the root of the problem. And without addressing it, you can’t meaningfully advance the rest.
What the architecture makes possible
Once that foundation is in place, the architecture can start doing something genuinely useful.Sachin’s technical framing: the knowledge management system acts as the source of truth for CMC data — not a document repository, but a structured layer where product, process, quality, and materials knowledge are organized and accessible through APIs. Downstream systems — MES, DCS, SCADA — stay current through event-driven architecture rather than manual synchronization. An intelligent layer sits on top to support retrieval, pattern recognition, and decision support. A single pane of glass gives cross-functional teams a shared view of tech transfer KPIs.
What that changes in practice is worth making concrete. Instead of answering site-selection questions from static documents, teams work from live dashboards and scorecards. Instead of rebuilding FMEAs from scratch at every new site, risk models are defined, populated, and refined over time. Instead of comparing QC files line by line in a workshop, parameters sit side by side in an integrated view.
The key point — and this came up explicitly in the room — is that none of this is about replacing experts. The SME doesn’t go away. What changes is that the SME stops spending most of their time reconstructing context that should already exist, and starts spending more time using live, traceable information to make better decisions. With that architecture, you have the right input at the right moment in the right context — with full traceability for governance and compliance.
The longer game
One of the more useful conversations in the room happened when someone asked directly: is anybody actually making real progress? The answer was honest: yes, some. But it’s slow. And it’s slow not because the tools don’t work, but because the organizational change required is significant and the ROI isn’t always easy to build in traditional hard-savings terms.An audience member made an observation that stayed with us: over the last three years, their personal life had been fully digitized. They use AI every day. But at work, the environment still feels antiquated. That gap is real, and it’s not going to close on its own.
The industry is beginning to recognize this too — Stellix is a founding member of the Digital CMC Consortium, alongside Novartis, Takeda, Thermo Fisher, and Pioneering, focused on building the shared business and data models for digital tech transfer that the industry currently lacks.
Where to start
If you walked away from Aspire wondering what to actually do next, here is our answer — not a general one, but the specific sequence that we’ve seen work.Step one: name the owner. Not the committee. Not the function. One person who is accountable for digital tech transfer from the first handoff to the last. If that person doesn’t exist, stop talking about technology until they do. Every tool you buy before solving this problem will underperform, because no one will be accountable for making it work.
Step two: digitize the knowledge layer before anything else. Not the execution systems — you likely already have MES, LIMS, SCADA. What’s missing is a structured digital home for product and process knowledge: the CPPs, the FMEAs, the site-specific parameters that currently live in spreadsheets and Word documents and PowerPoints. That layer is the foundation. Without it, integration is just connecting broken pipes.
Step three: progress all six strands together. Governance, product knowledge, data foundation, digital infrastructure, change management, and analytics. Not sequentially — in parallel, at roughly the same pace. A company that’s highly mature on digital infrastructure but hasn’t touched change management will fail just as reliably as one that’s invested nothing at all. The strands hold each other up.
None of this is fast. But it is knowable, and it is sequenceable. The organizations making real progress are the ones that stopped waiting for the perfect moment to start and began treating digital tech transfer as a structured operating-model change — not a systems project, not a pilot, not a working group. A change they own, end to end.
