Compliance programs, systems, and processes are often used interchangeably when referring to improvements. However, there are important distinctions that if understood will help to identify where and how to make improvements to effect the best outcomes.
In this blog post, I will outline the differences between these functions and show how each helps organizations better target their resources to improve compliance.
Let's start with defining what a process is.
Process Model (simplified):
A process is a set of ordered steps that takes input and transforms it to produce an output. These steps are outlined in a process plan where each step can be further described by a procedure.
The purpose of a process is to execute the process plan.
Consistent output is accomplished by consistently following standard work plans.
Systems Model (simplified):
A process becomes a system when it is connected with other elements particularly other processes. The most important, from a systems perspective, is connecting with measurement processes to control and reduce output variability. This is often simplified as a feedback loop.
The purpose of a system is to execute the process and keep the output within specified limits.
Consistent output is accomplished by both process consistency and by controlling the process using a feedback mechanism.
Program Model (simplified):
A program defines the outcomes that the systems and processes are to achieve. It also provides the resources and capabilities need to support them. While systems focus on consistency and greater efficiency, the role of a program is to improve outcomes.
Programs exist to reduce safety incidents, reduce risk, reduce costs, increase reporting of near misses, and so on. Programs serve to change the state of the organization and use systems to do that. As targets are changed, the program also changes by adjusting: capabilities, capacity, processes, and system controls.
As previously mentioned, the purpose of a program is to achieve a change in state. This is different from the purpose of a system which resists change to maintain the current state.
Failure to understand this distinction has often been the cause of system failures for many IT initiatives. Projects, which temporarily serve a program function, introduce new capabilities and corresponding systems and then disband at the conclusion of the project. At that time the system often incorrectly moves to a maintenance mode. When this happens the program functions essentially stop.
Systems in a maintenance mode are only provided with enough resources to execute the processes and fix issues. The only program level governance come from audits which as we mentioned in a previous blog is not the right driver for improvements.
Another important function of a program is to validate outcomes. It is well understood that you can have an efficient system, that produces the specified outputs, and at the same time fail to achieve the intended outcomes. Validating that programs actually achieve their targeted outcomes is essential to meeting compliance.
How To Introduce Change
Introducing changes is necessary to improve program outcomes as well as to control system processes. From a compliance perspective, changes need to be made in such a way to: maintain compliance continuity, manage risk, and achieve the desired intent of the change.
The Plan-Do-Check-Act (PDCA) improvement cycle can be used to show how changes are introduced from both the program and system level.
The following diagram uses a modified PDCA cycle (IDEF0 Format) to show the interaction between the program level (shown in red) and the system level consisting of a primary process (shown in blue):
As an aside, IDEF0 depicts control inputs as lines coming in at the top which helps to visualize the feedback points. In addition, the PDCA Act function has been divided into "Manage" and
"Provide Resources" to better show where the program and system functions reside.
From this model, we can see where changes are triggered and how they interact at both the program and system level. Managing change triggers in a controlled fashion will help to preserve continuity when adapting to changes in compliance demand.
Where to Improve Compliance
The models presented so far help clarify important differences between programs, systems and processes. The following table summarizes these distinctions, some of which have been previously mentioned along with a few new ones:
Knowing what these distinctions are allows us to also know where changes need to be made and how to make them.
For example, if a program outcome is not being achieved the first step is to verify that the systems are executing consistently. This is a verification activity that can be conducted as an audit or as embedded measurements within the process itself.
If the system passes verification then it is the role of the program to assess capabilities and make changes to mature them or introduce new ones. Rapid introduction of new capabilities can follow a Lean Startup (MVP) approach followed by continuous improvement (PDCA) on the system side.
To learn more on how to build sustainable compliance platforms visit our site at (www.leancompliance.ca)