I have seen this pattern enough times that the opening sales deck could be automated: infographic of an "integrated quality loop", a hero screenshot of a dashboard, and a promise that "regulatory readiness is built‑in." The reality, in practice, is different: what often arrives is a robust, well‑designed database with document control and a few workflows. Useful, but not the organisational change people bought.
I work on CE‑marking and post‑market files under MDR 2017/745 every day. My job isn’t picking pretty views — it’s making sure Annex II technical documentation, risk files, PMCF and post‑market surveillance connect to the operational realities on the shop floor. An eQMS that is "a database with a UI" can store evidence. It rarely makes teams change how they work.
Where the vendor vision and customer reality part ways
Vendors sell three things: automation, visibility, and compliance-as‑a‑feature. Customers expect the system to fix broken processes, reduce audit stress, and make notified‑body review painless. The gap appears along predictable axes:
- Process vs product: sales decks show idealised workflows. Implementation uncovers undocumented local exceptions, legacy spreadsheets, and critical human checks that the product doesn't accommodate.
- Configuration vs change: vendors expect customers to change their processes to fit the product; customers expect the product to adapt to their regulated processes.
- Features vs outcomes: a "CAPA module" exists, but it may not link to risk files, supplier nonconformances, or design changes in a way that a notified body finds traceable.
- Validation and evidence: the vendor ships software; the customer still needs URS, IQ/OQ, test scripts, and a documented validation strategy to satisfy ISO 13485 and to demonstrate control during audits.
To be fair, no vendor can do your SOPs for you. But most projects fail because nobody asked the right question early enough: how will this tool change the way people do their work?
The common failure modes I actually see
- Under‑scoped requirements. The URS excludes "edge cases" and legacy Excel trackers. Six months in, those trackers are still the single source of truth.
- Weak integration strategy. The eQMS lives by itself; engineering PLM, issue tracker, and the complaint database do not. Traceability becomes manual.
- Insufficient CSV. The "validation pack" is a PDF that doesn't match the configured system. Test coverage is thin and acceptance criteria are vague.
- Poor role design. The system assumes one flavour of user. Engineers swear at the UI; QA uses workarounds.
- Training-as-a-day. A one‑time training workshop produces a few champions, not sustained adoption. The CAPA backlog grows because the tool didn't simplify the owner's task.
- No measurable metrics. Nobody agreed on leading indicators (time to close CAPA, change control lead time) so success is a feeling, not a KPI.
How to stop buying a database and start getting a QMS
From projects that eventually worked, here are the concrete things that changed outcomes.
- Start with mapped processes, not features
- Document the actual steps for change control, CAPA, supplier management and PMCF.
- Identify decision points that need evidence, signatures or escalation.
- Define outcomes and KPIs before you evaluate vendors
- Example KPIs: median CAPA closure time, percent of changes linked to risk assessment, audit findings relating to traceability.
- Require a demonstrable validation package
- URS, traceable test scripts for each configuration, IQ/OQ/PQ or equivalent, and a clear demarcation of vendor vs manufacturer responsibilities in the OQ.
- Plan incremental delivery
- Pilot with one process (e.g. CAPA + change control) and get rapid wins. Use the pilot to refine configuration and training.
- Demand process integration, not API screenshots
- Show me how the eQMS will link a CAPA to a design change, to a supplier NCR, to the risk management file and to the PSUR/PMCF cycle.
- Design for the actual user
- Make the engineer's path short: actions they must do are clear, few clicks, and supported by templates. Avoid forcing engineers to "learn QA speak" to update a record.
Validation is not optional theatre
Under ISO 13485 and MDR obligations, the manufacturer must demonstrate control over records, device history and processes. An eQMS that is delivered as a configurable SaaS still requires a documented validation approach. In my teams I insist on:
- A CSV (computer system validation) plan aligned to the URS.
- Traceable test cases covering normal, edge and negative scenarios.
- A production deployment checklist and a configuration freeze for the pilot.
- Post‑go‑live monitoring: metrics and a review cadence for the first 6‑12 months.
To be blunt: "the vendor validated it" is not sufficient. You must own the validation evidence that maps the system to your QMS processes.
When the vendor truly helps
The vendors I trust are the ones who ask: "How do you do CAPA today?" and then propose a phased automation plan, not a one‑size‑fits‑all template. They provide reusable test scripts, help with migration templates, and expose change‑impact mapping so your engineers can see which documents, risks and devices a change touches.
Connected workflow matters: automated CAPAs that suggest related documents or supplier records are useful only if they are reviewable, auditable and easily overridden by a human. That is controlled assistance; not magic.
Final thought
If your next eQMS evaluation is starting with screenshots and price per user, you are starting in the wrong place. Start with process maps, clear KPIs, and a validation expectation that the vendor must meet. You will still buy a database — but with the right preparation it becomes a QMS that changes how people work.
What single process in your organisation would you pilot first to prove that an eQMS is more than a database?
