Seven steps to engineering process flow – an orgtology perspective.

​At micro level, an organisation is made of activity and resources. Jointly, they drive performance and relevance. Therefore, all activity will relate to either purpose or intent.

Where activity links to purpose, it cycles. Where it links to intent, is begins and ends. Thus, all organisational activity is either repetitive or non-repetitive. The effect of this, is that Org does all its work through either processes or projects. The former drives operations, whilst the latter executes a strategy.

In this essay, I give the seven basic steps on how to create process flow. I.e., I explain how to understand the operations of Org.

An Orgtologist will understand operational activity through reverse engineering. I.e., we begin through a grasp of its purpose and then work backwards to a detailed cycle.

If purpose begins and runs a process, then we must reverse engineer purpose to understand the process flow.

Our first task is thus to grasp purpose. From here we can dissect it into activity, time, resources, flow, rules, targets, etc. Process thus begins as an idea. We then unpack it backwards into efficient flow of activity and resources.

Activity begins in purpose and then loops back to purpose. In so, purpose is the beginning and the end, the genesis, and the goal. Unlike projects, the end repeats, thus processes cycle.

​"Purpose" is where process flow begins. A process is a sequence of activity that produces an output. This output is always born from purpose. E.g., If my purpose is to be healthy, I will have the right weight, a good heart rate, low levels of stress, etc. To achieve these outputs. I must eat nutritious food, exercise, have good sleeping habits, etc. I must thus internalise processes that will maintain my purpose. It is not something that can end.

Managers often confuse purpose with intent. Where this happens, they change the behaviour of activity. E.g., "To become healthy" is not a purpose but an intent. This means that we are developing a project and not a process. "I live a healthy life", is a purpose. It shows a current reality and internalises a process. In so, it creates a state that is "normal". Intent does not imply a current state. It is a vision or desire of the future. In terms of health, intent might be "to become healthy" or "to live healthy". These are projects that change or create processes. In precis, purpose is a "we're doing it now" thing, whilst intent is a "to be" thing.

Projects works towards a future state. I.e., it works towards an outcome that does not exist yet. A process must produce a continuous state. In other words, instead of creating a future desire, we create an ongoing reality.

A process construct works with a repetitive past. Maintaining a current reality is different from defining a desired state.

When we define purpose, we draft a performance measure. I.e., we create a target that shows capacity at a specific point in time. E.g., living a healthy life means weighing "x" kg, having a heart rate of "x" beats per minute, etc. These measures are not goals. They are something that I must maintain, not achieve.

We can thus see that performance targets have different rules to relevance targets. Their relationship is dual and not linear. That is the nature of orgtology.

​In this step, we create the story that will bring purpose to life. This will take form as a sequential to-do list. So, the question is, "what must we do to get our purpose going?"

Case Study:

The International Orgtology Institute must accredit Orgtologists. For this, they have a process called, "Accredit new practitioners".

To serve their accreditation purpose they hold the following narrative…

• As new applicants apply, they must check for compliance.
• If an applicant complies, then they must issue a letter of compliance.
• If the applicant does not comply, but the IOI has exempted hir, then they must issue a letter of acceptance. The IOI council can exempt an applicant from all or some of the requirements. In such case, the accreditation process must enforce the councils ruling.
• If the applicant does not comply, then give feedback and guidance. Of course, where the IOI exempts an applicant, no feedback is necessary.
• If fees are payable by the applicant, then receive the fees from hir on time.
• Upon payment of fees, begin developing the applicant as an Orgtologist.
• Where no fees are payable, and the applicant must be developed, start with that.
• Where the applicant qualifies as an Orgtologist, the IOI must change hir profile. They will do this by changing the category to "Orgtologist".
• After this, the IOI must continuously monitor the Orgtologists compliance status.

​Now that we have a narrated "purpose", we can create efficiency. Efficiency happens when you get more out than what you put in. This begins when we prioritize the flow of action. The aim of efficiency is to get a perfect match between time, cost, resources, and priority.

To prioritize, we must create process flow. We ask the question; "what must happen before, and after what?" The narrative, designed in step 2, now looks like the flow chart below.

To show the efficient flow of work, we use arrows.

There are three arrow types that we use to show process flow. They are:

• Solid arrows, which creates movement.
• Dashed arrows, which creates a cycle.
• Connectors that help us to not to get our lines crossed.

The table below show the three arrow types.

You will note that we construct our process horizontally from left to right, and we loop back from right to left. Our research has shown that most find it the easiest to follow the flow of activity in this way.

When we draw a process map, we create our idea of a process. However, two-dimensional display limits us. So, we try to express it in the best way we can. The reality of any process is that it interacts in a much more dynamic way than we can ever depict on a PC screen.

In the example above, we mix activity with conditions. E.g., "if the applicant complies, then issue a letter of acceptance". To create efficient process flow we must separate activity from conditions.

In the example, we have a conditional question followed by a decision:

Conditional question: Does the applicant comply?

Decision: If "yes", then issue a letter of acceptance. If "no", then give guidance.

It is easiest to test a condition through a question. E.g.: "Does the applicant comply?". If "Yes", then issue a letter of acceptance, and if "No", then give guidance.

When it comes to activity, we always start with a verb. E.g., "compliance" is unclear, whilst "check for compliance" is as clear as crystal. Below, I use the example of the IOI "Accredit new practitioners" process. It shows how we separate conditions from activity.

We show a condition as a diamond shape within a process. We mostly depict it as a question with a "Yes" or "No" choice. Each choice holds its own consequence.

The effect of conditions is that they bring a "or" dynamic to process engineering. I.e., it is this or that, and never this and that.

Where one activity flows to two or more other activities, both must happen. If not the case, you must add a condition.

The table below shows how we depict a condition within a process.

​At this point, we have completed the process flow. The next step is to decide what power and authority each activity has. It could for instance be a task, which means that we must execute it directly. Or, it could be a process, which means that it has its own sequence of activity and conditions.

I use the "Accredit new practitioners" process, once more, to show what the final product looks like. Below is a screenshot:

To show the authority and power of different activities, we use symbols and colour codes. These differ to other process engineering methods. The table below shows each symbol (some with colour codes) and what each one means.

The "Accredit practitioners" process below shows a range of symbols. It is parent to the above "Accredit new practitioners" process.

The tables below show the authority and power of each activity. They also show the dependency links for the entire process.

Anything that happens within a process holds three options. They are:

• We do it internally, which means that we pay for it.
• We outsource it to another entity, whom we pay to do it.
• An external entity, who we do not pay, does it.

When it is an external task or process, there is something that an external entity must do for the process to flow. E.g., a government department must approve a document before the process can move on.

To label the power and authority of each activity we use a coding system. We call this code "C-Keys". It stands for classification keys. We also use the C-Keys as a numbering system. Below are the C-Keys with the meaning of each:

• iT - Internal Task (task done by an employee).
• oT - Outsourced Task (task done by a non-employee).
• eT - External Task (task not in budget of the organisation).
• sT - System Task (task done through artificial intelligence).
• PF - Process functionality (condition, decision, questions, etc).
• iP - Internal Process (process within process family).
• siP - Shared Internal Process (created outside the process family).
• oP - Outsourced Process (process executed by non-employee).
• eP - External Process (process not in budget of organisation).

In effect, each C-Key creates a consequence. It thus changes the nature and intelligence of the activity.

The "resource weight" shows how much of the budget each activity will use.

The last step is to create rules and targets for the process. Rules create boundaries, whilst targets measure the capacity of a process.

Targets measure the performance of a process at a specific point in time. We only create a target where deviation from efficiency is possible. That is why AI needs no targets. It only works on rules. Where humans are involved, we work with both targets and rules. Both measures aim to control the process.

Below are the targets that will test the "Accredit new practitioners" process.

This is a brief introduction on how to develop process flow. Mastery in this field will take a lot of practice. Yet, there is nothing that will teach one more about operations, than to engineer its process construct.

Join the Orgtologist Certification Program (OCP) - Empowering Executive Teams Worldwide