How to develop system and process briefs

In my article "How to engineer a process construct", I explain that the drawing of a process map is less than 40% of the work. To make a process intelligent it needs data as well as time, cost, and priority. I explain TCP Efficiency™ in another blog post. The aim of this post is to work with the collection of data.

The data that a process needs are targets, risks, cost, and other information that will aid its application. I discuss "how to create process construct targets" in a separate blog post. We record the data that a process needs in documents that we call "briefs". When we work with a process construct™, we user two types of briefs. They are the "system" and "process" briefs.

The system brief™ gives information on each of the four orgamatics™ systems. I explain these systems in my post: "What is Orgamatics?". A process brief™ gives information on the processes that flow from these systems. In this blog post I will first explain what information we must record for a system brief and then I will explain that of a process brief.

System Brief... 

The systems brief must encapsulate all processes within, and therefore, it is a lengthy document. Often large organisations have more than one hundred processes. To capture data for all these processes can become a cumbersome and often contaminated exercise. So, to remedy this, we assume that all the processes that flow from the same system have similar risks, opportunities, and inefficiencies. When I use the word "similar", I aim for about 75%. The effect of this is that a system brief has much more information to capture than a process brief.

The items that we assume to be similar within all processes that flow from the same system are:

• Purpose of the system;
• Critical success factors for efficiency;
• Critical success factors for effectiveness;
• Risk assessment;
• Risk mitigation and contingency;
• Units whom are responsible for the system;
• Policies and operating procedures that empower the system;
• Core targets for the system;
• Customers of the system;
• Stakeholders to the system;
• Laws and rules that bound the system;
• Suppliers to the system;
• Competitors to the system;
• Resources that the system needs; and
• The values that bind the people who run the system.

Of course, there are other data that must go into a system brief, such as the name of the system, the system number, etc. However, there are information bits that need a more detailed discussion. Therefore, I discuss them in distinct blog posts. These are:

• Risk assessment, mitigation, and contingency;
• Organisational design and structure (that creates the units that are responsible for a system);
• Development of the policies and procedures that must empower a system;
• Creating core targets for a system;
• The customers and stakeholders of a system;
• Resources to the system; and
• The values that dictate behaviour within the system.

As you might see, to develop a system brief takes in-depth knowledge of numerous systems and dynamics, all of which I cannot discuss in detail here. I do so in other posts. Below is a sample of a system brief. I use the core business system of the IOI, since I have already introduced you to its process flow.

Process Brief... 

The data that we collect in a process brief is much less than that which we record in a system brief. Of course, the most important data that we must feed into our process brief, is its outputs, also called targets. This takes some skill, which I explain in my blog article: "How to create targets for a process construct". Apart from the targets, a process brief must also show its location within the construct. That means we must link it with a system, a parent, siblings, and child processes. I give a precis on this in my blog article: "How to engineer a process construct."  However, for clarity, I give explanations for the hierarchy of a process construct below...

A Process: 

A process is a sequence of activity, functionality, and choice that creates a predetermined result, which you want to repeat. Any process begins with a purpose, therefore, one can see a process as a purpose in action. In its simplest form, a process is an algorithm, since through unambiguous specification, it creates an output. If automated, a process can follow a set of rules, perform calculations, and solve problems. A process always aims to achieve efficiency through creating and internalizing implied intelligence.

Core Process: 

In orgtology, we hold the belief that any organisation has one purpose and therefore one process. This is so, since purpose cannot exist without process.  Therefore, the energy, intelligence, and intent that you accumulate around your purpose, is your organisation. In so, purpose in action = organisation. We call this "one" process the core process of an organisation. Of course, there are organisations that have more than one primary purpose, such as a Revenue Authority that must also manage customs at border posts. Yet, in my experience, if you cannot unite purpose, or if you have a complex interdependent system that will manage the multiplicity of purpose, then it would be in your interest to find and define one purpose.  One might argue that there are organisations such as Virgin Enterprises who run hundreds of companies that differ vastly in their products and services. But, these companies all run on their own processes. Therefore, the Virgin head-office has the purpose of starting and overseeing new businesses. That is their purpose, and the companies that fall under their umbrella will all contribute to that goal by focusing on their own process constructs.

An Orgamatics System: 

In the post: "What is Orgamatics?", I define and explain the basic systems of Org. A system is a container for one or more process families. E.g., "stakeholder relations", "marketing", and "labour relations"could be three process families with numerous processes linked to them, all under the relationship system. We know that processes belong to a system if they have the same purpose as the system has. E.g., "recruitment", "procurement", and "funding" all have the purpose to resource an organisation, therefore they all belong to the resource system.

A Process Family: 

A process family is a cluster of processes that are all linked to one parent process. E.g., if a "manage intelligence" process has three child processes, namely: "transformation"; "risk"; and "monitoring and evaluation", then they all belong to the same process family, which in this case will be the "manage intelligence" process family. A system often has more than one process family.

A Parent Process: 

A parent process is a process that creates child processes. In the example above of the "manage intelligence" process, it has three child processes, namely: "transformation";  "risk", and monitoring and evaluation". 

Child Process: 

All processes below the core process are child processes, since they cannot exist without a parent process.  A child process simply says that it was created within a process family. In the examples that I have given under "process family" above, the "manage intelligence" process has three child processes. We depict a child process as a green oval shape. 

A Shared Process: 

A shared process is a process that is used in a specific process sequence, but that is not part of the process family where it is used. In other words, a shared process is a borrowed process. We depict a shared process as a purple oval shape. 

Other information that a process construct must have, and which will not take much of your time, are:

• Purpose of the process;
• Duration of the process;
• Its cycle time;
• Classification;
• Cost breakdown;
• The physical location where it will run;
• The tacit intellect (human intelligence) that the process must have; and
• The rules for this process.

Although the above looks like an extensive list, most of the work lies with the process targets. The rest should mostly take less than an hour to obtain. Below is a sample of a process construct for the "Accredit New Practitioners" process of the IOI. I have shown the flow of this process in my blog post: "How to engineer a process construct".

I must warn once more, that when one develops system and process briefs, it is not just the completing of a form. It takes extensive experience and skill to work with targets, risks, policy, and the more. That is why the IOI does not allow independent practice of these methods until a person has been trained to be an orgtology practitioner.