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.
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.
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:
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:
To show the efficient flow of work, we use arrows. There are three "tools" that we use to show process flow. They are:
I show these "tools" below:
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.
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:
|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.
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…
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:
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.
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 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.
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.
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.
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…
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.
© 2018: CFT Hendrikz