Is modeling in IDEF0 relevant today?

Known today not only in narrow circles, the abbreviation IDEF0 is the first methodology that standardizes work on business processes. It was developed in the middle of the last century as part of an aerospace project in the United States and, having shown its effectiveness, became a federal standard. In our country, in 2000, a document “ IDEF0 Functional Modeling Methodology. Guidance document Functional Modeling Methodology IDEF0 Guidance Document. Official edition. State Standard of Russia RD IDEF0 - 2000. Developed by the Research Center for CALS - technologies "Applied Logistics". Adopted and put into effect by the Decree of the State Standard of Russia 2000 Moscow”, but as a standard it was never approved. Although this did not prevent this methodology from becoming one of the most popular tools for graphical modeling of business processes in our country. In this article, I suggest that you consider the IDEF0 model and evaluate the relevance of this approach at the present time.

Basic concepts and abbreviations

Let's deal a little with the names of the key elements of the methodology. The IDEF0 graphics standard is part of the SADT (Structured Analysis and Design Technique) methodology. IDEF is an abbreviation for ICAM Definition, and ICAM is derived from Integrated Computer Aided Manufacturing, which translates as integrated computerization of production. The SADT methodology is a whole family of 15 different models, which together were supposed to allow us to explore the structure, parameters and characteristics of production, technical and organizational and economic systems.

IDEF0 is a functional model, which is the core of building all other structures, it links together information and material flows, organizational structure, control actions and the company's activities. A graphical standard for process modeling is also commonly referred to as a notation. That is, notation is a system of requirements and rules for building an activity model in one form or another. Therefore, IDEF0 is appropriate to call the notation that is part of the SADT methodology.

The IDEF0 notation is a fairly rigorous technique that was originally developed, like engineering design standards, for manual modeling. Therefore, it contains requirements for the placement of arrows, the format of all elements, the content of the information frame for the IDEF0 diagram, etc. Since the company's activities are a complex multi-level system of actions, there are always a lot of schemes, and unambiguous systematization and navigation through all elements of the model is necessary. Now this is done mainly by computer systems that support modeling in this notation. AllFusion Process Modeler and Business Studio systems are the most famous and available on the territory of Russia today. I plan to devote separate articles to the review of these systems.

Function block

The central element of the IDEF0 model is the function , which is displayed in the diagram as function block- a rectangle inside which the action is indicated in the form of a verbal noun. The action can be very different in scale - from the activities of the company in general and to specific manipulation in particular. Examples: "Production and sale of ceramic dishes" and "Drawing on the product."

Required Function Block Elements in IDEF0

Regardless of the scale of actions, all functions are displayed uniformly and necessarily contain 4 key streams that are rigidly assigned to the sides of the functional block:

on the left - inputs or resources used to execute the function;
on the right - outputs or results of the function execution;
above - control actions that determine how and how many results need to be produced;
below - mechanisms that reflect who and with what should do this work.

This approach allows you to save a little on explanations in the diagrams and achieve unambiguity in the display of flows, which makes the whole model harmonious.

To build a functional model, the IDEF0 methodology requires the following rules to be observed.

Inputs are resources that transfer their value to outputs completely, that is, they are completely spent on creating a result, and mechanisms are resources that transfer their value only partially (equipment through depreciation, and people through wages).
Management is a necessary element of the model, as it ties all actions to the company's system of regulations, clearly indicating which rules and requirements must be observed in the process of performing a function. Often this stream is treated formally, but at the same time the scheme loses its rigor, and sometimes even its meaning.
Each function block must have at least one arrow on each side (since there can be no work without resources or results, and an instruction without an executor or instruction will be incomplete).

The considered scheme is the "brick" of the IDEF0 approach. Functional modeling involves a gradual transition from the general to the particular through decomposition. Decomposition is a “deepening” into the function under consideration, dividing it into smaller functions. At the same time, when the top-level function is presented in a generalized way and then decomposed, it is appropriate to call it a process.

Context diagram

At the highest level, the company is seen as a "black box" in which some activity takes place that translates inputs into outputs. This level is usually called "", that is, a diagram that describes the context of the company's activities. Additionally, the context diagram displays the key characteristics of the entire model.

The goal is a specific formulation of the purpose of the model, according to which the accuracy of building the model can be verified in the future.
Point of view - from whose face the model is built, since the model is always dependent on its author and the focus of attention. If we are building a general model of an enterprise, then it is usually presented from the point of view of its director.
The model type is an indication of what information is displayed on the diagrams. There can be 2 fundamental options here: AS IS (“as is”) or TO BE (“as will be”). This separation is necessary because we can build models for both the analysis of activity and its transformation. We must be clear about what we are doing and communicate this information to others.

Thus, the context diagram contains in the most generalized form a description of the company's activities, which are permeated by the flows that connect the company with the outside world. I think they should also be a little more detailed.

Main streams

Experience has shown that, despite the apparent simplicity and formality of this level, it is often necessary to linger on it for a long time, since all the results that are significant for the owner and the market should be reflected here. An error can lead to the creation of models that do not fulfill the tasks set for the business. To check that meaningful flows are shown, make sure that all 4 main types of flows are present in your diagram.

Material: materials and components at the input and finished products at the output.
Client: a potential client at the entrance and a satisfied one at the exit.
Financial: at the input, this is usually investments, customer payments (revenue), loans and other income; the output is payments to suppliers, taxes, payments on loans and profits.
Informational: at the input, these are all flows of information about the external environment (market conditions, competitor behavior, technological innovations, etc.), and at the output, this is the flow of information that the company reports about itself to the world (all advertising information, as well as all types of reporting to regulatory authorities).

Note that the company is an open system, and nothing comes and goes in it. The company is only able to convert incoming flows into outgoing ones, and if it does this well, then an additional cash flow (profit) appears, reflecting in a sense the quality of the entire system.

(click to enlarge)

It's good if you highlight each of these types of flows with a different color so that you can easily distinguish the movement of resources and not miss important points. For example, you can often observe the absence of a client in the company's flows, therefore, work with him is based on a residual principle - the client often feels like a hindrance to company employees whose tasks are focused on processing the flow of documents.

Control arrows can be represented by only 1 type of flow - informational, which can be divided into 2 subtypes. The first is documents such as:

laws and regulations;
orders, orders;
instructions and regulations;
plans;
design documentation, etc.

The second is undocumented information, which most often includes the requirements of the owners.

And, finally, mechanisms - there are only 2 types of flows: equipment (material) and performers (divisions and people). There can be no documents here, just as there can be no people on the control arrows!

Continuous numbering is provided for navigation in the model. The context diagram is numbered "A-0". In the future, each functional block receives its own number, no matter how deep the decomposition is.

Decomposition

After working out the flows of the context diagram, we can move on to decomposition. Going one level down, as if opening a "black box", we first see a blank sheet with arrows that have been attached to the functional block.

(click to enlarge)

And this is where the actual functional modeling begins - we need to understand what set of actions can connect these flows and ensure that all requirements are met. The difficulty lies in the fact that there are a lot of actions in the company, and we have the right to display no more than 9 functions on the diagram, otherwise the diagram will become unreadable and, accordingly, useless.

It is not always easy to arrange a complex activity in such a way that it remains visual, readable and at the same time complete. Most often, they resort to dividing the entire variety of processes into main large blocks, the most significant of which are the following.

Creation of a product (result).
Promotion and sale - work with a client flow.
Ensuring product creation activities are secondary processes that are necessary to comply with government requirements or work convenience (personnel and accounting, transport services, cleaning of premises, etc.).
Creation of control flows is the activity of developing management decisions that will determine the requirements for all company processes.

The figure below shows the decomposition diagram of our example.

(click to enlarge)

In the diagram, the processes should be located diagonally - this is called principle of dominance, which implies the arrangement of functional blocks from left to right and from top to bottom - in order of importance or in chronological order. The block numbering is the same.

Further work on the model is similar to the first step - the decomposition of each functional block of the first level is carried out. The block numbering will contain the number of the first level: A1.1 ... A1.n, A2.1 ... A2.n, etc.

Conclusions about the relevance of the notation

Within the framework of this article, it was possible to display only the basic concepts of the IDEF0 notation using a short example of IDEF0, by which, of course, it is difficult to judge the methodology as a whole. But a fairly large experience of using this notation in practice allows me to draw the following conclusions.

The model has a good visualization potential, but, in my opinion, its greater value is in the disciplinary effect. The rules and restrictions laid down in the methodology make it necessary to develop a systematic and strict attitude to the models, which has a very good effect on the quality of the final result.
The model allows you to build communication flows between externally not strongly related things: to connect the subsystems of the front and back offices with management, which is much worse for other notations.
The approach is simple and understandable for most project participants. Building and reading diagrams in this notation is limited only by the desire to delve into the intricacies of business flows.

Some of the above arguments lead one to think that this approach is the best and only one for complete activity modeling. But we must not forget that the functional model is designed only for the upper level of modeling. Using the IDEF0 notation to design work at the level of performers leads to the fact that the schemes are purely illustrative and it is impossible to build an explanatory regulation on their basis, since they do not contain:

specifying the start and stop events of the process;
conditions for the transition from one action to another;
the ability to visually display all resources and performers without overloading the scheme with arrows.

Therefore, if you use this notation for the tasks for which it is intended (structuring top-level activities), then IDEF0 is practically the only notation today that allows you to do this meaningfully and accurately.

In project management, this modeling standard is most applicable where you need to link different projects or processes in visual flows. At the same time, the graphical model will allow for a more rational distribution of responsibility and resources among tasks. The logic of the project tasks, reflected in the diagrams, will help to prepare a better schedule in the form of a Gantt chart.