CDMO Batch and Project Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does changeover get scoped as a fixed buffer?

Because that is how it appears in the plan the developer is shown. Somebody opens the scheduling board or the project file and there is a gap between two campaigns labelled changeover with a number of days next to it. The obvious software translation is a configurable buffer, and it is quick to build.

The number in that gap is a planner's judgement, not a constant. It depends on the product pair, on whether the pairing requires full cleaning validation sampling or routine verification, on analytical turnaround for those samples, and on quality release capacity for the suite itself. It also consumes resources the schedule needs to know about, particularly laboratory time, which is why sites that model it properly frequently discover the analytical laboratory rather than the suite is their real bottleneck.

The fix is to specify changeover as a first class campaign object before pricing: its own tasks, its own sampling, its own analytical turnaround and its own release gate, with cleaning validation status per product pair held as data. Ask any prospective developer to model a changeover on a whiteboard. A team that has done this asks about product pairs, validation status, laboratory turnaround and suite release. A team that offers a configurable buffer has built a project planner and will not survive contact with your floor.

What goes wrong when you bring existing batch records and product data into the system?

The batch records do not migrate, and expecting them to is the single most common planning error here. An approved master batch record is a controlled document tied to a client's filing and your quality system, and moving it into a new structure is authoring and approval work rather than a data transfer. Executed records from previous campaigns stay where they are under your retention obligations and should be left there.

What can be migrated is the wrong thing to migrate directly. Every client programme currently holds its own record authored from scratch, so importing them one by one reproduces the problem the build exists to solve, which is that onboarding a new programme takes months of configuration.

The fix is to invert the work. Before migration, decompose your existing records into a library of reusable unit operations owned by your organisation, each with its own controls, prompts and evidence requirements. A client programme then assembles those blocks with client specific parameters, limits and additional steps, and only genuinely novel steps need new authoring. That decomposition is quality unit work with quality unit timelines, and it should be sequenced ahead of the software with its own owner and its own deadline. It is also the deliverable that moves programme onboarding from months toward weeks, which is capacity your commercial team can sell.

Why do the manufacturing execution, laboratory and ERP (Enterprise Resource Planning) integrations break after launch?

Because they are four different problems that proposals routinely price as one line. Reading batch progress from Korber PAS-X or Emerson Syncade is not the same as writing an instruction into it. A laboratory information management system speaks a different language about samples and results. Your ERP owns materials and finance and knows nothing about a campaign.

After launch the failures are quiet. A sample result that arrives with a status the scheduler does not recognise stops advancing a changeover, and the suite sits while everyone believes the laboratory is late. A material lot released in the ERP under a code that changed does not reach the campaign, and a planner works around it manually, which means the schedule and reality diverge without anybody filing a fault.

The fix is to name one owner per fact and monitor the data rather than the connection. The execution system owns what happened on the floor. Your layer owns the schedule, the programme structure and client visibility. The ERP owns materials and finance. Then track the flows themselves: unmatched sample results, campaigns whose planned and actual durations diverge beyond a threshold, materials expected and not received. Alert on movement, because these interfaces almost never fail with an error, they fail by going quiet.

What happens when client segregation is treated as a permissions setting?

You fail a client audit, and the remedy is architectural rather than a configuration change. Two clients in your building may be competitors. One may have a person in plant walking your corridors. Both have audit rights. Neither may see the other's process, materials, schedule detail, deviations, or even that a particular capability exists on your site. A role that hides a menu does not satisfy that, because the data is still reachable through a report, an export or a search.

The specific exposures are predictable. A cross programme scheduling view shown to a client contact reveals another client's campaign timing. An export leaves the building with no record of who took it. A search returns a result the user should not know exists.

The fix is to make programme scope a property of the data model rather than the interface: every record belongs to a programme, every query is scoped to the programmes the user is entitled to, and cross programme views exist only for named internal roles. Client portals become read only projections of that client's own programme covering campaign status, batch progress against plan, open deviations affecting their material, documents awaiting their review and released quantities. Watermark and log every export. Get this right at the start, because retrofitting it after an auditor asks how you enforce segregation costs far more than designing it in.

Should you build custom or configure what you already own?

If you run one or two suites for a small number of clients on a single modality, stay where you are. A validated paper or hybrid batch record, a scheduling board and your ERP will hold, and a platform build would consume capital that belongs in equipment.

If you already run PAS-X, PharmaSuite or Syncade, keep them for execution. They execute batches well, they are validated, and replacing them means revalidating the part of your operation with the highest regulatory weight for no commercial gain. The sensible split is to keep the execution system and build the scheduling, programme management and client visibility layer around it, which is significantly cheaper than replacement and is frequently the superior answer regardless of cost.

Before commissioning anything, ask your quality and production leads what your current systems can do that nobody uses. Configuration and training gaps account for a share of the frustration in most sites we look at, and closing them costs a fraction of a build.

Build when two or more hold: more than three suites with shared equipment so scheduling is a genuine constraint problem, more than four client programmes onboarded a year with configuration time limiting how much business you can accept, competing clients in the building whose separation depends on people being careful, a commercial team quoting dates operations does not trust, or milestone billing you know is leaking and cannot locate.

How do hidden costs get into the quote?

Through five doors, and the first roughly doubles the engineering effort of anything it touches.

• Electronic batch records in scope. Executed records carry validation, audit trail and electronic signature obligations, and a quote that prices a record module like a form builder has not accounted for any of it.
• Number of modalities. Sterile fill finish, active ingredient synthesis and cell therapy have genuinely different campaign models, and one abstraction covering all three usually produces something awkward for each. Pick one modality and one suite group first.
• Replace versus integrate. Integrating an existing execution system is materially cheaper than replacing it, and the two options should never appear under the same price.
• Client portal depth. Read only status is straightforward. Client review and approval of documents inside your system brings identity, signature and confidentiality questions that are real work.
• Constraint elicitation. Changeover rules and scheduling constraints exist as an experienced planner's judgement in most sites, and turning them into data takes weeks of structured sessions that belong in the plan as a priced deliverable.

What separates a build that works from one that fails here?

Model a changeover with them before you sign anything, and judge the questions they ask rather than the diagram they draw. Product pairs, cleaning validation status, analytical turnaround and suite release are the right questions. A fixed buffer is the wrong answer and it predicts the rest of the project.

Ask how client segregation is enforced, and accept only programme scoping in the data model and in every query. Roles and hidden menus will fail an audit and you will pay for the rebuild.

Ask what they have actually integrated, naming the system, and expect an honest account of which of PAS-X, Syncade, a laboratory system and an ERP they have not done. Those are four different problems with different protocols and different internal politics, and a supplier claiming all four without specifics is describing a capability rather than a history.

Sequence the release so the first thing you deliver is scheduling with changeover, programme structure, segregated access and a client status portal, and leave electronic batch records to a later phase once the scheduling numbers are trusted. Then settle ownership before kickoff: your repository, your infrastructure accounts, your unrestricted right to hire anyone else. At Digital Heroes the client owns the code from the first commit. A system holding your clients' process knowledge and your executed manufacturing records must never be recoverable only through a supplier's cooperation.