Pharma digitalization: The data problem runs deeper

Anyone working in the pharmaceutical industry knows the picture. The systems are in place. SAP is running. A LIMS is in use. Maybe even Benchling or another specialized lab tool. And yet these systems often don't work together the way they should.

What we keep hearing in conversations with IT leaders and business units is this: the data is there, but we can't really get to it.

In most cases, the issue isn't that too little is being stored. It's what gets lost in the process of storing it. And that has direct consequences for everything companies want to do with their data today, from process optimization to AI.

Not everyone is struggling with the same problems. Smaller, long-established companies often haven't even made the move to digital document management yet. SOPs are printed, signed by hand, and archived in boxes. When three sites are involved and a department head refuses to sign at the final step because one paragraph isn't right, the entire approval process starts over.

Mid-sized companies have solved this and are grappling with the next stage: training records. In pharmaceutical manufacturing, every employee who performs a process step must be able to prove they have been trained for it. If you manage that in Excel spreadsheets, your next audit will be a problem.

Larger corporations have both under control and face a different question. They have the data, but the data has no context. The measurement is there. But who took it, under which conditions, and at which process step has been lost somewhere between system A and system B.

blu BEYOND supports companies at all three stages. And one thing keeps showing: the problems at stage three originate at stage one.

The classic response to a lack of data continuity is to build interfaces. SAP talks to the LIMS, the LIMS talks to the analytics system. That works as long as the systems stay stable.

In life science IT, they often don't. Software in this industry, especially in fields such as cell and gene therapy, is replaced faster than in almost any other. By the time an interface between system A and system B is finished, system B is sometimes already due for replacement. Companies invest considerable resources in connections that become obsolete a few years later.

A different approach is to integrate the business processes rather than the systems. Instead of building an interface between SAP and Benchling, you define a service for analysis requests, regardless of which software currently delivers that service. When the analytics system changes, only the connection in the background changes. The process itself stays intact.

Data generated at the process level doesn't describe what a system stored. It describes what actually happened in the process. It is contextualized by design and can be used for analyses that simply aren't possible at the system level.

A real-world example: In one project, we found that analysis requests consistently took longer on Thursdays than on other days. The cause was a recurring lunchtime meeting of the responsible lab head, which delayed his approvals. This information wasn't visible in any of the systems involved. Only process-level integration brought it to light.

At blu BEYOND, this is exactly the architectural level we work on. Not because it's technically elegant, but because it's the only one that holds up in the long run in an environment where systems change constantly.