Process Risk and Control Series Issue 1: Process Risks and Control Points — Turning "Might Go Wrong" into "Surely Prevented"

Summary: Behind every process flowchart 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 recently launched a new incoming quality control (IQC) process — IQC personnel sample, inspect, judge, and release materials according to the inspection work instruction. The flowchart was completed, the documents were approved, and the training was conducted. Three months later, a customer complaint arose due to a batch of nonconforming materials entering the production line. A review revealed that the inspector had 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 flowchart were carried out, but the control points were not properly set — or there were no control points at all.

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

2. Process Risks: What Are They?

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

Process risks are not the same as enterprise-level operational or strategic risks. They are more specific and daily — they are 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 a quality incident occurs, and 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: Desk Review Based on Flowcharts

The most basic method is to review the existing flowchart (swimlane or flowchart) 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 could be incorrect?
• Is the output complete — are there any actions or information that should be passed on but are missing?
• Is the execution flexible — do operators have discretionary space? What risks might this space bring?

This method is easy to implement and requires no additional tools, but its depth is limited — it can only identify risks that are "visible" on the flowchart. Risks that are "invisible" (such as data inconsistencies in information systems, 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 flowchart and the actual execution. It is recommended to use the following methods:

1. Process Walkthrough Testing: Select actual business samples and trace them from start to finish to see if the actual path matches the flowchart. Pay special attention to areas where "temporary workarounds" or "special approvals" are used — these are often concentrated areas of process risk.
2. Process Historical Data Analysis: Retrieve data from the past 6 to 12 months — rework rates, abnormal events, customer complaints, audit nonconformities — and attribute them to process nodes. 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 do you think is the most likely to go wrong in this process?" "Have you ever encountered a situation where the process runs smoothly but the result is incorrect?" The intuition of frontline operators 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:

• For each process step, list possible failure modes (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 prioritizing them — in a resource-limited situation, it is clear which risks to address first.

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

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

What Are Control Points?

Control points are inspection, verification, audit, confirmation, or interception mechanisms embedded in the process. Their purpose is to detect issues promptly and prevent defects from passing through during process execution.

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: Set control points to detect risks as soon as they occur. The earlier the detection, 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 in-process verification.

Principle Two: Separate control points from operational nodes. Self-inspection and mutual inspection should not be performed by the same person (unless it is an error-proofing design). This is the principle of "independent inspection function" — the operator and the inspector should not be the same person, otherwise, self-inspection loses its meaning.

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

Principle Four: Match control frequency to 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 is risky, while excessive control affects efficiency.

Principle Five: Control points themselves must be controlled. Who checks the checker? The execution of control points should be included in process audits and process performance measurements — for example, 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 integrate control points into the process as organic components rather than additional "burdens."

Step One: Draw Control Points into the Flowchart

Control points should be explicitly marked on the flowchart, just 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 the control points in the process documentation.

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

Each control point needs clear ownership:

• Who executes (position, not name)
• Under what conditions (e.g., "per batch," "when an abnormality occurs," "at a predetermined time")
• What criteria are used for judgment (specific, measurable pass/fail criteria)
• What actions are taken 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 (cannot be skipped)
• 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 with Control Indicators

Setting 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 control points judging nonconformities that are actually conforming
• Control Cost: Time, labor, and resources consumed by each control point

6. Common Misconceptions

1. More control points are better. Incorrect. Each control point has a cost — time, labor, and efficiency loss. Control point settings should be precise, not excessive. It is better to have a few effective control points than many that are ineffective.
2. Control points are only the responsibility of the quality department. Incorrect. Control points should be embedded in the core processes of every business department. Control points for incoming material 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 control points is a one-time effort. Incorrect. Processes and 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. Incorrect. Automation merely transforms manual operations into system operations; process risks do not disappear — they change form. Disconnected data interfaces, system logic bugs, and declining data quality are specific risks of automated processes. Control points are still needed, but they may take the form of system monitoring and alerts rather than manual inspections.

7. Conclusion

The "first half" of process construction is about getting the process running — mapping activities, drawing flowcharts, defining roles and outputs. The "second half," which truly makes the process valuable, is about ensuring the process runs stably and safely — and this requires consciously building control points into the process design.

Good control point design is like adding "multiple layers of protection" to the process — turning "might go wrong" into "surely prevented."

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

Knowledge Number: 3.4.1

Version: v20260609

Author: Quality Excellence Think Tank