Building a top-level company's activity model based on the principles of systems engineering. Chapter 1. Processes or functions?

Dmitry Pinaev

Head of “Umalogic”

Introduction

How top-level process models are created was, and still is, one of the business architect’s guarded secrets. There are a number of established top-level process models, and these are usually used as examples. However, there is not always sufficient justification to put any of these examples into practice. In this article, we suggest an approach to creating an activity model of complex systems such as organizations, based on the principles of systems engineering. IDEF0 is proposed as the modeling notation of choice.

In the article, we aim to cover the following topics:

The activities of an organization: are they processes or functions? What are we actually modeling in the top-level process model?
The possibility of using IDEF0 notation for the top-level model.
How should the constituent parts of the organization be divided?
The principle of modularity in the design of system architecture.
The principle of autonomy in the design of organizational system architecture.
Peculiarities of creating a top-level model in the IDEF0 notation.

The following ideas are used in the reasoning and justification of the proposed solutions:

The concept of ontology and the set theory used to construct classes.
4D extensionality.
Notation suitable for instances and classes (Matthew West, Developing High Quality Data Models, ISO 15926-2 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model).
The concepts and procedures used in system engineering.

However, the specific concepts of these theories and disciplines are used minimally and in an accessible form. There are certain reservations to the conclusions drawn in this article, but we have omitted these so as not to overload the narrative.

Why do we need these theories at all if we are discussing obvious things? The point is, they are not always so readily understandable. In the community of business architects and business process management specialists, debate still goes on as to which concepts should be included in the top-level process model: process groups or process categories — and are there processes there at all? The matter is not that straightforward: sometimes it is rather difficult to understand which objects the authors of books and articles on management are actually talking about. It is possible to understand complex ideas only by carefully constructing the ontology of the subject area from below, i. e. from concrete objects up to more abstract concepts.

For example, if we say „table„ and then point our finger at it, 99% of analysts will agree with us. If we say “furniture" — a higher class — then 98% of analysts will agree. But if we take the concept of an end-to-end process, then analysts are unlikely to be able to agree on a clear definition and unambiguously single out the actual end-to-end process. Each and every one of those analysts will offer a different solution.

Formulation of the problem

Let us consider the case where an analyst is called upon to create a model of an existing company.

At first glance, the task is simple. After all, the analyst does not need to come up with anything new: it is enough just to look at the work of the company, that is, at objects which exist in reality. Every day, the company performs thousands, and perhaps even millions of specific (i. e. those having a start and end time, as well as a place) operations.

A specific process is also an operation and also has a time and place for execution. A process is simply an operation the structure of which is either known to the subject or the subject able to assume the existence of such structure. This is the phenomenon of our consciousness: when we do not know the structure of an operation or if the structure is not important to us in the context under consideration, we refer to it as an operation. Whenever we need to, we can easily break down the operation in terms of space and time and call it a process.

Another example: we can call the same object both a system when we consider it separately, and a component when we consider it in the context of an over-arching system. In good ontologies, an object can be both.

But we do not want to deal with so many objects, so we take the first, quite natural step, and combine operations into classes according to the principle of similarity. The first step toward classification is relatively easy: we see operations that are similar to each other in the reality around us and we attribute them to the same class. For example, the „assembly of a chair„ or “drafting a waybill". And this allows us to state the first obvious fact: in our activity model, we are modeling classes of operations, not specific operations.

Of course, if necessary, we can model specific operations. Consider, for example, a Gantt chart in which the tasks have a specific scheduled execution time.

Notes:

In the following text, rather than the general „class of operations„, the more familiar concept of the “class of processes„ will be used.

Though the reader is already familiar with the use of the OOP concepts: „process“ and “process instance„ instead of “class of processes" and „process“, respectively. Within the framework of this article, these concepts are identical.

Processes may take place at different times and in different places. We combine those we consider to be similar into a single class, even though the number of operations in them may be different. Remember: in the process diagram (of a typical model), there will be forks and cycles that in reality lead to different sets of operations for specific processes.

Although the number of resulting process classes will be smaller, it will nevertheless be extremely large, hundreds and even thousands. What should we do next? Logically, the process classes need to be put into ever more abstract classes as we climb to ever higher levels within the model. But for what purpose? In order to ensure that the model is compact at the top level (bird’s eye view) and satisfies the following requirements:

The model must be able, in its entirety, to fit into the head of a single person.
The model must be understandable to those who have not received any kind of training (and, ideally, be suitable for use as teaching material for beginners).
The model should unambiguously answer the question of what exactly does the company do? And so, it is most desirable that the model is able to fulfill requirement 4.
The model should show how operations are linked at inputs and outputs.

What are the challenges in creating a top-level model? Those who have tried to create such a model for an existing business (and almost all the analysts I know begin with this) already know that

Incorporating process classes into more abstract classes is not an easy task. There will always be those classes of processes that do not fit anywhere and those that appear to fit everywhere at one and the same time.
There may be too many process classes at the top level.
And, most importantly, there are nearly always big questions regarding the clarity of the model.

As an example, let us consider the work not of novice analysts but some of the models that have long been used in practice.

APQC PROCESS CLASSIFICATION FRAMEWORK (PCF) — CROSS INDUSTRY — VERSION 7.2.1 SEPTEMBER 26, 2019

APQC PCF is one of the most widely-known process classifications.

Characteristics:

Created for company benchmarking (for making comparisons between companies);
13 high-level process categories: 6 operational and 7 management and support categories;
Depth: up to level 5 in some places. With 1264 elements (activities) at level 4 total.

Criticism:

Overcomplicated ontology: 2 entities for grouping processes (Category, Process Group, 3 entities for decomposing processes (Process, Activity, Task):
Strictly specified fixed number of levels.
In practice, attempts to restrict classification to a rigidly specified number of levels often fails. Imagine you were told that you can decompose absolutely any system (for example, a table or a nuclear power plant) into no more than 5 levels;

The comprehensibility of the resulting model would clearly raise questions. For example, for some reason, operational processes include a group called „1.0 Developing a Vision and Strategy„. And in it, in “1.2 Develop business strategy", organizational design activities are highlighted; just a very small fragment:

OPERATING PROCESSES
1.0	Develop Vision and Strategy
1.2	Develop business strategy
1.2.5	Create organizational design
1.2.5.1	Evaluate breadth and depth of organizational structure
1.2.5.2	Perform job-specific roles mapping and value-added analyses
1.2.5.3	Develop role activity diagrams to assess hand-off activity
1.2.5.4	Perform organization redesign workshops
1.2.5.5	Design the relationships between organizational units
1.2.5.6	Develop role analysis and activity diagrams for key processes
1.2.5.7	Assess organizational implication of feasible alternatives
1.2.5.8	Migrate to new organization

There are no links at the inputs and outputs.

TYPICAL MODELS OF THE BUSINESS STUDIO ECOSYSTEM

A large number of normative models are used. Among these, I would personally single out the following models that have become widespread in the Business Studio ecosystem:

The Timur Kadiyev’s 8-process model

It is executed in the IDEF0 notation, operations are grouped according to the life cycles of company elements and external objects.

The model satisfies all the criteria put forward at the beginning of the article for a top-level activity model. Nevertheless, in my opinion, this model has a number of drawbacks, among which the main ones are:

The model contains a temporal paradox: Both the system design activity and the design result (system model) are shown in one diagram;
There is also the system assembly activity (through the mechanism link), which complies with IDEF0 specifications but also, as with the design, raises existential questions (how the system works and how we assemble it are shown in the same diagram and happen, as it were, simultaneously) and overloads the diagram with real models having larger numbers of blocks.

Typical structures of Group of Companies "Sovremennie Tekhnologii Upravleniya" processes

This is a reworking of Timur Kadiyev’s process model into the process register and its localization in respect of the following activities:

Provision of services (PDF);
Project activities (PDF);
Manufacturing (PDF);
Management of the company (PDF).

This is, in fact, an analog of the APQC classifier. By the way, it is also used for benchmarking, moreover, it is automated on www.bizdiag.com.

Igor Lozovitsky’s model

This model identifies 18 groups of processes divided into three areas. The model is created in IDFE0, but the VAD notation is used for the top-level presentation view.

The model is interesting because activity is separated into three areas: Main, Management and Supporting. In my opinion, this is an advantage since it allows one to focus on a given aspect of the company activity. So, for example, the value creation chain in the main activity sphere is easily distinguished.

PROCESSES OR FUNCTIONS?

Now is the time to precisely define the concepts with which we are dealing in the high-level company’s activity model.
And we will start, traditionally, by criticizing the APQC classifier:

I have also come to the conclusion, quite independently of Bruce Silver, that the concepts we operate in the top-level activity model are timeless. That is, we cannot indicate time limits, for example, of such activities as developing a vision and strategy or developing and managing products and services (examples from APQC). But what we can say is that we know for sure that such an activity exists, and from time to time it produces concrete results.

We also said above that we combine the classes of processes we saw in reality in the high-level model into something more. In general, in common modeling paradigms, there are only three ways to combine objects (their names may differ depending on the paradigm):

Composition;
Aggregation;
Classification (inclusion of a member in a class).

Let us take a closer look at these. As a result of Composition and Aggregation, we get the whole object. But the main thing here is that we get an object with its own 4D boundaries, which, if desired, we can point at with a finger. For example, when we say that a process is divided into parts, we are talking about the composition relationship since both the parts and the whole are an object—operation. Here we can fix the intermediate result. We have established that when we move down the hierarchy levels from the process level, we are dealing with a composition relationship.

Is it suitable for describing the phenomenon that we observe in higher-level activity models? No, because, as noted above, the concepts that arise in the top-level activity model are not objects.

Let us try to think about the concept of Class.

We understand a class to be first and foremost the aggregation of its members. Members are included in the class based on a set of criteria.

The class is timeless, it always exists. You cannot tap your finger on the class, it is not an object.

The concept of Class and the operation Classification perfectly describe what we are doing in the top-level activity model with classes of processes. For example, including the process classes from APQC 1.1.1.6 Analyze Demographics or 1.2.6.1 Identify Organizational Goals (assuming, of course, that the members of these classes are processes that have a beginning and an end) as members in the class 1.0 Develop Vision and Strategy means that all the specific processes within a particular company, those which have already been completed, those being carried out at this moment and those that will be carried out in the future, are related to the strategy development activity. And the processes of all the classes, which, as we have decided, relate to the development of strategy, are in fact this activity.

In an ontology based on set theory, it would be possible to include a class as a member in another class. In this example, we include the mentioned process classes as members in the Develop Vision and Strategy class.

We get the intermediate levels of our model in a similar way. In order to do this, we introduce subclasses of the class 1.0 Develop Vision and Strategy into the model. But the relationship here will be different: it will be specialization (class/subclass). The members of these subclasses will, as before, be process classes.

Using only two concepts, Operation and Process, it is possible to develop a simple ontology that allows activities to be decomposed to an unlimited depth. (We shall not consider the concepts of Class and Class of Classes since these are at the base level of the ontology.) Compare this with the five concepts in the APQC framework, which are needed to build just 5 levels of decomposition.

You could get by with just the one concept, Operation. But the Process concept is familiar, and it will be difficult to exclude it from the language.

You can read this ontology as follows:

Some operations are processes;
#Process1 consists of operations #Operation1 and #Operation2;
Processes are aggregated into process classes;
Process classes are aggregated into classes of process classes.

Using idef0 notation to create top-level activity models

Let us take a break from our mental gymnastics and take a look at the good old IDEF0 notation. We know it to be a functional modeling notation that is used to create top-level models. It is based on the structural analysis and design methodology (SADT) described in Structural Analysis and Design Methodology (SADT) by David A. Mark and Clement McGowan.

This methodology is famous mainly because it gave us the idea of function decomposition. Surprisingly, the book does not define what a function is. Something approaching a definition appears in the IDEF0 standard based on it:

I always had a great number of issues with this definition. For example, if a function is a process, then why come up with a new concept? What would be new in it?

Let’s figure it out. The description of the IDEF0 notation emphasizes the timeless nature of the model:

And the semantics of the inputs and outputs of a function includes the following principles:

The appearance of an object at the input of a function does not necessarily imply its activation. In some cases, the appearance of one object at the input is sufficient, while in others several are required;
Objects do not have to appear at all the inputs of a function.

Thus, IDEF0 models focus on describing WHAT needs to be done, the functions and the interfaces between them.

I think it has already become clear what I am driving at. The object that appeared before us earlier fits the definition of the idea of a function:

A function is a class of process classes.
(Or, as OOP would have it, if a process is a class, then
a function is a class of processes).

Consequences of this definition:

We can create a function out of any class of processes we choose.
Any criteria can be selected for inclusion in the class. For example, as shown above, we may decide that certain classes of processes are relevant to strategy development.
Or we might now move to solve another philosophical problem: is accounting a process or not? Accounting is definitely not a process. It is a function that includes all the classes of the processes related to accounting objects.
One class of processes can be included in several functions (and this is not a sin, as is now commonly believed; the world is too multifaceted to be described by a single taxonomy).
We can generalize functions upwards to infinity. There is a class/subclass relationship between the parent and child function. At the lower level, when only one class of processes is included in the function, they usually change the model type and move on to creating a typical model of the processes of the class (describing all the processes of the class). In this case, further splitting into parts occurs using the composition link.
This approach has long been supported by Business Studio. We now know what this means in theory.
Arrows between functions simulate objects moving between functions. What this means in reality is that there will be two specific processes between which the specific objects move. But as in any class model (with an indication of the corresponding multiplicity at the end of the link), not all links will exist between every pair of processes. When combining the arrows that model function interfaces into larger arrows, the approach is similar to that used with functions.

Notes on ontology

Why, at first glance, is such a great deal of attention paid to the objects and classes of our ontology and the links between them? In good ontologies, you should be able to go from the upper-level abstract classes to the final objects underlying the ontology and be able to point them out. If you are unable to do this, then it is most likely that your ontology is not as transparent and used in practice as you would perhaps like.

It is also a very good thing if your ontology is in sync with the ontology of others. In the case described, that would appear to be so. The ontology is consistent with IDEF0, BPMN and the Archimate languages.