In two preceding articles (Cost cutting by process based risk analysis – Part 1 and Part 2) I have described a process based method that helps us to identify mission critical activities und sub processes. The idea is to find a way that enables us to focus our protective measures on the technical equipment, which is involved in those critical activities. Thereby, we could reduce measures to those sensitive entities rather than protecting any equipment around our premises.
As I was asked for an end-to-end example several times I designed a small process, which is about controlling a business premises of a small refinery. This company has three risks to take care of. In case it happens (not very likely, though) a fire is a massive danger because it could destroy the entire company. An accident regarding an oil leakage is much more probable to happen. But let us assume that the company is able to handle it on its own. Therefore, the severity is not too high. As the company secures its premises with a fence, which is electronically controlled, we will have to manage alarms of that kind as well. This process is located at the central guard duty, which is operated by the company.
Please, consider this as an example. I know it lacks real world’s complexity. No refinery will work that simply. But, as I said, this is only a construct to provide an understanding of this approach.
Process overview and activity risk
The following picture shows a BPMN diagram of that simple process.
Basically, we have an event-based gateway, which is triggered by one of the following events: a fire alarm, an oil alarm or a fence circuit alarm. If one of the alarms occurs the sub process in question is started. Independent of the type of alarm the process will proceed by documenting the alarm measures taken.
As you may tell by the colour coding I consider the sub processes “Manage fire alarm”, “Manage oil alarm” and “Manage fence alarm” as potentially endangered. In opposite to those main processes, I judge the documentation activity as not critical. Of course documentation is important. But even if we fail in doing so we have saved our company from burning down at least. This is the reason why I consider documentation and logging to be of lower priority.
At this state we have the first risk estimation: the activity risk.
Activities within the sub processes
In the next step we will inspect the sub processes and their activities. In the preceding articles I have described that the activity risk of a sub process is transferred to its activities. As we know so far not all activities of a sub process are endangered. Therefore, we have to distinguish between them. Another major aspect in analysing sub processes and activities is to achieve the process risk. This is based upon the activity risk and the activity’s number of usages throughout all processes.
The fire alarm sub process starts with a validation of the alarm. It is not critical. But the following processes are. The company’s fire fighters have to be alarmed as well as the city fire department. Both processes are sensitive. If one or both fails, the entire premise could burn down. Quiet a risk! In a following step we will dive into this activity to identify involved entities (technical components).
But let us take a look at the oil alarm first. It is very similar. Company’s fire fighters will have to solve the problem too. But the city fire department is not needed. Instead, the guard duty has to inform the environment agency about the occurrence. Nevertheless, this is not critical.
Please, notice that the activity “Alarm company’s fire fighters” is one and the same in both processes. As we will see this has an impact on the process risk.
I will show the third process for completeness. Due to this being an example I will not go into more details of this process.
The process risk
So far we have distinguished between activities at risk and not risky activities. Furthermore, we can tell where an activity is used. Now we will view at the process risk. The following chart shows the critical activities and their usages throughout the sub processes. The result is the process risk.
This diagram clarifies the different priorities between those three sensitive activities. Because “Alarm company’s fire fighters” is used in two processes, it gets a higher process risk of 18. It is the sum of the activity risks of the sub processes “Manage fire alarm” (10) and “Manage oil alarm” (8).
In the preceding article I proposed the process risk to be the multiplication of the activity risk and the number of usages. But, as you see, we have one activity that is used in two sub processes, which have different activity risks. So which one to choose? 10 * 2 or 8*2 ? This is the reason why we should better sum it up instead. You see, this approach is evolving still.
After we have investigated the one activity on top level and all activities inside of the sub processes, now we know where we should focus our efforts on. From six activities („Document alarm measures“ is listed on the top level, but it is an activity) only three remain, which we see as rather risky. This is quite a reduction. Don’t you think so?
In the next step we will analyse the remaining activities in more detail to find out related technical equipment. Proceed to the second part of this example of process based risk analysis.