Process Risk and Control Series Issue 1: Process Risk and Control Points — Turning "Potential Issues" into "Definite Prevention"

Abstract: Behind every process diagram lies a list of risks. This article systematically explains the three-tier method for identifying process risks, the classification and setting principles of control points, and the complete implementation path from "identifying risks" to "embedding them into processes," helping quality managers truly integrate risk control into their processes.

1. A Scenario: The Process Runs, but Risks Run Too

Scenario: A manufacturing company has just launched a new incoming quality control (IQC) process—where IQC personnel sample, inspect, judge, and release materials based on inspection work instructions. The process diagram is complete, the documents are signed off, and the training is done. Three months later, a customer complains that a batch of nonconforming materials has entered the production line. Upon review, it is found that the inspector skipped a critical dimension measurement because the work instruction did not explicitly state "this item cannot be skipped"; the review node in the process only checked the report format, not the completeness of the inspection items.

All the "activities" in this process diagram were executed, but the control points were not set up properly—or there were no control points at all.

This is not an isolated case. Many companies focus on whether the process can run smoothly, but they often overlook another equally important question: Is the process stable and safe?

2. Process Risk: What Exactly Is It?

Process risk refers to the possibility of failing to achieve the intended goals or producing adverse outcomes due to design flaws, execution deviations, environmental changes, or interface failures during the execution of a process.

Process risk is not the same as enterprise-level operational or strategic risks. It is more specific and routine—hidden in the following scenarios:

These risks share a common characteristic: they do not naturally expose themselves. When the process runs smoothly, these risks may remain "latent" until they cause a quality incident, at which point everyone realizes the problem.

3. Process Risk Identification: Three Levels, from Surface to Depth

To truly identify risks, it cannot be done by guesswork. It is recommended to proceed through the following three levels:

Level One: Desktop Identification Based on Process Diagrams

The most basic method is to review the existing process diagrams (swimlane diagrams or flowcharts) node by node. For each decision box, handoff line, or record point, ask yourself three questions:

• Is the input reliable—is there a possibility that the preceding information or materials are incorrect?
• Is the output complete—are there any information or actions that should be transmitted but are missing?
• Is the execution flexible—do operators have discretionary space? What risks might this space bring?

This identification method has a low threshold and does not require additional tools, but its depth is limited—it can only identify risks that are "drawn" on the process diagram, while those that are "not drawn" (such as data inconsistencies in information systems or hidden differences in personnel capabilities) are easily overlooked.

Level Two: Process Verification Based on Actual Operations

There is often a significant gap between the ideal process on the diagram and the actual execution. It is recommended to use the following methods:

1. Process Walkthrough Testing: Select actual business samples and track them from start to finish to see if the actual path matches the one on the process diagram. Pay special attention to areas where "temporary workarounds" or "special approvals" are used—these are often concentrated areas of process risk.
2. Historical Data Analysis of Processes: Retrieve data from the past 6 to 12 months—rework rates, abnormal events, customer complaints, audit nonconformities—and attribute them by process node. If a node has a significantly higher abnormal rate than others, it is worth investigating further.
3. Operator Interviews: Directly ask frontline operators: "Which step in this process do you think is most likely to have problems?" "Have you ever encountered a situation where the process runs smoothly but the result is incorrect?" The intuition of frontline personnel is usually accurate.

Level Three: Structured Risk Analysis Based on FMEA

For critical processes (those affecting quality, safety, and compliance), it is recommended to introduce the Process FMEA (PFMEA) approach:

• List possible failure modes for each process step (such as missed inspections, incorrect judgments, delays, omissions).
• Evaluate the severity (S), occurrence (O), and detection (D) of each failure.
• Calculate the Risk Priority Number (RPN) = S × O × D.
• Prioritize high-risk nodes based on RPN.

The value of PFMEA lies not only in identifying risks but also in setting priorities—in situations with limited resources, it is clear which risks should be addressed first.

4. Control Points: The "Safety Belts" of Processes

Once risks are identified, the next step is to set up control points.

What Are Control Points?

Control points are inspection, verification, audit, confirmation, or interception mechanisms embedded in the process, aimed at timely identifying issues and preventing defects from propagating.

Control points are not an "additional burden" on the process but rather a quality insurance.

Main Types of Control Points

Five Principles for Setting Control Points

Principle One: Control points should be set up immediately after the risk occurs. The earlier the issue is detected, the lower the correction cost. If an error in the production process is only discovered before shipment, the cost of rework or recall is much higher than process verification.

Principle Two: Control points should be separated from operational nodes as much as possible. Self-inspection and mutual inspection should not be performed by the same person (unless it is a poka-yoke design). This is the principle of "independent inspection functions"—operators and inspectors should not be the same person, otherwise, self-inspection loses its meaning.

Principle Three: High-risk process nodes should be prioritized for control points. Based on the PFMEA scoring results, nodes with the highest RPN should be prioritized. Do not apply equal effort.

Principle Four: Control frequency should match the risk level. High-risk processes can be fully inspected, medium-risk processes can be sampled, and low-risk processes can be periodically reviewed. Insufficient control can lead to hidden dangers, while excessive control can affect efficiency.

Principle Five: Control points themselves should also be controlled. Who checks the inspectors? The execution of control points should be included in process audits and process performance measurements—such as whether inspection records are complete and whether sampling results are promptly fed back for improvement.

5. From Identification to Embedding: Four-Step Method for Implementing Control Points

Identifying risks and designing control points is just the first step. The real challenge is to make control points an integral part of the process rather than an additional "burden."

Step One: Draw Control Points into the Process Diagram

Control points should be explicitly marked on the process diagram like process nodes. It is recommended to use standard control point symbols (diamonds or inverted triangles) and describe the specific operation methods, frequency, and judgment criteria of control points in the process description documents.

Step Two: Clearly Define the Responsible Person and Details for Each Control Point

Each control point needs a clear assignment:

• Who will execute (position, not name)
• Under what conditions will it be executed (e.g., "per batch," "when an abnormality occurs," "at a predetermined time")
• What standards will be used for judgment (specific, measurable criteria for pass/fail)
• What is the handling path for nonconformities (rework, scrap, concession, escalation)

Step Three: Embed Control Points into the Process System

In paper-based or manual processes, control points can be reflected through forms, signatures, and checkmarks. In information systems, control points should:

• Be set as mandatory process steps (non-skippable)
• Have hard constraints (the process stops if conditions are not met)
• Retain control records (who, when, what control actions were taken, and the results)

Step Four: Validate Control Effectiveness Using Control Indicators

Setting up control points is not the end. It is necessary to monitor the effectiveness of control points. Common indicators include:

• Interception Rate: Number of issues detected by control points / Total number of issues entering control points
• Missed Inspection Rate: Number of upstream quality issues detected downstream / Total number of issues
• False Alarm Rate: Proportion of items judged as nonconforming by control points but are actually conforming
• Control Cost: Time, manpower, and resources consumed by each control point

6. Common Misconceptions

1. More control points are better. Wrong. Each control point has a cost—time, manpower, and efficiency loss. The setting of control points should be precise, not excessive. It is better to have each control point be effective than to have a hundred that are ineffective.
2. Control points are only the responsibility of the quality department. Wrong. Control points should be embedded in the core processes of every business department. Control points for incoming materials in procurement, design reviews in R&D, and self-inspections in production—only when control points are cross-functional are risks truly managed.
3. Setting up control points is a one-time effort. Wrong. Processes change, risks change, and control points need to be continuously updated. It is recommended to review the control points of core processes at least once a year to ensure they remain effective and to identify better control methods.
4. Automated processes do not need control points. Wrong. Automation merely transforms manual operations into system operations; process risks do not disappear—they just change form. Disconnection of data interfaces, system logic bugs, and data quality degradation are unique risks of automated processes. Control points are still needed, but they take the form of system monitoring and alerts instead of manual inspections.

7. Conclusion

The "first half" of process construction is to get the process running—clarifying activities, drawing process diagrams, defining roles and outputs. But the "second half" that truly adds value to the process is to ensure it runs stably and safely—and this requires us to consciously build control points into the process design.

Good control point design is like adding "multiple layers of protection" to the process—turning "potential issues" into "definite prevention."

In the next issue, we will delve into approval levels and authorization—the most common but easily abused type of control measure in processes.

Knowledge code: 3.4.1

Version: v20260609

Author: Quality Think Tank