Does one design or discover a process? To manifest, purpose must become a process. Therefore, there is purpose before process. When we create a process, we explicitly depict a purpose. It is our idea of what Org must do to get outputs. When we design outputs, we discover outcomes. This will help us to redesign our process. One will thus interchangeably design and discover a process.
A process construct is a blueprint of how activity must cycle. Therefore, a process construct is a blueprint for the operations of Org. Any organisation has only one process that creates an interdependent network of activity. This network will cycle without end.
To better understand the core process of Org, we divide it into smaller parts. This probing will create a network of processes within Org. We call this network a process construct. A construct does not necessarily take the shape of an organogram. Mostly it will take the shape of a three-dimensional molecular structure. There are no rules to what shape it takes. Its task is to show how we achieve operational efficiency. A process construct is thus an explanation of the operations of Org.
When one unpacks the flow of activity within Org, one engineers a process construct. To do so, we probe, understand, and depict. It is about grasping interdependency in terms of level and flow.
If Org begins as a purpose, then one can only understand its operation by turning its purpose into a process. Purpose cannot exist without flow of activity. It is only when activity begins to flow that outputs and resources begin to make sense.
The first step is to understand the purpose of Org as a process. The next task is to reverse engineer this purpose back to the frontline. This begins when we cluster our high-level activity into systems. A system is a container of processes with similar purpose. E.g., recruitment, procurement, and budgeting all have the task to channel resources into Org. In so, they create one "resource" system.
Our task is to reverse engineer "purpose". Thus, we link the purpose of Org to the purpose of each system. In so, we link the purpose of each system to the purpose of each process, etc. It ends where we regulate our processes with policy, procedures, and targets.
To engineer a process construct, one must define purpose in an uncontaminated way. Contamination happens when we add rhetoric to a basic truth. Mostly, when one tries to sell or boost a purpose, one will add effect to make it more attractive. Purpose should explain the organisation as it is. Rhetoric distracts one from the basic truth of purpose. E.g., "We create a body of knowledge and manage policy that will drive certification processes, which attracts an increasing number of stakeholders to take part in the practice of Orgtology". There is a lot of rhetoric in this statement. To refine it, we must ask: "What is the most basic thing that this organisation must do?" In this example, it is to "regulate the practice of orgtology". From here one can unpack "how", "where", "who", and "when".
A process construct begins in simplicity. As we reverse engineer this simplicity to the frontline, we unpack its complexity. Purpose is the simplicity. Every purpose delivers a service or product. Org must acquire and manage the resources that will help it to 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.
Our first step is to create high-level flow for activity. As we break our construct into levels, we will add detail. Level one should give an overview of the operations of Org. To show how this works, I use the Orgtology Institute as an example.
The International Orgtology Institute (IOI) must regulate the practice of orgtology. This is their purpose. To turn this into a process, we must list their core activities. These are the main things that the IOI must do. They are:
These activities do not show priority or sequence. To do that we must create process flow.
The process flow below 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 is 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 our example, one can create four systems for Level 1. The table below shows what they are. Each has a distinct statement of purpose.
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 "orgtology core business" system. 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 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 is a process that originates form a parent. Any oval shape shows that there is another level to unpack. In other words, a process within a process.
"(iP5) Accredit Practitioners" has two child processes (green) and two shared processes (purple). For this 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 three, activity create outputs. The buck stops here.
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. E.g., 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 our example, "core business" holds four process families. The "resource system" has only one process family. Organisations can structure their construct as they see fit.
The sketch below shows the basic structure of a construct. Each circle is a process. 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., runs on data. They draw this data from the process construct. These applications do not have to create more data. This enables advanced technology to give real time reporting on any operational application.
A process construct is 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