Process approach to IT management. Reference models. The reference model of the teacher's competence The ideal reference model in which the main

The proposed BPM (Business Process Management) reference model is based on the following chain of prerequisites:

    Increasing the productivity of an enterprise as a complex system requires its rational construction, and process management is the most modern concept for such a construction;

    BPM (as a discipline) offers a systematic approach to the implementation of process management;

    Each process-driven enterprise has its own BPM-system - a portfolio of all business processes, as well as methods and tools to guide the development, execution and development of this portfolio;

    The flexibility of an enterprise BPM system is a major factor in its success;

    A specialized software platform (BPM suite) for implementing an enterprise BPM system is necessary, but not sufficient, since BPM occupies a special place in the enterprise architecture.

Goal: increase the productivity of the enterprise

To manage their productivity, most enterprises use the feedback principle (Fig. 1), which allows them to adapt to the external business ecosystem by performing a certain sequence of actions:

    Measuring the progress of production and economic activities (usually such measurements are presented in the form of various metrics or indicators, for example, the percentage of returning customers);

    Isolation of events important for the enterprise from the external business ecosystem (for example, laws or new market needs);

    Determination of the business development strategy of the enterprise;

    Implementation of the decisions taken (by making changes to the business system of the enterprise).

According to the classic recommendation of Edward Deming, the author of numerous works in the field of quality management, including the famous book "Overcoming the Crisis", all improvements should be carried out cyclically, continuously and with verification at each cycle. The extent and frequency of these improvements will depend on the specific situation, but it is recommended that such cycles be kept fairly compact. Various improvements can affect different aspects of the enterprise. The question is, how can an enterprise achieve the best results in each specific case? There are two objective prerequisites for optimizing the activities of an enterprise as a whole:

    Providing management with appropriate information and decision-making tools;

    Ensuring that an enterprise's business system is capable of making the necessary changes at the required pace.

The most modern concept of organizing the work of an enterprise is process management, in which processes and services become explicit.

Process management

The business world has long understood (see techniques such as TQM, BPR, Six Sigma, Lean, ISO 9000, etc.) that services and processes are the basis for the functioning of most enterprises. Many enterprises use process management to organize their production and economic activities, as a portfolio of business processes and methods of managing them.

Process management, as a management concept, postulates the expediency of coordinating the activities of individual services of an enterprise in order to obtain a certain result using explicitly and formally defined business processes. Moreover, services are operationally independent functional units; an enterprise can have many elementary nanoscale services that are organized into a mega-service (the enterprise itself).

Using an explicit coordination definition allows you to formalize the interdependencies between services. The presence of such formalization makes it possible to use various methods (modeling, automated checkout, version control, automated execution, etc.) to improve business understanding (for making better decisions) and increase the speed of development of business systems (for faster implementation of changes ).

In addition to processes and services, enterprise business systems work with events, rules, data, performance indicators, roles, documents, etc.

To implement process management, enterprises use three popular disciplines for continuous improvement of business processes: ISO 9000, Six Sigma, and "Lean" or "Lean" production. They affect various areas of the business system of the enterprise, however, it is always provided for the collection of data on the actual work done and the use of a certain model of business processes for decision-making (although sometimes this model is only in someone's head). At the same time, they offer different and complementary methods for determining exactly what changes are needed to improve the functioning of an enterprise's business system.

What you model is what you do

In fig. 2 shows a generalized model of a process-controlled enterprise.

What is the main difficulty in optimizing the activities of such an enterprise? Different parts of a business system use different descriptions of the same business process. Usually these descriptions exist separately and are developed by different people, are updated at different rates, do not exchange information, and some of them are simply not explicitly. The presence of a unified description of the business processes of the enterprise makes it possible to eliminate this drawback. This description should be explicitly and formally defined in order to simultaneously serve as a model for modeling, an executable program and documentation that can be easily understood by all employees involved in the business process.

This description is the foundation of the BPM discipline that allows you to model, automate, execute, control, measure, and optimize workflows that span software systems, employees, customers, and partners within and outside the enterprise. The BPM discipline considers all operations with business processes (modeling, execution, etc.) as a whole (Fig. 3).

At the moment, the BPM industry has not yet developed a proper system of standards for the formats of formal description of business processes. The three most popular formats: BPMN (Business Process Modeling Notation, graphical representation of business process models), BPEL ( Business Process Execution Language , formalizing the execution of interaction between Web services) and XPDL (XML Process Description Language, www.wfmc.org, a specification for exchanging business process models between different applications) were developed by different groups and for different purposes and, unfortunately, do not adequately complement each other.

The situation is aggravated by the fact that different manufacturers are behind different formats and each is trying to "push" his solution to the market. As it has been repeated many times, in such a struggle, the interests of the end user are little taken into account - today there is no sufficiently powerful organization representing the interests of the end user of BPM (by analogy with the group of standards for HTML, the success of which is explained by the adoption of a single test ACID3 by all developers of Web browsers for comparison their products). The ideal situation in BPM would be a standard definition of execution semantics for a BPMN-like description of business processes. It is the standard execution semantics that would guarantee the same interpretation of business processes by any software. Additionally, such a description should allow adaptation of the degree of description of business processes for the needs of a particular consumer (for example, a user sees a rough diagram, an analyst - a more detailed one, etc.).

All this does not mean that BPEL or XPDL will become unnecessary - their use will be hidden, as is the case in the field of preparation of electronic documents. The same electronic document can simultaneously exist in XML, PDF, PostScript, etc., but only one basic format (XML) is used to modify the document.

BPM Discipline in Enterprise Culture

In addition to processes and services, enterprise business systems work with such additional artifacts as:

    developments(events) - phenomena that occurred within and outside the boundaries of the enterprise, to which a certain reaction of the business system is possible, for example, when receiving an order from a client, it is necessary to start a service business process;

    objects (data and documents objects) - formal informational descriptions of real things and people forming a business; This is information at the input and output of a business process, for example, the business process of servicing an order receives at the input the actual order form and information about the client, and at the output generates a report on the execution of the order;

    activities(activities) - small work that transforms objects, for example, automatic activities such as checking a customer's credit card or human activities such as endorsement of a document;

    regulations (rules) - restrictions and conditions under which the enterprise operates, for example, the issuance of a loan for a certain amount must be approved by the general director of the bank;

    role (roles) - Concepts representing the relevant skills or responsibilities required to perform certain actions, for example, only a senior manager can sign a specific document;

    audit trails (audit trails) - information about the execution of a specific business process, for example, who did what and with what result;

    key performance indicators (Key Performance Indicator, KPI) - a limited number of indicators that measure the degree of achievement of the set goals.

Figure: 4 illustrates the distribution of artifacts between different parts of an enterprise business system. The expression "processes (as templates)" means abstract descriptions (models or plans) of processes;

the expression "processes (as instances)" refers to the actual results of executing these templates. Typically, a template is used to create many instances (like a blank that is copied many times for different people to fill out). The expression "services (as interfaces)" refers to the formal descriptions of the services that are available to their consumers; the expression "services (as programs)" refers to the means of executing services — such means are provided by service providers.

To successfully work with the entire complex set of interdependent artifacts, any process-managed enterprise has its own BPM system - this is a portfolio of all business processes of the enterprise, as well as methods and tools for guiding the development, execution and development of this portfolio. In other words, an enterprise BPM system is responsible for the synergistic functioning of various parts of the enterprise business system.

BPM-system, as a rule, is not ideal (for example, some processes can exist only on paper, and some details "live" only in the minds of certain people), but it does exist. For example, any implementation of ISO 9000 can be considered an example of a BPM system.

Improving the BPM system of an enterprise, in addition to purely technical aspects, must take into account socio-technical issues. An enterprise BPM system has many stakeholders, each of whom solves their own problems, perceives the BPM discipline in their own way, and works with their artifacts. For the successful development of an enterprise BPM system, it is necessary to pay special attention to the problems of all stakeholders and explain to them in advance how improving the enterprise BPM system will change their work for the better. It is imperative to achieve a common understanding of all artifacts among all stakeholders.

Specialized software for the implementation of BPM systems

The growing popularity and great potential of BPM have led to the emergence of a new class of enterprise software - BPM suite, or BPMS, containing the following typical components (Fig. 5):

    Process modeling tool - a graphical program for manipulating artifacts such as events, rules, processes, activities, services, etc .;

    Testing tool (Process testing tool) - a functional testing environment that allows you to "execute" a process in various scenarios;

    Repository of templates (Process template repository) - a database of templates of business processes with support for different versions of the same template;

    Process execution engine;

    Repository of instances (Process instance repository) - a database for running and already completed instances of business processes;

    Work list - the interface between the BPM suite and the user performing some activities within one or more business processes;

    Dashboard - an interface for operational control over the execution of business processes;

    Process analysis tool - an environment for studying the trend in the execution of business processes;

    The Process simulation tool is an environment for testing the performance of business processes.

The need for interoperability between the BPM suite and enterprise software that supports other artifacts has given rise to a new class of enterprise software - the Business Process Platform (BPP). Typical BPP technologies (Fig. 6):

    Business Event Management (BEM) - real-time analysis of business events and launching relevant business processes (BEM is associated with Complex Event Processing (CEP) and Event Driven Architecture (EDA));

    Business Rules Management (BRM) - explicit and formal coding of business rules that can be modified by users;

    Master Data Management (MDM) - simplification of working with structured data by eliminating chaos when using the same data;

    Enterprise Content Management (ECM) - management of corporate information intended for a person (generalization of the concept of a document);

    Configuration Management Data Base (CMDB) - a centralized description of the entire information and computing environment of an enterprise, used to link BPM to information and computing resources of an enterprise;

    Role-Based Access Control (RBAC) - control access to information in order to effectively separate control and executive powers (separation of duty);

    Business Activity Monitoring (BAM) - operational control of the functioning of the enterprise;

    Business Intelligence (BI) - analysis of the characteristics and trends of the enterprise;

    Service-Oriented Architecture (SOA) is an architectural style for building complex software systems as a set of universally accessible and interdependent services that is used to implement, execute and manage services;

    Enterprise Service Bus (ESB) is a communication environment between services within an SOA.

Thus, the BPM discipline is able to provide a uniform, formal and executable description of business processes that can be used in various tools of the BPM suite, with real data collected during the execution of business processes. However, the high flexibility of an enterprise BPM system is not automatically guaranteed after purchasing a BPM suite or BPP - the ability of a particular BPM system to develop at the required pace must be designed, implemented and constantly monitored. Like human health, none of this can be bought.

BPM in enterprise architecture

The need to involve almost all corporate software in a single logic for improving an enterprise BPM system raises the question of the role and place of BPM in the enterprise architecture (Enterprise Architecture, EA). EA is the established practice of IT departments today to streamline the information and computing environment of the enterprise. EA is based on the following rules:

    The current situation with the information and computing environment of the enterprise is carefully documented as an as-is starting point;

    The desired situation is documented as an endpoint to-be;

    A long-term plan for transferring the information and computing environment of an enterprise from one point to another is being built and implemented.

All of this would seem to be quite reasonable, but you can immediately see the difference from the approach of small improvements that underlies process management. How can these two opposing approaches be reconciled?

The BPM discipline can solve the main problem of EA - to give an objective assessment of the production and economic capabilities (and not just information and computing) of what will be at the point to-be. Despite the fact that EA describes the full range of artifacts of an enterprise (its genotype), it cannot reliably say what changes in this genotype affect specific production and economic characteristics of the enterprise, that is, the phenotype of the enterprise (a set of characteristics inherent in an individual at a certain stage of development ).

For its part, the BPM discipline structures the interdependencies between artifacts in the form of explicit and executable models (a business process is an example of interdependencies between artifacts such as events, roles, rules, etc.). The presence of such executable models makes it possible, with a certain degree of reliability, to assess the production and economic characteristics of an enterprise when the genotype of the enterprise changes.

Naturally, the more interdependencies between artifacts are modeled and the more reliable these models are, the more accurate such estimates are. Potentially, the symbiosis of the nomenclature of enterprise artifacts and the formally defined interdependencies between them gives an executable model of the enterprise at a specific point in time. If such executable models are built on common principles (for example, krislawrence.com), then it becomes possible to compare the effect of applying different enterprise development strategies and the emergence of more systematic and predictable technologies for transforming some executable models into others.

In a sense, the EA + BPM combination can become a kind of navigator that provides guidance and practical assistance in business and IT development while implementing the general line of the enterprise.

It's no secret that software vendors today define and develop BPM in different ways. However, the more promising path for BPM development is end-user BPM, and the BPM reference model is the first step in creating a common understanding of BPM among all stakeholders.

The reference model proposed in the article is based on the author's practical experience in the design, development and maintenance of various corporate solutions. In particular, this model was used to automate the annual production of more than 3,000 complex electronic products with an average lead time of several years. As a result, maintenance and development of this production system required several times less resources than with the traditional approach. n

Alexander Samarin ([email protected]) - corporate architect of the IT department of the government of the canton of Geneva (Switzerland).

Process Frameworks for BPM

An approach to the implementation of business process management technologies that simplifies the implementation of BPM systems implies a clear definition of a business task and the corresponding business processes; implementation of these processes in a period of no more than three months in order to demonstrate the value of this approach; further expansion of the implementation to the main business objectives. However, the main challenge along the way is misunderstanding and lack of alignment between the business and IT departments. Specialized reference models (Process Frameworks) can greatly simplify the implementation project and reduce costs.

Reference model - a package of analytical and software resources, consisting of descriptions and recommendations for organizing a high-level structure of a business process, a set of attributes and metrics for assessing the effectiveness of execution, as well as software modules created for quickly building a prototype of a business process for its subsequent adaptation to the specifics of a particular company.

Reference Models help define and set requirements and enable business processes, they are based on industry standards and include industry expertise. For typical processes, reference models can help you select and model key workflows, define key performance indicators (KPIs) and metrics that measure performance in key areas, as well as manage activities and problem solving, analyze root causes, and handle exceptional cases.

The structure of a typical reference model includes: recommendations and description of the subject area; elements of composite user interfaces (screen forms and portlets logically connected into chains); service wrappers for quick access to business data; examples of typical business rules; key performance indicators and elements for their analysis; executable process models; data models and process attributes; adaptation to the legal framework and the specifics of business in a particular country; recommendations for the stages of deployment and implementation of processes. Such a set of resources will allow you to quickly adapt to the implementation of the process approach within a specific business process management system, reduce the iteration time of the development cycle, test execution and process analysis. At the same time, the maximum correspondence between the technical implementation and the existing business task is achieved.

However, as analysts at AMR Research point out, "technologies and methods by themselves are not capable of providing any benefits -" more "does not always mean" better. " Some companies use many different solutions, but the efficiency only decreases from this. Literacy in the use of such technologies is important. The reference models are based on industry-accepted standards and Software AG's experience in creating a reference model for defining customer requirements. In practice, this model becomes a starting point from which customers can create the desired model.

The Process Framework, for example, for the order processing business process, includes a basic process model with diagrams of actions for various users and roles, selected KPIs from the SCOR (The Supply-Chain Operations Reference-model) model for the whole process and individual stages. rules to support different processing sequences, for example based on customer segment, targets for different customer segments, product types and regions, and dashboards to help manage exceptional situations.

The Process Framework allows you to focus on the need and possibility of adjusting KPIs for specific customer groups and configuring them taking into account the emergence of new products, entry into new regions or market segments. Such information will enable supply chain, trade, logistics and manufacturing managers to better control specific activities, and IT managers to quickly assess the real health of the IT systems that support order processing.

Vladimir Alentsev ([email protected]) - consultant for BPM and SOA, representation Software AG in Russia CIS (Moscow).

The reference model architecture artificially includes two dimensions:

process measurementthat characterizes the results of the process, which are significant measurable objectives of the process;

process capability measurement, which characterizes the set of process attributes that apply to any process and are measurable characteristics that are necessary to control the process and improve its ability to execute.

The reference model groups processes, when measuring a process, into three life cycle process groups, which contain five process categories according to the type of activity to which it refers.

Initial life cycle processes consist of process categories supplier - customer and engineering.

Process category supplier - customer consists of processes that are directly affected by the customer, the development of support and software transition to the customer, and provide for the correct functioning and use of the software product and / or services.

Engineering process category consists of processes that directly define, implement or maintain a software product, its relationship to the system and its customer (customer) documentation.

Supporting life cycle processes consist of support process categories.

Organizational Life Cycle Processes consist of categories of management and organization processes.

Control process category consists of processes that contain generic methods that can be used by anyone who manages any type of project or process within the software lifecycle.

Organizational process category consists of processes that establish the organization's business goals and design (develop) a process, product, and active resources that, when used by projects in the organization, will help the organization achieve its business goals.

Process categories and processes provide a grouping of types of activities. Each process in the reference model is described in terms of goal assertion. These claims include unique functional process objectives that are validated in a specific environment. The goal statement includes additional material that defines the outputs of the successful implementation of the process. Meeting the purpose of the process represents the first step in building process capability.

The reference model does not specify how, or in what order, the elements of the process goal statements are to be achieved. Process objectives will be achieved in an organization through various lower-level activities, tasks, and methodologies performed to produce a work product. These tasks performed, activities and procedures, as well as the characteristics of the work products produced, are indicators that demonstrate whether the goal of a particular process has been achieved.

Process capability development is characterized in terms of process attributes grouped into capability levels. Process attributes are process attributes that can be rated on a scale of achievement, providing a measure of the process capability. The attributes apply to all processes. Each process attribute describes an aspect of the overall control and efficiency of the process in achieving its objectives and contributing to the business objectives of the organization.

A capability level is characterized by a set of attributes that work together. Each level provides a major enhancement to the process execution capability. Levels constitute a rational path of development through improving the capabilities of any process.

There are six levels of capability in the reference model.

Level 0: Unfinished... General failure to achieve the goal of the process. There are not easily identified work product or process outputs.

Level 1: Executable. The goal of the process has generally been achieved. Achievement cannot be strictly planned and tracked. Organizational personnel are aware that the process must be performed and there is general agreement that the process is performed as and when required. There are certain work products of the process and they are evidence in favor of achieving the goal.

Level 2: Managed... The process develops work products according to certain procedures, is planned and monitored. Work products meet specific standards and requirements. The main difference from Executable level in the fact that during the execution of the process, work products are now generated that fully meet the quality requirements within a certain period of time and the allocated resource.

Level 3: Installed. The process is performed and controlled using a defined process based on good software engineering principles. Individual process implementations use documenting processes, validated, customized versions of the standard in achieving the outputs of a specific process. The resources needed to establish a process definition are also in place. The main difference from Managed level is that the process Set level uses a specific process that is able to achieve its outputs.

Level 4: Predictable. A certain process, in practice, is consistently performed within certain limits and achieves certain goals. Detailed process steps are collected and analyzed. This leads to a quantitative understanding of the process capability and an improved ability to predict performance. The execution of the process is objectively controlled. The quality of the work products is quantitatively known. The main difference from Set level is that a certain process is now performed sequentially within certain constraints in order to achieve its certain outputs.

Level 5: Optimizing. Process execution is optimized to meet current and future business needs. The process achieves repeatability when specific business goals are achieved. The quantitative performance of the process and performance objectives for implementation are established based on the organization's business objectives. An ongoing process that monitors these goals allows for quantitative feedback and improvement is achieved by analyzing the results. The main difference from Predictable level is that defined and standard processes are now dynamically changing and adapting to effectively achieve current (actual) and future business goals.

Naturally, the reference model cannot be used as a basis for making reliable and consistent assessments of process capability, since the level of detail is not sufficient. The descriptions of the process goal and capability attributes in the reference model need to be supported by a comprehensive set of process performance and capability metrics. Thus, a consistent rating of the process capability will be possible.

Process measurement

This subsection provides a classification of the processes adopted in organizations involved in the development, operation, acquisition, delivery and maintenance of software. The classification recognizes five categories of processes that contain all processes. The categories and their processes are comparable to those defined in the draft ISO / IEC 12207, Information technology - Software process life cycle, which we discussed in Section 2.

As noted above, in the reference model, processes are grouped into three groups and five process categories:

initial life cycle processes include the categories of the engineering process and the supplier - customer;

supporting life cycle processes include support process categories;

organizational life cycle processes include the categories of process management and organization.

Individual processes are described in terms of six components.

Process ID. Identifies a category and a sequential number within that category. The numbering scheme differs between top-level and second-level processes. The identifier consists of two parts: a category abbreviation (for example, ENG for the engineering process category) and a number (for example, CUS. 1 stands for the Acquisition Process and CUS. 1.2 stands for the second level process, the Supplier Selection Process, which is a constituent (component) process of the Acquisition Process ).

Process name.A descriptive phrase that identifies a fundamental property of the process (for example, Supplier Selection).

Process type.There are 3 types of top-level processes (basic, extended, new) and 2 second-level processes (component, extended), which are related to ISO / IEC 12207 processes as follows. New processes are in addition to those defined in ISO / IEC 12207. Basic processes are identical in purpose to ISO / IEC 12207 processes. Extended processes are augmented on an existing ISO / IEC 12207 process. Component processes group one or more ISO / IEC 12207 activities from the same process. Extended component processes group one or more ISO / IEC 12207 activities from the same process and include additional material.

The purpose of the process. Material that specifies the purpose of the process, which sets the overall goals for performing the process at the top level. Optional additional material can be included to further define the goal statement.

Process results.List of descriptions of the results of the process.

Process notes. An optional list of informative notes regarding the process and its relationship to other processes.

For example, here are a few processes from each process category.

CUS.1 Acquisition Process

Basic process

goal Acquisition Process is to obtain a product and / or service that satisfies the need expressed by the customer (client). The process begins with the definition of the customer's needs and the desired results, with the acceptance of the product and / or service required by the customer. As a result of the successful implementation of the process:

A contract will be developed that clearly expresses the expectations, responsibilities and obligations of both the customer and the supplier;

A product and / or service will be produced that will satisfy the customer's stated need;

The purchase will be verified so that certain constraints such as cost, plan and quality are met.

CUS.1.1 Acquisition Preparation Process

Component Process CUS.1 - Acquisition Process

goal Acquisition Preparation Process is to establish the needs and objectives of the acquisition. As a result of the successful implementation of the process:

The need to acquire, develop or expand a system, software product or software development process will be identified;

System requirements will be formulated;

An acquisition strategy will be developed;

Acceptance criteria will be defined.

ENG.1 Development Process

Basic process

goal development process is to transform an agreed set of requirements into a functional software product or software system that meets the customer's stated needs. As a result of the successful implementation of the process:

A software product or software system will be developed;

Intermediate work products will be developed, indicating that the final product is based on agreed requirements;

Consistency will be established between software requirements and software designs;

Test data will show that the final product meets the agreed requirements;

The final product will be installed in the target environment and accepted by the customers.

NOTE: The agreed requirements can be achieved through the operation of the Acquisition Process (CUS. 1) or the Requirements Establishment Process (CUS. 3).

ENG.1.1 System Requirements Development and Review Process

Component Process ENG.1 - Development Process

The purpose of the System Requirements Development and Analysis Process is to establish system requirements (functional and non-functional) and architecture, identifying which system requirements should be allocated to which system elements and in which version. As a result of the successful implementation of the process:

System requirements will be developed that meet the established customer needs;

A solution will be proposed identifying the main elements of the system;

The agreed requirements will be allocated to each of the main elements of the system;

A release strategy will be developed to prioritize system requirements;

System requirements will be approved and modified as required;

The requirements, the proposed solution and their links will be communicated to all interested parties.

SUP.1 Documentation Process

Advanced Process

goal Documentation Development Process is to develop and maintain documents that record information generated by a process or action. As a result of the successful implementation of the process:

A strategy will be developed identifying documents to be produced during the life cycle of the software product;

Standards will be defined to be consulted for document development;

All documents to be produced by a process or project will be identified;

All documents will be developed and published in accordance with certain standards;

All documents will be supported according to certain criteria.

NOTE - The process supports the execution of process attribute 2.2 in the examples where it is introduced.

MAN.1.1 Project Management Process

Component Process MAN.1 - Control Process

goal Project Management Process is to identify, establish, coordinate and control the activities, tasks and resources required for the project to create a product and / or meet the agreed requirements. As a result of the successful implementation of the process:

The scope of the project will be determined;

The feasibility of achieving the project objectives with the resources and constraints available will be assessed;

The tasks and resources needed to complete the work will be measured and assessed;

Interfaces between project elements and other projects and organizational units will be identified and verified;

Project execution plans will be developed and implemented;

Project progress will be checked and reported;

Actions to correct deviations from the plan and prevent recurrence of problems identified in the project will be taken when the project objectives are not achieved.

NOTE - This process supports the execution of process attribute 2.1 in the examples where it is introduced.

ORG.2 Improvement Process

Basic Process

The Improvement Process is a process for establishing, evaluating, measuring, managing, and improving the software life cycle process. As a result of the successful implementation of this process:

A set of organizational process assets will be developed and made available;

The organization's process capability will be periodically assessed to determine the extent to which the process implementation is effective in achieving the organization's objectives;

Measuring Opportunity

Measuring the capability of a reference model defines a measurement scale for evaluating the process capability of any process. Process capability is defined at six points on an ordinal scale, which allows an assessment of capability from the lower end of the scale, the unfinished level, to the upper end of the scale, the optimizing level. The scale measures the increase in the ability of a performed process from efficiency that is not capable of achieving certain results to efficiency that is capable of achieving a business goal and supporting continuous improvement of the process. Consequently, the scale defines a clear path for improvement for each individual process.

Within the capability model, the capability measure is based on a set of nine process attributes (AP) (see Table 4.1). Process attributes are used to determine if a process has reached a given capability. Each attribute measures a specific aspect of the process capability. Attributes are themselves measured on a percentage scale and therefore provide a more detailed understanding of the specific aspects of process capability required to support process improvement and capability determination.

As an example, here is one of the attributes of the third level of capability.

AP 3.1 Attribute process definition and transformation

To what extent is the process running as a converted instance of the standard process definition. The standard process meets the specific business objectives of the organization. The transformation is performed to meet the specific goals of the process instance. As a result of fully achieving this attribute:

The process documentation, together with appropriate guidance for customizing the standard process documentation, will be determined that is capable of meeting the normal scope of the process and the functional and non-functional requirements for the work product;

The execution of the process will be carried out in accordance with the selected and / or adapted standard process documentation;

Historical data of the process execution will be collected, firstly, to establish and improve the understanding of the process behavior, and secondly, to assess the resource requirements of the process execution;

Experiences using process documentation will be used to improve the standard process.

Table 4.1.

room

Name

Level 1

Process in progress

AP 1.1

Process execution attribute

Level 2

Guided process

AP 2.1

Execution control attribute

AP 2.2

Work Product Control Attribute

Level 3

Established process

AP 3.1

Process definition and transformation attribute

AP 3.2

Process resource attribute

Level 4

Predictable process

AP 4.1

Process Dimension Attribute

AP 4.2

Process control attribute

Level 5

Optimizing process

AP 5.1

Process change (verification) attribute

AP 5.2

Improvement Opportunity Attribute

A process attribute represents a measurable characteristic of any process as defined above.

N Not reached:

0% - 15% - there is little or no confirmation of the achievement of a certain attribute.

P Partially achieved:

16% - 50% - there is a confirmation of a reliable systematic method to achieve a certain attribute. Some aspects of achievement can be unpredictable.

L Largely achieved:

51% - 85% - there is a confirmation of a reliable systematic method to significantly achieve a certain attribute. The execution of the process can change in some areas.

F Fully achieved:

86% - 100% - there is confirmation of a complete and systematic method to fully achieve a certain attribute. No significant flaws exist within a specific part of the organization.

Each process attribute assessed in any part of the organization, including the highest level of capability identified in the area of \u200b\u200bassessment, must be consistent with a rating using the attribute scale defined above. A set of attribute ratings for a process forms a profile for that process. The evaluation output includes a set of profiles for all evaluated processes.

The identifier used must provide objective evidence of use in order to determine the rating to be retrieved. The ratings can be presented in any format such as matrices or as part of a database, provided that the submission allows the identification of individual ratings according to this link scheme.

The capability level achieved by a process should be derived from the attribute rating for that process, according to the process capability level model defined in Table 4.2. The purpose of this requirement is to ensure consistency of values \u200b\u200bwhen a process capability level is referenced to a process.

The tables below contain the summary lists of the processes that are included in the reference model (table 4.3) and the correspondence between the processes of the reference model and the processes defined in the draft ISO / IEC 12207 standard (table 4.4).

Table 4.2

Scale

Process attributes

Assessment

Level 1

Process execution

Mainly or completely

Level 2

Process execution

Execution control

Work product management

Completely

Mainly or completely

Mainly or completely

Level 3

Process execution

Execution control

Work product management

Process resource

Completely

Completely

Completely

Mainly or completely

Mainly or completely

Level 4

Process execution

Execution control

Work product management

Process definition and transformation

Process resource

Process measurement

Process control

Completely

Completely

Completely

Completely

Completely

Mainly or completely

Mainly or completely

Level 5

Process execution

Execution control

Work product management

Process definition and transformation

Process resource

Process measurement

Process control

Process change

Possibility of further improvement

Completely

Completely

Completely

Completely

Completely

Completely

Completely

Mainly or completely

Mainly or completely

Table 4.3.

Process

room

Name

room

Name

Acquisition (basic)

Purchase preparation (component)

Supplier selection (component)

Supplier Verification (Component)

Customer approval (component)

Support (basic)

Establish Requirements (New)

Functioning (advanced)

Functional use (extended component)

User support (advanced component)

Development (basic)

Analysis and development of system requirements (component)

Analysis of software requirements (component)

Software development (component)

Software design (component)

Software integration (component)

Software testing (component)

System testing and integration (component)

System and software operation (basic)

Supporting life cycle processes

Documenting (advanced)

Configuration management (basic)

Quality assurance (basic)

Verification (basic)

Validation (basic)

Joint review (baseline)

Check (basic)

Problem solving (basic)

Measurement (new)

Reusable (new)

Management (basic)

Project management (component)

Quality management (new)

Risk management (new)

Organizational alignment (new)

Improvement process (basic)

Process creation (component)

Process Assessment (Component)

Process improvement (component)

Human Resource Management (advanced)

Infrastructure (basic)

Table 4.4.

Activities and processes 12207

Processes 15504

Initial life cycle processes

Acquisition process

Acquisition process

basic

Initialization

Acquisition preparation process

Component

Preparation of the Application-for-Offer [-application for the contract]

Supplier selection process

Component

Contract preparation and adjustment

Supplier selection process

Component

Supplier verification

Supplier verification process

component

Acceptance and completion

Customer approval process

component

Delivery process

Delivery process

basic

Initialization

Delivery process

basic

Preparing a response

Delivery process

basic

Contract

Delivery process

basic

Planning

Delivery process

basic

Execution and management

Delivery process

basic

Review and evaluation

Delivery process

basic

Delivery and completion

Delivery process

basic

Requirements establishment process

Development process

Development process

basic

Process implementation

Development process

basic

Analysis of system requirements

component

System architecture development

System requirements development and analysis process

component

Analysis of software requirements

Software Requirements Analysis Process

component

Software architecture development

Software development process

component

Working software design

Software development process

component

Software coding and testing

Software design process

component

Software integration

Software integration process

component

Software qualification testing

Software testing process

component

System integration

component

System qualification testing

System testing and integration process

component

Software installation

Delivery process

basic

Program support

Delivery process

basic

Functioning process

basic

Process implementation

Functional use process

extended component

Functional testing

Functional use process

extended component

System operation

Functional use process

extended component

User support

User support process

extended component

Operation process

basic

Process implementation

Software and system operation process

basic

Analysis of problems and modifications

Software and system operation process

basic

Modification implementation

Software and system operation process

basic

Commissioning

Software and system operation process

basic

Migration

Software and system operation process

basic

Utilization of software

Software and system operation process

basic

Supporting life cycle processes

Documentation process

Documentation process

extended

Process implementation

Documentation process

extended

Development and development

Documentation process

extended

Products

Documentation process

extended

Exploitation

Documentation process

extended

Configuration management process

Basic

Process implementation

Configuration management process

basic

Configuration identification

Configuration management process

basic

Configuration control

Configuration management process

basic

Configuration status accounting

Configuration management process

basic

Configuration assessment

Configuration management process

basic

Release and delivery management

Configuration management process

basic

Quality assurance process

Quality assurance process

basic

Process implementation

Quality assurance process

basic

Product warranty

Quality assurance process

basic

Process guarantee

Quality assurance process

basic

Quality assurance systems

Quality assurance process

basic

Verification process

Verification process

basic

Process implementation

Verification process

basic

Verification

Verification process

basic

Validation process

basic

Process implementation

Validation process

basic

Plausibility check

Validation process

basic

Joint review process

Joint review process

basic

Process implementation

Joint review process

basic

Project Management Reviews

Joint review process

basic

Technical reviews

Joint review process

basic

Verification process

Verification process

basic

Process implementation

Verification process

basic

Verification process

basic

Problem solving process

Problem solving process

basic

Process implementation

Problem solving process

basic

Solution of problems

Problem solving process

basic

Measurement process

Reuse process

Organizational Life Cycle Processes

Management process

Management process

basic

Initialization and scoping

Project management process

component

Planning

Project management process

component

Execution and control

Project management process

component

Review and evaluation

Project management process

component

Closing

Project management process

component

Quality management process

Risk management process

Organizational alignment process

Infrastructure process

Infrastructure process

basic

Process implementation

Infrastructure process

basic

Infrastructure creation

Infrastructure process

basic

Infrastructure Operation

Infrastructure process

basic

Improvement process

Improvement process

basic

Process creation

Process creation process

component

Process evaluation

Process Assessment Process

component

Process improvement

Improvement process

component

Process preparation

extended

Process implementation

Human Resource Management Process

extended

Preparation of essential development

Human Resource Management Process

extended

Preparing the implementation of the plan

Human Resource Management Process

Methodological materials on organizational, methodological, psychological and pedagogical support for professional growth, self-realization of teachers and the formation of key competencies, a profile of competencies of a teacher were developed by the regional scientific and methodological center for expert assessment of pedagogical activities of the State Budgetary Educational Institution of Higher Professional Education of the Moscow Region "Academy of Social Management"

The text is provided for your reference.
The reference model of the competence of a pedagogical worker, developed in the regional scientific and methodological center for expert assessment of pedagogical activity, due to its characteristics, is a normative, predictive model aimed at the result, therefore it underlies the control and measuring materials used in certification, defining their goals, objectives and content ...

We present a reference model of the competence of a teacher in a graphical and descriptive form.

Picture 1- Reference model of key competencies of a teacher

The reference model of the teacher's competence (Figure 1) is an ideal, verbalized, that is, encoded with signs of a natural language, a teacher's model, which is an ideal image, a standard of a specialist that meets all the requirements for teaching staff during certification for the first and highest qualification categories, pp. 30, 31 of the Procedure for attestation of pedagogical workers of state and municipal educational institutions, the requirements set forth in the unified qualification reference book of positions of managers, specialists and employees (annex to the order of the Ministry of Health and Social Development of the Russian Federation of August 26, 2010 No. 761 n), and professional standards.

When designing a reference model of a teacher's competence, we relied on the author's developments, various scientific schools, in particular, we used the domestic research of I.A. Winter, N.V. Kuzmina, A.K. Markova, and foreign studies of the Council of Europe.

Key competence we consider it as an integral characteristic of a pedagogical worker, which allows him to freely navigate in the social and professional space, to perform professional activities efficiently and effectively, to solve standard and non-standard professional and pedagogical tasks, to be a socially adapted person, capable of constant personal and professional self-development.

The scope of competence is competency profiles as components of its knowledge, skills and attitudes, meaningfully determining competence.


Figure 2 - Special and professional competence

Special and professional competence (Figure 2), that is, possession of their own professional activities at a sufficiently high level, the ability to project their further professional development.

    understanding the purpose, mission of the profession;

    possession of the norms of professional activity, high efficiency;

    achieving high results and their stability; professional excellence;

    professional consciousness (awareness of the maximum number of signs of professional activity: content, means, labor results);

    professional thinking, professional intuition, independence in solving professional problems;

    optimal psychological cost of the result, no fatigue and overload.

Within the special and professional competence highlights the following competency profiles :

1. Subject competence , that is, the depth, consistency of knowledge on the subject and their application in teaching practice; the ability to implement curricula of basic and elective courses in various educational institutions.

2. Organizational and methodological competence , i.e. readiness to apply modern educational methods and technologies, including informational ones, to ensure the quality of the educational process; activities, actions, techniques, skills, methods of work, techniques used in this profession to successfully achieve a result; ability to organize educational activities of students (pupils).

3. Diagnostic competence , i.e. possession of psychological and pedagogical knowledge, psychological and pedagogical actions, methods, techniques, skills, techniques, technologies; the ability to apply modern methods of diagnosing the achievements of students and pupils; carry out pedagogical support of the processes of socialization and professional self-determination of students, preparing them for a conscious choice of profession.

4. Analytical and evaluative competence , that is, the ability to analyze and evaluate the formation of universal educational actions, mental operations of students, taking into account their individual characteristics and capabilities, both in qualitative and quantitative indicators (points in the rating, category, etc.); apply methods of mathematical and statistical processing of information; participate in professional tests, the result of which is a differentiated (qualitative and quantitative) assessment of professionalism.

5. Predictive competence , that is, the ability to determine growth prospects, zones of proximal development of their students and their professional development; to be aware of the potential opportunities of schoolchildren and their own; awareness of development prospects and opportunities for their implementation (prognostic criteria); self-design, self-experimentation; building your own strategy for professional growth, building and implementing a scenario for your professional life; consistency between the motivational and operational side of the activity.

6. Research competence , that is, the ability to apply the methods of theoretical and experimental research; plan, organize, conduct and analyze a pedagogical experiment on the implementation of innovations; ability to analyze and synthesize; research skills; the ability to generate new ideas (creativity); demonstrate an understanding of the quality of research relevant to the discipline; Demonstrate an understanding of experimental verification of scientific theories.

Figure 3 -

Communicative competence (Figure 3) - competence of social interaction as the ability to adequately establish mutual understanding, avoid conflicts, create a climate of trust; referring oneself to a professional community; possession of the norms of professional communication, ethical norms of the profession; orientation of professional results for the benefit of other people, their spiritual enrichment with the means of their profession; the ability to cooperate, make contacts, easy compatibility; competitiveness, the ability to arouse interest in society in the results of their professional activities.

Communicative competence manifests itself in the followingcompetency profiles :

1. Social and communicative competence , that is, the ability to find verbal and non-verbal means and ways of forming and formulating a thought during its generation and perception, adequate to situations of interaction; the ability to use public speaking skills, including in the field of broadcasting their own experience (the ability to broadcast their own positive experience to the pedagogical community: articles, speeches, participation in competitions; ability to conduct discussions, polemics; willingness to interact with colleagues).

2. Organizational and communicative competence , that is, the ability to organize productive communication and cooperation of schoolchildren; the ability to conduct educational activities in the form of dialogues, polemics, disputes, discussions, exchange of views, scientific disputes, etc.

Figure 4 - Information competence

Information competence (Figure 4) is related to information technology ownership:

  • receiving, processing, issuing information; transformation of information (reading, note-taking);
  • mass media, multimedia technologies, computer literacy;
  • possession of electronic, Internet technology.

Information competence is manifested in the following profiles:

1. Information retrieval competence , that is, the ability to find the necessary information from various sources.

2. Information and analytical competence , that is, the skills to analyze information and manage it; readiness to use the basic methods, methods and means of obtaining, storing, processing information; willingness to work with a computer as a means of information management; ability to work with information in global computer networks.

3. Information technology competence , that is, the ability to use, reproduce, improve the means and methods of obtaining and reproducing information in printed and electronic form; knowledge of basic applied programs and the ability to use them; Computer skills.


Figure 5 - Personal competence

Personal competence, i.e., stable professional motivation, the presence of a positive self-concept, creative attitude, conscious professional creativity, changing oneself by means of the profession; individuality in professional work; openness to continuous professional training, experience accumulation, change; possession of the techniques of self-realization and development of individuality within the framework of the profession, readiness for professional growth, the ability for individual self-preservation; self-development of professional abilities; strong goal-setting; professional learning; reliance on past professional experience, continuity; an increase in individualization and relative autonomy with professional growth.

Profiles personal competence:

1. Self-development and self-expression competence - sustainable motivation, ability to set goals, professional abilities, professional learning ability, self-presentation, positive emotions; ability and readiness for education throughout life, possession of methods of personal self-expression and self-development, means of resisting professional deformations of the individual.

2. Reflexive competence - a system-forming component of professional pedagogical activity and the quality of a person, which allows reflection to be carried out most effectively and adequately, which ensures development and self-development, promotes a creative approach in educational and professional activities, achieving their maximum efficiency and effectiveness; acmeological phenomenon contributing to the achievement of the highest results in activities; professional and personal qualities of a teacher, his readiness and ability for reflective activity using knowledge, skills, skills, professional and life experience; ability for introspection and self-esteem.

The idea of \u200b\u200bcontrol according to the reference model, proposed in 1961, can be realized with a slight modification of the circuit in Fig. 11.27. This idea had a great influence on the work on control systems. Its essence is to build, synthesize or adapt a system, the overall impulse response of which best matches the characteristic of the reference model or the characteristic of some ideal model.

Suppose, for example, that the dynamic characteristics of aircraft control differ significantly for speeds up to the sound barrier and supersonic. To provide the pilot with the ability to adequately control the aircraft, regardless of its speed, an autopilot is introduced, which receives the pilot's control signals and actuates the control servos. The response of the aircraft to pilot control signals corresponds to the response of some reference model, which is chosen by the system designer to provide the aircraft with a “steering feel” that is convenient for pilots. Many physical systems are synthesized so that their characteristics are similar to those of models, and many of these systems are adaptive.

It is not difficult to implement the described approach by modifying the circuits in Fig. 11.11 or 11.27. To do this, simply replace the inverse delayed model with the reference model. The overall performance of the system is then more likely to be similar to that of the reference model than simply a delayed jump. Such a modification of the circuit is shown in Fig. 11.28.

In the systems in Fig. 11.11 and 11.27, the delay is introduced to allow accurate inverse modeling, corresponding to a low level of rms deviation. If there is a delay, you can get a delayed, but more accurate response. As noted above, the introduction of a delay is necessary in cases where there is a response delay in the controlled system or this system is not a minimum phase. When replacing the delay with the reference model, in cases where the delay is needed for accurate inverse modeling, it is usually necessary to introduce it into the reference model.

Figure: 11.28. Control with an adaptive inverse model, similar to Fig. 11.27, but with the inclusion of the reference model

In this case, it is necessary to form such a characteristic of the reference model, which can be realized by sequentially switching on the controlled system and the adaptive filter, if the weight coefficients of this filter correspond to the minimum standard deviation. The diagram in Fig. 11.28 works well when flexible conditions are specified for an adaptive system. However, one should not assume that this circuit is less inertial or has a more accurate response than is possible for the controlled system and its adaptive control device with a finite impulse response.

For an example of an adaptive control system using inverse modeling using a reference model, consider the following implementation of the circuit in Fig. 11.28:

reference model: the weights in the weights model in the adaptive process iteration control unit. In fig. 11.29 shows the response to a unit jump of an uncompensated controlled model, and Fig. 11.30 - the response of the compensated system, superimposed on the response of the reference system. Obviously, a very close approximation has been obtained.

Model classification

The problem of classifying models, like any fairly complex phenomena and processes, is complex and multifaceted. The objective reason for this is that the researcher is only interested in one property (or several properties) of the system (object, process, phenomenon), for which the model was created. Therefore, the classification can be based on many different classification features: description method, functional purpose, degree of detail, structural properties, scope, etc.

Let's consider some of the most frequently used classes (types) of models (Table 1.4.1).

Table 1.4.1

Classification attribute Types of models
Essence of the model - material (physical) - ideal (imaginary) - informational (theoretical, abstract)
Characteristics of the simulation object - appearance model - structure model - behavior model
Degree of formalization - non-formalized - partially formalized - formalized
Purpose of the model - research:. descriptor. cognitive. conceptual. formal - educational - workers:. optimization. managerial
Role in object management - recording - reference - prognostic - simulation - optimization
Time factor - static - dynamic

Material(physical, real) models - models built by means of the material world to reflect its objects, processes.

Ideal(imaginary) models - models built by means of thinking on the basis of our consciousness.

Information(abstract, theoretical) models - models built on one of the languages \u200b\u200b(sign systems) for coding information.

Material Modelsare real, material constructions that serve to replace the original in a certain respect. The main requirement for the construction of this class of models is the requirement of similarity (similarity, analogy) between the model and the original. There are several types of similarity - geometric, physical, analogy, etc.

Geometric similarityis the basic requirement for the construction of geometric models, which are an object geometrically similar to its prototype and serving for demonstration purposes. Two geometrical figures are similar if the ratio of all respective lengths and angles is the same. If you know the coefficient of similarity - the scale, then simply multiplying the size of one figure by the scale value determines the size of the other figure. In the general case, such a model demonstrates the principle of operation, the relative position of parts, the process of assembly and disassembly, the layout of the object and is intended to study properties that are invariant (independent) from the absolute values \u200b\u200bof the linear dimensions of the object. Examples of geometric models are: car models, mannequins, sculptures, prostheses, globes, etc. They depict the prototype not in all the variety of its properties, not in any qualitative boundaries, but in purely spatial boundaries. Here there is a similarity (similarity) not generally between things, but between special types of things - bodies. This is the limitation of this class of models. Note that direct similarity is realized here.

Physical similarityrefers to the model and the original of the same physical nature and reflects their similarity in the same ratios of the same physical variables in the corresponding space-time points. Two phenomena are physically similar if, according to the given characteristics of one, the characteristics of the other can be obtained by simple recalculation, which is analogous to the transition from one system of units of measurement to another. Geometric similarity is a special case of physical similarity. With physical similarity, the model and the original can be in more complex geometric relationships than linear proportionality, since the physical properties of the original are not proportional to its geometric dimensions. It is important here that the physical variable space of the model is similar to the physical variable space of the original. In this case, the physical model in relation to the original is an analogy of the type of isomorphism (one-to-one correspondence). The central problem is the problem of correct recalculation of the results of a model experiment for the results of testing the original in real conditions. The similarity is based on meeting some physical criteria.

Ideal(imaginary) models are ideal constructions in our minds in the form of images or ideas about certain physical phenomena, processes, objects, systems (geometric point, infinity, etc.).

Abstract(theoretical, informational) models - models representing objects of modeling in figurative or symbolic form.

Examples of abstract models are some hypothesis 1 about the properties of matter, assumptions about the behavior of a complex system under conditions of uncertainty, or a new theory about the structure of complex systems.

On abstract models and on speculative analogy (similarity) between the model Mand original Sabstract (theoretical) modeling is being built.

A prominent representative of abstract and symbolic modeling is the mathematical model.

Mathematical modelit is a set of mathematical formulas, equations, relations, describing the properties of the object of modeling of interest to the researcher.

To investigate each aspect of modeling (type, structure, behavior) or their combination, appropriate models can be used: appearance models, structure models, behavior patterns.

Appearance modelmost often comes down to listing the external features of the object of modeling and is intended for identification (recognition) of the object.

Structure modelis a list of the constituent elements of the modeling object with an indication of the links between these elements and is intended for visual display, study of properties, identification of significant connections, study of the stability of the object of modeling

Behavior modelis a description of changes in the appearance and structure of a modeling object over time and as a result of interaction with other objects. The purpose of the behavior models is to predict the future states of the modeling object, manage objects, establish connections with other objects external to the modeling object.

Objectively, the levels of our perceptions, the levels of our knowledge about various phenomena, processes, systems are different. This is reflected in the ways of representing the phenomena under consideration.

TO informal models can be attributed to displays (images) obtained using various forms of thinking: emotions, intuition, figurative thinking, subconsciousness, heuristics as a set of logical techniques and rules for finding the truth. In unformalized modeling, the model is not formulated, but instead some fuzzy mental reflection (image) of reality is used, which serves as the basis for decision-making.

An example of vague (intuitive) ideas about an object is a fuzzy description of a situation based on experience and intuition.

TO formalized models include figurative models, when the models are built from any visual elements (elastic balls, fluid flows, trajectories of bodies, etc.).

Formalizable abstract models include sign models, including mathematical constructions, programming languages, natural languages, together with the rules for their transformation and interpretation.

By their purpose, the models are designed to solve many problems:

research(descriptor, cognitive, conceptual, formal) models are designed to generate knowledge by studying the properties of an object;

educationalmodels are designed to transfer knowledge about the studied object;

workers(optimization, management) models are designed to generate the right actions in the process of achieving the goal.

TO research models include semi-natural stands, physical models, mathematical models. Note that research models can act as training models if they are designed to transfer knowledge about the properties of an object. Examples of working models are: a robot; autopilot; a mathematical model of an object built into a control or monitoring system; artificial heart, etc. At the same time, research and teaching models should be close to reality, and working models should reflect this reality. There is no clear line between these models. So, for example, a research model that adequately reflects the properties of an object can be used as a working one.

Research models are carriers of new knowledge, teaching models combine old knowledge with new.

Working models idealize accumulated knowledge in the form of ideal actions to perform certain functions that would be desirable to perform.

Descriptor models- descriptive models are designed to establish the laws of change in the parameters of these processes and are implementations of descriptive and explanatory meaningful models at the formal level of modeling.

As an example of such a model, we can cite the model of the motion of a material point under the action of applied forces, using Newton's second law. By specifying the position and speed of the point at the initial moment of time (input values), the point mass (model parameter) and the law of variation of the applied forces (external influences), it is possible to determine the speed and coordinates of the point at any subsequent moment in time (output values).

Cognitive(mental, cognitive) model - models that represent a kind of mental image of an object, its ideal model in the head of a researcher, obtained as a result of observing the original object.

Forming such a model, the researcher, as a rule, seeks to answer specific questions, therefore, everything unnecessary is cut off from the infinitely complex structure of the object in order to obtain its more compact and laconic description.

Cognitive models are subjective, as they are formed speculatively based on all previous knowledge and experience of the researcher. One can get an idea of \u200b\u200bthe cognitive model only by describing it in a sign form. The representation of a cognitive model in natural language is called meaningful model .

Cognitive and content models are not equivalent, since the former may contain elements that the researcher cannot or does not want to formulate.

Conceptual modelit is customary to call a meaningful model, in the formulation of which the concepts and representations of subject areas of knowledge are used that study the object of modeling.

In a broader sense, a conceptual model is understood as a meaningful model based on a certain concept or point of view.

Formal modelis a representation of a conceptual model using one or more formal languages \u200b\u200b(for example, mathematical theory languages, universal modeling language, or algorithmic languages).

In the humanities, the modeling process in many cases ends with the creation of a conceptual model of the object.

In natural science and engineering disciplines, as a rule, it is possible to build a formal model.

Thus, cognitive, content and formal models make up three interrelated levels of modeling.

Optimization models- models designed to determine the optimal (best) parameters of the simulated object from the point of view of a certain criterion, or to find the optimal (best) control mode for a certain process.

As a rule, such models are built using one or more descriptive models and include some criterion that allows you to compare different options for sets of values \u200b\u200bof output quantities with each other in order to choose the best one. Restrictions in the form of equalities and inequalities related to the features of the object or process under consideration can be imposed on the range of values \u200b\u200bof the input parameters.

An example of an optimization model is modeling the process of launching a rocket from the Earth's surface in order to lift it to a given height in minimaltime under restrictions on the magnitude of the impulse of the engine, the time of its operation, the initial and final mass of the rocket. In this case, the mathematical relations of the descriptive model of the rocket motion appear in the form of constraints such as equalities.

Note that for most real processes, structures, it is required to determine the optimal parameters at once according to several criteria, i.e. we are dealing with the so-called multicriteria optimization problems.

Management models- models used to make effective management decisions in various areas of purposeful human activity.

In general, decision-making is a process comparable in complexity to the process of thinking in general. However, in practice, decision-making is usually understood as the choice of some alternatives from a given set of them, and the general decision-making process is represented as a sequence of such choices of alternatives.

Unlike optimization models, where the selection criterion is considered definite and the desired solution is established from the conditions of its extremality, in management models it is necessary to introduce specific optimality criteria that allow comparing alternatives with various uncertainties of the problem. The type of the optimality criterion is not fixed in advance in management models. This is the main feature of these models.

Registration modelsare models designed to register properties and qualities of interest to the researcher that are not available for direct registration at the modeling object.

When solving problems of managing complex dynamic objects, reference and prognostic models are used, which are a formalized display of the desired characteristics of a controlled object for the purposes of current or future object management.

Reference modelIs a model that describes in one form or another the desired (idealized) properties of the object of modeling (control).

Predictive models- models designed to determine futurestates ( the futurebehavior) of the modeling object.

Simulation modelsIs a set of descriptions of system elements, interrelationships of elements with each other, external influences, algorithms for the functioning of the system (or rules for changing states) under the influence of external and internal disturbances.

Simulation models are created and used when the creation of a unified model of a complex system is impossible or involves very great difficulties, the available mathematical methods do not allow obtaining satisfactory analytical or numerical solutions of the problems under consideration. But the presence of descriptions of elements and algorithms of functioning makes it possible to simulate the process of functioning of the system and produce measurementscharacteristics of interest.

It can also be noted that simulation models can be created for a much wider class of objects and processes than analytical and numerical models. In addition, since for implementation, as a rule, computing means (computers and other means) are used, universal or special algorithmic languages \u200b\u200bserve as means of formalized description of simulation models.

Simulation modeling when studying large (complex) systems

remains practically the only available method of obtaining information about the behavior of a system under conditions of uncertainty, which is especially important at the stage of its design. Using this method, one can select the structure, parameters and control algorithms of the synthesized system, evaluate their efficiency, and also simulate the behavior of the system under conditions that cannot be reproduced on a real prototype (for example, accidents, failures, emergencies, etc.). When the behavior of the system under the action of random factors is studied in imitation modeling with subsequent statistical processing of information, then it is advisable to use the method of static modeling as a method of machine implementation of the simulation model. At the same time, the method of statistical tests (Monte Carlo method) is considered as a numerical method for solving analytical problems.

A special class of models are cyberneticmodels that reflect the management aspects of the behavior of complex systems based on information exchange between its elements. The very physical nature of cybernetic models differs from the physical nature of the prototype and its elements. A feature of cybernetic models is the possible presence in them, in addition to the control mechanism, also mechanisms of self-organization, learning, adaptation, etc., and in more complex systems - and artificial intelligence.

Taking into account the time factor in modeling leads to the use of static and dynamic models.

Static modelsreflect the steady-state (equilibrium) operating modes of the system;

Static modes of operation of elements, objects, systems are reflected in their static characteristics (linear, nonlinear) and are described by the corresponding algebraic functional dependencies.

Dynamic modelsreflect unsteady (nonequilibrium, transient) modes of system operation.

Differential equations or systems of differential equations are most often used to describe non-equilibrium (transient) modes of system operation.

Let us consider some of the properties of models that allow, to one degree or another, either to distinguish or to identify a model with an original (object, process). It is customary to distinguish the following properties of models: adequacy, complexity, finiteness, truth, proximity.

Adequacy.Under adequacyit is customary for models to understand the correct qualitative and quantitative description of an object (process) for a selected set of characteristics with some reasonable degree of accuracy.

Adequacy is the most important requirement for a model; it requires the model to correspond to its real object (process, system, etc.) with respect to the selected set of its properties and characteristics. In this case, we mean the adequacy not in general, but the adequacy for those properties of the model that are essential for the researcher. Full adequacy means the identity between the model and the prototype.

A mathematical model can be adequate with respect to one class of situations (state of the system + state of the external environment) and not adequate with respect to another. The use of an inadequate model can lead either to a significant distortion of the real process or properties (characteristics) of the studied object, or to the study of nonexistent phenomena, properties and characteristics.

You can introduce the concept of the degree of adequacy, which will vary from 0 (lack of adequacy) to 1 (complete adequacy). The degree of adequacy characterizes the proportion of the truth of the model relative to the selected characteristic (property) of the object under study. Note that in some simple situations, the numerical assessment of the degree of adequacy is not particularly difficult. The difficulty in assessing the degree of adequacy in the general case arises from the ambiguity and vagueness of the criteria of adequacy themselves, as well as because of the difficulty of choosing those signs, properties and characteristics by which the adequacy is assessed.

The concept of adequacy is a rational concept, therefore, increasing its degree should also be carried out at a rational level. The adequacy of the model should be checked, monitored, refined constantly in the process of research on particular examples, analogies, experiments, etc. As a result of the adequacy check, it is found out what the assumptions made lead to: either to an acceptable loss of accuracy, or to a loss of quality. When checking the adequacy, it is also possible to justify the legality of the application of the accepted working hypotheses in solving the problem or problem under consideration.

Simplicity and complexity.The simultaneous demand for simplicity and adequacy of the model is controversial. From the point of view of adequacy, complex models are preferable to simple ones. In complex models, a greater number of factors can be taken into account that affect the studied characteristics of objects. Although complex models more accurately reflect the simulated properties of the original, they are more cumbersome, difficult to visualize and inconvenient to use. Therefore, the researcher seeks to simplify the model, since it is easier to operate with simple models. When striving to build a simple model, the basic model simplification principle:

you can simplify the model as long as the basic properties, characteristics and patterns inherent in the original are preserved.

This principle indicates the limit of simplification.

Moreover, the concept of simplicity (or complexity) of a model is a relative concept. A model is considered simple enough if modern research tools (mathematical, informational, physical) make it possible to carry out qualitative and quantitative analysis with the required accuracy. And since the capabilities of research tools are constantly growing, those tasks that were previously considered difficult can now be classified as simple.

A more difficult task is to ensure the simplicity / complexity of the model of a complex system, consisting of separate subsystems connected to each other in some hierarchical and multi-connected structure. Moreover, each subsystem and each level have their own local criteria of complexity and adequacy, different from the global criteria of the system.

In order to reduce the loss of adequacy, it is more expedient to simplify models:

1) at the physical level while maintaining the basic physical relationships,

2) at the structural level while maintaining the basic systemic properties.

Simplification of the models at the mathematical level can lead to a significant loss of the degree of adequacy. For example, truncation of a high-order characteristic equation to the 2nd - 3rd order can lead to completely incorrect conclusions about the dynamic properties of the system.

Note that simpler models are used to solve the synthesis problem, and more complex exact models are used to solve the analysis problem.

Finite models.It is known that the world is infinite, like any object, not only in space and time, but also in its structure (structure), properties, relations with other objects. Infinity manifests itself in the hierarchical structure of systems of various physical nature. However, when studying an object, the researcher is limited to a finite number of its properties, connections, resources used, etc. He, as it were, “cuts out” from the infinite world some finite fragment in the form of a specific object, system, process, etc. and tries to know the infinite world through the finite model of this fragment.

The finiteness of systems models lies, first, in the fact that they reflect the original in a finite number of relations, i.e. with a finite number of connections with other objects, with a finite structure and a finite number of properties at a given level of study, research, description, available resources. Secondly, the fact that the resources (information, financial, energy, time, technical, etc.) of modeling and our knowledge as intellectual resources are finite, and therefore objectively limit the possibilities of modeling and the very process of cognizing the world through models. Therefore, the researcher (with rare exceptions) deals with finite-dimensional models.

The choice of the model dimension (its degrees of freedom, state variables) is closely related to the class of problems to be solved. The increase in the dimension of the model is associated with problems of complexity and adequacy. In this case, it is necessary to know what is the functional relationship between the degree of complexity and the dimension of the model. If this dependence is power-law, then the problem can be solved by using computer systems. If this dependence is exponential, then the “curse of dimension” (R. Kalman 1) is inevitable and it is practically impossible to get rid of it.

As noted above, an increase in the dimension of the model leads to an increase in the degree of adequacy and, at the same time, to a complication of the model. Moreover, the degree of complexity is limited by the ability to operate with the model, i.e. by those modeling tools available to the researcher. The need to move from a rough simple model to a more accurate one is realized by increasing the dimension of the model by invoking new variables that are qualitatively different from the main ones and which were neglected when building a rough model. These variables can be classified into one of the following three classes:

1) fast flowingvariables, the extent of which in time or space is so small that, when roughly considered, they were taken into account by their integral or averaged characteristics;

2) slow flowingvariables, the extent of change of which is so great that in rough models they were considered constant;

3) small variables(small parameters), the values \u200b\u200band effects of which on the main characteristics of the system are so small that they were ignored in rough models.

Note that the division of the complex motion of the system in terms of speed into fast and slow motion makes it possible to study them in a rough approximation independently of each other, which simplifies the solution of the original problem. As for small variables, they are usually neglected when solving the synthesis problem, but they try to take into account their influence on the properties of the system when solving the analysis problem.

When modeling, one strives, if possible, to single out a small number of main factors, the influence of which is of the same order and is not too difficult to describe mathematically, and the influence of other factors can be taken into account using averaged, integral or "frozen" characteristics.

Approximation of models.It follows from the above that the finiteness and simplicity (simplification) of the model characterize qualitythe difference (at a structural level) between the original and the model. Then the approximation of the model will characterize quantitativeside of this difference.

You can introduce a quantitative measure of approximation by comparing, for example, a rough model with a more accurate reference (full, ideal) model or with a real model. Model closeness to the original inevitable, exists objectively, since the model as another object reflects only certain properties of the original. Therefore, the degree of approximation (proximity, accuracy) of the model to the original is determined by the statement of the problem, the purpose of modeling.

Excessive striving for increased model accuracy leads to its significant complication, and, consequently, to a decrease in its practical value. Therefore, apparently, the principle of L. Zadeh is true 1 that when modeling complex (human-machine, organizational) systems, accuracy and practical meaning are incompatible and exclude each other. The reason for the inconsistency and incompatibility of the requirements for the accuracy and practicality of the model lies in the uncertainty and vagueness of knowledge about the original itself - its behavior, its properties and characteristics, about the behavior of the environment, about the mechanisms of goal formation, ways and means of achieving it, etc.

The truth of the models.There is some truth in each model, i.e. any model in some way correctly reflects the original. The degree of truth of the model is revealed only when it is practically compared with the original, because only

practice is the criterion of truth.

On the one hand, any model contains the unconditionally true, i.e. definitely known and correct. On the other hand, the model also contains the conditionally true, i.e. true only under certain conditions. A typical mistake in modeling is that researchers apply certain models without checking the conditions for their truth, the limits of their applicability. This approach will lead to incorrect results.

Note that any model also contains the supposedly true (plausible), i.e. something that can be either true or false under uncertainty. Only in practice is the actual relationship between true and false in specific conditions established. Thus, when analyzing the truth level of the model, it is necessary to find out:

1) accurate, reliable knowledge;

2) knowledge that is reliable under certain conditions;

3) knowledge assessed with a certain degree of uncertainty;

4) knowledge that cannot be estimated even with a certain degree of uncertainty;

5) ignorance, i.e. what is unknown.

Thus, the assessment of the truth of the model as a form of knowledge is reduced to identifying the content in it of both objective reliable knowledge that correctly reflects the original, and knowledge that roughly estimates the original, as well as what constitutes ignorance.