Key Takeaways
- AI in pharma and life sciences planning exposes data problems before it solves planning problems. That distinction changes what an implementation is worth.
- Pharmaceutical manufacturers run two planning systems simultaneously: the ERP and the planner's institutional knowledge. Only one is visible to the business.
- When AI removes the planner's silent corrections, constraint violations emerge. These are not system failures. They are the first accurate map of where the product master has drifted from operational reality.
- At Colorcon, more than 20% of product records carried incorrect planning attributes corrected manually for years. Once fixed, 70% of planning tasks were automated.
- InspireXT's Data and AI Practice, built with Databricks, extends this diagnostic from a single site to the full enterprise data estate.
Pharma planning runs on two systems. Only one is in the ERP.
Every pharmaceutical manufacturer of meaningful scale has a planning system, usually an ERP such as Oracle or SAP, or something older and heavily customised. The system holds the master data: product specifications, batch sizes, resource capacities, customer orders, and ship dates.
Alongside that system, there is the planner. The planner holds a second planning system entirely, built from years of running the same process across hundreds of production cycles. They know which product records have drifted from how the product actually behaves on the floor. They know which blender or reactor handles which formulation, not because the system says so, but because they learned it from experience. They know which orders can be consolidated without violating quality parameters, which cleaning sequences cannot flex, which customer has a hard ship window that leaves no room for a schedule adjustment.
This second system is the real planning system. The ERP is the starting point.
The problem is that the second system is invisible to the business. It lives in one or two people’s heads and is never formally documented. It does not appear on any dashboard or audit report. Because the schedule holds week after week, there is no visible signal that the ERP alone could not have produced it. Deloitte’s 2025 Smart Manufacturing Survey found that 46% of manufacturers report significant challenges filling planning and scheduling roles. The talent pressure is real, but it is a symptom of a structural condition: when planning capability lives in people rather than systems, every departure carries an operational risk the business absorbs silently, without ever connecting it to the data underneath.
Why the gap between the ERP and the planner is structurally invisible
The invisibility of this gap is produced by the manual process itself.
When a planner adjusts a batch size because they know the system value is wrong, that adjustment creates no record anywhere in the operation. There is no exception log, no flag in the ERP, no documented reason for the change. The schedule looks like it came from the system. The customer ships on time. The Head of Supply Chain sees a clean dashboard and draws the reasonable conclusion that the planning process is working well.
What the Head of Supply Chain does not see is that the planner corrected seventeen product records this week, that three of them carry bulk density values the ERP has held incorrectly since a supplier specification changed eighteen months ago, and that if a different person had built the schedule using the system values literally, two of this week’s batches would have been sized incorrectly and one would have violated a GMP cleaning sequence before the error was caught.
This is the structural condition in most pharma planning operations today. The system looks accurate because a person is constantly correcting it without leaving a trace. CDER warning letters rose 50% in FY2025, with more than a third citing GMP violations traced to documentation failures, specifically gaps between what the system recorded and what happened on the floor. Many of those failures had the same origin as the condition described above: a manual workaround that worked reliably until it did not, and left no documentation to show it had been running in the first place.
The gap remains invisible until automation arrives, at which point it becomes the most visible thing in the operation.
What AI actually does when it runs against pharma planning data for the first time
The AI planning algorithm does not think. It does not compensate or apply judgement built from years of experience. It takes what the system holds and runs the optimisation against those values literally, without adjustment, and without the institutional knowledge that tells a planner which values not to trust.
When a bulk density value is wrong in the Oracle product master, the algorithm uses the wrong value. It calculates a batch size based on that value, and if the calculated batch size exceeds the blender’s validated working capacity, the system produces a constraint violation. It flags the output and halts rather than routing around the problem the way the planner would have.
To an implementation team seeing this for the first time, the constraint violations can look like system failures. In the first week of go-live, when violations flag across multiple product records simultaneously, the instinct is to look for bugs in the configuration. The bugs are not in the configuration. They are in the data, and every constraint violation is a precise record of exactly where the system value and operational reality have diverged. The algorithm is not finding planning errors. It is finding data errors that the planning process had been absorbing silently at the cost of the planner’s time and expertise, for years.
This is what makes AI a diagnostic tool before it is an automation tool. Its inability to compensate, the very thing that makes an implementation feel like it is failing at first, is precisely what makes the data problem visible for the first time.
The constraint violations were not failures. They were a map.
Once an implementation team understands what the constraint violations represent, the output changes completely in meaning.
Each flagged exception is not a broken output to be fixed in the system configuration. It is a location, a precise address in the product master where the system data has drifted from operational reality, with a record of how long that drift has been running unchecked. The map that emerges from reading those exceptions tells a specific story about the operation. It shows which product categories are most affected, which types of data drift are most common, and how each category of error has been silently compensated for. Supplier specification changes that were documented in quality records but never updated in planning attributes. Equipment replacements logged in maintenance systems but never reflected in resource capacities. Formulation updates that passed through change control but whose planning parameters were never revised.
No manual audit would have produced this map because these errors do not appear in the fields that standard validation rules check. The ERP accepts the values. They pass every automated test. They are wrong in ways that only become visible when a system tries to use them literally to produce an executable production schedule. The AI’s literal-mindedness is the diagnostic instrument, and its output before it automates anything is the most accurate picture the business has ever had of its own data quality.
What Colorcon found when they looked at that map
Colorcon is a global provider of pharmaceutical film coating systems, specialty excipients, and related materials used in tablets and oral dosage forms across more than 100 countries. Their operation runs entirely made-to-order across 700 raw materials and more than 5,000 formula combinations, with no finished goods buffer. The production schedule is the customer commitment, which means a planning error does not become an inventory adjustment. It becomes a missed delivery.
InspireXT built an AI-driven planning layer on top of Colorcon’s existing Oracle EBS environment, using Oracle Fusion Cloud as the planning layer and connecting the two systems through Oracle’s own public APIs, which remain backward compatible through every quarterly platform update. Oracle EBS remained unchanged. A custom constraint-based scheduling algorithm was built inside Oracle Fusion’s extension framework, evaluating formulation type, batch size, equipment availability, cleaning status, and ship date priority simultaneously across all open orders.
When the algorithm ran against Colorcon’s Oracle product master for the first time, it produced constraint violations across a significant portion of the product catalogue. Bulk density values, the parameter that determines which blender handles which formulation and at what batch size, were incorrect for more than 20% of the product records going through the planning process. Colorcon’s planning team had been correcting for these errors for years, adjusting blender assignments from experience every week without ever documenting why. The ERP showed clean data. The planning team knew better. The Head of Supply Chain had visibility into neither.
Once the errors were mapped and corrected, 70% of planning tasks previously handled manually were automated. More than 20% of tasks the team had assumed required human judgment turned out to be automatable once the data underneath them was accurate. The automation rate was not the headline. The data map was. The automation followed from fixing what the map revealed.
The full Colorcon case study is available here: How InspireXT fixed planning and scheduling gaps at Colorcon
If your planners are correcting data your ERP believes is accurate, book a 30-minute review and we will show you exactly which records and what it costs.
Why fixing the data first changes the ROI calculation for AI in planning
Most AI planning ROI conversations in pharma are built around automation rates: what percentage of manual tasks the system will handle, how many planner hours will be freed, and what the productivity improvement will look like in year one. These are real gains, but they are not the largest gain available from the same implementation.
Every AI planning system built on wrong data produces wrong outputs, and it produces them faster. The automation compounds the error rather than the accuracy. A constraint-based scheduling algorithm running against a product master where 20% of records carry incorrect values will automate the wrong schedule at scale, faster than a planner could have produced it manually. This is why data accuracy is the ROI that matters first. Fix the data and the automation delivers its full potential. Deploy the automation on uncorrected data and the implementation team spends the following eighteen months debugging outputs that root cause analysis will eventually trace back to the product master.
McKinsey’s benchmarking across global pharmaceutical companies found that moving from bottom-quartile to top-quartile planning performance is worth two percentage points of EBIT, with the path running through planning frequency and data accuracy rather than capacity investment. For CDMOs specifically, the manufacturers winning contracts in 2026 are those whose planning systems can make delivery commitments with confidence, and that confidence requires accurate data underneath the algorithm.
Why the problem compounds across sites and single-site diagnostics are not enough
The Colorcon engagement surfaced data problems at one site. For a global pharma manufacturer running multiple sites, the same condition exists at each of them, with different planners making different corrections against different drift patterns, none visible to the others. The product master at the US facility has drifted. So has the one in Europe and Asia. Each has been corrected by a different planner, producing a different set of silent adjustments that no one across the enterprise can see.
A single-site AI implementation finds the data problem at one location. For a global manufacturer to understand the full picture of where planning data has drifted from operational reality, the diagnostic needs to run at enterprise scale, across every Oracle instance and every site simultaneously, producing a unified view rather than a sequence of disconnected site projects.
How InspireXT's Data and AI Practice, built on Databricks, runs this diagnostic at enterprise scale
InspireXT’s Data and AI Practice was built in partnership with Databricks to address the data infrastructure problems that enterprise-scale AI deployment in complex industries requires. At a single site, the diagnostic described in this piece runs against one Oracle product master. At enterprise scale, the Databricks Lakehouse architecture aggregates product master data from multiple Oracle instances and other ERP environments into a unified data layer before the planning algorithm runs. Instead of the AI running against one site’s data in isolation, it runs against the enterprise data estate simultaneously, and the constraint violations that surface reflect the full picture of where data has drifted, at which sites, across which product categories, and for how long.
This changes the diagnostic from a project deliverable at one location to an ongoing enterprise capability. The Lakehouse ingests updated product master data on a defined cadence, and data drift that would previously have accumulated silently for years, corrected by individual planners at individual sites without documentation, surfaces as an exception the moment it appears in the data. InspireXT has built delivery frameworks and accelerators on this architecture specifically for pharma and life sciences manufacturers, including product master audit logic, constraint-based scheduling integration, and GMP-aware exception handling. The outcome is an enterprise data foundation that the planning layer can trust, not a technology installation that requires a separate remediation programme.
Three questions every pharma leadership team should answer before their next AI planning implementation
The diagnostic value described in this piece is available to any pharma manufacturer implementing AI-driven planning, but it only becomes available if the implementation starts with the right question. The right question is not what the automation rate will be. It is what the algorithm will find in the data before it automates anything, and whether the organisation is prepared to act on that finding.
Three questions help clarify the answer. First, how many product records in the planning system carry values that planners adjust from experience rather than using directly? If that number is unknown, the data map the AI produces is the most important first deliverable. Second, if the most experienced planner left this week, what percentage of their scheduling knowledge exists in documented form? That gap defines the scope of the data correction problem the AI will surface. Third, when were the critical planning attributes in the product master last audited against actual production outcomes? If the answer is during the original ERP go-live, the drift accumulated since then is running in the operation right now, corrected silently by the planning team, invisible to everyone above them.
Key questions leaders are asking about AI and data in pharma planning
If AI finds data problems first, does the implementation take longer to deliver value?
Not if it is designed around the diagnostic from the start. At Colorcon, the data map produced by the constraint violations was the fastest route to automation, not a delay to it. Every corrected record removed a category of manual override the planner had been performing each week. Implementations that push for automation targets before correcting the data spend the second half of the project debugging outputs that trace back to the product master.
Is the data drift problem specific to Oracle environments, or does it appear across ERP platforms?
The mechanism is the same regardless of platform. Oracle, SAP, and legacy custom ERP systems all hold product master data that was accurate at go-live and has drifted since. The platform determines how the integration is built and how constraint violations surface, but the underlying condition is consistent. The Databricks data layer is platform-agnostic in how it ingests and aggregates product master data from multiple source systems.
What does the first 90 days of an AI planning implementation with InspireXT look like in pharma?
The first phase is always diagnostic before it is productive. InspireXT runs a Day in the Life of a Planner session using the client’s actual orders, product master, and planning constraints on the new system in front of the planning team. This produces the first version of the data map within days. By day 30 the map is substantially complete and corrections have begun. By day 60 the algorithm is running on corrected data. By day 90 the planning team is working on decisions rather than reconciliation.
InspireXT’s Data and AI Practice works with pharma and life sciences manufacturers to close the gap between the planning system the ERP holds and the planning system the business actually runs. If the condition described in this piece is familiar