8 minutes reading time (1699 words)
Featured 

How to engineer a process construct

process-construct-engineering How to engineer a process construct
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.
I my post "What is a process construct?", I clearly define it. It is a blueprint of how activity must cycle. Therefore, a process construct is a blueprint for the operations of Org. In the same post, I also explain that any organisation has only one process. It is an interdependent network of activity that cycles without end. To better understand such process, one must divide it into smaller parts. This probing will create a hierarchy of processes within Org. That hierarchy is a process construct. A construct does not necessarily take the shape of an organigramme. It could take the shape of a three-dimensional molecular structure. There are no rules to what shape it takes. The hierarchy of a process shows how Org assembles its operations. The entire process exists on its first level. The other levels are not new additions, but explanations. A process construct is an explanation of the operations of Org.

What is a Process Construct?

There are only two ways to do work. One is repetitive, in other words, doing something that we have done before. The other is non-repetitive, which means doing things that we have never done before. When we cycle work it is a process, and when we complete it, it is a project. Repetitive work will maintain things, whilst non-repetitive work will cha...
https://orgtology.org/index.php/2015-06-01-09-45-25/orgtology-blog/17-what-is-a-process-construct
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.

(1) Basic construct of a process construct

To engineer a process construct, one must first define the purpose of Org. One must do that 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 participate in the practice of Orgtology". There is a lot of detail in this statement of purpose. The best way to refine it, is to 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 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 basic flow of an orgamatics process construct


(2) Process construct engineering: Level One

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 International Orgtology Institute (IOI) must regulate the practice of orgtology. This mission will create the following activity:

  • Acquire and manage resources for the IOI.
  • Create and maintain an Orgtology Body of Knowledge (OBoK).
  • Create and maintain policy to regulate the practice of orgtology.
  • Develop orgtology practitioners.
  • Accredit practitioners.
  • Manage providers.
  • Create awareness.
  • Manage customer relationships.
  • Monitor and evaluate.
  • Manage intelligence (risk & transformation).

The above list of activity does not show priority or sequence. To do that we create process flow.

Orgamatics process engineering case study: Regulate Orgtology (Level 1)

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.


(3) Process construct engineering: Creating Systems

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:
Core Business
​ 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.

Orgamatics process construct engineering case study: Regulate Orgtology (systems)


(4) Process construct engineering: Level Two

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.


Orgamatics process construct engineering case study:  Accreditation of Orgtology Practitioners (Level 2)


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".



(5) Process construct engineering: Level Three

"(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.


Orgamatics process construct engineering case study: Accredit New Practitioners (Level 3)

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.


(6) Practical Application

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.


The structure of an orgamatics process construct.


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.


Empowering Excecutive Teams Worldwide

Copyright

© 2018: CFT Hendrikz

How to develop system and process briefs
What is a Process Construct?

Related Posts