I always struggle on whether we design a process or whether we discover it. If we can produce a result, then a process does exist. But, it would be naïve to say that the humans who discover these processes do not add some of their own experiential flair. In my blog post: "What is a process construct?", I discuss what a process is, and why it is important to grasp the process construct of any organised system.
When you engineer a process construct™, the right place to start is to get an uncontaminated definition of its purpose. What this means is that we must define the organisation for what it is. E.g., if the the Orgtology Institute sees their mission as: "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", then we must crop it in such a way that we can grasp it in its simplest form. In so, the first task of an Orgtologist is to break this purpose down into its most basic form, without any frills or icing. In this case we can say that the IOI's work is to "regulate orgtology". Please note that it is not our aim to turn mission statements into something clinical that has no verb. We just take away the added information so that we can work with Org in its purest form.
With this uncontaminated purpose construct, we can begin to ask questions such as; "How does the IOI regulate orgtology?"; "What exactly should the IOI control to regulate orgtology?"; "What must be in place if they want to regulate orgtology?"; "What work must they do to repetitively regulate orgtology?"; "How must they prioritise this work?"; "Which verbs would best describe the this purpose?"; etc.
As we answer the questions around purpose, we begin to map it as one core process. This is both incredibly complex and minimal at the same time. It is complex, because if you get it wrong, then you create a false base for all the operations within Org. The impact of this is huge. In reverse, it is minimal because we want to create an extremely basic process without much functionality or complexity. This is a core process that will give birth to a myriad of processes. To do so, it will have systems, process families, and levels. In precis, it is a holistic picture of all the operations of Org, in its most simplistic form.
Now, if wishes were horses, then all that we needed to do would be our core business, but we know that this is not the case. You must sell yourself, mange your money, get help, work with people, etc. In my blog post: "What is Orgamatics?", I have shown how any organisation must have three systems that supports its core business. I also discuss each of these systems in that post. The systems are:
Below is a diagram that shows how the three systems interact with their core function.
Now that we have defined the relationships between our systems, we can use orgamatics process mapping to map our core business process. Our first task here is to ask which process families must be within these systems. A usual route is to begin with the resourcing of your organisation, then enabling it through relationships, after which you must do your work (core business), which we follow up by processing its intelligence so that we can create a learning Org. I explain more on process mapping in my blog post: "Six steps to creating process flow for a process construct". Below is an example of a "Level 1" process. At this level we always try to depict Org in its most basic and simplistic way, without losing any of its complexity. In this case I used the core business process of the International Orgtology Institute.
The process above, is a core process. All other processes, policies, procedures, and operating risks will be born from this process. We can also identify the systems with their process families here. In the given process, there are ten process families and four systems...
Please note that there is no rule on how many process families any system can or must have.
Below is an example of how we unpack a "Level 2" process. Remember that all level 2 processes are children of the core process. In this case, I will be taking "(iP5) Accredit Practitioners" process to show how we unpack each process on level 2. We must do so for all ten of the level 1 processes.
I explain how to work with process flow in another post, but must mention here that the purple oval shapes are "shared processes" and the green shapes are "child processes". From this "Accredit Practitioners" example, one can then see that there are two child processes (iP12 and iP13), and two shared processes (iP4 and iP9). To show you how to unpack a level 3 process, I must choose one of the child processes of level 2. I have taken the "(iP12) Accredit New Practitioners" process to show how we unpack a process on level 3. You can see that there are no more child processes here. In other words, this is where rubber meets the road. There is no prescription on how many levels a process construct must have. We break the construct into a few levels so that we can follow it. If we do not do this, the maps become too cumbersome.
To summarize this article, I give a sketch below that shows a simplistic view of a process construct. To grasp it, we must first know that the black circle at the top of the hierarchy is the level 1 process of Org. Above, I gave an example of this in the "(iP1) Regulate Orgtology" core process. You can also see how this core process creates systems and process families that gives birth to a myriad of child processes. We organise our process construct into levels, but as I have discussed above, this is not a role structure.
Please note that this sketch does not represent all the process families and processes of the IOI. If I did, the sketch would be too large. In this sketch, you can see that only levels one and two have set process types. Level one will always be the core process and level two will always introduce the process families of a process construct. From level three downwards we simply divide child processes to make them manageable. It is key that we note that process families do not have a one-to-one relation to systems. In the above sketch, "System 4" holds two process families, whilst other systems each hold one process family. Organisations can structure their construct as they deem fit. Also, important to note, is that 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. I discuss process flow in my post: "Six steps to creating process flow for a process construct".
To depict a process construct is not the entire task. Most of the work is to create and define intelligence within the construct. I have discussed some of that in my post: "What is a process construct?" In my blog post: "How to develop system and process briefs." I explain how we record the information that a process construct needs to become intelligent.
© 2018: CFT Hendrikz