Lines are blurry, and it’s not helping Quality 4.0 program leaders

My LNS Research colleague Tom Comstock recently wrote an update to the IX Platform landscape that was published in our Industrial Transformation blog. 

There is one theme from that post that I want to pull the thread further on here; Blurring lines of demarcation between architectural elements of Industrial Transformation (IX).

This was a significant issue when I was on the other side of the table, trying to develop my strategy. 

As I was educating myself on the offerings, I found that a couple of things stood in my way of achieving clarity. 

1. 1. 1. Everyone calls themselves a “Digital Transformation Solution” because it’s a marketing tactic.

      2. Defining the fit between needs and potential solutions was up to me. 

Of course, this second issue aligns with LNS Research’s recommendation to follow a “business first” approach (Figure 1), where the goals and objectives are defined first, well before solutions selection is on the table.

Figure 1: Follow a business-first approach

Still, the lack of clarity in the market is a 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. 

This builds on an earlier trend in the space - companies often used ERP, PLM, or generic workflow tools (Lotus Notes) to manage quality. Now it is moving to next-gen toolsets.

1. 1. 1. Bleed over between Enterprise Quality Management Systems (EQMS) and Connected Frontline Workforce (CFW) applications.

      2. Bleed over between EQMS, Analytics, and low-code/no-code aspects of IX platforms.

      3. Unresolved “home” for training and other functions. 

This begs additional questions. What is the strength of a particular application in helping me solve my business needs? What is the application “sweet spot” of the value proposition that I should expect, and what 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: 

1. 1. 1. Low-code/no-code citizen developer environments.

      2. Analytics for embedded process performance and the larger, more impactful analysis of significant data sources connected to the EQMS from Operations, Suppliers, Customers, Product Development, et al.

      3. Application of Machine Learning and Artificial Intelligence to help speed embedded processes along.

      4. Robotic Process Automation (RPA) to create logic chains within and between processes inside the EQMS solution.

Does the solution criteria consideration 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? 

By our definition, an EQMS (Figure 2) is a software application that does these things: 

1. 1. 1. Provides processes and documents to meet various ISO and ISO-derived Quality standards and requirements.

      2. Robotic Process Automation within defined processes and between logic chains of related methods (i.e., Deviation to CAPA).

      3. Flexibility to have Interconnectivity to other business software systems (as applicable) such as ERP, MES, PLM, CRM, SCM, et al., or be standalone if those other systems aren’t deployed, yet.

      4. Reporting and data visualization capability for embedded processes.

      5. Advanced Analytics capability on embedded processes and other Quality-related datasets such as supplier, operations, and customer-related data.

Figure 2: EQMS in Digitally Mature 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 

The EQMS should have the 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 various quality standards requirements 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 toward implementing Learning Management Systems (LMS) through the corporate HR function. Additionally, Connected Frontline Workforce 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 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, sorry) the different applications as necessary to meet the goals. Using the example above, an LMS is ideal for development training activities, but 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, and 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 digitally mature organization. However, if these tools don’t have a home elsewhere in the digital architecture, an EQMS can house them until more mature architecture is achieved. 

Recommendations

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 Industrial 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 connectivity and the open architecture needed to support data flow in and out of the application. 

Quality 4.0 and EQMS are on the LNS Research agenda for a refresh this year, so stay tuned for more on this space in the coming months.

All entries in this Industrial Transformation blog represent the opinions of the authors based on their industry experience and their view of the information collected using the methods described in our Research Integrity. All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.