A process construct should show both, simplicity and complexity. We begin through understanding purpose. Then we create a holistic picture of Org, in its most simple form. Every purpose delivers a service or product. This does not happen by itself. Org must acquire and manage the resources that will deliver its service or product. To stay relevant and performing, Org will have to create and keep relationships. Along its path, Org will face problems, obstacles, and opportunities. To deal with these, it must transform and manage risk. This is Org's process construct in its most simple form.
The first step to engineering a process construct is to create flow of activity. One must do this in a fundamental and simple way. As one breaks the construct into levels, one can add detail. Level one should only give process flow that gives a helicopter view of the entire operations of Org.
The above list of activity does not show priority or sequence. To do that we create process flow.
This process flow shows a high-level chart. As we dissect it, we will define its detail. E.g., "manage Intelligence" holds the processes of risk, transformation, and research. In turn "transformation" includes strategy, project management, etc.
To unpack the detail of a process, often becomes complex. To simplify its understanding, we divide the core activity of a "Level 1" process into systems. A system is a container for processes that share a high-level purpose. Systems help us to probe the detail of process mechanics. In so, we can gain expertise on how the parts of Org works. This makes the detail of a process less complex.
In the orgtology example, one can create four systems for Level 1. The table below shows the four systems of the IOI. Each has a distinct statement of purpose.
| System:|| Statement of Purpose:|
|| Regulate the practice of orgtology.|
| Relationships|| Create and keep relationships.|
| Resources|| Acquire and manage resources.|
|Orgtelligence|| Transform and manage risk.|
The flowchart below depicts this table. I use colour coded rectangles to box the processes into systems.
From this level onwards, we work within a system. Below is an example of how we unpack a "Level 2" process. All level 2 processes are children of the Level 1 (core) process. In this case, I will be taking "(iP5) Accredit Practitioners" process to show how we unpack it on level 2. We must do so for all ten of the Level 1 orgtology processes.
Each shape and colour in the process flow has meaning. The colour coding is unique to orgamatics. The rest follows traditional process engineering methods. Where we depict activity as a purple oval shape, it is a shared process. This means that Org already uses this process elsewhere. Where we depict activity as a green oval shape, it is a child process. This means that it is a process born within this process. Any oval shape shows that there is another level to unpack. Where the activity shows a rectangle shape, it is the end of the line. This means that there is no next level for such activity. The buck stops there. Mostly, activity on Level 3 of the process construct are shown in rectangles. I explain these mechanics in the post; "Six steps for creating process flow in a process construct".
"(iP5) Accredit Practitioners" has two child processes and two shared processes. For this Level 3 example, I use "(iP12) Accredit New Practitioners".
At level 3, rubber meets the road. There are no more child processes here. In levels one and two, we delegate activity. In level three, activity create outputs.
There are no rules on how many levels a process construct must have. We break the construct into a few levels so that we can work with it. The levels are there to present a complex construct in an uncomplicated way.
You will notice that all activity is within a cycle. Every "end" creates a new cycle. The aim of a process construct is not to end, but to cycle in a more efficient way.
A process construct is a complete model. It shows how activity flows throughout the organisation. It will cluster data within activity. This enables Org to draw data from the process construct for its applications. A construct defines operations. A performance management system will draw its indicators from the construct. Risk managers will define risks from the construct flow. Cost managers will calculate cost of each activity and in so devise a budget, etc. The practical value of a process construct is vast.
Level one will always be the core process. Level two introduces the process families into the process construct. From level three downwards we simply divide child processes to make them manageable. There can be more than one process family within a system. In the above sketch, "System 4" holds two process families. The other systems each hold one process family. Organisations can structure their construct as they deem fit. Yet, the sketch above only shows how we create a construct. It is not possible to show the back loops and direct relationships. In other words, the sketch does not show most of the complexity involved in a process construct.
Org will capture all its implied intelligence within the construct. The effect is that Org will need no added information for its various applications. Applications such as performance-, risk-, cost-, etc., will run on data that they draw from the process construct. These applications need not create more data. This enables advanced technology to give real time reporting on any operational application.
To depict a process construct is not the entire task. Most of the work is to create and define intelligence within the construct. The construct becomes the blueprint for the operations of Org. It gives a nodal point where we can extract and apply data to generate a myriad of reports. It shows how activity flows and where Org uses its resources. It increases efficiency and enables effectiveness. It gives a scientific way to grasp the operations of Org.
© 2018: CFT Hendrikz