Your System Passed the Audit. Why Are Outcomes Not Improving?
In August 2017 I wrote a short post called Where to Make Compliance Improvements. It was one of the first things I published on my site. Nine years later I still point people to it. The core ideas have not changed. They have only become more important.
The post made a simple claim.
Programs, systems, and processes are different things. Each does a different job.
If you confuse them, you will make improvements in the wrong place and wonder why outcomes do not change.
Three Levels, Three Jobs
Here is the short version.
A process is a set of ordered steps that transforms inputs into outputs. Its purpose is to execute the plan. Consistent output comes from consistently following standard work.
A system is a process connected to other elements, most importantly to measurement. The feedback loop is what makes it a system. Its purpose is to keep output within specified limits. A system resists change. That is its job.
A management program defines the outcomes the systems and processes are meant to achieve. It provides the resources and capabilities to support them. Its purpose is to change the state of the organization: fewer incidents, lower risk, more near misses reported. A program introduces change. That is its job.
One level stabilizes. The other adapts. The tension between them is healthy and necessary. An organization needs both.
Why the IDEF0 Diagram Matters
The most useful part of the 2017 post was the following diagram. It shows a modified PDCA cycle drawn in IDEF0 format, with the program level in red and the system level in blue.
IDEF0 is a functional modelling notation. Every function is a box. Inputs enter from the left. Outputs leave on the right. Mechanisms, the people and tools that perform the work, come in from the bottom. Controls come in from the top.
That last convention is the point. When controls enter from the top, you can see where regulation acts on a function. You can see which signals regulate which activities. You can see where a change is triggered and at which level it lands.
The diagram also splits the Act step of PDCA into two functions: Manage and Provide Resources. This makes the boundary between system and program visible. Managing adjusts the process to keep it in control. Providing resources changes the capabilities and capacity available to the system.
The first is a system function. The second is a program function.
This split is especially helpful when deploying ISO standards. ISO has adopted PDCA as the overarching process for its management system standards. When PDCA is applied as a single loop, every clause is treated as part of one system. The IDEF0 view shows which requirements stabilize the system and which change it.
Operational planning and control is a system function. Support, which provides resources and competence, is a program function. Knowing the difference tells you where to look when a standard has been implemented and outcomes still do not change.
Why This Is Still Missed
I am often asked why these distinctions are not more widely understood. I see a few reasons.
The language is used loosely. Management system standards use "system" to describe almost everything. Programs, systems, and processes become interchangeable words in policy documents and audit reports.
PDCA is taught as one loop and the solution to solving all problems. Organizations apply PDCA to tighten procedures when they should be building capabilities.
We draw flowcharts but not control diagrams. Flowcharts show steps in order. They rarely show what regulates those steps. Without a picture of control, people cannot reason about how to better regulate outputs, never mind outcomes.
Projects substitute for management programs. In 2017 I wrote about management initiatives where a project performed the program function, delivered new capabilities, and then disbanded, leaving the system in maintenance mode with audits as the only remaining governance. I continue to see the same pattern today, particularly when it comes to implementing AI governance.
Audits verify systems but do not assess capability. Audits are good at checking whether a system executes as specified. They are poor at telling you whether the program is achieving its intended outcomes. You can have an efficient system that produces the specified outputs and still fail to achieve the outcome. Audits can help you verify systems, but you need something else to validate management programs.
Where to Start Improving
The diagnostic order from 2017 still applies.
If a program outcome is not being achieved, first verify that the systems are executing consistently. This can be done through audit or, better, through measurement embedded in the process itself.
If the systems pass verification, the problem is at the program level. The program must assess its capabilities and either mature them or introduce new ones. New capabilities can be introduced quickly with a minimum viable approach. Continuous improvement through PDCA then stabilizes them on the system side.
This order matters. Changing programs when systems are inconsistent adds variation. Tightening systems when capabilities are missing adds effort without improving outcomes.
What Has Grown Since 2017
The 2017 model became the foundation for our Operational Compliance Model. The OCM adds a fourth level above programs: governance. Governance sets direction. Programs introduce change. Systems resist change. Processes do the work.
Each level regulates the one below it. Each needs its own feedback. Each needs its own measures.
This is why I talk about full-stack metrics: adherence, conformance, performance, effectiveness, and integrity. A single measure cannot tell you which level is failing.
The underlying idea is cybernetic. Every regulator needs a model of what it regulates. The IDEF0 diagram is one such model. It gives you a way to see where regulation happens in your organization and where it is missing.
The Takeaway
The first question in any improvement initiative is deciding what outcomes require improvement followed by where best to make the change.
Organizations regulate themselves through levels, and each level has its own purpose: processes do the work, systems keep it in control, programs change outcomes, and governance sets direction.
Every improvement effort lands at one of these levels, whether it is deploying an ISO standard, responding to an audit finding, or introducing AI. When the level is wrong, effort increases and outcomes stay the same.
This is why a model matters. You cannot improve what you cannot see, and most organizations have no picture of how they regulate themselves.
Read the original post here: Where to Make Compliance Improvements
