What Makes a QMS Implementation Successful: Five Factors From the Field

What Success Means for a QMS Implementation

A quality management system (QMS) is the set of processes a company uses to control quality: deviations, CAPA (corrective and preventive action), change control, complaints, audits, training, and document control. An electronic QMS, or eQMS, is the software that runs those processes. When people talk about a “QMS implementation,” they usually mean moving those processes from paper, spreadsheets, or an older eQMS onto a new platform, often across several sites and countries at once.

It is easy to define success as go-live: the system is validated, the data is migrated, and users can log in. That definition is too narrow. A system can go live on schedule and still fail in every way that matters. Users build side spreadsheets because the workflow does not match their work. Sites keep their own local forms because the global design ignored real differences. Investigations take longer because a three-step approval has grown to seven. Records become hard to read because nobody agreed what a complete record looks like.

A recent trade column by two eQMS practitioners put the problem plainly: two companies can license the same system and arrive at very different results, because one builds a clean, navigable system and the other builds a maze of categories, fields, and approval steps.⁶ The same authors argue that “implementation should be treated as a quality design activity, not a technical deployment.”⁶ We agree, and the five factors in this article are a way to make that idea concrete.

The Regulatory Baseline Is About Management, Not Software

The regulations do not tell you which eQMS to buy. They tell you who is responsible for the quality system working. ICH Q10, the international guideline on pharmaceutical quality systems, states that “Senior management has the ultimate responsibility to ensure an effective pharmaceutical quality system is in place to achieve the quality objectives.”¹ It also says management should participate in the design, implementation, monitoring, and maintenance of the system, and should define roles, responsibilities, and authorities across the organization.¹ EU GMP Chapter 1 carries the same expectation, and adds that senior management’s leadership should secure the support and commitment of staff at all levels and sites.²

In the United States, 21 CFR 211.22 gives the quality control unit the responsibility for approving or rejecting all procedures or specifications that affect the identity, strength, quality, and purity of the drug product, and requires its responsibilities and procedures to be in writing.³ A new eQMS changes many of those written procedures at once. That alone makes the implementation a quality decision, not an IT project that quality signs off at the end.

FDA’s guidance on the quality systems approach to CGMP makes the multi-site point directly. It says that in a well-run quality system, “all managers should demonstrate strong and visible support for the quality system and ensure its implementation throughout the organization (e.g., across multiple sites).”⁴ A global QMS rollout is exactly that situation.

Why the Stakes Are Higher Than a Software Upgrade

The quality system is also where regulators increasingly look for signs of maturity, not just compliance. FDA’s Center for Drug Evaluation and Research (CDER) runs a Quality Management Maturity (QMM) program built around five practice areas: management commitment to quality, business continuity, advanced pharmaceutical quality system, technical excellence, and employee engagement and empowerment.⁵ CDER’s 2023 white paper on the program notes that the multiagency federal Drug Shortage Task Force found 62% of drugs that went into shortage between 2013 and 2017 were linked to manufacturing or product quality issues.⁵ A QMS that people trust and use helps detect problems early. A QMS that people work around hides them.

Sakara Digital’s earlier two-part series, Implementing a Global Quality Management System (QMS): Lessons from the Field, walked through the phases of a global rollout, from governance and harmonization to data migration, validation, go-live, and sustainment. This article takes a different cut. It looks across the phases at the five conditions that decide whether those phases go well, and at how to test for each one before the project starts.

Factor One: A Clear Vision With Agreed Goals

Every QMS implementation starts with a reason. A recent inspection finding exposed weak CAPA tracking. The legacy eQMS is reaching end of support. A merger left the company running three quality systems. Leadership wants one set of quality metrics across all sites. Each of these is a valid reason, and each points the project in a slightly different direction.

The trouble starts when the reasons are not written down and ranked. Most programs claim three goals at once: compliance, efficiency, and global harmonization. Those three goals often pull against each other. A clear vision does not pretend otherwise. It says which one wins when they collide.

How the Three Common Goals Compete

None of these goals is wrong. The problem is that each design decision during configuration will favor one over the others. If the steering committee has not agreed on the order, the order gets set by whoever is in the configuration workshop that day. That is how a deviation workflow designed for efficiency at one site ends up with compliance steps added by a second site and harmonization fields added by the global team.

Writing Goals That Can Be Measured

ICH Q10 asks senior management to make sure quality objectives are defined and communicated, are supported by all relevant levels of the company, and align with the company’s strategy. It goes on: “Performance indicators that measure progress against quality objectives should be established, monitored, communicated regularly, and acted upon as appropriate.”¹ That standard applies to the quality system itself, and it is a good standard for the implementation program too.

A goal like “improve efficiency” cannot guide a configuration decision. A goal like “reduce the median time from deviation open to investigation approval” can. So can “every site reports CAPA effectiveness using the same definition” or “no open audit observation relates to the QMS process at go-live plus six months.” The specific targets belong to the company, and they should come from its own baseline data, not from a vendor brochure.

Three practical tests help here:

• Baseline first. If you cannot measure today’s cycle time, record quality, or overdue rate, you cannot show improvement later. Pull the baseline from the legacy system before migration changes the data.
• One owner per goal. Each goal should have a named executive who answers for it at steering committee meetings.
• A stated limit. Each goal should carry at least one limit, such as “without increasing approval steps” or “without reducing the information available to investigators.”

Vision Is a Leadership Act, Not a Project Charter Section

The earlier SD series made the point that executive sponsorship must last beyond kickoff. The vision is the main thing sponsors bring to the table. A sponsor who funds the program but cannot explain in two sentences what it is for, and which goal wins in a conflict, is not giving the project what it needs.

The authors of a recent column on eQMS selection make a related point: “An eQMS should not be viewed as a technology program, nor as a substitute for leadership, governance, or culture.”⁷ They also note that selection decisions are often driven by historical use, familiarity, perceived industry standards, and incumbent vendor relationships, with objective requirement-driven evaluation coming second.⁷ When the vision is vague, the same habits shape the implementation as well.

Factor Two: Engage Quality, Manufacturing, Regulatory, IT, and End Users Early

A QMS touches almost every function in a pharma or biotech company. Deviations start on the manufacturing floor or in the QC lab. Change control reaches into engineering, validation, supply chain, and regulatory affairs. Complaints come through commercial and pharmacovigilance channels. Training records span the whole workforce. If any of these groups first sees the new system during user acceptance testing, the project is already behind.

Early engagement means these groups help define the design, not just review it. EU GMP Annex 11, the EU’s GMP annex on computerized systems, says “There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT.”⁹ ICH Q9(R1) makes a similar point about quality risk management: it is usually done by interdisciplinary teams that include experts from the relevant areas, such as the quality unit, engineering, regulatory affairs, production operations, and supply chain.⁸ The risk assessments that shape a QMS configuration need the same mix of people.

What Each Function Brings, and What Happens Without It

End Users Are Designers, Not Just Testers

The most common engagement mistake is treating end users as a test resource. They are brought in for user acceptance testing, find that the workflow does not match their work, and are told that the design is frozen. At that point the choice is between a slow redesign and a system people will resent.

A better pattern is to involve a small group of representative users from the start. The Pharmaceutical Online column describes a core team in which quality owns the design intent, a knowledgeable administrator turns that intent into configuration through process mapping, and representative end users test whether the result matches how work is done.⁶ The authors recommend a defined design phase that documents intended workflows and record expectations before anything is built, followed by sandbox testing against real scenarios.⁶

“Real scenarios” matters. A test script that walks through an ideal deviation tells you little. A walkthrough of last quarter’s three messiest deviations, using the proposed workflow, tells you a great deal: where the form has no field for what happened, where the approval route breaks when a site QA head is on leave, and where the investigator has to leave the system to find information.

Regulatory Affairs Is the Function Most Often Missed

Quality, manufacturing, and IT are nearly always on a QMS project. Regulatory affairs often is not, because the QMS is seen as an operations system. That is a mistake, mostly in change control. Many changes to processes, suppliers, specifications, or facilities can affect what a company has registered with health authorities. The change control workflow is where someone has to ask whether a regulatory submission is needed, and in which countries.

If regulatory affairs helps design that step, the question gets asked consistently and the answer is recorded in the system. If it does not, the question is handled informally, and the gap tends to surface during an inspection or a regulatory filing.

Make Engagement Real by Giving People Time

Early engagement only works if people have time to do it. A manufacturing lead who is asked to join design workshops on top of a full production schedule will send a deputy, skip sessions, or approve designs without reading them. ICH Q10 asks management to determine and provide adequate resources, including human resources, to implement and maintain the quality system.¹ For an implementation, that means backfilling or freeing up the subject matter experts the design depends on, and saying so in the project budget.

Factor Three: A Global Core With Risk-Based Local Flexibility

Global harmonization is one of the strongest reasons to implement a new QMS. One process across sites makes metrics comparable, lets quality leaders see trends across the network, simplifies training, and reduces validation effort for future changes. But full uniformity is rarely possible, and trying to force it can push sites into workarounds.

The regulations expect this balance. ICH Q10 says: “While some aspects of the pharmaceutical quality system can be company wide and others site specific, the effectiveness of the pharmaceutical quality system is normally demonstrated at the site level.”¹ EU GMP Chapter 1 contains the same principle, along with the requirement that the size and complexity of the company’s activities be considered when developing or changing the quality system.² Inspectors visit sites. A global design that looks clean at headquarters but cannot be explained at the site level does not help anyone.

What Belongs in the Global Core

The global core is the set of elements every site uses in the same way. It should be large enough to make the system comparable across sites and small enough that sites can still run their operations. In practice, these elements usually belong in the core:

• Process structure. The main stages of each workflow (for example, initiation, assessment, investigation, approval, and closure for a deviation) and the decision points between them.
• Classification schemes. Severity and risk categories, root cause categories, and change types. Without common categories, global trending is impossible.
• Data definitions. What “overdue,” “closed,” and “effective” mean, and which date fields drive each metric.
• Record completeness standards. What a complete deviation, CAPA, or change record must contain before it can be approved.
• Core roles and approval authority. Which roles must approve which decisions, in line with the quality unit’s responsibilities.
• Global metrics. The small set of indicators that leadership reviews across the network.

Where Local Variation Is Justified

Local flexibility is not a loophole. It exists because some differences between sites are real and lasting. Common reasons include:

• Local regulatory requirements. GMP rules have moved closer together, but they are not identical. Japan, for example, revised its GMP Ministerial Ordinance effective August 1, 2021, to introduce the pharmaceutical quality system at manufacturing sites, with international harmonization of GMP standards as one stated aim.¹¹ Convergence of this kind narrows the gaps, but the wording, documentation practices, and inspection focus of each authority still differ.
• Product and process type. A sterile fill-finish site, an API plant, and a packaging site generate different deviation types and need different investigation detail.
• Site size and volume. A site with a handful of quality staff may not have enough people to support the same number of separate approval roles as a large plant.
• Language and local procedures. Users must understand the procedures and forms they follow. Training under 21 CFR 211.25 has to be in the operations the employee performs and in the written procedures as they relate to that employee’s functions.¹³
• Local systems. Sites may run different ERP, LIMS, or MES systems that the QMS must connect to, at least until those are harmonized too.

Use Quality Risk Management to Decide, Not Negotiation

The hardest part of this factor is not the list. It is the process for deciding when a site gets a variation. Without a clear process, the decision becomes a negotiation, and the site with the loudest leader gets its way. A better approach is to treat each variation request as a small risk-based decision.

ICH Q9(R1), the revised guideline on quality risk management, states that “The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk.”⁸ It also warns that subjectivity can directly affect the effectiveness of risk management activities and the decisions made, and says subjectivity should be managed and minimized.⁸ Both ideas fit variation requests well. A request to add a local field for a site-specific equipment ID is low risk and should be easy to approve. A request to remove a global approval step or change a severity definition is high risk and needs real justification, because it breaks comparability and may weaken a control.

Keep the Core Lean, Including the Configuration

A global core is also the best defense against configuration growth. The Pharmaceutical Online column describes how a deviation process that should need three approval steps can, after a series of well-meant additions, come to require seven.⁶ The authors recommend staying within the vendor’s base configuration wherever possible and treating every customization request as a liability that must be justified, because customizations may not survive vendor upgrades and generate recurring validation and maintenance work.⁶

The same logic applies to validation. EU GMP Annex 11 asks that risk management be applied throughout the lifecycle of a computerized system, and that decisions on the extent of validation and data integrity controls be based on a justified and documented risk assessment.⁹ The Pharmaceutical Online authors point to ISPE’s GAMP 5 Second Edition, the industry guide to computerized system compliance, as a sound basis for matching the rigor of validation and documentation to risk and complexity.⁶ FDA’s final guidance on Computer Software Assurance (first issued in September 2025 and reissued on February 3, 2026, under the title Computer Software Assurance for Production and Quality Management System Software) takes a similar risk-based view, although it is written for medical device production and quality management system software rather than for drug manufacturers.¹²

For a QMS implementation, this means a lean global core is easier to validate, easier to change later, and easier to explain to an inspector. Each local variation adds to the validation and maintenance burden for every future release. That is one more reason to approve variations through a risk-based process rather than by default.

Factor Four: Change Management From Day One

A note on terms first. ICH Q10 uses “change management system” to mean the control of changes to products and processes, one of the four core elements of a pharmaceutical quality system.¹ In a QMS implementation, “change management” also means something else: helping people move from the way they work today to the way the new system expects them to work. Both matter, and teams sometimes confuse them. This section is about the second meaning.

People-focused change management is often scheduled late. Training is planned for the month before go-live, communication starts when the cutover date is announced, and resistance is dealt with as it appears. By then, the design is fixed and the main opportunity to bring people along has passed.

Training Is Necessary, but It Is Not Change Management

Training is required. Under 21 CFR 211.25, each person in drug manufacturing must have the education, training, and experience to perform assigned functions, and training must cover the operations the employee performs and the CGMP requirements and written procedures related to those functions.¹³ A new eQMS changes procedures, so it changes training needs for nearly everyone.

But training on screens is not the same as helping people change how they work. FDA’s quality systems guidance says typical quality systems training should address policies, processes, procedures, and the desired work culture, including topics such as communication, change, and behavior. It also lists evaluation of training effectiveness as part of what managers are expected to establish.⁴ A user who can click through a deviation form but does not understand why the new severity categories exist will pick the wrong one, and global trending will suffer.

Good QMS training for an implementation usually has three layers:

• Why the process changed. What the old process got wrong, and what the new one is meant to fix. This is where the vision from Factor One reaches the user.
• How the work changes. Who now does what, which decisions move, and which handoffs disappear or appear.
• How to use the system. The screens, fields, and steps, ideally taught using the site’s own real examples.

Who Delivers the Message Matters

Prosci’s benchmarking research on change management, drawn from more than 10,800 responses from change management professionals, finds that active and visible sponsorship has been the top contributor to success since 1998.¹⁴ The same research reports that “58% of employees prefer to receive communications about the personal impacts of change directly from their supervisors,” while most want to hear the business reasons from the CEO.¹⁴

For a QMS program, that points to a two-level communication plan. Senior leaders explain why the company is investing in a new quality system and what it is meant to achieve. Supervisors and site quality leads explain what it means for each person’s daily work. A global communication from headquarters cannot do the second job, however well written.

Do Not Skip the Middle Managers

Prosci’s research identified mid-level managers as the group most resistant to change, with 43% of participants naming them.¹⁴ In a QMS implementation, mid-level managers are often the people whose approval queues, reports, and team workload change most. A QC manager who used to see every deviation in a spreadsheet may now see them in a dashboard that works differently. A site QA lead may gain or lose approval authority.

These managers need to hear about the change early, help shape it where they can, and get support to lead their teams through it. If they are not on board, their teams will notice, and the new process will be followed in form but not in spirit.

The Compliance Culture Barrier

There is a barrier particular to regulated industries. A peer-reviewed study of continuous improvement in the Irish pharmaceutical industry found that 45% of participants saw a highly regulated environment as a possible barrier to continuous improvement.¹⁵ The main obstacles linked to strict regulatory regimes were “fear of extra validation activity, a compliance versus quality culture,” and a regulatory culture of being “safe.”¹⁵

QMS implementations meet this barrier head on. Users and managers may resist changes not because the new process is worse but because any change feels risky. A risk-based validation approach, explained clearly, helps. So does showing people that the new system is meant to make quality work easier to do well, not just easier to audit. Change management in this setting includes helping people see that a well-designed process change is itself a quality improvement.

Build Internal Capability, Starting With Administrators

The earlier SD series stressed the role of business champions in training and adoption. One group deserves specific attention: system administrators. The Pharmaceutical Online column argues that weak administration is often the hidden cause of struggling implementations, and that formal administrator training on configuration, category management, and permissions is a high-return investment.⁶ Administrators influence how categories are maintained, how change requests are handled, and whether the system stays clean after go-live.

If administrators learn the system only from the implementation partner’s handover document, the company will depend on outside help for every change. If they help configure the system from the start, they can maintain it when the project team leaves.

Factor Five: Partners Who Understand Regulation, Process, and People

Almost no pharma or biotech company implements a global QMS alone. Most work with the software vendor, a systems integrator, and often a validation or advisory partner as well. The choice of partners shapes the result as much as the choice of platform.

The regulations make clear that using partners does not move accountability. EU GMP Annex 11 says that when third parties are used to provide, install, configure, integrate, validate, maintain, modify, or retain a computerized system, formal agreements must exist that include clear statements of the third party’s responsibilities. It adds that internal IT departments should be treated the same way.⁹ Annex 11 also states that the competence and reliability of a supplier are key factors in selection, and that the need for an audit should be based on a risk assessment.⁹ ICH Q10 applies the same logic to outsourced activities in general: the pharmaceutical company remains ultimately responsible, and should assess the suitability and competence of the other party before outsourcing.¹

Three Kinds of Understanding a Partner Needs

Many partners are strong in one of the first three. Software vendors know their platform. Integrators know configuration and data migration. Validation firms know testing and documentation. Fewer combine regulatory depth, hands-on quality process experience, and attention to the people side. When one partner lacks a dimension, the company has to fill it, either with internal staff or with a second partner, and the plan should say who.

Questions to Ask a Prospective Implementation Partner

The Foundation the Partner Inherits

Even the best partner cannot fix weak foundations. ProPharma Group’s guidance on eQMS implementation notes that an implementation “is only as good as the foundation that was established,” pointing to clarity in the user requirements, effort invested in business process models, the right people on the project, and clearly defined responsibilities for the solution provider.¹⁶ Most of those foundations are owned by the company, not the partner. They are Factors One through Four.

This is also why partner selection should come after the vision is agreed and the core team is named. A company that picks a partner before it knows what it wants will tend to adopt the partner’s default design, which may suit the partner’s last client better than this one.

How the Five Factors Depend on Each Other

The five factors are not a menu. Each depends on the others, and a weakness in one shows up as a problem in another. That is why programs that seem to fail on one point, such as a delayed go-live or poor adoption, often trace back to a different factor.

Common Failure Chains

The Order Matters

The factors also have a natural order. The vision (Factor One) has to exist before the right people can be engaged (Factor Two), because they need to know what they are designing toward. The cross-functional team is what makes a sound global core and variation process possible (Factor Three). Change management (Factor Four) starts at the same time as design, because the people designing the system are the first people who need to change. And partners (Factor Five) are best chosen once the company knows what it wants and who will own the result.

In practice, programs rarely get to do things in a clean sequence. A legacy system may be near end of support, or a merger may set the timeline. When time is short, the factors still apply. What changes is that the steering committee has to make explicit decisions about which risks it is accepting, rather than finding out later.

The Quality Maturity Connection

There is a final reason to think about the factors together. The five practice areas in CDER’s QMM program (management commitment, business continuity, advanced pharmaceutical quality system, technical excellence, and employee engagement and empowerment) describe a mature quality organization.⁵ The QMM white paper describes engaged employees as people at all levels who take ownership and are empowered to identify, communicate, escalate, and start changes that improve processes.⁵ A QMS implementation run on these five factors exercises the same capabilities. A company that runs its implementation this way is not only installing a system; it is practicing the behaviors a maturity assessment looks for.

A Readiness Check Before Kickoff

The checklist below is meant for a steering committee meeting before the program starts, or at an early checkpoint if the program is already underway. It is deliberately short. Each question should have a clear yes or no answer and a named owner. A “no” is not a reason to stop. It is a risk the committee should either fix or accept on the record.

Using the Check During the Program

The same questions work as a periodic health check. Revisit them at the end of design, before validation execution, and before each site’s go-live. Some answers will change. A site may join late and need its own engagement plan. A new executive may arrive with different goals. The variation register may grow faster than expected. The point is to notice these shifts while they can still be managed.

It also helps to track a few measures that show whether the factors are holding:

• Vision: the number of design decisions escalated to the steering committee because goals conflicted, and how quickly they were resolved.
• Engagement: attendance of named design team members at design sessions, by function.
• Global and local: the number of approved variations by site and type, and how many have passed their review date.
• Change: training completion before go-live, and record error rates in the first months after go-live.
• Partners: the share of configuration changes after go-live that internal administrators can make without outside help.

These are not industry benchmarks. They are signals for the program team. Their value comes from watching the trend at your own company, not from comparing against a published number.

After Go-Live: Keeping the Factors Alive

The five factors do not end at go-live. The vision needs to be restated as the system moves into routine use and new goals, such as better trending or AI-assisted review, come forward. The cross-functional team should continue as a process ownership group. The variation register needs regular review. Change management continues with every vendor release that changes the user experience. And the partner relationship should shift from delivery to support, with the company’s own team doing more over time.

ICH Q10 asks senior management to govern the quality system through management review, to make sure it remains suitable and effective.¹ A new QMS is a good occasion to make that review meaningful: to use the system’s own data to ask whether quality processes are working, and to act on the answer.

Conclusion

QMS implementation success is decided mostly outside the software. A clear, ranked vision gives every design decision a direction. Early involvement of quality, manufacturing, regulatory, IT, and end users makes the design fit the work. A lean global core with a risk-based variation process gives the network comparable data without forcing sites into workarounds. Change management that starts on the first day brings people along while their input can still shape the result. And partners who understand the regulations, the processes, and the people help build a system the company can run on its own. Each factor maps to a clear regulatory expectation, from ICH Q10’s management responsibilities to Annex 11’s rules on cooperation and supplier agreements, which is a useful reminder that these are not optional extras. They are part of running a quality system well.

Sakara Digital works with pharma and biotech organizations planning and running quality system implementations, from defining the vision and global design to readiness checks and partner selection. If you are preparing a move to a new eQMS, or a program already underway has started to drift, and you want an independent perspective on where to focus, we are happy to have that conversation.

For Further Reading