What are you buying: screens, or the evidence chain?
Here is the question to settle before the first demo is booked. When an inspector asks for last October's deviation, the CAPA it opened, the change that followed, and whether the operators on that shift were trained on the revision in force, how many tools does your team open to answer, and how long does it take? If the answer today is three tools, an email thread and most of an afternoon, that is the cost you are buying software to remove. A platform that looks modern in a ninety-minute walkthrough and still leaves that afternoon in place has not bought you anything.
That framing changes what an evaluation is for. Buying an eQMS for pharma manufacturing is not a software decision with a quality footnote. It is a quality-system decision that happens to be delivered as software, and the thing being purchased is an evidence chain: controlled records, readable approvals and inspection retrieval that stay together without anyone reconstructing them. If the platform cannot do that, it recreates the same work you already do in spreadsheets and shared drives, with a licence fee attached.
The eight-dimension buyer page is the committee briefing: validation evidence, residency, TCO, timeline. This post is the manufacturing test those dimensions have to survive, and the questions I would put to any vendor before shortlisting them.
Buying software is not buying a quality system
QMS versus eQMS is the vocabulary split. This post is the purchase split.
| Software purchase | Quality-system purchase |
|---|---|
| Digitises the forms you already fill in | Governs the work as it moves |
| Stores records in modules | Keeps the evidence chain on the work |
| Wins a demo on screens and click-paths | Wins an inspection on retrieval |
| Leaves validation as a later project | Makes supplier assessment and intended-use assurance part of the buy |
| Easy to switch in a slide | Expensive to leave once it is the record |
A tool can have a document screen, a CAPA screen and a training screen and still fail if those records do not stay connected when the process moves. That is the buying mistake: choosing software that digitises forms instead of governing the evidence chain.
21 CFR Part 11 does not tell you to buy an eQMS. It describes properties of an electronic record. §211.68 already asks that computerised equipment used in manufacturing and control is checked, and that only authorised people change the records it holds. The predicate rule does not pause because the vendor's slide said "compliant".
What an eQMS purchase does not buy you
Three things get sold that cannot be sold.
Compliance. The quality unit still owns the judgements. A platform can make those judgements easier to record and harder to lose. It cannot sign them for you.
A finished validation. EU GMP Annex 11 is blunt: "The application should be validated; IT infrastructure should be qualified." When a third party provides, configures or hosts the system, formal agreements must set out responsibilities, and "the competence and reliability of a supplier are key factors when selecting a product or service provider" (Annex 11, §3). Later: "The regulated user should take all reasonable steps to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately" (§4.5). That assessment is your work. The vendor's pack is evidence you review, not a conclusion you inherit.
A smaller quality system by itself. If deviation, CAPA, change and documents still live as separate piles, you have paid for a login. Connected quality records is what that failure looks like after you already bought. Catch it in the evaluation.
FDA's 2003 Part 11 Scope and Application guidance did not retire the predicate rules. Records still have to be trustworthy for the activity they support. A purchase order is not that proof.
What pharma buyers should score, and in what order
The shortlist is usually built around feature lists. Build it around workflow control instead.
| Evaluation area | What good looks like | Red flag |
|---|---|---|
| Evidence chain | A deviation, its CAPA, the change, the document revision and the training on that revision can be read as one story | Isolated forms; QA rebuilds the path from exports |
| Document control | Current version at point of use; superseded versions readable, not competing | Shadow copies; sign-off chasing in email |
| Audit trail and signatures | History on the record, in a form a reviewer can read; individual credentials | A system log nobody opens; shared accounts |
| Deviations and CAPA | Event to investigation to action to effectiveness, still linked | Closed because the due date passed, not because it worked |
| Change control | Impact, linked documents, training, verification on the same change | Approved in a meeting, implemented from memory |
| Training | Assignment and evidence tied to the procedure that actually changed | Completion-only hours; no link to the revision in force |
| Validation posture | Vendor evidence you can leverage, plus a path for your intended use | "We're validated" with no pack you can review |
| Inspection retrieval | Search, export, readable history, on the clock of an inspection | Evidence that exists only after a week of reconstruction |
| Where records live | A space that holds your records and not another customer's | Vague tenancy; an export you cannot stand behind |
| Cost of leaving | Data out, in a form you can re-validate elsewhere | Hosted screenshots; no usable archive |
The Part 11 RFP scorecard drills the electronic-record clauses. The eQMS RFP scorecard this post wires is the broader bake-off: eight weighted dimensions, three vendors, a number a steering committee can defend. Use both if Part 11 is the gate; use this one to stop a pretty demo beating a weaker trail.
What the demo cannot show you
Demos are rehearsed. Inspections are not.
A walkthrough will show you that a button exists. It will not show you what happens when the person who built the record has left, the procedure has revised twice, and the investigator picked a different deviation from the one in the script.
Ask to drive, not to watch.
- Open a closed CAPA from a date the sales engineer did not pick. Follow it to the source event, the change, the documents, the training.
- Pull the history of one field. Who changed it, when, what it said before, whether anyone reviewed that change.
- Ask for the record as it stood on a date in the past, not only as it stands today.
- Export what you would hand an inspector. Read it. If you need a narrator, the export is not the record.
- Have your validation lead ask where the vendor's evidence stops and your intended-use work begins. If the answer is "we handle all of that", treat it as a claim to test, not a gift.
Why audit trails fail even in digital systems is the post-purchase version of the same test. If the trail is off, unread, or missing the before-value, you will fail it in a live system the same way you fail it in a demo that never opened the trail.
Six questions that survive a polished walkthrough
Write the answers down. If they only exist in the room, they will not exist in the steering pack.
- Can deviation, CAPA, change, document and training stay on one path? Deviation, CAPA and change is the seam.
- Can QA retrieve that path in inspection time, without a reconstruction project?
- Is the audit trail a property of the record, or a separate log that needs a specialist?
- What validation evidence ships, and what remains yours because it is your process? CSV versus CSA is the method.
- Where do the records live, and can you take a copy that is only yours if you leave?
- After go-live, does the quality team's week get smaller or larger?
If 1 or 2 is a speech instead of a click, stop. The rest of the scorecard will not save a system that fails retrieval.
Validation posture for an eQMS buy
This is the evaluation area most teams under-weight because it sounds like paperwork. It is the area inspectors will ask about first once the screens look fine.
Computer software assurance did not lower the bar. FDA finalised the guidance on 24 September 2025 and reissued it on 3 February 2026, the day after the Quality Management System Regulation took effect, under the current title Computer Software Assurance for Production and Quality Management System Software. It is formally a device guidance (CDRH and CBER). Pharma sites still validate under §211.68, §11.10(a) and Annex 11. What travels is the method: intended use first, effort scaled to process risk, vendor evidence used rather than blindly re-run, the conclusion still yours.
So a buyer question is not "are you CSA or CSV?" It is:
- Do you ship evidence a regulated company can actually leverage, or is validation a separate product?
- Can we see how our configuration and our use are supposed to be assured, as distinct from the platform's own testing?
- When you release a change, what do we re-check, and who owns that decision?
GAMP 5 frames the same split in supplier-assessment language. A configured commercial system is not "already validated" because other companies use it. Annex 11 §3.3 even says documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled. Popularity is not intended use.
No approach makes validation automatic. A starting pack shortens the work. Your quality unit still signs the conclusion.
Where the records live
If an export of "our CAPA" can ever include another customer's rows, you do not have a record you can stand behind. Ask, in writing, whether your operational data lives in a database that is only yours. That is a different risk conversation from a shared schema with application-level filters. Do not accept "multi-tenant SaaS" as an answer; ask how isolation is enforced, and ask to see an export.
Region is chosen once. What data residency locks in is the longer version. Write down compute, database and files, and whether the contract names the region. Certificates: ask for the current report and its scope, not a logo.
What a wrong eQMS decision costs
It rarely fails on day one. It fails by putting the old problems inside a nicer wrapper: audit requests still take too long, QA spends the week reconciling the tool, and someone keeps a side tracker "just in case" — which is how you get two originals. Leaving later is a data-migration and re-validation project, not a cancellation. The cost of being wrong compounds for the life of the validation.
What still belongs outside the eQMS
Not every working file should move on day one. Keep analysis extracts, one-off models, and personal notes that are not the record. Spreadsheets in regulated quality draws that line: working file versus system of record. If the file disappeared tonight and you could still reconstruct the quality decision from a governed record, it can stay a working file. If not, it is in scope for the buy.
LIMS, MES and ERP integrations are real. Score them as interfaces that must not break the trail, not as a reason to accept a quality system that cannot hold its own records.
A scorecard before you schedule demos
Do this on paper, or in the workbook, before anyone books a room.
- Name the three processes that hurt most in the last inspection or the last mock. Those are the demo script. Not the vendor's.
- For each, write the retrieval test: which record, from which date, linked to what.
- Weight the eight scorecard dimensions so the two or three that would sink you cannot be outvoted by a long list of nice-to-haves.
- Demand the artefact, not the claim: a sample trail, a sample export, a sample pack, a tenancy statement, an exit format.
- Score 0–5 against that evidence. Notes column on. A "5" without an artefact is a "2" you have not admitted yet.
- Only then watch a demo, and drive it yourself.
That is the fastest way to separate a platform from a polished walkthrough. Download the eQMS RFP scorecard for that bake-off: eight weighted dimensions, three vendors, a number a steering group can defend.
How Complere holds up in that evaluation
The story stays on the work. A deviation, the actions that followed, the change, and the people trained on the revision can be read together. You are not assembling the inspection answer from three exports.
History is something you open, not something you rebuild. Who did what, when, and what the record said before, sits with the action. A reviewer who was not in the room can still follow it.
Approval lives on the item. A sign-off is part of the record it applies to. You should not need last Thursday's email to prove which version was agreed.
Your records sit in a space that is only yours. An export you hand an auditor is yours because there is nothing else in that space to mix in.
Vendor evidence is a start, not a certificate. You get a pack your team can adopt. You still decide intended use, configuration, and what "good" looks like on your site.
Your team owns the decision, the procedures and the assurance conclusion. The software's job is to make the evidence behind them cheap to produce, on the day someone asks and long after the people who made them have moved on.
