How to translate operational targets from bottom to top in a process construct

In my posts, "Creating targets for a process construct" and "How to engineer a process construct", I have explained that in orgamatics™, we create a process construct™ from the top down but that we target it from the bottom up. This is because Org™ does its work at the front-end and therefore, the top processes must just accurately summarize the work that we do at the bottom.

In the mentioned posts, I also explain that as we go up in our process construct, the number of targets that we have, become limited to the child processes that the parent process has. This is so, since the purpose of each child process becomes a target of the parent. Through this we assume that the livelihood and growth of the purpose of a process is evidence that the process is achieving its targets. This is evolutionary movement, unlike the revolutionary movement that I discuss in my posts on strategy.

Our front-end processes have no limits to the number of targets that they can have. With these processes it is not about the number of targets, but about whether the targets truly show that these processes are performing at their utmost ability.

Below is an example of how we wrote targets for the IOI process of " (iP12) Accredit New Practitioners".

Remember that we can link many child processes to one parent process. The above table that shows the targets for the "(iP12) Accredit New Practitioners" process, is just an example of one such child-process. You will see that we took the purpose of the process and put it in the evidence box. This means that if we achieve all the targets, the purpose will be alive and growing. From this example, we can deduct that if: the IOI only admits compliant practitioners; the system is fully automated; and they do not get any complaints of people who use the system, then there is evidence of an integrated and automated process that registers and accredits compliant orgtology practitioners. This is how we relate targets to purpose.

We record the purpose and parent of each process in the process brief. I have discussed process briefs in my post: "How to develop system and process briefs". Below is an example of where to find the name of a parent process on a process brief. It also shows the purpose of the process that will now become a target to its parent process. I still use the example of the IOI's " (iP12) Accredit New Practitioners" process, so that we can follow its trail until it contributes to the core operational targets within a strategic document.

The purpose of the "(iP12) Accredit New Practitioners" process must now become a target for its parent, which in this case is the "(iP5) Accredit Practitioners" process. Below is a sample of what the targets of (iP5) will look like. You will see that (iP5) has two targets, which means that it has two child processes. The first of these child processes is the "(iP12) Accredit New Practitioners" process, and you can see its purpose featuring as the first target for (iP5).

Of course, as with its predecessor, the purpose of (iP5) above, must become a target to its parent, which in this case is the "(iP1) Regulate Orgtology" process. You can pick up all this info in the process brief for "(iP5) Accredit Practitioners". Below is an extract of the process brief for (iP5):

However, there is a snag here. That is that in orgamatics, we have a rule that the purpose of a level two process always becomes a target for the system of which it is part, and not of its level one parent. The reason for this is that a level one process is the original process that gave birth to the core systems of Org™. So, we must first summarize all the targets within the systems, so that the purpose of each system becomes a target for the core business process of Org. In this way our level one process, in this case "(iP1) Regulate Orgtology", will only hold a few key targets that cover all its operations. I know that all this might seem confusing when one reads it for the first time, and in my experience the only way to fully grasp this is to do it as a practical exercise. Although abstract, it is quite simple.

So, we can see that "(iP5) Accredit Practitioners" belongs to the "(iS1) Core Business" system. This means that the purpose of (iP5) becomes one of the targets for (iS1). Below is a sample of the targets for "(iS1) Core Business" system. Each target there embodies the purpose of a process family that the (iS1) system holds within. From the four targets below, we can then deduct that (iS1) has four process families. Target number three shows the purpose of (iP5), which is the example that we have been working with.

Now, all that we must still to do, is to translate the purpose (evidence) of each system to our core "Level 1" process, which in this case is the "(iP1) Regulate Orgtology" process. The IOI's process construct holds four systems, which means that they have four core operational targets. Each of these four targets serves as a precis for a myriad of targets from process families with their child processes. In the IOI case, they derive their four core operational targets from 54 front-end process output targets. The table below shows the four core operational output targets for the IOI. Target number one denotes the purpose of my above example of the "(iS1) Core Business" system.

In my posts on strategy, I pose that any strategic document must hold two statements within. These are:

1. A statement of operational efficiency; and
2. A statement of strategic effectiveness.

The IOI will list their core targets, as shown above, in their strategy document as part of their statement of operational efficiency.