ERP platforms like SAP and Oracle were built for batch inventory and financial records, not for patient-specific therapies where a missed collection window can mean a missed treatment.
Life sciences teams that try to force patient journey tracking into ERP end up with shadow systems, stressed coordinators, and dashboards showing green while therapies quietly drift into risk.
A life sciences data management platform keeps ERP as the system of record for finance and compliance while a dedicated intelligence layer handles patient journey visibility across clinical, manufacturing, and logistics signals in near-real time.
Knowing where to start matters: picking one focused use case, such as slot coordination or referral-to-infusion tracking, and delivering a working data product in 60–90 days gives teams the foundation and organizational trust to expand.
Somewhere in a cell and gene therapy program right now, a patient services coordinator has 14 browser tabs open. One is the ERP. One is the courier portal, showing a temperature excursion alert. One is the CDMO (Contract Development and Manufacturing Organization) portal, showing capacity reductions. The ERP says everything is on track.
Life sciences organizations run advanced science, including cell and gene therapies, decentralized trials, and real-time oncology review models. Their operations are not as advanced and are held together by spreadsheets, emails, and status fields. The ERP was never designed to represent a non-linear patient journey.
From our vantage point, working with life sciences organizations, ERPs aren’t broken. They’re doing exactly what they were built to do: manage static, batch‑based inventory and financials.
The problem is that the operating model has changed, but the mental model underneath the systems has not.
This blog is our attempt to unpack that mismatch as candidly as possible based on what we’ve seen work, what we’ve seen fail, and where we think the industry needs a different kind of foundation.
ERP thinks in items and batches. The patient journey doesn’t.
Traditional ERP systems like SAP, Oracle, and many others were built for a linear blockbuster world where raw materials come in, batches are produced, inventory is stored, and finished goods are shipped out.
The core entities are materials, purchase orders, batches, locations, and general ledger accounts. That model works well for predictable, centrally manufactured products, and it’s still necessary in life sciences today.
But in therapies where:
The drug is literally the patient’s own cells
Manufacturing capacity is measured in high‑value slots instead of pallets
A missed collection window can mean a missed therapy
…that model collapses.
We see this most clearly when we map how an ERP thinks versus how a patient journey actually unfolds:
ERP’s view: A set of orders, reservations, and stock movements that generally look “green.”
Reality on the ground: Logistics delays, eligibility changes, consent issues, viability risks, and cross‑border handoffs that never show up as first‑class entities in the ERP.
This is how you end up in situations where every ERP status is technically fine, but when you blend in courier data, CDMO telemetry, and clinical milestones, you realize a therapy is quietly drifting into a risk zone.
We’ve had more than one engagement start with some version of,“Our systems all say we’re on time, but we keep cancelling or rescheduling therapies at the last minute. What are we missing?”
The short answer: the patient journey lives between systems, not inside the ERP.
Where ERP quietly becomes the bottleneck
The biggest risk we see is the expectation that ERP should be the system of truth for something it was never designed to represent.
Across sponsors and manufacturers, a few failure patterns keep showing up:
1. Treating patients like inventory
We routinely see patient‑specific therapies modeled as if they were just exotic SKUs:
Patients mapped to material numbers or generic customer IDs
Viability windows shoehorned into requested delivery dates
Appointment changes and clinical events embedded as free‑text comments
From an implementation perspective, this is clever. From a patient‑journey perspective, it’s dangerous.
When you’re relying on an ERP item master to stand in for a real person’s care pathway, you’ve already accepted a lossy translation, a model that permanently discards clinical nuance. Every workaround (custom fields, status codes, bolt‑on workflows) adds complexity without fixing the core modeling problem.
2. Shadow systems and “human middleware”
When we go onsite, it’s rare to find a team that isn’t running some flavor of shadow system around the ERP:
Excel trackers for referral‑to‑infusion journeys
SharePoint lists for site‑level exceptions
Homegrown access databases or Teams tabs for slot scheduling
Slack/Teams channels for “real” status updates that never make it into the system of record
No one wakes up wanting to build these things. They appear because the real work doesn’t fit cleanly inside the ERP’s data model, especially once you factor in external partners, decentralized sites, and logistics providers.
In one patient‑journey program, we found:
ERP statuses showing everything as on track
A courier portal with temperature excursion alerts
A CDMO portal with capacity reductions
A patient services team manually reconciling all three in a spreadsheet at 10 p.m.
The enterprise believed the ERP was its “single source of truth.” In practice, the single source of truth was a stressed coordinator with 14 browser tabs open.
3. Integrations that deepen the illusion of control
When the cracks start to show, the natural reaction is to just say, “Let’s just integrate the ERP with the CDMO portal, EDC, and courier system. Problem solved.”
We’ve been down this path many times. Point‑to‑point integrations can move data faster, but they don’t change what the ERP can meaningfully represent.
You can:
Push batch IDs and Certificate of Analysis (COAs) into ERP
Pull shipment statuses and slot confirmations into custom tables
Trigger alerts off certain field combinations
You’re still trying to express a multi-party patient journey through structures built for static inventory and financial control.
The result is what we call integration friction:
More interfaces to maintain
More failure points
More “green” dashboards that hide patient‑level risk
A candid look at our own learning: what we got wrong
It’s easy to critique from the sidelines. We’ve had to grow up on this, too.
On early projects, we made two mistakes we now actively coach against:
Mistake #1: trying to turn ERP into the hero
In one advanced‑therapy program, everyone (including us) wanted to fix the ERP:
Add more fields
Build more status codes
Extend workflows with custom logic
We invested months making the ERP smarter and more connected. We did improve some reporting and compliance workflows, but we didn’t materially change the frontline question,“Is this specific patient’s therapy safe, viable, and on track?”
Why? Because we were still forcing every question through an inventory‑centric lens. The more we tuned, the more brittle it got.
The turning point was when we stepped back and admitted that the system was doing its job. We were asking it to be something it’s not.
Mistake #2: underestimating the “black box” of external partners
In another engagement, we assumed that if we could pipe CDMO data into a warehouse and then into ERP, we’d unlock the visibility the sponsor needed.
We did get better data in, but we’d underestimated:
The volume and messiness of time‑series manufacturing telemetry
The reality that critical data was still locked in PDFs, portals, and email threads
The need to harmonize patient, product, and batch context across clinical, manufacturing, and logistics domains
We had to acknowledge that this wasn’t an ETL problem, but rather an architecture and modeling problem.
What a life sciences data management platform actually does
Over time, our approach has shifted from making the ERP smarter to letting the ERP do what it’s good at, and put the intelligence somewhere else.
The pattern that’s worked best is:
ERP remains the system of record for finance, core inventory, and compliant documentation.
Ingests multimodal data (ERPs, labs, portals, DCTs, logistics, RWE)
Harmonizes it into a semantic layer where Product, Batch, and Patient are first‑class, connected entities
Applies analytics and AI to answer “What should we do next?” in real time
Bakes compliance‑as‑code into the pipelines and models themselves
It then feeds decision‑ready insights back into ERP and downstream tools in the form they can actually consume: updated reservations, recommended slot changes, prioritized worklists, and alerts that are grounded in full‑context, patient‑level intelligence.
ERP remains a necessary part of the architecture. It stops being where you go to understand the health of a therapy program.
Where to start if you’re a VP of Manufacturing or Clinical Ops
When leaders tell us that their ERP is in the way, the temptation is to launch a multi‑year replacement or embark on a massive integration program.
Our advice, based on both scars and successes:
Stop asking ERP to be something it’s not.
Treat it as a system of record. The intelligence layer is where decisions about patient-centric therapies get made.
Make the patient journey a first‑class data concept.
In whatever platform you choose, explicitly model Patient, Product, Batch, and Site and how they relate over time. If you can’t query, “Show me this patient’s journey from referral to infusion across all partners,” you’re missing the foundation you need.
Pick one painful area. Whether it’s slot coordination, external manufacturing visibility, or referral-to-infusion tracking, focus on building a single data product that delivers clear operational value in 60–90 days.
Layer intelligence above, not inside, your ERP.
Implement an intelligence platform that can ingest ERP data, external partner data, and clinical signals together, apply AI and decision intelligence, and then push specific, validated actions back into ERP and adjacent systems.
Bake GxP validation into the architecture.
In life sciences, speed without trust is a non‑starter. Treat compliance‑as‑code as a requirement from day one so the intelligence layer can stand up to audits and regulatory scrutiny.
None of this requires a big-bang ERP replacement. In most of phData’s engagements, the ERP stays, and improves, once it stops carrying patient-journey logic it was never built for.
Ready to bring this approach into your organization?
If you’re wrestling with these challenges today and want to go deeper into what that intelligence layer looks like in practice, architecturally and operationally, our Life Sciences Intelligence eBook digs into the patterns, pillars, and case studies behind this approach.
FAQs
What is a life sciences data management platform?
A life sciences data management platform is a unified data layer that connects clinical, manufacturing, logistics, regulatory, and commercial data into a single governed environment. Unlike ERP systems, which are built for batch inventory and financial control, a life sciences data management platform models the patient journey as a first-class object, enabling near-real-time visibility and decision intelligence across the full therapy lifecycle.
Why do ERP systems fail in cell and gene therapy operations?
ERP systems were designed for linear, batch-based manufacturing where raw materials move through predictable stages to finished goods. Cell and gene therapies invert that model: the patient is the starting material, manufacturing slots are measured in units of one, and a missed collection window has clinical consequences, not just operational ones. ERP data models have no native concept of patient viability, cross-partner handoffs, or longitudinal care pathways, so teams end up building shadow systems around the ERP to track what actually matters.
How do you build a life sciences data management platform without replacing your ERP?
You don’t replace the ERP. It stays as the system of record for finance, core inventory, and compliant documentation. The intelligence layer sits above it, ingesting ERP data alongside signals from clinical systems, CDMO portals, logistics providers, and patient services platforms. The typical starting point is a focused lighthouse use case scoped to deliver a working data product in 60–90 days. That gives the organization a proof point and the architectural foundation to expand from there.
