8 minutes reading time (1609 words)

Six steps to creating process flow for a process construct

process-flow How to create process flow for a process construct.

In my blog posts "What is a process construct?", "How to engineer a process construct", and "How to develop system and process briefs", I work with various parts of a process construct. In this post, I focus on creating a process. In precis, I have divided this blog into six basic steps that will help you to create a process flow.

Step 1: Define purpose as a target

In my post: "Creating targets for a process construct", I show how to qualify and quantify targets. Therefore, my task here is only to work with "purpose" as the starting point of any process flow. A process is a sequence of activity that produces an output. This output is always born from purpose. E.g., If I have the purpose of being healthy, I will ignite a myriad of actions to make this purpose a relevant one. What is important is how we define such purpose. In my post on "How to engineer a process construct", I use the level 3 process of "Accredit new practitioners" as an example. A traditional way to define purpose for such a process would be: "To create and run an automated process that registers and accredits compliant practitioners". The problem with that is that we are defining a future state, or an outcome that does not exist yet. If we defined it as: "There is an integrated and automated process that registers and accredits compliant orgtology practitioners", then we put pressure on the system to ignite processes that produce a continuous state. In other words, instead of creating a future desire, we create an ongoing reality. We must remember that a process construct works with a repetitive past. This is the difference between creating current reality vs. defining a desired state. I deal with the latter in my posts on strategy. In this post we work with operations.

Step 2: Develop a narrative that will realize purpose

This is a basic step where we create the story that will bring our purpose to life. The best way to do this is to get the people with the most experience in a field into one room and to let them brainstorm. In our "Accredit new practitioners" example, the narrative should look something like this:

  • Check for compliance.
  • If the applicant complies, then issue a letter of compliance.
  • If the applicant does not comply, but the IOI council has exempted hir from all or some of the requirements, then enforce the councils ruling, and issues a letter of acceptance.
  • If the applicant does not comply, and does not qualify for exemption, then give feedback and guidance.
  • 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 orgtology practitioner.
  • Where no fees are payable, and the applicant needs development, start with such.
  • Where the applicant qualifies for the official designation as an orgtology practitioner, change the category on the applicant's webpage listing to show that ze is now an orgtology practitioner.
  • Continuously monitor the applicant's compliance.

Step 3: Create efficiency through the dependency of activity

Now that we have narrated "purpose" within a process, we can create efficiency. This means that we must get a similar or increased value from a process output, as the value that we have put in. We begin to achieve this where we can prioritize the flow of action. Where we get a perfect match between time, cost, and priority, we reach a high state of efficiency. At this stage, priority will create process flow. We ask the question; "what must happen before and after what?" In so, our narrative will flow like this:

Case Study 1: Creating a narrative from a purpose, which we depict in a process flow

To show the efficient flow of work, we use arrows. There are three "tools" that we use to show process flow. They are:

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

I show these "tools" below:

Datasheet 1: Creating process flow

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, we are mostly limited to a two-dimensional display. So, we try to represent it in the best way that 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.

Step 4: Separate conditions from activity

In the example above, we mix activity with conditions, e.g., "if the applicant complies, then issue a letter of acceptance". In this case we have a conditional question followed by a task:

​Condition: Task:
If the applicant complies Issue a letter of acceptance

Mostly, 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. We show a condition as a diamond shape within a process, mostly depicted as a question that has a "Yes" and a "No" choice, each leading to its own consequence. The effect of this is that conditions bring a "or" dynamic to process engineering, in other words, it is this or that, and never this and that. Where one activity flows straight to two or more other activities, both must happen, otherwise you must add a condition. The sketch below shows how we depict a condition within a process.

Datasheet 2: Process conditions

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 to show how we separate conditions from activity…

Case Study 2: Separating process conditions from process activity


Step 5: Give power and authority to activity

At this point, we have completed our process flow. All that we must still do, is to decide what power and authority each activity point 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. In my post: "How to develop system and process briefs", I explain the distinct types of processes. A main thing to remember is that anything that happens within a process has three options. These are:

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

In the last instance, which is an external task or process, there is something that an external entity must do so that our process can flow. E.g., a government department must approve a document before our process can move on.

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

Datasheet 3: Activity symbols

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

Case Study 3: Adding authority and power to process flow

To show the authority and power of each activity and the dependency links for the entire process, I give the two tables below. The "resource weight" shows how much of the budget for this process each activity will use. I discuss weights in my posts under the "TCP Efficiency" topic.

Case Study 4: Authority and power of process activities set out in a table

Mostly, a process on level three only has tasks and conditions. The "Accredit practitioners" process below gives a wider range of symbols. It is parent to the above "Accredit new practitioners" process.

Case Study 5: Diversity of process symbols in process flow

To label the power and authority of each activity we use a coding system, that we call "C-Keys", which are classification keys. We also use the C-Keys as a numbering system. Below are the C-Keys with their meaning:

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

Step 6: Define outputs

The last step in developing process flow is to create targets for the process, which has the aim to measure a process. I discuss the creation of targets in my post: "Creating targets for a process construct". Therefore, I only briefly mention targets here. In this post, I primarily used the "(iP12) Accredit new practitioners" process as an example. Below are the targets that will test the ability of this process…

Case Study 6: Creation of process output targets

This post will give you a brief introduction to developing process flow for a process construct. Unfortunately, it will take much practice and application to reach mastery. Yet, what I guarantee is this – there is nothing that will teach you more about your organisation, than engineering its process construct. 

The official website of Derek Hendrikz Consulting

Copyright

© 2018: CFT Hendrikz

The difference between a target, an output, and an...
You are because love is…

Related Posts