I would generically define an audit as an official inspection of a process and its outputs, or of a project and its outcomes. We can do this in a variety of ways and with an array of goals. In this post I explain how we do a process construct audit.

When we audit operations, we are auditing a process construct. Another term for a "process construct audit" will be "operational audit". It is the best way to know what is going on in your operations, and therefore it must be done. When we audit a process construct, we inspect two dimensions of any process or system. These are:

1. Causality;
2. Orgtelligence™; and
3. Targets.

...an audit as an official inspection of a process and its outputs, or of a project and its outcomes.

derek hendrikz

Causality

I explain what process teams must do in my blog post: "The work of a process team". In that post I also list and explain the seven tasks of a process team. Those who audit a process construct must do the exact same things. Except that in an audit, there will be a primal focus on "cause and effect" relationships of the process construct. I show the most important causations that an audit team must inspect below:

1. Input / output causality:

Inputs must create outputs, which must be greater than its inputs. This is how we calculate efficiency. But, in an audit we must first determine whether the inputs are in fact the cause for the outputs that we get. I often find that this is not the case, especially during strategy sessions where an EXCO team must create an action programme to achieve output targets. What they are effectively affirming is that the activity within their process construct is inadequate to produce their outputs. In most process models, the authors separate inputs from activity. In orgamatics we see activity and the resources they need, as inputs. A second thing that we must audit is whether we can sustain or increase our outputs whilst decreasing our inputs.

2. Process outputs / tacit intellect causality:

Our aim is always to reduce the human intellect needed to create an output. In this way we can use our tacit intellect in the project construct. An ideal situation is where we manage repetition of the past (process construct) through implied (process) intelligence, and an unknown future (project construct) through tacit intellect. An audit should show how we can reduce tacit intellect within a process construct, and to make sure that the human intellect that we must have is an absolute necessity. The less tacit intellect we waste in our process construct, the more we have available to inject into our project construct.

3. Critical success factors / risk causality:​

All risks are created in either a process or a project construct. We find risks by probing the critical success factors for a process to be both efficient and effective. These critical success factors define the risks. In an audit we must make sure that this is the case. In other words, we must verify whether the listed risks are indeed critical success factors for effective and efficient functioning of the process construct. I discuss risk management from an orgamatics perspective in other posts.

4. Process flow / policy causality:​

From process flow we create targets. I discuss this in my post: "Creating targets for a process construct". A process output target is a quantified measure of what a process must produce. Where such targets create non-negotiable and consistent outputs, e.g., "submit report 30-days prior to board meeting", then we turn it into a process rule. This means that where we do not allow any fluctuation within a target, it becomes a rule. These rules are our indicators of policy and procedures. In an audit, we must make sure that the rules of process flow and outputs are translated to policy and procedures. Furthermore, we must make sure that policy empowers our process flow.

5. Policy / procedures causality:​

As explained, we get our policy from process rules. A procedure is an explanation of a rule. It gives us step by step guidance on how to implement a rule. I explain more on this in my post: "The difference between policy, procedures, and a cyclic process". In an audit we must make sure that policy has adequate procedures that tell us how to implement the policy statement(s).

6. Purpose / evidence causality:​

All processes begin as a purpose. This same purpose becomes the evidence of the process output targets. In so, purpose creates process, which creates outputs, which we prove functional if the purpose of the process stays relevant. Therefore, the purpose is evidence that our output targets are working. An audit must show that this is the case.

7. Vertical causality:​

In my post: "How to translate operational targets from bottom to top in a process construct", I explain vertical causality. It means that there must be a "cause and effect" relationship between output targets throughout the levels of the process construct. It is key that an audit confirms this.

Orgtelligence​

Theory 2I of orgtelligence states that the intelligence of Org is the sum of process and human intelligence. In orgamatics our task is to groom and internalise the implied or process intelligence. To do this we must gather as much data as possible of any process. In my blogpost: "How to develop system and process briefs" I explain what information we must find and record. An audit must see to it that a process has enough data to create the feedback loops that will increase its orgtelligence. The table below shows the basic data that each process must capture. There is no "cast in stone" rule on this, and each organisation must use its own discretion.

​Process Data:

​​System Data:

Position of process in the construct (parent, system, level, etc.). Human collaboration (process team leader and process team). Purpose of the process. Duration and cycle time. Classification (internal or outsourced). Location (where does it cycle). Human intellect needed. Process rules. Process output targets. Cost breakdown. Process activity and flow. Conditions of flow.

Human collaboration (team leader and team). Purpose of system. Internal and external boundaries within which the system must function. Values that govern behaviour within the system. Customers and stakeholders to the system. Competitors and suppliers to the system. Resources that the system needs to function. Processes and units linked to the system. Internal policies and procedures that guide the system. Cost breakdown of the system. System output targets. Critical success factors and risks of the system. Risk ratings. Mitigation and contingency plans.

A process output target is a quantified measure of what a process must produce.

derek hendrikz

Targets

1. Not all targets are equal:

We use a weighting model to weigh output targets. I explain this model in my posts on TCP output efficiency. TCP stands for Time, Cost, and Priority. In the case of output targets, we only weigh priority. In other words, we have 1.00 point through which we divide each target. E.g. "Target 1" might weigh .35, "Target 2" = .25, and "Target 3" = .40. Jointly they will always weigh 1.00 point. In so, we can see that "Target 3" is the most important one, followed by "Target 1", and with "Target 2" as the least important one. When we audit a target, we must firstly question the reasoning behind the weighting of a target, and secondly, we must see to it that the target scores are multiplied with its weight. E.g., if you had to do 10 units of work and you did only nine, then your target score is 9. If the weight of this target is .40, then we must multiply that with the score, e.g., "9 x .40". Our final target achievement is then "3.6".

2. We assess annual targets quarterly:​

Most targets have an annual quantification. It is important to measure annual targets quarterly, so that one can intervene if necessary. If we find out that things are going wrong in quarter one, we can still save the target in quarter four.

3. Calculate a score:​

If we assess an annual target quarterly, we must work out the average to get a total score. We will take the score for each quarter, and then divide it by four to get an average score. Then we divide this average score with the pre-set target to get a "total score". E.g., if you have a target that says, "To increase sales by 30%", you might yield the following achievement: Q1 = 25%; Q2 = 15%; Q3 = 30%; and Q4 = 25%. You will now add the lot and divide them by four to get an average of 24%. To get a total score, you will then divide the result with your intent, which is 24/30 = 0.80. Our total target achievement score is therefore 80%. The last thing to do is to reduce your target score to its weigh, as shown above. If the weight for this target is .40, then you must multiply your score with that (80 x .40), which gives you a final score of 32%.

One should caution that sometimes the aim of your target is to reduce the chunk of something. E.g., if you have a target that reads: "Reduce the reported cases of misconduct with 10%", and you know that there were 55 cases of misconduct reported in the previous year, then your target for this year will be 50 (55 x 10%) reported cases. Let us assume that cases for this year are: Q1 = 11; Q2 = 7; Q3 = 8; and Q4 = 15, then you get 41 reported cases, but cannot just divide 41 by 55, since this will give you 75%. You will have to get its inverse quantity by deducting it from one (1 – 75), since you are calculating a reduction and not an increase. This will give you 25%. We then divide this 25% by the original target of 10% to get a target achievement of 250%. In so, by reducing the number of cases with 25%, we achieved our target of 10% by 250%. Another way to calculate this will simply be to get the difference between the former state of 55 and the current state of 41 cases, which gives you 14 cases less than the previous year. Simply divide 14 with 55 to get 25% which is your target achievement. Divide 25% by your pre-set target of 10% and you get a target achievement of 250%. This will always be the case where the aim of our target is to reduce the chunk of something.

A last thing about targets is that it is always good to measure the group target score against a bigger system, such as a parent process, a system, or the organisation. E.g., if your overall target score for "Process 1" is 92%, whilst the average target score for "System A" (of which "Process 1" is part) is 98%, then "Process 1" has underperformed compared against the overall performance of its system.

* * * 

To audit a process construct is an effective way to keep your construct up to date and relevant. It is therefore crucial that we regularly do so.

Join the Orgtologist Certification Program (OCP) - Empowering Executive Teams Worldwide