Myths of business process management haunt me. Almost every day, they tell me them in different combinations and interpretations. Sometimes, I try to explain their erroneous nature. Sometimes I just smile silently. But more often than not, I have to deal with the consequences, because belief in myths gives rise to reality.

I have collected the most common myths regarding business process management and divided them into 4 categories:
1. Myths of business process management
2. Myths of using business process management
3. Myths of implementing a process approach
4. Don't be fooled
Destroy myths that can lead to real consequences.

Myths of business process management

Creating models is business process management

Probably one of the most common myths that has firmly taken root in Russian companies. Many people really believe that the essence of business process management is to create models, but this is far from the truth. Let's find out why.

Business process management is responsible for the following activities in the company:
– Business process analysis
– Process design
– Process modeling
– Description of business processes
– Change and transformation of business processes
– Implementation
– Monitoring and control
– Increased efficiency
– And sometimes, also for organizing

Components of business process management

As you can see, process modeling is only a small part, but is responsible for the efficiency and continuous improvement of the company’s activities. Simply through the prism of business processes. Actually, this is not surprising and is not an exaggeration, because initially, the concept of business process management was created specifically to organize the continuous improvement of companies’ activities. If you want, the only goal of business process management is to continuously increase the company's competitiveness. But let's get back to modeling.

Thus, a model is a tool that facilitates the management of business processes. That's all.

That is why in many companies, business process management specialists deal only with modeling and description.

There really is another myth related to the fact that almost every employee can prepare a model. This is not just a myth, but a very harmful opinion.
The modeling process, in skillful hands, immediately turns into analysis and design. This allows you to save a lot of time when planning further improvements, because during the modeling process, the specialist is already correcting and planning for further improvements.

In order for a model to effectively perform its functions, it must be simple and clearly understandable. And to prepare such models, I tell you, you need extensive experience and a special, specific mindset.

Modeling is a small, but quite complex, part of business process management. The purpose of modeling is to obtain a tool for subsequent analysis, design and control of business processes.

The essence of business process management is writing regulations and other documents

Creating business process models is for advanced students. Those who are not looking for easy ways, value old school and prefer hardcore, believe that in order to manage business processes, it is necessary to overwhelm employees with regulations and other documentation. Remember the example about the 70-page description of the procedure from the previous paragraph? This is exactly what this is about. I think there is no point in describing the scale of the problems generated by belief in the current myth.

A number of representatives are fanatically convinced that a large volume of documentation is an indicator of real business process management. That, in fact, business process management should do just that – develop the paper industry. Moreover, it is paper, because electronic documentation is not acceptable. It doesn’t allow you to fill up your desktop and create the appearance of work)))

In one company, I happened to see so much documentation regulating the actions of employees that, when converted “per capita,” it turned out to be about 2,000 printed pages for each employee. Those. Every person in the company must take into account and follow the internal rules described on 2000 pages in their work. And these are only internal documents. The requirements of legislation and regulatory authorities are not taken into account here.
In general, the myth is dangerous and harmful. It creates a misconception about managing business processes, wastes company resources, creates obstacles in management, etc.

In fact, here, as with business process models, the document is a tool. A tool that links the way something is designed to the way it actually works. Just don’t talk about how the documents don’t work! Of course, they won’t work on their own; more effort needs to be made. But as an instrument, everything is exactly like that.
From the point of view of business process management, a document is any information that has a physical embodiment. This means that such information can be accessed, read, studied, sometimes covered from the rain, etc.

Documentation helps convey and use information, but is not the essence of business process management.

The goal of business process management is to turn people into robots in a rigid system

Many representatives of technical professions think so. It is necessary to regulate the activities of employees as much as possible. So that they cannot take a single step to the side. And since in Russia, the functions of process management are often transferred specifically to the technical direction, the myth about the “roboticization” of employees is firmly rooted in the corporate environment. As a result, companies and areas associated to one degree or another with the “creative” component of work are fleeing in panic from process management.

Like many myths about business process management, this one is harmful and even cruel. There is nothing more stupid than trying to make robots out of people and not taking advantage of the human component.
Most likely, those who promote this approach are supporters of the theory X McGregor. But that's not the point.

It’s very easy to dispel this myth using 4 arguments:

1. All business processes, except fully automated ones, involve people. If you do not take into account the features associated with them, then changes, and business process management is always associated with changes, will not be successful. All business process and change management professionals clearly agree that when planning and implementing management, it is necessary to take into account:
   – Organizational culture
   – Unspoken rules
   – Behavioral characteristics
   – Ideas and plans
   – Communications and rules adopted in the company
2. Business process management focuses on processes rather than their standardization. Who said that increasing efficiency is only possible through standardization? Oh yes, Henry Ford. He was a good guy. Made an entire industrial revolution. But product standardization is not identical to process standardization. Not always, standardization, as the only correct way to perform a process, will be useful. Processes need to be executed in a way that is efficient rather than routine.
3. A properly designed and implemented process, provides many development scenarios and the possibility of creating new ones! Without loss of specified efficiency. This is the highest level of business process management. It is probably worth devoting a separate article to this issue.
4. The use of management levels, principles and rules allows for efficiency with very large freedom of action. There is no need to try to describe the process of painting by an artist. However, the process of creating a picture can be described. Moreover, it can improve the efficiency of the writing process by eliminating distractions such as preparing the easel, paints, etc.

Got the idea?

Creating human robots is not the goal of business process management. The goal is to ensure efficiency and development of processes. And the use of creative and human components enhances rather than harms the process.

Operations automation is business process management

Let's agree right away - automation and control are completely different things. Business process management is about, uh, well, management. Not automation. And the key word here is business. Those. This is management aimed at achieving business goals.
The myth that business process management is automation is fundamentally false. It appeared when “non-techies” did not show sufficiently systematic approaches to management and issues of consistency were left to those who were closer to them – the “techies”. And they, in turn, gave birth to a gorgeous legend about total automation as the only tool for increasing efficiency and management. Time and the principle of a broken phone have led to the fact that the meaning of automation as an auxiliary tool for business was forgotten, and the implementation of IT technologies became self-sufficient.

In fact, automation is a tool. One of the management and efficiency tools. One of many tools.

The topic of business process management is becoming increasingly popular. A huge number of services and applications have appeared on the market that do not require deep technical knowledge to use and configure. Against this background, a large number of “specialists” began to appear offering services for “business process automation.”
Most of them talk about CRM, marketing process automation, sales automation and so on. They all say that they are engaged in optimizing and setting up business processes.

Sometimes you can even see messages like this:

“By the way, we washed down the bot here. Business diagnostics and site audits are carried out...”

A curtain. Puzzled silence. Someone nervously goes to the smoking room, and someone to the buffet.

These "experts" are missing two things:
1. What they are doing is very far from automating business processes, setting them up, and, even more so, from managing business processes. The most they do is automate operations and some procedures. For example, they can arrange for recording client requests from the website into your CRM system. This is somehow very far from optimizing business processes, don’t you think?

2. Optimization of business processes is impossible without a solid foundation, in the form of strategy, methodology and assessment of business processes at many levels. And the interconnections of processes at the organizational level should not be forgotten. Otherwise, you can get, for example, a huge flow of client requests, on which you will need to spend resources, and the conversion and profitability of sales will only decrease.

Optimizing business processes and automating procedures are two different things. Automation of procedures is a part not only of business process management, but also of normal automation.

Myths of using business process management

In our company/industry, business process management will not work

It will work. It will definitely work in your industry and in your organization.
There is no industry in the world in which the principles of business process management have not yet been applied. From the aerospace industry to providing escort services. Creative agencies, travel companies, logistics operators, representatives of heavy and light industry, IT companies and even casinos! This list can be continued endlessly.

Business process management works in any industry, and here's why:

1. Universality of principles. Basic management principles apply equally in all organizations. Special principles also apply everywhere, but, as a rule, are modified under the influence of the company's characteristics. In business process management, there are also principles that are applicable to any company. Regardless of your field of activity, you will determine the boundaries of business processes based on the same principles. It doesn’t matter what you produce - elements of space satellites, or create Internet pages, you will equally determine the intermediate products of the processes. The principles apply everywhere.
2. Adaptability of approaches. There are many approaches to managing business processes. The beauty is that, based on the principles of business process management, you will adapt approaches to suit your specific needs. Moreover, the correct implementation and use of approaches will include adaptation mechanisms. Every properly designed process contains such a mechanism.
3. Combinations of methodologies. Many business process optimization methodologies are good in themselves. But management involves the search and implementation of such a combination of methods that will show the greatest effectiveness in specific conditions. This combination will work best only for you. By the way, this is why blindly copying the approaches and methods of other companies will not work in your company.
4. Ease of implementation. In order to get the benefits of business process management, you do not need high-precision instruments and advanced information technologies. Yes, technology helps, but that's not the main thing. Business process management is very easy to implement because intuitive people. The process approach is based on logic and interconnectedness. And you don't need expensive tools to use them.

The process approach is always based on the reality of your company.

We tried managing processes - it doesn't work

And indeed. Many companies have tried to master process management and failed. Here are some examples of what these companies did:
– We created multi-volume descriptions of processes and procedures, and decided that people would then work on them themselves.
– They appointed owners of business processes, but did not explain why this was necessary and how to combine the roles of a functional and process manager.
– We introduced a super advanced electronic document management system, but did not transfer the employees’ work to it. As a result, costs not only did not fall, but also increased significantly.
All these are real examples, real companies.

It didn't work for them. Why? Because implementation.
The implementation is lame. This often happens with us - the idea seems good, but the execution ruins everything.
And it ruins because they underestimated and did not think through it. Didn't get the point. After all, the point, as I said above, is not in the description of the processes, but in what you do with it next.

When a person says that he tried to run a marathon, but he didn’t succeed and “it’s not my thing at all,” it’s worth finding out what was done for this and how much he ran. And it often turns out that he ran 500 meters from the bakery to the entrance, got tired, out of breath and decided to give up this idea. But he tried. I ran a full 500 meters. From 42 kilometers. Do you get my point?

Before you say something doesn't work, make sure it's done right. The instructions should be taken before use, and not after everything is broken.

Using business process management is very difficult and only works in large companies

Yes Yes. And running is only available to professional athletes.
If you have two legs and two arms (and even then it is not necessary), then you can run.

If you are already involved in management, you can use business process management.

The myth about the availability of advanced management technologies only to large companies is associated with the opinion that it is necessary to use expensive equipment, software and staff of specialists. They say that all this is expensive and only large companies can afford to spend such resources.

I hope I make you happy - all this is not true.
You don’t need super equipment, ERP software or world-class specialists.
All that is needed is to master the methodology and think about how to implement it with the available resources.
Expensive software can be replaced with affordable analogues. The specialists are not only expensive and well-known, but also very accessible and humane. And all equipment can be replaced with a laptop, notepad, pen and phone. Want to know how? Ask)))

In my practice, I have seen companies that do not take advantage of modern technologies at all, but are leaders in their industries. There were also opposite examples, when the personnel of the “interstellar ship” did not know how to work with all this and only wasted the company’s resources.

To manage business processes, you only need your company and your processes. All expensive resources can be found with an affordable analogue.

There is no point in dealing with processes in small companies

The smallest company I dealt with had less than five people.

If you provide customer service over the phone, it doesn't matter how many people in the company do the work. It could be one person and ten thousand. In this case, the processes will not differ much.
Yes, at that stage, while the company is small and all the personnel are located in one garage, management issues do not arise acutely. But efficiency issues are relevant regardless of size.

Even your personal processes can be optimized and managed effectively.

Moreover, if the company is not very large, it is usually very limited in resources, so the question of using them as efficiently as possible is a matter of survival.

Start managing business processes even at the stage of a one-person startup. This will bring much more benefits than all possible financial investments.

You can’t control “creative processes”

Creative processes can and should be managed, but in a slightly different way.
I'm not talking about the need to manage, for example, the process of writing a novella. When even the writer himself is unable to explain how such a process occurs. But it is necessary to concentrate on auxiliary processes, i.e. Those processes that will create the best conditions for the implementation of the main one.

What I mean? Well, for example, in order to summon the writer's muse and create a truly worthy work, you may need certain music and lighting. Perhaps a cup of freshly brewed coffee on the table will help you, and so on.
In this case, you need to focus on performing the processes associated with obtaining the necessary conditions as efficiently as possible.

Do you think companies like Google use a process approach? Of course it is used. You've probably heard that in the offices of this corporation, employees can eat well, sleep, relax, play games, play sports, and so on. You think this is done simply because they are big and have a lot of money. No!
This is an extremely pragmatic move, based on the above-mentioned principles of business process management - people are freed from the need to worry about and perform auxiliary processes in order to focus on the main ones.
This is how business process management works.

Creative processes are managed through auxiliary ones.

And by the way, if you are interested in direct control of creative processes, refer to the works of Edward de Bono. It offers a number of extremely interesting mechanisms.

Myths of using the process approach

To manage business processes, you need to understand the intricacies of work

This myth concerns not only the management of business processes, but management in principle. For some reason, many people believe that in order to manage, it is necessary to know in detail the features of the smallest operations.
As a result, there are situations when good specialists in their field, promoted to management positions, make decisions that harm the company. This is especially common in Russia. Last year, at a venture capital fair, a representative of a large foreign fund said, “The trouble with many companies is that excellent scientists and engineers try to take over the reins of the company without having any idea about management skills.” And indeed it is.

Managerial skills and special ones are completely different things. The manager does not need to understand the subtle aspects of performing special operations. He must be able to organize the work of specialists in such a way that they perform tasks that lead to the company’s goals as efficiently as possible.

If you pay attention to the discipline of management, you will immediately notice the separation of management and execution. The effectiveness of this separation has been proven for a long time.

Management occurs at different levels and only at the operational level is special knowledge required in order to assess, for example, the effectiveness of the application or implementation of technology.

The higher the level of management, the less specialized knowledge is required. And vice versa. The closer a manager is to performing operations, the more specialized knowledge he must have.

Business process management also occurs at different levels, but there is a lot of work to be done at other levels before it becomes necessary to delve into technology and operations. And during this time, the manager will have time to understand the peculiarities of operating activities to the extent necessary for effective management.

A good manager will always manage more effectively than the most highly qualified specialist.

Business process management is primarily concerned with management, and management principles are universal and do not require narrow knowledge of operational work. The acquisition of specialized knowledge occurs faster than the acquisition of management skills.

We can handle it on our own

In my opinion, I have already given enough arguments to debunk the myths about the complexity of managing business processes. However, it would be a mistake to believe that everything is so simple that you can quickly implement changes in your company.

Actually, this is where the catch lies. The business process management methodology itself is really very simple. But it is directly related to change, and change must be managed in such a way that it works. This is the main difficulty for non-experts in the field of process and change management. We are now talking about highly specialized skills from the previous part. Only these skills relate not to production technologies, but to change management technologies.

Specialists can assess what difficulties the company will encounter during the change process and take care of eliminating them in advance. It is a matter of special skills, knowledge and experience. Hiring specialists is much cheaper than eliminating the consequences of changes on your own.

The second point related to the myth is that quite often, employee time allocated to the implementation of business process management is planned on a residual basis. Those. employees devote most of their time to functional tasks and, if there is any time left, do something related to changes.
This approach absolutely does not work. If you want change to be implemented, it must be a daily responsibility of all employees involved. With all the ensuing impacts on them.

Again, most often, employees simply ignore change work due to high workload. Here you need not only to do the work, but also to make serious mental efforts. But high turnover is not conducive to this.

This is another reason why hiring a third-party specialist will be extremely useful, and sometimes simply necessary.

To be confident in your abilities, you need to allocate resources to implement changes. Involving specialists in business process and change management is an important, and sometimes necessary, step.

We do not have enough resources for implementation

In order to assess whether you have enough resources or not, you need to understand what resources are needed and in what quantities.

The main resource you will need is employees' time. At the same time, at the initial stage, top management spends the most time. The further the project moves through the management levels, the less time the tops require. For example, I would give the following figures:

Stage of defining business process boundaries
– Top management – ​​4-5 hours per week.
– Middle management – ​​5-6 hours per week.
– Functional managers – 2-3 hours per week.
– Specialists – 1-2 hours per week.

Business process description stage


– Functional managers – 4-5 hours per week.
– Specialists – 6-8 hours per week.

Change planning stage
– Top management – ​​4-5 hours per week.
– Middle management – ​​7-8 hours per week.
– Functional managers – 7-8 hours per week.
– Specialists – 4-5 hours per week.

Change implementation stage
– Top management – ​​1 hour per week.
– Middle management – ​​2-3 hours per week.
– Functional managers – 8-12 hours per week.
– Specialists – 8-10 hours per week.

In general, 20–30% of the working time of the employees involved should be allocated to implementing changes. Remember - changes are not implemented simultaneously, but in waves, so that in fact, you allocate very little time relative to all the company's resources.

This is, of course, a very approximate and rough estimate, but it should give an idea of ​​the required time investment. And yes, this assessment takes into account the presence of a specialist who will lead the changes.

If you are willing to allocate 20% of the working time of responsible employees, you will cope with change.

Hired specialists will do everything for you

Involving specialists in business process and change management will be very useful. This will make the task much easier. However, you need to understand that third-party specialists cannot do everything. They are not magicians, they do not have a universal button or a super robot. Specialists work most effectively when they work closely with company employees.

The “We pay, let them do it” approach will not work here. You will have to help them. And they will help you. This is a completely mutually beneficial cooperation.

The division of roles here is very simple. Specialists have management skills and technologies. You know your business and your industry best.
Specialists know what and how to do in management. You know how and what to do in technology.

Experts will not do everything for you. Only joint work brings results.

It is difficult to assess the effect of business process management

There are many ways to evaluate the effect of implementing business process management.
The simplest is functional cost analysis.

The point is this.
When all components of a business process are known, the cost of its implementation can be calculated. To calculate the cost of the process, the following is taken into account:
– Costs of performing operations by employees. Based on the duration of operations and the cost per person per hour of employees.
– Costs of raw materials and materials
– Costs of using tools based on their service life
– Costs of using infrastructure. If it is needed.
– Other production costs. For example electricity, water, etc.

In addition to this list, other costs may be taken into account. It depends on the characteristics of the field of activity and the company.

The cost of performing a process is assessed before changes and after a certain time. As a rule, when we believe that changes have become obvious.

The difference in the cost of performing the process is the effect you get.

Additionally, the return on investment for process changes can be calculated.
To do this, it is necessary to estimate the costs of changes and divide by the difference in the functional cost analysis before and after the change. This way you will get a number of repetitions of the process that will fully compensate for the costs incurred. If this figure suits you, the efforts were not in vain))

Methods for assessing the effectiveness of using business process management are varied, but simple to use.

We will see the results tomorrow

Not really.
Any changes take time. First, to organize changes. Then for their implementation, i.e. Direct process change. It then takes time for the changes to fully take root (or not) and for employees to begin performing work in accordance with the new process.

Implementing changes always meets resistance. And it also takes time to overcome it.
If you went to learn to swim, this does not mean that tomorrow you will be able to calmly swim several kilometers.

Different changes require different times. Some are very easy to implement – ​​literally in a couple of weeks. Others take years. Accordingly, the effect of the changes will also be visible on different time horizons.

We divide changes into “rapid” and “planned”. The effect of rapid changes is visible no more than 2 months from the date of implementation. Everything else is systematic improvement.

The speed of change myth often hurts companies. When the point of no return is just a short distance away, the company may give up. It is important to be able to soberly assess the possible speed of change and the effect obtained.

Change doesn't happen quickly. Neither in life, nor in companies.

Don't be fooled, or Quick cheese usually smells bad

Any specialist who has dedicated himself to the Cause is outraged by quackery. I'm not an exception.
Business process management is my profession, to which I devoted the main part of my working life. There have been outstanding successes and tremendous failures along the way. And there will be even more of them. This is the natural development of a professional. It's impossible to know everything, but I know 3 things for sure:
1. He who wants to get everything and cheaply receives nothing and is expensive.
2. Methodology, consistency and patience always bear fruit.
3. Only bad things happen right away. Everything good takes time.

That's why:
– Three-day trainings guaranteeing a 30% increase in sales – quackery
– Automation of business processes in a week – a hoax
– Automation of marketing processes is dangerous, because only calculations based on rough templates are automated.
– Twenty-five-year-old business process optimization expert – a brazen adventurer
– If you see “business process management” and “CRM” in the same sentence, this is about public CRM and nothing else.
– If a business process management specialist tells you that a business process is “a stable, purposeful set of interrelated activities that, using a certain technology, transforms inputs into outputs that are valuable to the consumer” - run away from him!
– Analyzing your business using a website is like treating teeth using a photograph.

Beware of myths and charlatans. Everything fashionable becomes a subject of speculation.

Annotation: Principles of creating an information system. Business process reengineering. Process mapping and modeling. Providing the process of analysis and design of IS with the capabilities of CASE technologies. Implementation of information systems.

4. Development and implementation of an information system

4.1. Principles of creating an information system

Many users of computer hardware and software have repeatedly encountered a situation where software that works well on one computer does not work on another similar device. Or the system units of one computing device do not interface with the hardware of another. Or the information system of another company stubbornly refuses to process the data that you prepared in the information system at your workplace. This problem is called the problem of compatibility of computing, telecommunications and information devices.

The development of computer systems and tools, their expanded implementation in all areas of science, technology, services and everyday life have led to the need to combine specific computing devices and information systems implemented on their basis into unified information and computing systems (ICS) and environments. At the same time, IVS developers faced a number of problems.

For example, the heterogeneity of technical means of computer technology in terms of the organization of the computing process, architecture, command system, processor bit capacity and data bus, etc. required the creation of physical interfaces that, as a rule, implement mutual compatibility of devices. With an increase in the number of types of integrated devices, the complexity of organizing the physical interface between them increased significantly. The heterogeneity of programmable environments implemented in specific computing devices and systems, in terms of the variety of operating systems, differences in bit depth and other features, has led to the creation of software interfaces between devices and systems. It should be noted that it was not always possible to achieve full compatibility of software products developed for a specific software environment in another environment. The heterogeneity of communication interfaces in the human-computer system required constant coordination of software and hardware and retraining of personnel.

The principle of "openness" of the information system

Solving compatibility problems has led to the development of a large number of international standards and agreements in the field of application of information technologies and development of information systems. The fundamental concept has become the concept of open systems.

The term "open system" can now be defined as "a comprehensive and consistent set of international information technology standards and functional standards profiles that specify interfaces, services and their supporting formats to enable interoperability and mobility of software applications, data and personnel."

This definition, formulated by specialists from the IEEE (Institute of Electrical and Electronic Engineers), unifies the content of the environment that an open system provides for widespread use. Currently, the generally recognized coordination center for the development and harmonization of open systems standards is OASIS (Organization for the Advancement of Structured Information Standards).

The general properties of open information systems can be formulated as follows:

• extensibility/scalability: providing the ability to add new IS functions or change some existing ones, while leaving the remaining functional parts of the IS unchanged;
• mobility/portability: ensuring the ability to transfer programs and data when upgrading or replacing hardware IS platforms and the ability for specialists using IT to work with them without retraining them when changing the IS;
• interaction: the ability to interact with other information systems (the technical means on which the information system is implemented are united by a network or networks of various levels: from local to global);
• standardizability: IS are designed and developed on the basis of agreed international standards and proposals, openness is implemented on the basis of functional standards (profiles) in the field of information technology;
• user friendliness: developed unified interfaces in interaction processes in the “man-machine” system, allowing a user who does not have special “computer” training to work.

A new look at open systems is determined by the fact that these features are considered together, as interrelated, and are implemented in a complex, which is quite natural, since all the above properties complement each other. Only together, the capabilities of open systems make it possible to solve the problems of design, development and implementation of modern information systems.

Structure of the information system environment

The generalized structure of any IS can be represented by two interacting parts:

• functional part, including application programs that implement the functions of the application area;
• environment or system part that ensures the execution of application programs.

Two groups of standardization issues are closely related to this division:

• standards for interfaces between application programs and the IS environment, Application Program Interface (API);
• standards for interfaces between the IS itself and its external environment (External Environment Interface - EEI).

These two groups of interfaces define the specifications of the external description of the IS environment - the architecture, from the point of view of the end user, the IS designer, and the application programmer developing the functional parts of the IS.

Specifications of external interfaces of an IS environment and, as will be seen below, specifications of interaction interfaces between components of the environment itself are precise descriptions of all necessary functions, services and formats of a specific interface. The set of such descriptions constitutes the Reference Open System Model.

This model has been in use for over 20 years and is defined by the Systems Network Architecture (SNA) proposed by IBM in 1974. It is based on dividing the computing environment into seven levels, the interaction between which is described by the relevant standards, and ensures the connection of the levels regardless of the construction of the level in each specific implementation (Fig. 4.1). The main advantage of this model is a detailed description of connections in the environment from the point of view of technical devices and communication interactions. However, it does not take into account the interconnection taking into account the mobility of application software.

Rice. 4.1.

The Open Systems Environment Reference Model (OSE/RM) defines the division of any information system into applications (application programs and software systems) and the environment in which these applications operate. Standardized interfaces (APIs) are defined between applications and the environment and are a necessary part of the profiles of any open system. In addition, in IS profiles, unified interfaces for interaction of functional parts with each other and interaction interfaces between components of the IS environment can be defined.

More details about the use of technology and open systems models will be discussed in Lecture 18.

Model for creating an information system

Methodologically, it is important, along with the considered models of the IS environment, to propose a model for creating an IS that would have the same aspects of functional groups of components (users, functions, data, communications). This approach will provide an end-to-end process of design and support at all stages of IS operation and the possibility of an informed choice of standards for system development and project documentation.

A company is a complex ontological (conceptual) structure, consisting of a certain set of entities and relationships (Fig. 4.2).

The interactions between its elements, determined by business logic and enshrined in a set of business rules, are the activities of the company. The information system “reflects” logic and rules, organizing and transforming information flows, automating the processes of working with data and information, and visualizing the results in the form of sets of reporting forms. Therefore, first you should create a business model of the enterprise, which is a reflection of the enterprise and its information management system.

When creating a model, a “language of communication” is formed between enterprise managers, consultants, developers and future users, which allows them to develop a unified idea of ​​WHAT and HOW an enterprise management system (corporate management system) should do. Such a business model is a tangible result, with the help of which you can specify the goals of IS implementation as much as possible and determine the following project parameters:

• main business goals that can be achieved through process automation;
• list of sites and sequence of implementation of IS modules;
• actual need for volumes of purchased software and hardware;
• real estimates of the timing of deployment and launch of the IMS;
• key users of the IS and an updated list of implementation team members;
• the degree of compliance of the application software you choose with the specifics of your company’s business.

The model is always based on the business goals of the enterprise, which completely determine the composition of all the basic components of the model:

• business functions, which describe WHAT the business does;
• core, support and management processes that describe HOW the enterprise performs its business functions;
• organizational and functional structure that determines WHERE business functions and business processes are performed;
• phases that determine WHEN (in what sequence) certain business functions should be implemented;
• roles that determine WHO performs business functions and WHO is the “master” of business processes;
• rules that define the connection and interaction between all the WHAT, HOW, WHERE, WHEN and WHO.

After building a business model (or in parallel with this), you can begin to form a model for the design, implementation and implementation of the IS itself (Fig. 4.3).

The experience of creating and using “custom” IS allows us to roughly identify the following main stages of their life cycle:

• defining system requirements and analyzing them - determining what the system should do;
• design - determining how the system will do what it is supposed to do; design is, first of all, a specification of subsystems, functional components and ways of their interaction in the system;
• development - creation of functional components and individual subsystems, connection of subsystems into a single whole;
• testing - checking the functional compliance of the system with the indicators determined at the analysis stage;
• implementation - installation and commissioning of the system;
• operation - the normal process of operation in accordance with the main goals and objectives of the IS;
• support - ensuring the normal process of operating the system at the customer’s enterprise.

Determining system requirements and analysis is the first stage of creating an IS, at which the customer's requirements are clarified, agreed upon, formalized and documented. In fact, at this stage the answer to the question is given: “What is the information system intended for and what should it do?” This is where the key to the success of the entire project lies.

The goal of systems analysis is to transform general, vague knowledge about the original domain (customer requirements) into precise definitions and specifications for developers, as well as generating a functional description of the system. At this stage, the following are determined and specified:

• external and internal operating conditions of the system;
• functional structure of the system;
• distribution of functions between a person and the system, interfaces;
• requirements for technical, information and software components of the system,
• quality and safety requirements;
• composition of technical and user documentation;
• conditions of implementation and operation.

The development of the above specifications when creating an IS intended to automate management processes generally goes through four stages.

The first stage of analysis - structural analysis of the enterprise - begins with a study of how the enterprise management system is organized, with an examination of the functional and information structure of the management system, and identification of existing and possible consumers of information.

Based on the results of the survey, the analyst at the first stage builds a generalized logical model of the original subject area, reflecting its functional structure, features of the main activity and the information space in which this activity is carried out (Fig. 4.4). Based on this material, the analyst builds a functional model “As Is” (As Is).

The second stage of work, in which interested representatives of the customer, and, if necessary, independent experts, are necessarily involved, consists of analyzing the “As Is” model, identifying its shortcomings and bottlenecks, and identifying ways to improve the management system based on the identified quality criteria.

The third stage of analysis, containing design elements, is the creation of an improved generalized logical model that displays the reorganized subject area or part of it that is subject to automation - the “As To Be” model.

The process (fourth stage) ends with the development of an “Automation Map”, which is a model of a reorganized subject area, on which the “automation boundaries” are necessarily indicated.

In most cases, the “As Is” model is improved by the systems analyst by eliminating obvious inconsistencies and bottlenecks, and the thus obtained version of the model is considered further as a preliminary “As It Should Be” model, which is subsequently supplemented in accordance with the enterprise development strategy (Fig. .4.5).

At the stage of analyzing the requirements for the designed system, the following are introduced:

• user classes and corresponding business transaction diagrams;
• models (diagrams) of applied activity processes and corresponding lists of functional IS tasks;
• classes of domain objects and corresponding entity-relationship diagrams reflecting the information model of this subject domain;
• topology of the location of departments and users served by this IS;
• parameters for protecting data, information and the system itself.

The main document reflecting the results of the first stage of creating an IS is the terms of reference for the project (development), which contains, in addition to the above definitions and specifications, also information about the order of creation of the system, information about allocated resources, target dates for individual stages of work, organizational procedures and activities for acceptance of stages, protection of design information, etc.

The next stage is design. In real conditions, design is a search and modeling of a development method that satisfies the requirements of the system functionality using available technologies, taking into account the given initial conditions and restrictions. Information systems design always begins with defining the purpose of the project. The main task of any successful project is to ensure that at the time of system launch and throughout its operation it is possible to ensure:

• the required functionality of the system and the degree of adaptation to the changing conditions of its operation;
• required system throughput and minimum system response time to a request;
• trouble-free operation of the system in the required mode, readiness and availability of the system to process user requests;
• ease of operation and maintenance of the system;
• necessary data security and user access rights.

Performance and reliability are the main factors determining the effectiveness of the system. Good design is the foundation of a high-performance system.

Information systems design covers three main areas:

• designing data structures that will be implemented in the database;
• designing programs, screen forms, reports that will ensure the execution of data queries;
• design of a specific environment or technology, namely: network topology, hardware configuration, architecture used, parallel processing, distributed data processing, etc.

Based on the results of the system analysis at the preliminary project stage, the following are developed:

• software and hardware implementation project, user interface project and technology for users to work in the system;
• distributed system architecture and telecommunications network specifications;
• data flow models (diagrams);
• functional block diagrams of application and system software (the latter in accordance with accepted IS environment models and standards profiles).

The preliminary design stage may involve prototyping parts that are important from the user's point of view to test their compliance with requirements early in the development phase.

At the detailed design stage the following are developed:

• complexes of functional IS programs and the project for implementing the IS environment;
• data structures, database maintenance tools;
• network addresses, telecommunication protocols and other components of the information exchange environment included in the designed IS;
• rules for limiting user access and means of their implementation.

The IS implementation stage involves the development and testing of components and comprehensive testing of the system.

The operation and maintenance stage involves monitoring the functioning of the IS, making the required changes to the information base in the process of ongoing work and upgrading the IS functions by application specialists using tools built into the system.

The stages of development, testing, implementation, operation and maintenance of an IS are united by the term implementation. Implementation of IP is an extremely complex multidimensional process carried out on the basis of sets (profiles) of harmonized international standards, specifications and agreements. This practice is a guarantee that the created information system will be implemented as an “open system”. In other words, such an IS will be scalable, mobile, portable, have user-friendly interfaces, etc.

The life cycle of an information system is formed in accordance with the principle of top-down design and, as a rule, is of a spiral-iterative nature. The implemented stages, starting from the earliest ones, are repeated cyclically in accordance with changes in requirements and external conditions, the introduction of additional restrictions, etc. At each stage of the life cycle, a certain set of technical solutions and documents is generated, and for each stage the initial documents and solutions are , adopted at the previous stage. The life cycle of an IS ends when its software and technical support ceases.

4.2. Business process reengineering

The introduction of information technologies and information systems implemented on their basis into the daily activities of an enterprise gives it tactical and long-term business advantages. Management's desire to use IT can remain only good intentions if it does not follow the established requirements and rules for the development, design and implementation of IT. Above we talked about the basic requirements for the standardization of objects and functional tasks, without which the implemented system will not be an open system, which will subsequently lead to numerous problems during its implementation and operation.

Following the requirements of standards when developing an IS automatically leads to the fact that the enterprise itself - the external environment for the IS - also meets the necessary requirements: definition and standardization of classes of users and objects, topology of data flows and work, architecture of inherited and developed subsystems, state of business processes and etc.

A business process is a system of sequential, purposeful and regulated activities in which, through control actions and with the help of certain resources, over a certain time, process inputs are converted into outputs - into results that are valuable to the consumer and bring profit to the manufacturer.

A standard enterprise-wide business process is implemented as a network of main, auxiliary, supporting and management processes (Fig. 4.6).

At the same time, the division into main and auxiliary processes depends to a certain extent on the subject area and direction of the enterprise’s activity: for a manufacturing company, for example, the activities of the legal department are auxiliary, and for a legal or consulting firm they are the main ones. Identification of processes is a prerequisite, without the implementation of which informatization of activities is impossible.

Enterprise managers who have decided to implement IT must firmly understand that the beginning of work on designing an information system most often entails mandatory reengineering of business processes! Reengineering consists of many methods and recommendations, among them you need to choose those that best satisfy your goals.

Business process reengineering is a set of methods and actions used to redesign processes in accordance with changed conditions of the external and internal environment and/or business goals.

There are several basic rules that should be followed during the reengineering process:

• development of consistent step-by-step procedures for process redesign;
• use of standard languages ​​and notations in design;
• the presence of heuristic and pragmatic indicators that allow assessing or measuring the degree to which the redesigned process or functionality meets the specified goals;
• the approach to solving particular problems and their totality must be systematic;
• even a small improvement should have a quick positive effect.

Reengineering of business processes and functions begins with a review of the goals of the enterprise, its structure, analysis of the needs of internal users and the market, products and services produced (Fig. 4.7).

Replanning goals and objectives involves revising the enterprise's policy and answering the following questions:

• What new challenges do the changed business conditions present us with?
• What does the enterprise represent now, and what do we want from it in the future?
• What kind of consumers do we serve, how much do we satisfy their requirements and expectations, and what needs to be done to attract new ones?
• What specific indicators determine the efficiency of an enterprise, labor productivity and product quality? Is this definition complete and adequate?
• What information technologies and tools will help us with this?

To answer these key questions, it is necessary, first of all, to carry out a detailed description of the business architecture of the enterprise, its business logic, build a functional model of the interaction of business processes, resources and personnel and reflect it in the IS architecture, the content of modules of information subsystems and visualization of information presentation forms . It is also necessary to have methods and tools for reorganizing processes, solving applied problems and managing a reengineering project (Fig. 4.8). Description of the business architecture of the enterprise allows:

• build a diagram of the main flows of data, work, movement of finances and documents;
• understand how information is distributed between departments and who the end user is in a particular business process;
• describe the interaction of processes and modules of the information system;
• determine the critical importance of types of information for specific levels of enterprise management;
• identify duplicate structures and connections.

The result of this description is:

• refined process network map;
• matrix of relationships between processes and departments involved in these processes;
• information about what automation systems exist, in what operations they are used, where and what data is used, what automation and information systems need to be developed;
• functional diagrams of data flows (Data Flow), work flows (Work Flow), financial flows (Cash Flow), management impact flows (Control Flow) and document flow (Doc Flow).

A functional model will help to create precise specifications of all operations, procedures and relationships between them. Such a model, if constructed correctly, provides a comprehensive description of the functioning process and all the information flows within it. This model describes the “As Is” state. Based on the results of the analysis of possible ways of improvement, from the real model it is necessary to move to a model that characterizes improvements - the “As To Be” model, option - “As It Should Be” (Fig. 4.9).

Functional modeling is a rather serious problem; the completeness and compliance of the constructed model depend both on the modeling tools and on the qualifications of the specialists performing this modeling.

Business process reengineering is a complex and multifaceted project that requires careful planning and elaboration of details. Table 4.1 shows the main stages of reengineering.

4.3. Process mapping and modeling

Today, three main functional modeling methodologies (and their accompanying tools) have become widespread: IDEF (Integrated DEFinition), UML (Unified Modeling Language) and ARIS (Architecture of Integrated Information Systems). For each of them, there are certain software products that, in addition to development, allow you to carry out transformations and operations for subsequent work with the resulting models. The most widely used today are the IDEF methodologies and the BPWin software product, which contains the IDEF0, IDEF3, DFD (Data Flow Diagrams) and ERWin (IDEF1x) methodologies from Computer Associates.

The history of the IDEF methodology begins in the 70s of the twentieth century with the SADT (Structured Analysis and Design Technique) methodology developed by Douglas Ross (Softtech INC). SADT was initially used by the US Department of Defense for practical process modeling as part of the ICAM (Integrated Computer Aided Manufacturing) program. The fundamental requirement when developing the family of methodologies under consideration was the possibility of effective exchange of information between all specialists participating in the ICAM program (Icam DEFinition). This methodology was subsequently transformed into the IDEF0 (Function Modeling, FIPS No. 183) standard. The IDEF family includes the already mentioned IDEF3 (Process Description Capture) and IDEF1x (Data Modeling, FIPS No. 184).

After the publication of the standards, they were successfully applied in a variety of areas of business, showing themselves to be an effective means of analyzing, designing and displaying business processes (by the way, it is also actively used in domestic government agencies, for example, in the State Tax Inspectorate). Moreover, the widespread use of IDEF (and the previous SADT methodology) is responsible for the emergence of the basic ideas of the now popular concept of “Business Process Reengineering” (BPR).

The information process is a sustainable process (a sequence of works and actions with data and information) related to the support of the production and economic activities of a company and usually focused on information services for creating new value. A business process includes a hierarchy of interrelated functional activities that implement one (or several) business goals of the company and reflect the results in the information system, for example, information support for the management and analysis of product output or resource support for product output (products here mean goods, services , decisions, documents).

Working with the IDEF method begins with setting a modeling goal. World experience shows that errors in goal setting lead to an average of 50% failures in the modeling process. Formulating a goal initially directs work in a given direction, and therefore limits the range of questions for analysis. Practical work begins with defining the context (Context, Context Diagram), that is, the top level of the system, in our case, the enterprise. After formulating the goal, it is necessary to outline the modeling area (Scope), which will subsequently determine the general directions of movement and the depth of detail (Decomposition). Actually, the IDEF methodology itself defines standardized objects for operation and display. For example, these include a function (Activity), an interface arc (Arrow), a note (Note), as well as the method of their location and interpretation (Semantics).

Recently, the Business Studio software product has appeared on the Russian market, which is specially created to work with IDEF methods and has an intuitive and friendly interface (User-friendly Interface).

The IDEF0 notation and methodology is based on the concept of a “block,” that is, a rectangle that expresses a certain business function (Figure 4.10). In accordance with the standard, a function must be expressed by a verb phrase. In IDEF0, the roles of the sides of the rectangle (functional meanings) are different: the top side has the meaning “control”, the left side means “input”, the right side means “output”, the bottom side means “execution mechanism”.

The second element of the methodology and notation is the “flow”, called the “interface arc” in the standard. This is an element that describes data, informal control, or anything else that influences the function depicted by the block. Streams are indicated by a noun phrase.

Depending on which side of the block the flow is directed to, it is, accordingly, called “input”, “output”, “control”. The figurative element representing flow is an arrow. A stream can be interpreted as a representation of an object, which refers to both an information object and an actual physical object.

An important factor is that the “source” and “destination” of flows (that is, the beginning and end of the arrow) can, as a rule, only be blocks. In this case, only the output side of the block can be the source, and any of the remaining three can be the receiver. If it is necessary to emphasize the external nature of the flow, then the “tunneling” method can be used - hiding or appearing the interface arc from the “tunnel”.

And finally, the “third pillar” of the IDEF0 methodology is the principle of functional decomposition of blocks, which is a model interpretation of the practical situation that any action (especially something as complex as a business process) can be broken down (decomposed) into simpler operations ( actions, business functions). Or, in other words, an action can be represented as a set of elementary functions.

An example of a functional model of the process of shipment and delivery of products is shown in Fig. 4.11.

The degree of formalization of the description of business processes may vary depending on the tasks being solved. A specialized language BPEL (Business Process Execution Language) has been developed to describe information processes. BPEL is based on XML to formally describe business processes and protocols for their interaction with each other. BPEL extends the Web services interaction model to include transaction support.

Currently, the BPMS (Business Process Management System) methodology is actively developing - a class of software for managing business processes and administrative regulations. (The terms BPM system and simply BPM are also used). Using BPMS allows you to organize effective interaction between managers and IT specialists, make better use of existing subsystems and speed up the development of new ones.

The main functions of BPMS are modeling, execution and monitoring of business processes. Based on monitoring data, enterprises identify bottlenecks and improve their business processes. The management cycle is closed when, with the help of BPMS, changed business processes are quickly put into operation.

Modern methods of designing and developing IS software are trying to fully focus on the possibilities of automated, operational changes. The most difficult process turned out to be the standardization of the BPEL language to unify the use of the same constructs by software from different manufacturers. IBM and Microsoft have defined two quite similar languages: WSFL (Web Services Flow Language) and Xlang, respectively.

The growing popularity of BPML and the open movement of BPMS to users led Intalio Inc., IBM and Microsoft to the decision to combine these languages ​​into a new language BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP and Siebel Systems contributed BPEL4WS version 1.1 to OASIS for standardization in the Web Services BPEL Technical Committee. Although BPEL4WS appeared in versions 1.0 and 1.1, the WS-BPEL OASIS technical committee voted on September 14, 2004 to call the specification WS-BPEL 2.0. This change was made to align BPEL with other Web services standards that, based on the Naming Convention, begin with the letters "WS-".

Active Endpoints Corporation, Adobe, BEA, IBM, Oracle and SAP published consensus specifications BPEL4 People and WS-HumanTask, which described how the interaction of processes with people could be implemented in the system and BPEL notations. It is expected that semantics will be added to BPEL in the form of WS-HumanTask and various other additions.

4.4. Providing the process of analysis and design of IP with the capabilities of CASE technologies

The term CASE (Computer Aided Software/System Engineering) is currently used in a very broad sense. The original meaning of the term CASE, limited to issues of automation of the development of software only, has now acquired a new meaning, covering the process of developing complex IS as a whole.

Now the term CASE tools refers to software tools that support the processes of creating and maintaining IS, including analysis and formulation of requirements, design of application software (applications) and databases, code generation, testing, documentation, quality assurance, configuration management and project management, as well as other processes. Thus, modern CASE tools, together with system software and technical support, form a complete IS development environment.

The emergence of CASE technology and CASE tools was preceded by research in the field of programming methodology. Programming has acquired the features of a systems approach with the development and implementation of high-level languages, methods of structured and modular programming, visual modeling and design tools based on the UML (Unified Modeling Language), tools for their support, formal and informal languages ​​for describing system requirements and specifications, etc. d. In addition, the emergence of CASE technology was facilitated by such factors as:

• training analysts and programmers receptive to the concepts of modular and structured programming;
• widespread adoption and constant growth in computer performance, which made it possible to use efficient graphics tools and automate most design stages;
• the introduction of network technology, which made it possible to combine the efforts of individual performers into a single design process through the use of a shared database containing the necessary information about the project.

CASE technology is an IS design methodology, as well as a set of tools that allow you to visually model a subject area, analyze this model at all stages of IS development and maintenance, and develop applications in accordance with the information needs of users. Most existing CASE tools are based on methodologies of structural (mostly) or object-oriented analysis and design, using specifications in the form of diagrams or texts to describe external requirements, connections between system models, system behavior dynamics and software architecture [Vendrov A. M. ,www.citforum. ru/database/case/index.shtml].

CASE tools allow you to create not only a product that is practically ready for use, but also ensure the “correct” process of its development. The main goal of the technology is to separate software design from its coding, assembly, testing and to “hide” as much as possible from future users all the details of software development and operation. At the same time, the designer’s work efficiency is significantly increased: development time is reduced, the number of software errors is reduced, and software modules can be used in future developments.

Most CASE tools are based on the methodology/method/notation/structure/tool ​​paradigm.

The methodology sets guidelines for evaluating and selecting a software development project, stages and sequence of work, and rules for applying certain methods.

Method - a systematic procedure or technology for generating descriptions of software components (for example, descriptions of flows and data structures).

Notations are intended to describe the system as a whole, its elements: graphs, diagrams, tables, block diagrams, algorithms, formal languages ​​and programming languages.

Structures are a means for implementing structural analysis and constructing the structure of a specific system.

Tools - technological and software tools to support and enhance methods.

CASE technologies have the following main advantages, which allow them to be widely used in the development of information systems:

• accelerate the process of collective design and development;
• allow you to create a prototype of an ordered system with specified properties in a short time;
• free the developer from routine work, leaving time for creativity;
• ensure the efficiency and quality of developed software by automating control of the entire development process;
• support the maintenance and development of the system at a high level.

It should be noted that, despite all the potential capabilities of CASE tools, there are many examples of their unsuccessful implementation, as a result of which CASE tools become “shelf” software.

In this regard, the following must be taken into account:

• CASE-remedies do not necessarily give an immediate effect; it can only be obtained after some time;
• the real costs of implementing CASE tools usually far exceed the costs of purchasing them;
• CASE tools provide opportunities for significant benefits only after successful implementation, effective user training, and regular use.

You can also list the following factors that make it difficult to determine the possible effect of using CASE tools:

• a wide variety of quality and capabilities of CASE tools;
• relatively short time of using CASE tools in various organizations and lack of experience in their use;
• wide variety in implementation practices of different organizations;
• lack of detailed metrics and data for already completed and ongoing projects;
• wide range of subject areas of projects;
• varying degrees of integration of CASE tools in different projects.

Some analysts believe that the real benefits of using some types of CASE tools can only be realized after one or two years of experience. Others believe that the impact may actually occur during the operational phase of the IS life cycle, when technological improvements can lead to lower operating costs.

Listed below are the main types and sequence of work recommended when constructing logical models of a subject area within the framework of the CASE technology for analyzing an enterprise management system.

1. Conducting a functional and information survey of the management system (administrative and managerial activities) of the enterprise (Fig. 4.2):
   • determination of the organizational structure of the enterprise;
   • determination of the functional structure of the enterprise;
   • determination of the list of target functions of structural elements (divisions and officials);
   • determining the scope and order of inspection of the structural elements of the control system in accordance with the formulated target functions;
   • inspection of the activities of the selected structural elements;
   • construction of an FD diagram of a control system indicating structural elements and functions, the implementation of which will be modeled at the DFD level.
2. Development of models of activity of structural elements and the management system as a whole:
   • identifying a variety of external objects that have a significant impact on the activity of a structural element;
   • specification of input and output information flows;
   • identification of the main processes that determine the activity of the structural element and ensure the implementation of its target functions;
   • specification of information flows between the main processes of activity, clarification of connections between processes and external objects;
   • assessment of volumes, intensity and other necessary characteristics of information flows;
   • development of a hierarchy of data flow diagrams that form a functional model of the activity of a structural element;
   • combining DFD models of structural elements into a single model of an enterprise management system.
3. Development of information models of structural elements and a model of the information space of the control system:
   • defining model entities and their attributes;
   • conducting attribute analysis and optimization of entities;
   • identifying relationships between entities and defining types of relationships;
   • analysis and optimization of the information model;
   • combining information models into a single model of the information space.
4. Development of proposals for automation of the enterprise management system:
   • defining the boundaries of automation - compiling a list of automated structural elements, dividing the processes of the main activity into automatic, automated and manual;
   • compiling a list of subsystems and logical workstations (automated workstations), determining ways of their interaction;
   • development of proposals for the order of design and implementation of subsystems and individual logical workstations included in the IS;
   • development of requirements for basic technical support of information systems;
   • development of requirements for basic IS software.

A logical model that reflects the activities of the enterprise management system and the information space in which this activity takes place represents a “snapshot” of the state of affairs (functional structure, roles of officials, interaction of departments, accepted technologies for processing management information, automated and non-automated processes, etc. .) at the time of the examination. This model allows you to understand what the enterprise does and how it functions from the standpoint of system analysis, and to formulate proposals for improving the situation.

The development of a logical model of the subject area, its consistent transformation into a model of the target IS, will allow for the integration of promising proposals from management and leading employees of the enterprise, experts and system analysts, and to form a vision of the new, reorganized and automated activity of the enterprise (Fig. 4.12).

The constructed model is a complete result for the following reasons.

1. It includes a model of the existing manual technology adopted by the enterprise. A formal analysis of this model allows us to identify bottlenecks in enterprise management and formulate recommendations for its improvement (regardless of whether further development of an automated system is planned or not).
2. It is independent and separable from specific developers, does not require maintenance and can be painlessly transferred to others. Moreover, if for some reason the enterprise is not ready to implement the project at a given time, the model can be “put on the shelf” until the need for it arises.
3. It allows for effective training of new employees in specific areas of the enterprise’s activities, since the relevant technologies are contained in the model.
4. With its help, it is possible to carry out preliminary modeling of promising areas of activity of the enterprise in order to identify new data flows, interacting processes and structural elements.
5. It ensures the dissemination of accumulated experience at other enterprises and makes it possible to unify the administrative, managerial and financial activities of these enterprises.

The model is not just the implementation of the initial stages of work and the basis for the formation of technical specifications for its subsequent stages. It represents an independent result that is of great practical importance, since it allows the further use of CASE technologies for the actual design and development of IS.

The most powerful of these software packages is the Rational Rose (RR) package from IBM-Rational, with which you can design and support the entire life cycle of software product development (Fig. 4.15 Fig. 4.16. Maintenance of the life cycle of a software product with RR

4.5. Implementation of information systems

The implementation of corporate IP, developed independently or purchased from a supplier, is often accompanied by disruption (redesign) of existing business processes at the enterprise. We have to rebuild them to meet the requirements of the standards and the logic of the system being implemented. Let us note right away that the introduction of information systems solves a number of managerial and technical problems, but gives rise to problems associated with the human factor.

The implementation of an information system, as a rule, greatly facilitates the management of enterprise activities, optimizes internal and external information flows, and eliminates bottlenecks in management. However, after the system has been successfully installed, “tested” in operation and shown to be effective, some employees show reluctance to use the IS in their work. As a result of the reengineering, it becomes clear that some employees largely duplicate the work of others or are not needed at all. In addition, the implementation of CIS is accompanied by mandatory training, but, as Russian experience shows, there are not many people willing to retrain. Breaking old skills and instilling new ones is a long and difficult process!

It must be clearly understood that corporate IP is designed to simplify the management of an organization, improve processes, strengthen control and thereby provide competitive benefits. Only from this point of view can the benefits of its implementation be assessed.

Following this logic, it becomes clear that although corporate IS is generally intended to provide all users with the necessary information, management of the development and implementation of CIS is the prerogative of the company's top management! Do leaders understand this?

Here, too, we have to fight persistent stereotypes. “Why do I need a corporate system if things at the enterprise are already going well?” “Why break something if everything works?” But most often there is no need to break it. At the first stage, you only need to competently and correctly formalize and transfer the identified processes within which the enterprise lives into corporate IS. Such formalization will only sharpen and refine successful marketing and production ideas, optimize the management and control process and allow for targeted changes in the future.

The introduction of a new IS is a complex process, lasting from several months for small IS to several years for the IS of large distributed companies with a wide range of products and a large number of suppliers. The success of a project for the development (acquisition) and implementation of IP largely depends on the readiness of the enterprise to conduct the project, the personal interest and will of management, a realistic program of action, the availability of resources, trained personnel, and the ability to overcome resistance at all levels of the established organization.

By now, a standard set of techniques for introducing information systems has emerged. The basic rule is to complete the required phases sequentially and not skip any of them.

The following factors are critical to implementation:

• the presence of clearly defined project goals and IP requirements;
• availability of a strategy for the implementation and use of IP;
• conducting a pre-project survey of the enterprise and constructing “As is” and “As will be” models;
• planning work, resources and monitoring the implementation of the implementation plan;
• participation of senior management in the implementation of the system;
• carrying out work on IS implementation by systems integration specialists together with enterprise specialists;
• regular monitoring of the quality of work performed;
• quickly obtaining positive results at least in part of the implemented IS modules or during its trial operation.

Before starting to develop an implementation project, you must:

• formalize the goals of the IS implementation project as much as possible;
• estimate the minimum necessary costs and expense items;
• set a high priority for the implementation project over other ongoing projects;
• give the project manager the maximum possible powers;
• carry out mass educational work with the personnel of the enterprise in order to convey to everyone the importance and necessity of the upcoming transformations;
• develop organizational measures for the use of new information technologies;
• distribute personal responsibility across all stages of implementation and trial operation.

It is also necessary to determine the functional areas of implementation of information system modules:

• organizational management;
• organizational and administrative support;
• business process management;
• management, planning, financial and accounting;
• personnel Management;
• document management;
• logistics management;
• management of relations with clients and the external environment.

In addition to what is listed above, it is necessary to set technological requirements for the implementation of IS:

• system platform: implementation and adaptation of a ready-made solution from the manufacturer or custom development in accordance with the customer’s technical specifications.
• integrability: data is stored and processed in a single information space - this ensures their completeness, consistency, reliability and reusability; the system may include newly developed and already used technologies and applications.
• adaptability: the system is configured in accordance with customer requirements and the characteristics of the customer’s information field.
• distributed: the system can function effectively in geographically remote divisions and branches of the enterprise.
• scalability: the system can be implemented in the form of a frame containing basic modules and expanded in accordance with the requirements of a changing external and internal environment.

Main phases of information system implementation

Phase "Preliminary work on the preparation of the IS implementation project." During the pre-project survey of the enterprise (Fig. 4.1.4), detailed information is collected about the structural structure of the organization, functional relationships, management system, main business processes, flows within the enterprise (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), necessary for building appropriate models and selecting objects for automation. The timing, resources, types and volumes of work, the range and cost of software, hardware and telecommunications, the cost of personnel training, etc. are assessed.

Phase "Project preparation". After completion of the first phase, preliminary planning and formation of project launch procedures are carried out:

• formation of project and expert groups;
• distribution of powers and responsibilities;
• determination of organizational and technical requirements for the implementation process;
• clarifying customer specifications and expectations;
• training of the implementation group consisting of specialists from the customer enterprise.

For some reason, the last very important point is often missed when drawing up an implementation plan. But the success of the entire project greatly depends on it! After the start of financing, the project is considered to be launched.

Phase "Conceptual development of the project". During this phase:

• a conceptual project is formed and approved;
• a mandatory unambiguous understanding of the intentions of all project participants regarding the implemented IS is achieved;
• the goals and objectives of the project are clarified and specified;
• the dimensions of the system prototype are determined;
• the enlarged work plan, the sequence of stages and conditions of trial operation, planning, financial and reporting indicators are agreed upon.

Moreover, all these actions must be documented, agreed upon and approved by all interested and responsible parties.

Phase "Project Implementation". During the main implementation work, the system environment is created, installed and configured, system administration procedures are determined, and basic hardware and software systems and applications are installed. The system configures the organizational, staffing and organizational-functional structures of the enterprise using such organizational units as a branch, department, division, work group, etc.

Systematic security issues of system operation in multi-user mode are being worked out. Applications, templates, reports, client access forms are created, and user powers are distributed. All systems are being tested in "combat mode" with the participation of all interested parties. After the implementation phase ends, the implementation project is considered complete. The information system is put into operation.

Vladimir Malzam Business analyst

The role of analysis methods in process management

In the field of business process analysis, it is widely believed that many new, more effective management approaches have emerged in recent years. It would be more correct to say that technical tools are appearing that expand the boundaries of applicability of methods discovered decades ago, but which had a narrow application due to the complexity of their information technology support.

Process control was first mentioned by Henri Fayol in his book General and Industrial Management, published in 1916. It systematized solutions that made it possible to turn a mining and metallurgical company into an industry leader, which was on the verge of bankruptcy at the time of his arrival at the company. At that time there were also researchers who narrowly specialized in operational management, statistical approach and other aspects of management.

In the second half of the twentieth century, a bias towards aggressive marketing became relevant. Fundamental scientific works were split into fragments that were not self-sufficient, wrapped in marketing packaging, declared to be the latest achievements of scientific thought, and sold as a commercial product. As a result, the professional level of management began to be limited to knowledge of their subject area and personal experience. The path to using scientific and economic developments was blocked by information noise. To simplify the sale of products, the same noise management was disoriented in choosing solutions offered by consulting companies.

After studying many books, articles, varying degrees of information noise, and gaining practice, a universal structure of the process management system was formed. It does not contradict either business practice or theoretical trends. This is the “skeleton” into which any operational activity fits. At the same time, within its framework it is possible to use those scientific and economic developments that are relevant for the specific specifics of business.

The opposition of fragmented approaches is the main problem of modern business analytics, which often turns it from a normal professional activity into a planned unprofitable show business. The management system, based on the presented model, allows within the same organization to use different approaches for different processes, without opposing them to each other.

I should note that the presented model is relevant for increasing the efficiency of operational activities, is of limited use in the field of sales and is not applicable for project activities.

A detailed consideration of each type of analysis is worthy of independent articles; within the framework of this one, I will describe only their essence and the tasks they solve.

Functional Process Analysis

Target: assessing how efficiently existing processes are organized, searching for more effective ways to implement them.
Data source: graphical models of business processes.

With paper regulation, models lose relevance after 3-6 months, and analysis usually requires a re-description of processes with a break from the work of performers for interviewing. BPMS systems, due to the logic of their operation, ensure the relevance of process models at any time.

Example: An analysis of the process of selling equipment for trade and services for its registration with the tax office revealed the following. Sales managers simultaneously performed a number of functions:

• Receiving calls from buyers, advising them, agreeing on the content of the transaction and its details;
• Preparation of a package of documents for the transaction;
• Coordinating the work of couriers to deliver documents and goods, accept cash payments and carry out registration actions with tax inspectorates;

A formal violation of the “principle of division of labor” in this case was an appropriate and effective solution. During the period of maximum call flow, the preparation of documents was postponed, and the entire sales department was responsible for receiving calls. When the calls became fewer, the freed-up managers worked on preparing documents to support transactions agreed upon over the phone.

Depending on the range of services, up to 22 documents were prepared for each transaction. In the existing information system, this required 350 mouse clicks and 25 minutes of working time. The development of an information system module that allows the creation of the entire package has reduced labor costs for this operation by 8 times.

In the original form of the process, managers had to postpone the preparation of some documents until the end of the working day, often staying at work until 20:00. Next, the courier delivered the documents to the client for signature and payment. Documents prepared before 17:00 of the current day were delivered to the client the next day. Documents prepared later were delivered “every other day.” With such an organization, from verbal approval of the transaction to its confirmation with the client’s signature and payment, it took 2-3 days.

The improvement of the information system, in addition to reducing the cost of the process, formed the basis for a number of measures that reduced the time from the call to the transaction being signed by the client by 24 times. From 2-3 days to 2-3 hours. This arrangement reduced the risk of the client refusing the verbal agreement and indirectly increased sales.

Plan-factor analysis of indicators

There are processes for which it is impossible to ensure 100% efficiency, for example, selling goods based on incoming calls or collecting regular installments under concluded contracts. Analyzing the causes of unsuccessful outcomes can provide answers to how to improve productivity by reducing the percentage of failures.

Target: identifying factors that negatively affect the effectiveness of the process, searching for options for changing the process in order to smooth out or eliminate the negative impact of these factors.
Data source: in small organizations - a survey of performers, in large organizations - collection and analysis of statistics in the context of reasons for refusal, regions, branches and performers.

Example: The housing and communal services company faced the problem of collecting payments.

The initial task was posed as follows: the accountant for accrual of utilities, benefits and subsidies cannot cope with the volume of work. There are errors in the accruals; the calculation results are stored in paper form. When servicing a queue of payers and controversial situations arise, it is impossible to quickly track and justify the history of the formation of the amount to be paid. This provokes customer suspicions of abuse and conflict situations, leading to payers refusing to repay the debt.

Automation of payments made it possible to eliminate errors in calculations. When communicating with a client, an accountant could track and explain the history of the formation of any figure in 8 seconds. Accrual transparency has brought a number of positive consequences to the work. Conflicts disappeared, but collection rates increased by only 3-5%.

Further, the focus was shifted from optimizing existing processes that produce 80% of collection rates to identifying factors that lead to refusal to pay for the remaining 20%. Plan-factor analysis identified the reasons for refusal to repay debt and made it possible to find solutions to eliminate or smooth out their negative impact:

Factor #1- the payer has a low income and cannot pay the full amount on his own. According to the law, the payer has the right to pay for housing and communal services an amount not exceeding 20% ​​of family income. The difference is subsidized by the state. To exercise the right to a subsidy, the payer must provide an approved package of documents quarterly. The payer often does not know about his right to a subsidy, or does not know how to exercise it.
Solution: do everything to ensure that the payer entitled to the subsidy receives it. Advise on the registration procedure, provide the necessary certificates on your part. Next, demand that you pay the remaining twenty percent yourself.

Factor #2- benefits and subsidies are provided for the amount accrued for the area “within the social norm.” This puts pensioners who have apartments with large square footage at risk. To reduce utility bills, they usually try to minimize the number of “registered” relatives in their apartment, but get the opposite effect - according to the logic of the law, they end up in the status of “living in luxury”, deprive themselves of the right to a subsidy, some benefits and receive services at an increased rate. at 20% tariff. As a result of these actions, the payment amount grows to a level incompatible with life; clients are physically unable to pay it.
Solution: make a selection of information about clients who have “extra” living space. Consult them on the principles of accrual of services and calculation of the optimal number of relatives registered in the apartment, in order to minimize the amount of accrued payments and obtain the right to a subsidy.

Factor #3- the head of one of the departments, responsible for intra-house communications, refuses to fulfill most of the residents’ requests. At the same time, he has such developed “emotional intelligence” that clients simply leave without complaining above. As a sign of protest, they refuse to pay for all services, whether provided or not provided.
Solution: organize the acceptance of applications through the department responsible for collecting payments. It must transfer applications to the executing unit and maintain statistics on payer satisfaction.

The fourth and fifth factors of refusal to pay were also identified; to demonstrate the basic principles, I think the above are sufficient. This example reveals the following features of plan factor analysis:

1. It is impossible to improve efficiency by analyzing the process.

Insufficient effectiveness is usually associated with the absence of some of the necessary actions in the current process. By analyzing a model, it is impossible to identify actions missing from it. It is necessary to focus attention on the gap between the required performance and the actual one, and try to identify the factors causing the formation of this gap. The next step will be to refine the process in order to eliminate or smooth out their negative impact on the result.

2. There are no relationships between negative factors

As can be seen from the examples, the lack of obviousness of legislative norms has no connection with the abuses of one of the managers, despite the fact that they lead to the same result - a decrease in payment collection by several percent. Process analysis develops in the analyst the habit of perceiving the subject of study as an interconnected chain. In design factor analysis, you must be willing to give up this thought pattern.

In large organizations with many branches, it is advisable to replace a personal survey with an organization for collecting statistics. Further analysis will reveal not only the factors that require elimination, but also the performers who have found a way to smooth them out in their work. Identifying such performers, the solutions they have developed, and replicating the solutions to all branches can have a positive impact on the work of the organization as a whole.

Using periodic reports to collect statistics can have a negative impact on data quality. It is difficult for the performer to retain information in memory until the reporting date arrives. The BPMS system allows you to add the required field to the user task interface and make it mandatory to fill it out in case of a negative outcome. The contractor will have to enter the result into the system immediately upon completion of communication with the client.

Structural process analysis

Target: identifying process boundaries, correct identification of inputs and outputs.
Data source: graphical models of business processes described during functional analysis.

Structural analysis reveals two types of errors:

1. Errors in goal setting;
2. Inconsistencies between authority and responsibility;

Errors of this kind can be either unintentional or introduced deliberately. To correct unintentional errors, it is enough to identify them. To neutralize the destructive struggle for influence and privileges, it is necessary to involve senior management in solving this problem.

Regardless of the reasons for their occurrence, these errors lead to incorrect selection of KPIs. Motivation to achieve incorrect KPIs has a number of extremely negative consequences:

• Incorrect KPI strictly motivates managers and performers to multiply process defects and leads to punishment for real improvement. This catastrophically reduces efficiency, process defects are steadily reproduced;
• Conducting a functional analysis loses its meaning - it turns into an endless “struggle with symptoms”;
• Carrying out plan factor analysis either becomes impossible or multiplies the original inefficiency;

About analysis technology

The SADT methodology gives the highest quality results in structural analysis. In this case, the source models require conversion to IDEF0 notation.

It is worth paying attention to the fact that structural analysis requires the analyst to have professional skills that are the opposite of functional ones. In the labor market, most resumes containing a mention of the IDEF0 notation imply knowledge of the notation, but ignorance of the methodology, which is fundamentally important for structural analysis. This situation is due to a misunderstanding of its role in process management and attempts by analysts to use this notation for other purposes - for functional analysis - with a naturally disastrous result.

With a clear understanding of the goals and a serious attitude towards the methodology, any analyst can master it in 2-4 weeks. Mastery means not only knowledge of notation and methodology, but the practical consolidation of thinking patterns that are the mirror opposite of functional analysis.

Example No. 1

On one of the projects, the task was set to increase the performance of the sales department. Initially, this department was assigned the “sales volume” KPI, which at first glance is logical. A strict motivation system was also focused on sales volume - there was no salary part of the salary, only a percentage of sales.

The original KPI “sales volume” dictated a vague way of achieving it - “work harder and better.” It was impossible to apply design factor analysis to such a goal. Replacing the KPI with “percentage of requests completed with transactions” opened a plan-factor cross-section - “what influenced clients’ refusal of a transaction.” Further, a plan-factor analysis identified 12 factors (!) that increase the risk of a client refusing a transaction. Changes were made to the process, eliminating the very possibility of manifestation of many factors and significantly smoothing out the negative effects of the remaining ones.

Related departments responsible for attracting clients stopped depending on the emotional assessment of the manager and received a measurable benchmark for improving their work - the number of incoming calls from potential clients.

It is worth noting that the rigidity of the motivation system is an independent factor. It must be selected by the manager for each process individually, so that interaction with employees remains constructive.

Excessive motivational pressure to achieve KPIs can lead to negative selection of employees and the destruction of work ethics in the team. Responsible employees who do not want to mislead managers will either be forced out of their jobs or will accept the rules of the game to the detriment of the interests of the organization.

Example No. 2

The central office took measures to improve the efficiency of maintenance of the payment terminal network. For technical specialists, a KPI was chosen - the number of visits for maintenance and repair. Further, a strict standard and a steep proportion of bonus reductions have been assigned.

Subsequently, it was revealed that 80% of trips involve restarting GPRS modems to restore communication with the Internet. Periodic interruption of GPRS sessions is due to the peculiarities of this technology. To restore communication, the terminals are equipped with special devices - watchdog timers, which work correctly only in conjunction with the appropriate software. This software was not included in the images recorded on the terminals' hard drives. Attempts at high-quality repairs required more time for readjustment, led to the failure of the “plan for the number of repairs” and a serious deduction in bonuses.

If “downtime of terminals in a faulty state” had been chosen as an efficiency indicator, technicians were motivated to minimize this indicator, and the rigidity of the motivation system was reasonable - the cost of network maintenance would be reduced by 5 times, with a fivefold increase in the quality of its work (reducing downtime in repair).

Decomposition of strategy into target indicators

The essence of managing an organization is to link the content of activities with changing external conditions:

• interests of owners;
• financial market;
• customer needs;
• competitive environment;
• legislation;
• current technologies, etc.

The essence of process management is to reconfigure them to achieve KPIs that realize the strategic goals and interests of the organization. Process management may imply both achieving indicators for existing KPIs and reorienting the content of processes to other KPIs. Targets for process management are formed by decomposing strategic goals.

Data source: strategic goals of the organization and types of performance indicators identified during the structural analysis of processes.

Purpose of decomposition: to focus the attention of managers and performers on indicators that realize the strategic goals of the organization and organize a system for their control.

A simple example of such a decomposition is a sales plan, detailed at the levels of departments, branches and all subsequent levels, up to the final seller. The sales plan is only a fragment of the target management system. A full-format system simultaneously contains both financial (budgeting) and non-financial indicators. Non-financial indicators also require decomposition at each level, down to the final performer. Until goals are detailed down the hierarchy, there are no benchmarks for improving performance.

Decomposition of strategy is the competence of management; the role of the analyst is auxiliary.

In practice, with paper-based regulation, decomposition of non-financial indicators is usually not used, since it is impossible to organize a high-quality and inexpensive control mechanism. The cost of such a mechanism, when using paper regulations, is guaranteed to exceed the potential benefit, and without control and plan-factor analysis, the system is unable to work. An analogy can be drawn with a sales plan - if you develop a plan and are not interested in actual results, the plan will turn into a collection of good wishes.

An attempt to collect indicators using classical automation methods is not flexible enough - projects that last for months and years catastrophically constrain management activities. Information systems of the BPMS class fundamentally solve this problem - the collection of indicators is built into their basic functionality; it is enough to indicate control points in the model and prescribe calculation algorithms.

Overview of classic management tools and BI systems

The influence of the quality of management tools on the effectiveness of analysis methods

In the practice of organizations, an approach based on identifying the key process and selecting an individual management concept for its specifics has become established.

• Mechanical engineering companies have developed the “Lean” concept by deeply studying the principles of functional analysis. Its goal is to eliminate, in extremely long production chains, unproductive costs and excessive freezing of working capital in work in progress (interoperational backlogs).
• Electronics manufacturers have developed the concept of "Six Sigma", based on a subtype of plan factor analysis - statistical. Its goal is to reduce the percentage of defects through a comprehensive selection of technological process parameters.
• Companies specializing in the sale of services typically use budgeting as a basic management system.

In most cases, support processes are fundamentally different from core processes, so applying basic concepts to them is useless or destructive. In current practice, auxiliary processes remain in a weakly controlled state.

What is the reason for this situation?

The selection of a management concept involves a decomposition of goals and the practical use of analysis methods. But analysis only allows us to find a solution. The implementation of solutions in medium and large organizations involves coordinating the work of a large number of performers.

System management tools – regulation, automation or BPMS systems – allow you to avoid chaos in this situation. Their use is associated with costs, both for organizing processes and ensuring their control. Often these costs exceed the predicted economic benefit. It is the costs of classical tools that make integrated process management objectively irrational and limit the scope of their use to key processes of the organization.

What risks does it bring?

Weak control of auxiliary processes opens up scope for abuse. Units that do not have correct and measurable goals are left to their own devices. Some of them focus on the absence of complaints from subcontractors. Some use lack of control as a basis for building a hidden system of abuse. As a result, the efficiency of such a unit is reduced by hundreds and thousands of percent. And the efficiency of adjacent departments decreases by 30-60%.

In recent years, the level of maturity of some BPMS systems has become sufficient to eliminate these risks and organize, based on them, an integrated management system. Using a BPMS allows you to significantly reduce the costs of administering and controlling processes, both key and auxiliary.

At the same time, BPMS also has its limitations. The use of this system requires a balanced approach to the redistribution of management decisions between different tools for their implementation. To balance the instrumental system, it is necessary to clearly understand the essence, advantages and disadvantages of each of them.

Regulation

Since most activities are carried out by employees, the basic management tool is based on the provisions of labor laws. Regulation is a legal tool for managing processes.

The work of legal instruments is based on the following logic:

1. An employment contract is concluded with the employee, in which he voluntarily assumes obligations to carry out the orders of his immediate supervisor and obey the company’s rules;
2. The manager's orders (management acts) are drawn up in a format that has legal force;
3. The employee gets acquainted with the orders and carries them out;
4. The manager controls the execution;
5. If the order was not carried out in the form prescribed by the management act, it means that the employee violated his obligations under the contract. In this situation, the Labor Code of the Russian Federation gives the employer the right to apply disciplinary punishment, up to and including dismissal;

To give legal force to management acts, it is usually sufficient to supplement the content with the name “Order”, the date and the signature of the manager. The content may be included in the annex to the order without losing its legal force.

In the form of orders, both management acts are approved, valid until they are executed, and instructions with regulations, valid until they are canceled by another order. Instructions describe actions performed by one worker. The regulations describe the interaction of several workers during the execution of the process. Often, employees involved in the execution of the process belong to different departments and are subordinate to different managers.

The management system is formed in the form of a set of regulations and instructions - normative and administrative documentation (NRD). The NSD is the “internal legislation” of an organization, detailing the requirements for employees specified in employment contracts. Its purpose is to provide managers with a system management tool. Change the approach to management, from developing situational orders, to improving the system of principles for implementing the functions for which the manager is responsible.

The shortcomings of regulation are divided into two categories: “typical” - amenable to elimination, and “systemic”, which cannot be eliminated within the framework of legal management principles.

Typical disadvantages of regulation

1. Competency requirements The use of legal instruments requires an understanding of the principles of their operation by all parties, including performers. Universities teach such knowledge to students studying in the specialty “Organization Management”. In managerial positions, as a rule, it is not graduates of abstract management departments who perform better, but managers with specialized education in the field they manage. This provokes an attitude towards regulation as an end in itself; the use of NSD often degenerates from system design into a purposeless ritual routine.
   If the preparation of the regulations is not carried out by the manager, but by a dedicated specialist, even if he understands the essence of his activity, he is still afraid of a negative assessment by higher management of the degree of pseudoscientificity of his work. Such concerns may be imaginary or well-founded, the result will be the same - the document will deliberately be prepared in an unreadable, clerical style, with the aim not to ensure the efficiency of the process, but to obtain the signature of the director.
2. Uncritical to errors The legal instrument is not critical to errors; the performer always has the opportunity to ignore an incorrect requirement and perform the task “according to the situation.” This is another factor that does not motivate the developer to develop high-quality regulations. Defects in development can reduce the effectiveness of activities to any extent, no one will ever know about it. Only those errors that provoke serious conflicts between participants in the process will be identified.
3. Lack of feedback from performers The ease of circumventing the requirements of the regulations and the formal risk of punishment motivate the contractor to suppress information about the loss of relevance of the regulations. As a result, the “management tool” turns into a “catch-up documentation tool” - it does not solve any problems and is supported on the basis of the principle “this is the way it is, everyone does it this way.” With the loss of relevance, the NSD system turns either into a library of non-binding waste paper, or into a factor causing destructive psychological pressure on responsible and effective performers, due to potential liability for forced violations.

All "typical" deficiencies relate to maintaining the quality of management documentation. With a competent approach to organizing the NSD system, they can be eliminated or smoothed out.

Systemic lack of regulation

There is only one systemic drawback of regulation - the problem of control. It is possible to measure the final result relatively qualitatively, but it is almost impossible to control whether all the requirements of the regulations were observed.

Fulfillment of requirements can be achieved by coordinating them with the internal and external motivation of the employee, which turns this task into solving an equation with many variables, requires training costs and does not guarantee against unintentional errors. It is also possible to organize external control, but it only works for those requirements, the violation of which gives rise to conflict situations or catastrophic consequences. If the requirements are aimed at increasing the efficiency of the process, control will cost more than the benefits of compliance with them, or will be physically impossible to implement.

Regulations do a satisfactory job of managing risks, but are of little use for managing the efficiency and effectiveness of processes. Its main advantage is its versatility. Even with all its shortcomings, it is applicable to any aspect of activity. Its use is advisable for those requirements for employees whose administration with more efficient tools is not feasible due to technical limitations.

Automation

Often a number of process actions can be removed from the employee’s area of ​​responsibility. In the service sector, automation has proven itself well for these purposes. Automated fragments are executed instantly, cheaply and do not require a control system.

Automation has two disadvantages:

1. Strict restrictions on the scope of operations - only processing, transmission and storage of digitized information is possible. In the vast majority of cases, it is possible to automate only certain fragments of the process. The remaining operations are performed by employees in accordance with regulations and instructions. Fragmented automation can significantly increase labor productivity, but is not capable of providing end-to-end management and control.
2. High development cost, as well as duration, unacceptable for process management tasks. It is advisable to use classical programming languages ​​focused on the development of replicable software only for fragments of processes whose operating logic has not changed for years. This further narrows the scope of application of classical information systems.

BPMS class information systems are designed to combine automation, electronic regulation and end-to-end control of process execution.

BI systems (digression)

Before describing the third type of tools (BPMS), I will expand on the term BI, since in the future I will have to use it.

The abbreviation BI stands for "business intelligence". When the term was coined, it was assumed that the main advantage of this tool would be “data mining” – “artificial intelligence” algorithms capable of finding non-obvious patterns in company data that are useful for business management. Subsequently, manufacturers of BI systems were unable to develop truly useful algorithms and “business intelligence” became a marketing label behind which stands the next generation of OLAP systems.

The BI system is a combination of:

• Separate database;
• Tools for analyzing a multidimensional data array and visually displaying the results;
• Integration tools for loading source data from external systems;

Preliminary copying of information into a separate database allows you to:

• Do not overload source information systems (IS) with search queries;
• Simultaneously use, for analysis, data downloaded from functionally different IS;
• Consolidate data from identical systems that use separate database instances. For example, data from regional branches.

As a rule, the system allows the use of several query languages ​​(SQL, MDX, etc.). These languages ​​were developed to be accessible to business users and not require specialized IT education. Typically, requests are drawn up by a specialist who has completed a short-term training course. The involvement of programmers is only required to organize the uploading of data into the analytical database, with a specified frequency. Sometimes this requires modification of the software from which the download is performed.

BI systems allow, without the involvement of IT specialists:

• Perform random search queries and analyze the results in various sections;
• Create periodic reports and automate their distribution to specified users;
• Display query results in the form of dashboards and assign access rights to users (managers);
• Provide access to reports and dashboards via smartphones and tablets;

Examples of management dashboards:

BI systems reveal their advantages in a narrow range of tasks, which is not relevant for every organization. Usually this is inventory management and logistics of large retail chains - pharmacies, grocery stores, bookstores. Their assortment can number tens of thousands of items. If goods have a limited shelf life and analysis requires taking into account the geography of storage locations, analysts have to deal with hundreds of thousands of batches. For such tasks, BI systems are an indispensable tool.

BI tools separated into a separate BI system have nothing to do with process management. Technically, it can be used to monitor indicators, but the need to involve IT specialists with every process adjustment dramatically increases costs and makes process management impractical.

At the same time, integration of BI functionality into BPMS systems is a prerequisite for using them for their intended purpose. This integration allows you to customize the control system without involving IT specialists. Given the iterative nature of process management, this solution reduces management costs by an order of magnitude.

BPMS. Operating principles, advantages and limitations

Information systems of the BPMS class are created to replace most of the regulations, classical information systems (IS) and the collection of management analytics. BPMS stands for "Business Process Management Suite" and in translation means "a set of business process management tools."

BPMS is a fusion of a classical information system and a “Workflow engine” - an “engine” for sending user tasks. The "workflow engine" has a lot in common with email, but there are some differences:

Workflow and E-mail - difference No. 1

Instead of emails, instructions to do something are sent between employees - “User Tasks”.

Screenshot 1 - Workplace of the Contractor

Workflow and E-mail - difference No. 2

The “To” and “From” fields are hidden from the employee; he must complete the Task, enter the result into the interface and confirm it. The interaction logic is fixed at the development stage, in the form of an executable process model. The worker is the initiator of the process, starts it manually, then tasks are sent according to the model.

Screenshot 2 - Process Developer Interface

An executable process model is created in several steps:

1. “Areas of responsibility” are transferred to the model window for each performer with the mouse. In screenshot No. 2 they are displayed in the form of vertical fields with names:
   • "Administrator of the selling division";
   • "Operational support worker";
   • "Underwriter";
2. “Tasks” are placed in areas of responsibility;
3. The order of execution of Tasks is specified by “arrows”;
4. In "gateways" the branching logic is configured;

The gateway in screenshot No. 2 implements the following logic:

• If the risk group of the insured’s profession is fifth or higher, create a task for the underwriter “Calculate and approve the underwriting coefficient”;
• Otherwise, if the risk group is below the fifth, execute the Script Task “Calculate the insurance premium and generate a policy mask”;

Workflow and E-mail - difference No. 3

In email there is one main field in which all the information is placed, in an unstructured form.

In the workflow module, an individual user interface is created for each Task, with a set of different fields, as in a classic information system. The values ​​of each field are stored separately in the database. In the future, they can be used to automate calculations or generate analytics.

A classic information system implements the other extreme - it provides the user with all interface elements at the same time. This requires memorizing instructions that explain, for each task a worker may encounter, which interface elements need to be used and in what order. When an employee makes a mistake, it is often necessary to involve an IT specialist to correct it.

In the workflow module, the employee receives a Task, with an interface configured only for its solution. There are no unnecessary elements. There is no need for training, the risk of error is reduced by orders of magnitude.

If necessary, instructions for its execution can be placed in the Task interface, freeing the employee from the need to remember them.

Typically the interface contains:

• fields with the initial conditions of the Task;
• instructions for completing the Task, if necessary;
• input fields for the execution result.

The Task interface is created in two stages

First stage: in tabular form, a “list of data” is prepared that will have to be operated in the process;

Screenshot 3 - Tabular registration of process data types

Second phase: the developer opens the properties of each Task and drags the necessary fields from the “data list” onto the user interface layout with the mouse.

Screenshot 4 - Transferring fields from the data list to the Tasks interface layout

When executing a process instance, the employee must complete the received order, enter the result into the interface and confirm it with the exit button. Next, according to the process model, the system will generate a new order for the next employee. This ensures the interaction of performers within the process and the collection of information about its progress.

Other BPMS components

In addition to the workflow module, BPMS includes standard features of a classic information system:

1. Automation of mathematical and logical calculations;
2. Generating reports and management dashboards;
3. Preparing forms for printing;
4. Some BPMS contain modules for integration with external systems: IP telephony, 1C accounting, corporate website, SMS information services, etc.

To automate calculations, a Task of the “script” type is placed in the process model, and a processing algorithm is entered into its properties. In screenshot No. 2 you can see the following Task with the name “Calculate the insurance premium and create a policy mask”. Systems from different manufacturers use different script programming languages ​​- C# (CSharp), Java or JavaScript.

To generate reports and management dashboards, the system has built-in BI tools. It differs from independent BI systems in the absence of a separate analytical database. This solution allows you to refuse to involve IT specialists when adjusting processes and their control systems.

As a result, the development of executable processes contains six stages:

1. Create a process model;
2. Create a list of data;
3. Create an individual user interface for each Task;
4. Configure gateway logic;
5. Write automation scripts;
6. If necessary, ensure integration with external systems (if there is no ready-made integration module, the involvement of an IT specialist will be required);
7. Link user accounts to roles in the process;

All these actions, except for complex scripts, are performed by the business user using drag-and-drop methods or filling out configuration tables.

Benefits of BPMS

The implementation of BPMS allows you to solve the following problems:

1. Reduce the cost and duration of software development by 10-30 times Development of a process application takes 5-30 days, adjustment (process management act) - from 10 minutes to 4 days. 90% of labor costs are implemented by a trained business user, without the involvement of IT specialists.
   The development is organized on the principle of dragging objects with the mouse and filling out tables. A business user can create a better product by focusing on solving organizational problems, instead of “fighting technical difficulties” caused by the excessive complexity of classical programming languages;
2. Reduce the duration of implementation of current versions of the process to several minutes Deep changes in the company, through regulation, take 1-2 months, with many unintentional mistakes made by workers and their correction during the adaptation period. Minor changes made to regulations are often ignored by employees.
   The process in BPMS is “published to the server” in hot mode and does not require the suspension of executors. Immediately after “publication” all branches begin to work according to the new version.
3. Reduce time costs for employee retraining significantly The system allows you to avoid memorizing a large part of the documentation. When changes are made to the process, in most cases, performers will not even need to be notified about it. The interaction logic is administered without their participation. And the content of the Task, if necessary, is written in its interface. The employee can only do what the logic and interface description require of him;
4. Reduce to zero the cost of maintaining up-to-date process models and regulations transferred to the system. Process models are suitable for functional and structural analysis at any time. Eliminates the need to start each iteration of the analysis with a project to re-describe (update) processes.
   Electronic regulations (process applications) are also relevant at any time. It is not technically possible to bypass most of the requirements of electronic regulations. If an employee finds a need for updating, he will have to escalate this problem to management. Within 1-4 days the process will be finalized and the contractor will be able to solve the problem that has arisen.
5. Reduce the cost of monitoring process indicators significantly With paper regulation, many indicators are not recorded, since the cost of its implementation is unreasonably high. This is reflected in the quality of management decisions. In BPMS systems, the time spent on executing Tasks does not require accounting - this function is built into the system. Collecting statistics on deviations from the optimal process flow is also a basic function.
   Integrated BI tools allow, without the involvement of IT specialists, to organize control of any process indicators. The benefit, compared to external BI systems, is that when adjusting a process, adjustments to its control systems are often required. Built-in BI tools require several tens of minutes to configure, instead of several days/weeks typical for reconfiguring integration with external BI systems.

If there is not enough available data to collect analytics, it can be organized by adding the missing fields to the Tasks interfaces and publishing it as a new version of the process. The employee will enter data at the time of its greatest relevance, and not remember it at the end of the month/week when drawing up a report, which also has a positive effect on their quality.

Limitations of BPMS

BPMS show their advantages to the greatest extent if the nature of the activity fits into certain restrictions:

1. The contractor has at his workplace a computer, tablet or smartphone connected to the Internet or the organization’s local network. With the proliferation of smartphones and tablets, this limitation is becoming less and less relevant.
2. Requires coordination of the work of several performers;
3. The nature of the process means that its correct execution guarantees the required result;

An example of “suitable” activities would be the fulfillment of obligations under contracts, in the field of banking and insurance services. In standard contracts, obligations are fixed, this ensures repeatability of processes. At the same time, these processes require the coordinated work of different specialists, often located in different regions.

An example of an "inappropriate" activity, in some cases, would be interaction with customers. Each instance of the process for selecting and selling housing, for example, is accompanied by one agent and does not use the capabilities of the Workflow engine to coordinate the work of different employees.

At the same time, the specifics of working with a client require an order of magnitude greater flexibility from the system than the Workflow engine can provide. The client can change his wishes at any stage, which can lead to a return to any stage that has already been completed. Only CRM can meet the specifics of such processes.

Can BPMS completely replace IT systems?

This is determined by the specifics of the activity. The downside of BPMS functionality is slightly lower performance. There is no guarantee that such systems can withstand the loads typical of large banks. In this case, electronic regulation will be partial, limited by the performance of the system. Insurance and other businesses are much less demanding of this factor.

Can BPMS completely replace administrative documentation?

The use of administrative documentation remains appropriate when it is necessary to link the risk of non-fulfillment of any requirements with the possibility of applying articles of the Labor Code.

The benefits of BPMS are proportional to:

• the share of management documentation that can be replaced by this system;
• the initial share of budget expenses spent on organizing processes suitable for transfer to the BPMS environment, with subsequent optimization;

This explains the demand for BPMS systems in insurance, banking and some other service sectors.

It is worth noting that the market, called BPMS, often offers stripped-down “workflow engines for programmers.” Typically, they do not have built-in BI tools and require, at best, a professional programmer to design processes, and in some cases, an entire team of IT analysts, architects, testers and implementers. Therefore, when choosing a BPMS, you should carefully check the available functionality and the quality of its implementation.

Conclusion

As a result, the set of process management tools will look like this:

When implementing the system, the analyst will be faced with the task of effectively distributing process functions among administration tools, taking into account their advantages and limitations. It is worth noting that the weight of different elements of the system will be disproportionate, this is normal.

1. Specialized IP

This block will contain:

• Services provided by other organizations: Internet acquiring, SMS information, IP telephony, calculation of routes in Yandex maps, etc.
• Partially, the functionality of information systems already used in the organization. That part that is easier to integrate with BPMS than to transfer to script format.

1. Process scripts are information processing algorithms that are not present in old information systems or that are cheaper to re-register than to implement through integration. In the future, as part of process management, it will be easier and faster to adjust them than a bunch of functions of the old system and integration functions with it;
2. Electronic regulations (Workflow)

All rules for employee interaction that are technically possible to transfer are transferred to this block from legal regulations. In order to make violation of most of the requirements technically impossible for the employee. And the envisaged deviations from the optimal course of the process should be made transparent and controllable.

1. Legal regulations

This block will contain requirements that cannot be fixed technically, and violation of which by an employee should be potentially punishable, according to the norms of the Labor Code.

based on Comindware Business Application Platform

A comprehensive low-code business process management system (BPMS): modeling in BPMN 2.0 notation, process automation, case management - a reliable foundation for the digital transformation of an enterprise.

More than modeling and execution

Comindware Business Application Platform provides a complete set of tools for modeling, executing, optimizing an organization's business processes typical of traditional BPM systems, and goes beyond. In addition, the company receives a number of advantages characteristic of iBPMS (Intelligent BPM Suite) class systems and Low-code platforms:

• Convenient online tools for managing business processes. Modeling, execution, process analysis, task management, enterprise process architecture design, BPMS integration with third-party systems.
• Support for creative tasks. BPM solutions based on the platform from Comindware are not focused on business processes like traditional BPMS, leaving room for creative work (cases/instructions).
• Process management in the hands of business people (Low-code). The center of gravity of efforts to develop and further adjust business applications is shifting from programmers to analysts.

The specificity of the implementation of all the main process management tools in the Low-code platform from Comindware and a number of unique advantages for business distinguishes the Comindware Business Application Platform from traditional BPMS.

BPM Toolkit for Management and
optimization of business processes

In-depth digitalization and its spread to the entire business is a necessary condition for the success of modern business. A management technique called BPM (Business Process Management), which includes methodology and software, helps businesses develop in this direction. A business that practices process management techniques is built as a set of end-to-end business processes, which helps eliminate functional barriers in the company and radically increases the efficiency of all departments. Technological support for the BPM methodology is business process management systems (BPMS).

Comindware Business Application Platform includes a full set of business process management tools included in BPMS class software. Each tool included in the Low-code platform from Comindware is implemented taking into account current business requests for flexibility in both the main and auxiliary business processes of the enterprise.

Business Process Modeling

A graphical model of a business process is the main component of business process management and demonstrates the interconnection of all process elements within an organization or holding. This view helps you focus on targeted and meaningful information to solve business process optimization problems.

The Comindware platform provides flexible and convenient tools for modeling business processes even for non-BPM professionals. Moreover, developing forms, adapting interfaces and setting up basic integrations is also done by an analyst in a web browser and does not require programming skills. The business analyst creates a process diagram, identifies the participants, and describes the set and order of their actions. The constructed graphical models comply with BPMN 2.0, the modern world standard for BPM.

Process architecture modeling

The success of a company's process management largely depends on the organization's ability to correctly prioritize process optimization, focusing primarily on key business capabilities. A business capability is a set of processes, people and technologies that create value that are consistent with a company's strategic goals. In other words, business capability refers to the element that describes “what” a company is capable of doing, and business processes, in turn, describe “how” a company realizes its capabilities. The business capabilities model visualizes the entire range of capabilities of a particular business, and the process architecture helps to visualize the interconnection of processes.

Comindware Business Application Platform provides the ability to quickly build a model of business capabilities and process architecture, visualize the relationship between processes, and link them to specific goals. The business capability diagram is updated during optimization, which helps analyze the situation from top to bottom and effectively plan for upcoming changes.

Automation of a business process involves automatically going through its steps and notifying system users about the tasks and actions required of them at the current step of the process. Depending on the selected settings, the business process can be launched manually or automatically according to a schedule, an incoming request, or when a condition is met. With appropriate access rights, the user can receive information about the previous and next steps of the process and visually assess the stage of its completion.

The BPMS functionality of the Comindware platform is based on a process “engine” that:

• Routes requests
• Automates assigning tasks to users
• Calls external systems and services
• Receives requests from external systems
• Collects the necessary data and processes it
• Provides access to data in the context of the running process

The Comindware BPM system ensures the execution of a process of the required complexity and level of decomposition in one system.

Business process monitoring

Monitoring enterprise business processes is one of the BPM tools that helps the responsible person identify bottlenecks in the execution of business processes and respond to critical situations by adjusting the process diagram or employee actions. To successfully solve monitoring problems, it is critical to have effective access to process statistics and the ability to display data in a convenient format.

During the execution of business processes, Comindware Business Application Platform collects detailed statistics on their metrics and indicators. A visual representation of this data simplifies monitoring the execution of processes, identifying optimization and acceleration points. Statistical data is also a source of information for reengineering and optimizing the company’s complex business processes, making management decisions and adjusting the process architecture.

Business Process Optimization

Optimization of business processes involves a wide range of work aimed at increasing the efficiency of the company’s operating activities and improving the quality of implementation of the enterprise’s business capabilities and services. Optimization of business processes, in contrast to reengineering, is carried out on an ongoing basis and, as a rule, covers a fairly narrow area at the level of business capabilities or functions of the organization.

Comindware Business Application Platform helps identify potential optimization opportunities and makes it possible to test hypotheses on real business processes. An informative picture of opportunities for optimization is provided by the process architecture of an enterprise, together with statistical data from monitoring business processes. You can optimize specific processes and link their interactions with each other. To optimize a business process, it is enough to make changes to its graphical model from the browser without interrupting the execution of processes already running in the BPMS.

Task management

An important condition for the painless and successful implementation of a process approach to enterprise management is the provision of simple and convenient task management tools for ordinary company employees, and the Low-code platform from Comindware provides them.

No matter how complex the combination of business processes, projects and cases in the company may be, the employee sees his tasks in a single interface accessible from the browser, or directly in MS Outlook, with the appropriate configuration of out-of-the-box integration. This helps you plan time, set priorities, and manage tasks more effectively. The manager sees the tasks of a specific employee, and he can also get a summary of all processes, projects, cases in which a specific person is involved, even if other departments or divisions are responsible for them.

Integration with third party systems

Switching employees between multiple systems significantly slows down work and often makes it impossible to automate business processes. The task of a BPM system is to create a dedicated layer of process management, which is located above other technologies, integrated with legacy information systems (ERP, CRM, etc.) and allows you to implement end-to-end business processes and eliminate the need to switch between several systems.

Comindware Business Application Platform offers extensive integration with other systems. Integration via the OData protocol is configured with the mouse; for other protocols an open API has been created, based on the Web Services standard. Another integration possibility is through RPA robots.

Support for creative tasks

In the modern world, performers who perform work according to approved regulations are increasingly being replaced by knowledge workers, for whom traditional fixed processes are not suitable. In addition, exceptions often arise in the work of companies/institutions that do not fall within the framework of the described business processes. In these cases, more flexible and dynamic forms of work are needed, which are offered by adaptive case management (Adaptive Case Management). A case is a process that “unfolds over time”: only the first step is planned, and based on its results a decision is made about further ones, in contrast to business processes in which all steps are determined in advance.

Comindware Business Application Platform includes support for cases and provides a single space for both template-based work and creative work planned on the fly.

Case management (ACM)

ACM is a fairly new approach to managing creative problems, the process of solving which is difficult to formalize or does not require regulation. Comindware Business Application Platform was designed and created at the time of active development of the ACM approach, and support for case management was initially included in the basic functionality of the platform. By incorporating support for both cases and business processes into the platform's functionality, these controls seamlessly mix and match with each other. There is no impenetrable barrier between traditional work flows and cases—both business processes and cases generate tasks that are managed in the same way. The only difference is the way tasks appear: in the case of a business process, they are created automatically according to the process diagram; in the case of a case, an authorized employee decides what to do at each stage and to whom to delegate subtasks.

Migration from cases to business processes

Business process management “best practices” work best when they are filtered through the lens of experience—the history of the company itself. Comindware Business Application Platform minimizes the cycle from idea to working business process.

The low-code platform allows you to quickly, in case format, test in real practice various approaches to organizing the process of processing non-standard requests or tasks. The statistics collected during processing will help you choose the best option. Repeated exception handling collects statistics and best practices for handling specific scenarios. This experience can be easily transformed into an organized and executable process by migrating from cases to processes. In addition, cases and business processes are closely connected within the platform. Thus, a case can call a process and vice versa, and all the tasks generated by them are reflected in the end-to-end list of tasks, as well as in the integrated model of business capabilities.

Low-code: business process management in the hands of business people

The main advantage of business automation is the reduction of operating costs. Digital transformation makes it possible to reduce the response time of a business to changes in the real needs of customers, which often does not imply deepening automation, but the formation of new business models. Enterprises are increasingly interested in providing business users with the ability to actively participate in improving business processes and independently create business applications.

Comindware Business Application Platform fully supports the Low-code concept with a minimum of coding and a maximum of visual development. The Comindware platform solves the main problem of digitalization - speeding up the cycle from business need to working business process.

Development from the browser

To ensure the required pace of innovation, many companies are returning to the practice of developing IT solutions in-house, but, of course, at a new level. Now visual rapid development tools are in demand for creating and executing business applications in a single environment, accessible from anywhere on Earth, and the Low-code platform provides such development tools in full.

To get started, just get an account with user, analyst and/or developer rights in the BPM system - no need to install software on your computer. Setting access rights to data, documents, and BPM system functionality, including creating and exporting reports and editing forms, is also carried out in the browser using an online editor.

Update without interruption

During the operation of the system, business objects and business processes develop, become more complex, and acquire new attributes. In traditional BPMSs that use relational databases (DBs), making changes to business processes requires reconfiguring the database by IT specialists, blocking user access to the system while the changes are transferred to the production environment. This approach requires a lot of resources and time and does not provide the necessary speed of changes. Comindware Business Application Platform uses a graph database and provides a different, dynamic approach to making changes to business processes and business application logic.

In the Comindware Low-code platform, any changes can be made frequently and painlessly, without involving programmers or blocking user access to the program. This ensures the ability to quickly respond to constantly changing requirements for business applications implemented in BPMS.

Implementation of a BPM system

BPM systems are created to automate enterprise management and increase the efficiency of its operation. The BPMS structure includes a set of tools for modeling and executing processes, monitoring, analyzing and optimizing business processes. Some systems presented on the BPM market in Russia additionally include modules for form development, social interaction and other tasks.

There are many approaches to implementation and each organization chooses the appropriate one based on the current stage of enterprise development, further development strategy, as well as the class of selected software. Basic approaches to implementing a BPM system based on a Low-code platform:

• Evolutionary. The company acquires licenses for the platform, creates a BPM solution for its tasks, automates business processes, and develops the system using the company’s employees. At the implementation stage, they often order a demo from the vendor with a prototype of a BPM system for further independent evolutionary adaptation to business needs.
• Revolutionary. In order to simplify the project of implementing a BPM system, an organization often hires a BPM expert. He performs a preliminary analysis of the company's processes, trains employees and supervises the organization of work on the implementation of a BPM system and automation.
• Integration. Often, BPMS systems are implemented into an enterprise’s existing IT system. At the same time, a high level of integration of all IT solutions used is a decisive success factor. In this case, it makes sense to use the services of an integrator company from among Comindware partners. Experts will help you get the most out of every tool in your company's IT structure.

Regardless of the chosen implementation approach, further work with the business process management system based on the Comindware Business Application Platform is based on a simple scheme of actions:

• A business analyst, BPM expert or advanced business user creates a prototype of a solution. Programmers are hired only to create a specific part of business logic, data processing, and integration with other systems.

Business process management systems came to Russia from the West. There this class of systems is called BPMS (Business Process Management System) or BPM systems.

The main idea of ​​a business process management system is extremely simple: the business processes of the company in question are modeled using visual diagrams, the descriptions of which are then loaded into a computer system, and the system allows you to track the execution of these processes in the actual practice of the enterprise. The undoubted advantage of this approach is that the customer is guaranteed to receive a system that fully satisfies his needs and can change with the growth of the needs of a particular business.

In order for a business process to become manageable, it is necessary to ensure the routing of tasks in accordance with its logic, as well as control parameters such as the execution time of individual functions, deviations from the standard execution time, and the cost of the process. If a company uses such a tool, then we can talk about creating a full cycle of business process management, within which this process is improved, taking into account the collected statistics.

BPM class systems are the heirs of workflow systems, and the term workflow refers to the management of the flow of work and, through it, the business process.

The BPM systems market is divided into two large segments. The first segment is the market for BPM systems (system-to-system), and these solutions are initially focused on integration between information systems. They are mainly used for internal integration of business processes taking place in information systems.

An example of such integration could be the billing process in a telecommunications company, where many information systems can be used, the functions of which are performed without human intervention, but the systems must be integrated with each other for “end-to-end” automation of this process.

The second segment of the BPM systems market is BPM (person-to-person) systems, which are primarily designed to automate the sequence of work, that is, business processes performed by people.

There are five classes of BPM systems: administrative systems responsible for monitoring orders; tools for organizing teamwork with a main focus on document management, which can be attributed to the functionality of Docflow; BPM components of other systems - internal workflow modules in other systems; BPM systems designed for integration - systems with system-to-system integration functionality; independent BPM systems that allow solving problems of automating business processes performed by people.

In most cases, the use of BPM systems is most effective in those industries where companies initially have a process organization of activities and specificity in the logic of business processes, as well as a high frequency of changes in existing processes. For such companies, BPM systems are the only way to automate processes, since the use of “monolithic” IT solutions or in-house developments, as a rule, leads to the fact that due to emerging changes in business, these solutions quickly cease to meet new requirements.

Its further use significantly depends on the correct choice of a BPMS-class information system. However, today most decisions are made intuitively, which often leads to disappointment with the results of automation. When choosing BPM systems, as a rule, they focus only on external features - the number of installations, brand and cost. At the same time, no special attention is paid to its functionality and technical implementation, which leads to limitations in further work: lack of cross-platform, insufficient scalability, complexity of making changes.

One of the key stages in choosing a BPM system is developing requirements for the system and supplier. As part of this work, the most critical business processes are identified, the IT infrastructure is audited, the boundaries of automation are determined, and requirements are collected from key users of the company. The number of these requirements can vary widely; for example, for large companies it can be about 500, and for small companies about 100.

To make it easier to work with so many requirements, it is necessary to classify them into groups: functional, technical, cost, and supplier. This allows you to apply different standardization, weighing and evaluation methods for each group and achieve the highest quality assessment of the compliance of the BPM system with the needs of the company. It is necessary to pay attention to the following requirements when choosing a BPM system:

a) support for human-to-human tasks and user-friendly interface;

b) support for organizational structure and role groups;

c) the ability to reassign tasks, promptly intervene in the process and handle exceptional situations;

d) the ability to control the process logic from the user’s workstation; ease of use and administration;

e) the presence of graphical tools for developing business process models;

f) supported architectures and standards;

g) performance and scalability; ability to service multiple, long-running and distributed processes;

i) clear configuration interface and the possibility of minimal participation of IT specialists in implementation and support;

j) the ability to provide real-time information on deviations in process indicators;

k) support for service-oriented architecture (SOA - Service Oriented Architecture);

l) the presence of business process templates, on the basis of which new processes can be developed;

m) low total cost of ownership.

By taking these BPM system requirements as a basis and adding your company's specialized requirements, you can gain an understanding of what the BPM system you choose should be. Next, tender participants are determined by collecting information on existing BPM systems.

Currently, there are about 50 large suppliers of BPM systems on the Russian market, and their number is growing from year to year, so it is necessary to systematically approach the process of collecting information.

Information about BPM systems can be obtained by analyzing open sources, on the basis of which a list of systems accepted for consideration is compiled, and then using forms (RFI - Request For Information) a request for information is sent to suppliers. Based on the responses received, an initial analysis of compliance with the requirements takes place, after which tender participants are determined.

Once participants have been identified, a tender is held by drawing up and sending to suppliers a request for commercial proposal (RFP - Request For Proposal), containing a complete list of requirements for the BPM system.

Based on the participants’ responses, commercial proposals are evaluated, and it is also recommended to “try” how these systems will work on real company data. To do this, a test case of a business process is prepared or a “pilot” implementation of a BPM system is carried out on one process.

Experience in implementing projects in Russia has shown that the choice of a BPM system can be made within a month. During this time, you can formulate the necessary and sufficient requirements and, taking them into account, select a BPM system and implementation team.

The reasons for the poor use of BPM systems in company practice are related to several factors, primarily technological limitations. Business processes are dynamic objects, and management and control of such objects is possible only in real time, that is, if almost all actions performed during the execution of a business process lead to corresponding transactions in information systems. Only this situation allows you to track these actions, and ultimately the business process as a whole, automatically, in real time. However, the modern level of business automation in many companies is actually “total”, that is, all actions performed within business processes are reflected in information systems, and for a small number of procedures performed “manually”, there is a special mechanism within the BPM system - “Human workflow”, which allows you to bypass the restrictions imposed by “total” automation.

The second most important factor hindering the spread of BPM systems is the lack of understanding of how the implementation of this system affects business performance. With a process approach to business management, the optimality of business processes can be considered as the main indicator of its effectiveness in terms of the speed of their passage (execution) and the amount of resources spent on their implementation. Accordingly, to improve business efficiency from the point of view of the process approach, it is necessary to achieve the creation of a set of optimal business processes with maximum speed and minimum resource costs. As follows from the laws of economics, an increase in the speed of execution of operations (actions within a business process) leads to an increase in labor productivity, and a reduction in resources for their implementation leads to a reduction in costs.

Another factor influencing business efficiency when using BPM systems is real-time monitoring of the achievement of results within the framework of the execution of a business process. In other words, when using a BPM system, management sees not only what results have been achieved, but also how they were achieved. An example is the fact that when using a BPM system, it becomes impossible for a situation where 80% of the required quarterly work is completed in the last two weeks of the reporting period, since the critical alert system will instantly report problems in the business process, and the visual monitoring system (Business Activities Monitor) will show deviations from the specified parameters of its implementation in real time.

There is also a psychological component to using BPM systems that affects business performance. The point is that when monitoring the execution of business processes, the actual performers are under the direct and vigilant supervision of the BPM system, which makes it possible to minimize the irresponsible and negligent attitude of employees towards their duties.

We list the main platforms of BPM systems:

Lombardi Teamworks. The world's leading BPM platform. Offers today's maximum opportunities for building automated processes. Allows you to include analysts and business users in the development and process improvement cycle using tools specifically customized for these roles.

SourceCode K2. The platform is based on the most modern Microsoft technologies. Very developer friendly. The moderate cost of licenses and the traditionally low cost of development on the Microsoft platform allow us to consider K2 as an economical tool for solving a wide range of problems.

Intalio BPMS. The only fully functional open source BPMS today. Indispensable in situations where open source code is a mandatory requirement or the project budget does not allow considering commercial analogues. The platform has repeatedly proven its functional maturity, reliability and scalability in large projects.

IBM FileNet, EMC Documentum, Alfresco. Market leaders in corporate information management systems (EnterpriseContentManagement, ECM). They contain BPM components. They have proven themselves best in the tasks of automating processes focused on the preparation of documents.

Oracle BPM Suite, TIBCO iProcess, IBM BPM Suite. Full-featured software products for automating business processes from market leaders in integration platforms. A smart choice in case of complex implementation of a product line from one vendor.

A typical BPM system consists of a standard set of components corresponding to the well-known stages of the life cycle of a business process: design, execution, monitoring.

Design. Design refers to the development of a business process diagram. A BPM system usually includes:

1. graphic designer to draw a business process diagram

2. repository for storing it and organizing shared access

The ability to model a business process using a graphic editor is a fundamental feature of BPM systems: the design of a business process should be carried out by a business analyst without the participation of a programmer.

The procedure for creating a business process model is not much different from the usual procedure for drawing diagrams for business analysts. Draw the steps, describe the business logic, define user groups and a list of details entered at each step.

The result is stored on the server, after which the process can be initiated. If necessary, changes can be made to the circuit, also without the help of programmers. Alternatively, the business process diagram can be developed in any of the traditional business process modeling tools and transferred to the BPM system using import-export.

Execution. The core of a BPM system is its “engine” (BPM Engine). It starts instances of business processes, monitors changes in their states, stores the values ​​of details, and executes business rules.

The core of BPM systems also provides interfaces for connecting with external applications - special adapters, web services, drivers for accessing relational databases or other data sources. The use of these interfaces depends on the type of business process:

A relatively small proportion are business processes that a BPM system can perform fully automatically by running a number of specialized programs. For example, when an Internet service provider activates a new client, it must create an account for it on the server, add information to the system naming service, the web server and email configuration files, and finally generate an invoice and send it to the user along with a notification of service activation. Each operation is performed by a separate program (ideally through a standardized interface - a web service), and BPMS plays the role of a scheduler.

The most common type of business processes involves both interface with specialized applications and the participation of real people. For example, an employee of the financial department must register the fact of payment in the ERP system as a step in the business process of selling goods. This scenario requires the development of interface programs that work both with the context of the business process (that is, with its details) and with the external application program or database. In the context of the business process, links are saved - payment number, counterparty code - through which detailed information can be retrieved from an external application or database at the next steps of the business process. Developing such complex applications is usually the most time-consuming part of a BPM project.

Finally, there are business process steps that are impossible or too difficult to automate. In such a situation, the BPM system will signal to the user that he has been assigned a certain task and will wait for confirmation from him that it has been completed.

The key element of the user interface of a BPM system is the so-called “personal task list”, a list of steps of running instances of business processes assigned to this specific user or the role group to which he belongs.

Thanks to this organization of work, the performer at the computer does not have to think about which function and which external application it is time for him to work with: he sees a list of tasks assigned to him, and when he takes the next task for himself to perform, the required program starts automatically.

Monitoring. BPM systems provide access through a web interface, which makes it as easy as possible to involve employees of geographically remote departments and counterparty organizations in collective work.

The BPM system controls business processes in two ways:

1. The manager does not have to figure out “who has the arrow” - for each instance of a business process this is clearly shown by a dynamically generated graphic image.

2. The BPM system accumulates valuable statistics on the parameters of the execution of business process instances: intensity (number of instances per week or month), duration (time from start to completion), workload on individual specialists (number and duration of completed tasks).

BPM systems typically provide a basic set of reports on business process indicators. On their basis, so-called “key performance indicators” can be constructed.

Thus, the key features of BPM solutions are that they allow:

a) ensure flexible automation of “end-to-end” business processes (affecting the functioning of several functional divisions of the company and information systems);

b) provide the basis for the introduction of a process approach to organizing the work of organizational units of the enterprise;

c) allow you to organize effective control over the implementation of business processes in real time;

d) reduce the costs of interaction between different departments of companies and partners;

e) provide “seamless” integration between various business applications of the enterprise and partners;

f) allow you to reduce the implementation time of new solutions and business functions;

g) increase the return on investments already made in the company’s information systems.

Business process management systems are a new class of systems that allow you to model, control and improve the efficiency of enterprise business processes.