While the general best practices and management systems behind quality management have remained consistent for decades, the systems and solutions used to ensure the production and delivery of high-quality products and processes across the value chain have changed drastically. Systems that once seemed ideal have become obsolete and unable to address the rising complexities of today's markets.
Companies initially developed spreadsheet management systems, which were used to monitor and analyze quality data manually. With technological developments, there was a movement toward companies either implementing point quality solutions, many of them homegrown, or quality-specific modules in ERP systems to manage quality. In both cases, the vast majority of companies failed to meet global manufacturing companies' business and technical requirements.
Many companies with a global footprint have multiple Quality Management Systems deployed across the plant network, making the process of standardization a difficult challenge, with different systems that have "grown up" as the plant network matured without standardization as an initial goal.
As a result, many organizations now have a disjointed and broad set of systems that don't easily communicate with one another. Improvements with these systems are often localized, lacking the global visibility needed to manage quality effectively. Requirements and capabilities are often not strictly defined on hard boundaries between software solutions.
The lack of clarity in the market is an additional significant hurdle to grind through, even if the business needs are well-defined and clear. In other words, sorting the wheat from the chaff is still difficult. (Figure 1)
Figure 1: Follow a Business First Approach
This is building on an earlier trend in the space where companies often used ERP, PLM, or generic workflow tools (Lotus Notes) to manage quality. This trend has reversed and is now trending towards packaged tool sets.
The boundaries between EQMS and other software applications are shifting and very porous. For example:
-
-
-
Bleed over between EQMS and Connected Frontline Worker applications.
-
Bleed over between EQMS and Analytics and low-code/no-code aspects of Industrial Transformation (IX) platforms.
-
Unresolved "home" for training and other ancillary functions.
This begs the question: what is the strength of a particular application in helping solve business needs? What is the application "sweet spot" of the value proposition that I should expect and scope to not exceed?
It's the Goldilocks question: which solution is just right, not too hot, and not too cold?
When plotting a strategy for Quality 4.0, consider EQMS solutions with embedded capabilities for the application of:
-
-
-
Low-code/no-code citizen developer environments
-
Analytics for not only embedded process performance but the larger, more impactful analysis of large data sources connected to the EQMS from Operations, Suppliers, Customers, Product Development, et al.
-
Application of Machine Learning and Artificial Intelligence to help speed embedded processes along.
-
Robotic Process Automation to create logic chains within and between processes inside the EQMS solution.
Does the solution criteria need to have all of the capabilities embedded, or does it need to be able to connect to other solution sets that provide the required capabilities? What are the core capabilities needed to be an EQMS?
Software solutions in Industrial transformation have been trending toward interoperability as opposed to a vertically integrated single platform. The trend has been developing for years now and reflects a System of Systems concept.
System of Systems is a concept that a software application has a particular core functionality, such as:
-
-
-
MES has core functionality for scheduling optimization, data collection associated with manufacturing, inventory management, and resource management.
-
EQMS has core functionality for non-conforming material handling, corrective and preventive action processing, audit performance, compliance management, and regulatory reporting (in some cases).
-
Asset Performance Management has core functionality for the management of maintenance of equipment.
Yet all of these systems, and others, interoperate to serve a higher business purpose that is not wholly contained within any of them. Things such as:
-
-
-
Protecting the customer from defects.
-
Achieving the lowest cost to produce a given product
-
Meeting the customer's delivery needs
-
Maintaining maximum flexibility in manufacturing operations
By our definition, an EQMS (Figure 2) is a software application that does these things :
-
-
-
Provides processes and documents to meet the requirements of various ISO and ISO-derived quality standards.
-
Robotic Process Automation within defined processes and between logic chains of related processes (i.e., Deviation to CAPA)
-
Flexibility to have interoperability with other business software systems (as applicable), such as ERP, MES, PLM, CRM, SCM, et al., or be a standalone if those other systems aren't yet deployed.
-
Reporting and analytics capability for processes within the scope of the system.
Figure 2: EQMS in a System of Systems Architecture
However, lines of demarcation are porous. The Quality function has long had an oversight interest in many different aspects of process execution in other functions without ownership of those processes. Such as:
-
-
-
Maintenance
-
Customer Service
-
Product Design
-
Production
-
Delivery
-
Procurement
- Training
The EQMS should have inherent flexibility to interconnect with other applications where partner processes are executed without owning the process.
An example of where things get fuzzy is training.
Quality has traditionally been responsible for training within some organizations. This responsibility comes from requirements of various quality standards and a lack of prior ownership by another function. The role here is to "ensure competence" of people doing work affecting Quality. In recent years, there has been a movement towards implementing Learning Management Systems (LMS) through the corporate HR function. Additionally, Connected Frontline Workforce (CFW) applications have transformed training delivery into "on-demand, point delivery." These moves have disconnected the Quality function from the role.
So, where should the processes for training management and execution live in the digital environment? That question is currently being wrestled with as EQMS providers and others add or refine their training management capabilities. CFW applications are a well-positioned delivery method, but not all training can or should be delivered via a CFW application. There is still a role for an LMS and an EQMS in training as an organizational responsibility, but neither can effectively do everything in all cases.
The process needs to "play through" (Golf term there, sorry) the different applications as necessary to meet the goals. Using the example above, an LMS is ideal for development training type of activities. Still, an EQMS connected to a CFW app is ideal for worker certification and evaluation-type training on the shop floor.
Similar situations exist for Advanced Analytics, Low-Code/No-Code app development, or Machine Learning. There are use cases within the scope of an EQMS for each, but an EQMS should not be the "home" for these capabilities in a System of Systems architecture. However, if these tools don't have a home elsewhere in the digital architecture, an EQMS can house them until more mature, distributed architecture is achieved.
Trends in Quality and other functions impacting EQMS:
There has been some movement in the last couple of years toward solutions that target a specific industry vertical, such as Med Devices and Pharmaceuticals. Acquisitions have also occurred in the last couple of years, notably ETQ's acquisition by Hexagon and Sparta Systems' acquisition by Honeywell.
In our latest research on Digital Performance Excellence, EQMS has found a new set of use cases around providing a home for Digital Performance Excellence processes and toolsets. (Figure 3)
Figure 3: EQMS is the preferred home for DPX
Additionally, aligned with an emphasis on risk management from the Quality perspective, Risk Management around operational agility, flexibility, and resiliency concerns is a top-of-mind aspect of DPX.
No piece of software can change culture by itself. Still, for the elusive "Culture of Quality," being a data-driven, fact-based decision-making, and process-oriented culture, an EQMS goes a long way in making those ideals a reality within the quality function and across the value chain. (Figure 4)
Figure 4: EQMS impacts quality across the value chain
Those who are charting their path for a Quality 4.0 Transformation and considering an EQMS implementation as part of that strategy should:
-
-
-
Follow the LNS Research Transformation Framework, beginning with the business goals
-
Identify short-term needs vs. long-term capabilities
-
Look for capabilities not usually resident within an EQMS if those capabilities don't already exist elsewhere.
-
Insist on device, data, and software interoperability and open architecture supporting data flow in and out of the application.
LNS Research's Quality 4.0 and EQMS studies will be refreshed early next year, so stay tuned for more on this space over the coming months.