Why most pharma ERP projects fail at validation, not technology

The right ERP system is one that carries the GMP-relevant functions as standard and can be validated under EU GMP Annex 11: audit trail, access control, electronic signature, a batch status that blocks until release, and a link to serialisation. Three system classes meet this in different ways. An industry ERP often brings these functions with a vendor validation package; the price is a smaller vendor and partner market. A standard ERP with a GxP add-on combines a broad base system with a partner's industry logic; the price is two release cycles that both touch validation. A generalist ERP gives the most freedom but requires GxP functions to be built and validated in-house. Which class fits is decided by your GMP-relevant processes, your markets and your development stage.

Annex 11 of the EU GMP Guide governs computerised systems used in GMP-relevant processes. It doesn't prescribe a particular ERP, but it defines what the system must do and how it must be operated. That includes risk management across the life cycle, validation of the system, supplier assessment, data integrity at entry and storage, an audit trail for GMP-relevant changes and deletions with a documented reason, controlled access, and electronic signatures linked to the record. If batch release is recorded in the system, only a Qualified Person may give it. For the selection, this means: check these points against the system's standard, not against a promise of later customisation. The annex is currently being revised; the core requirements remain.

Yes, as soon as you generate data relevant to approval, manufacturing or distribution on the US market. 21 CFR Part 11 is the US FDA regulation on electronic records and electronic signatures. It applies by market, not by where the company is based: if you supply active ingredients or medicines to the US or manufacture for a US partner, you must meet its requirements. Part 11 and Annex 11 overlap heavily – audit trail, access control, validation, electronic signature – but differ in detail, for example in the requirements for signatures. So before the selection, clarify which markets you supply today and will supply in five years. A system designed only for the EU market becomes expensive when the US market is added later.

Risk-based and across the whole life cycle, not as a one-off test before go-live. In practice, many companies follow the ISPE's GAMP 5 guide. It starts with requirements: which processes and data are GMP-relevant, and what must the system do for them? From that follows a risk assessment that determines which functions are tested and how deeply. Then come supplier assessment, specification, testing of installation, functions and processes in operation, and a validation report. What matters for the ERP selection is how much of this the standard already carries. The more GMP-relevant functions are configured rather than programmed, and the better the vendor's validation package, the smaller your own validation scope – and the less has to be retested with every release.

With a batch status that has teeth. Every batch moves through defined states in the system – such as quarantine, in testing, blocked, released – and only the status "released" allows picking and shipping. The release itself is given by the Qualified Person under Annex 16 of the EU GMP Guide. If it is recorded in the ERP, Annex 11 requires that only authorised Qualified Persons can give it, with an electronic signature and unambiguous attribution to the person. The system should also manage retest and expiry dates, handle partial releases and market-specific blocks, and control batches from contract manufacturing with the same status as your own. It often fails not on the function but on the process boundary: release sits in the quality system, status sits in the ERP, and nobody has decided which system leads.

Since 9 February 2019, prescription medicines in the EU have had to carry safety features under the Falsified Medicines Directive 2011/62/EU and Delegated Regulation (EU) 2016/161: a unique identifier in a Data Matrix code with product code, serial number, batch number and expiry date, plus an anti-tampering device. The serial numbers are uploaded to the European verification system – in Germany via securPharm. The ERP usually doesn't generate the serial numbers itself, but it supplies the data they are based on: batch, expiry date, item and pack size. If this data runs separately in the ERP and the serialisation system, discrepancies arise that only surface at upload or verification. So test the interface between ERP and serialisation system during the selection, not during the project.

Almost everything that affects the ERP. In development, much of the data lives in lab notebooks, spreadsheets and standalone systems, and products are tracked in small quantities with a lot of manual work. Production brings commercial-scale batches, release processes, contract manufacturers, supply chains and inspections. At Formycon, a developer of biosimilars, tracking products across the value chain was entirely manual before the project. We gathered the requirements from the future operating model, not today's, designed the tracking process together with the company, and only then implemented it in the selected system. The order is the point: if you select the ERP for the development stage, you are selecting it for a stage that is just ending.

Yes, but responsibility stays with the company. Annex 11 requires outsourced services and their providers to be assessed and contractually governed as well. For a cloud ERP this covers where data is held, provider access, backup and restore, archiving over the required retention periods, and exit from the contract. The real question is the release cycle: a SaaS vendor rolls out updates on its own schedule, and every update can touch GMP-relevant functions. Without an agreed strategy – which changes the vendor announces in advance, which tests you run before deployment, which functions you can hold back for a time – every release becomes a validation project. Check this in the contract before you decide on the deployment model.

The time doesn't go into comparing systems, but into process analysis, assessing GMP relevance and the requirements specification. Only once it is clear which processes are GMP-relevant and which data the regulator needs to see can a vendor show in a proof of concept how their system works with your cases – not with their demo data. We plan each stage individually – process analysis, requirements specification, market analysis, selection with proof of concept – and fix its scope before it starts.

The effort depends on the number of GMP-relevant processes, sites, markets and contract manufacturers – not on company size alone. A development company before its first commercial batch has different requirements from a manufacturer with several sites and deliveries to the US. That is why we price each stage separately – process analysis, requirements specification, market analysis, selection with proof of concept – and fix its scope before it starts. After each stage you can stop, continue or adjust the scope. Our fee is the same whichever system you choose in the end: we don't sell licences and receive no vendor commission.