Using the Level Zero model 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 facilitate outcomes. In turn, 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 aims to cycle without end.

To connect everything within Org is the primary task of a process construct. It is the a neural network that holds all the implied intelligence of Org. Yet, this task is easier said than done. I have been involved in numerous organisational design projects, but cannot recall any executive team who was able to depict their organisational purpose as one interdependent process. 

An unconnected system is an unintelligent system. Level Zero is a basic model that aims to solve this problem. It is a model that I've designed during 2018, which divides Org into five categories. As a student of orgtology, I made sure that it does justice to Hypothesis 2x (the core assumption of orgtology). In so, Level Zero not only connects all the parts of Org, but it also helps to manage an equilibrium between its concrete and abstract parts. Without getting technical, one can say that the Level Zero model clearly separates what one must do to run Org from what one must to to change Org.

To engineer the process construct of Org means to design the operational idea of an organisation. A structure is a physical thing, whilst a construct is the idea behind the physical thing. I.e., when you draw a process flow for a factory floor, you will not find boxes and arrows there. You will find conveyor belts, people, robots, etc.

We begin our process construct engineering process with the Level Zero model. Through that, we connect all organisational processes to its purpose. In so, we create a network of processes within Org. This network is the process construct of Org. 

People often confuse the process construct with an organogram. They are not the same. A process construct is the lateral connection of activity throughout Org. An organogram (Org structure) connects the resource accountability and responsibility for the process construct. A process construct is the lateral connection of activity throughout Org, whilst an organogram connects resources within a vertical structure.

Most process engineering exercises begin through developing processes within the Org structure or organogram. In doing so, one will make activity to follow resources. This would not make sense to any scientific mind. At a basic level Org consist of activity and resources. When we arrange activity we create processes and projects. The purpose of resources is to fuel the activity. Thus, from an orgtology perspective resources follows activity, not the other way round.

Basic assumption of a process construct

An organisation is primarily a purpose that manifests through the arrangement and resourcing of activity. In so, Org is a network of processes.

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 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 front-line. To ease this task we use the Level Zero model. This begins when we develop a high level process for Org, and then cluster its activity into the Level Zero components.E.g., recruitment, procurement, and budgeting all have the task to channel resources into Org. In so, we will cluster them into the Level Zero  "resource" component.

Our task is to reverse engineer "purpose" to the front line. Thus, we link the purpose of Org to the purpose of each Level Zero component. From there, we link the purpose of each Level Zero component to the purpose of each process, etc. It ends where we control our processes with policy, procedures, and targets.

The Level Zero Model

I have created the Level Zero model in 2016 as a substitute for the balanced scorecard (BSC) model. This was primarily since I could not use the BSC for process engineering, risk and cost assessment. Also, the BSC does not separate operational from strategic activity. At least not from a Hypothesis 2x perspective. I.e., the BSC does not do justice to organisational design or operational efficiency analysis from an orgtology perspective. 

Unlike the BSC, the Level Zero Model is not sufficient to develop strategy since it focuses on functionality. It does not offer organisational perspectives, as with the BSC. To develop strategy from an orgtology perspective one must use the Level Zero Model in conjunction with the 5V Model. The 5V helps Org to create a strategic ladder of super goals towards its ultimate vision. Through Level Zero, we create high level operational targets for Org. In so, the 5V drives Org relevance (effectiveness), whilst Level Zero drives Org performance (efficiency). Strategy is the change needed to achieve Level Zero targets and to execute out 5V goals. We develop strategy within three perspectives. These are (1) Relationships,  (2) Efficiency (level zero targets), and (3) Effectiveness (5V goals). This method gives us clear guidance on what we must do to run Org (performance) versus what we must do to change it (relevance). This split is core to orgtology. The method might seem complex, but it will ensure long-term Org performance and relevance.  I explain strategy development from an orgtology perspective in another essay. 

The Level Zero model clusters Org into five areas of functionality. These are (1) Resources, (2) Product & service delivery, (3) Relationships, (4) Transformation, and (5) Risks. To perform we focus on resources, delivery, and relationships. To stay relevant we need to transform and contain risks. 

We use the Level Zero Model to create processes; identify risks, cost, and performance indicators; as well as to create targets, policies and procedures. There are numerous applications for this model. Below I show how we use it to develop a process construct, which will serve as a blueprint for operational performance and efficiency.

(1) Process construct engineering - Step 1: Create a Level One Process

Our first step is to create high-level flow for Org 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:

• 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.
• Transform (strategy, innovation, etc.)
• Manage Risk.

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 into lower levels, we define its detail. E.g., "Transformation" includes strategy development & implementation, project management, innovation, research, etc.

(2) Process construct engineering - Step 2: Test your Level One process against the Level Zero Model

The traditional way of engineering Org processes is to map them against an organogram (departments). This approach mostly leads to a myriad of duplication and silo functioning. Mostly so since an organogram represents resource clusters. I.e., everyone who has an HR background goes to the HR department. In so, people working with recruitment, training, employee relations, discipline, payroll, etc., are all clustered within the HR Department. Yet, recruitment, procurement, and budgeting all serve the same purpose, which is to get resources into Org. From a traditional process engineering view, they will not share the resourcing process because they are in different departments. I discuss the development of an organogram (Org structure) in another essay. However, it is important here to mention that from an orgtology perspective, we begin our process engineering exercise by understanding the Org purpose as one process. The second step is to test this process against the Level Zero Model. We do this to ensure that the Level One process covers all the necessary functional areas of Org. Where one of the Level Zero areas are not covered, the consequences could be detrimental. E.g., I once worked with an organisation who was rapidly losing market share. Through a simple Level Zero test, I could establish that they have no transformational processes, which meant there are no processes that helps them to remain relevant. 

Below I show a table with the purpose of each Level Zero area mapped against the Orgtology Institute's high level processes. I then show their Level One process (as above) color coded against the Level Zero Model. Through this we can establish that all the areas of the Level Zero Model are covered.

From here we break down these high level processes into lower levels, thus creating a process network, all linked to the purpose of Org. Since we've clustered all the parent processes into Level Zero functionalities, we can now easily assess the risks, cost, performance, targets, policies, procedures, etc. against each Level Zero functionality. E.g., we can asses the top ten risks of managing our resources, or the cost of transformation, or the performance indicators needed to manage relationships, etc. 

(3) Process construct engineering - Step 3: Break the process construct down into Level Two processes

The next step is to break the Level One process down into a myriad of level Two processes. In this way we can get specific of what needs to be done operationally. 

As an example, we tackle the "Service Delivery" area of Level Zero (example above). From Level One, we have identified four Service Delivery processes for the Orgtology Institute. These were:

 (iP3) Create and maintain an Orgtology Body of Knowledge (OBoK).

 (iP4) Create and maintain policy to regulate the practice of orgtology. 

 (iP5) Accredit practitioners.

 (iP6) Manage providers. 

We must now unpack the activity flow for each of these processes. I will will use "(iP5) Accredit Practitioners" to demonstrate how to unpack a process flow on Level Two.

Each shape and color in the process flow has meaning. 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.

(4) Process construct engineering - Step 4: Break the process construct down into Level Three processes

In the example above, the "(iP5) Accredit Practitioners" has two child processes (green) and two shared processes (purple). We must now develop the process flow for each of these. In so they become Level Three processes. For this example, I use "(iP12) Accredit New Practitioners".

In this case, Level Three is where 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. The buck stops here.

There are no rules on how many levels a process construct must have. We break the construct into 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. Projects have a clear beginning and end. But with a process, the beginning is the end, and the end the beginning.

Practical Application

A process construct is a complete model. It shows how activity flows throughout the organisation. Level Zero helps us to cluster data within this process flow. This enables Org to use the Level Zero Model to draw data 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 within 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. Through Level Zero we can generate meaningful reports relating to Organisational performance. E.g., we can know what our transformational activities cost us, or what our risks relating to establishing and managing stakeholder relationships are, or what the performance indicators for our service delivery should be.

Level one will always be the core process. Level two introduces the process families within the Level Zero Model. 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.

Conclusion 

A process construct is the blueprint for the operations of Org. Level Zero helps us to develop the construct and to extract and process data from it. It gives a nodal point from 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.