Oath of the Hyp. The chief project engineer is a key figure in the design process

Since February 2008, the working stage has begun regarding the documents that define the design process. It was the act of February 2008 that introduced its own rules for construction on the territory Russian Federation. Whatever month the construction takes place - December, April, May or August - you must approve the documents from the relevant authorities. This even applies overhaul on the object.

Government Decree 87 on the composition of project documentation,

For example, the very first paragraph states that any explanations on the use of the Regulations, which are approved in the Resolution, are given directly by the Ministry of Construction of the Russian Federation. All other issues are resolved in accordance with the competence of specific executive authorities involved in developing state policy.

Changes 2016

with changes contains several modifications compared to the old version. For example, the development of estimate standards intended for the construction of a specific facility is carried out in accordance with the decision of the Government of the Russian Federation.

Posted 04/01/2015

M. S. Podolsky, Chairman of the Subcommittee for organizing the activities of Chief Project Engineers of the Committee on Technological Design of Industrial Facilities of the National Association of Designers and Surveyors, Scientific Director of the International School of Chief Engineers (Chief Architects) of Projects at MGSU

A. V. Litvinov, Deputy General Director Consulting center "CNIO-project", member of the Council of the International School of Chief Engineers (Chief Architects) of projects at MGSU

IN modern conditions management, the customer has the opportunity to choose a design organization (PO) according to the optimal ratio of terms, price and quality of services offered. Given the apparent equality of the listed criteria, it is the quality project documentation can become a decisive condition for the success of software in the competitive struggle. The quality of design documentation is assessed both by objective parameters - compliance with the requirements of current standards and regulations, and by subjective parameters - maximum satisfaction of customer requirements. Both parameters are constantly changing: customers move from standard design to individual design, changes and additions to the regulatory and technical and legislative framework, new ones appear Construction Materials, new equipment, technologies, etc. The usual customer “satisfied” or “not satisfied” with project documentation is complemented by the need to constantly increase customer satisfaction, and this is embedded in the ideology international standards ISO 9000 series.

To provide required quality products, software must, if not keep up with scientific and technological progress, then at least keep up, offering the customer new, original and reliable design solutions.

What prevents the real improvement of the work of Chief Engineers (Chief Architects) of projects (GIPs)? In our opinion, firstly, the prevailing incorrect stereotypes regarding the place and role of the GUI in the design process, which are passed on from generation to generation of designers, and secondly, the insufficient qualifications of software managers in matters related to the activities of the GUI, which does not allow them to take adequate decisions, thirdly, the lack of a clear understanding of what the quality of a design solution consists of and for what part of it the GIP is responsible, fourthly, a simplified understanding of the mechanism of quality formation, including when it is implemented by subdesigners, and finally , fifthly, because the majority of designers have not yet realized the importance of the role of GUI in reducing costs design work.

It would be wrong to think that software managers and GUIs themselves do not want to eliminate the above reasons, but their attempts do not bring noticeable results, because instead of relying on facts that clearly dictate the right decisions, they are guided by past experience and subjective opinions that do not meet the requirements of the time.

In the process of discussing these issues, we often found ourselves on opposite sides of the barricade with many of our colleagues - with a kind of “collective opponent”, whose views were formed historically and who to this day lives in the past economic reality. This article is an additional objection to the “collective opponent”.

As is known, modern management recommends documenting important regulations, but the appearance of any regulation must be preceded by the formation of principles that establish, for example, “along or across the river” a bridge will be built. This is a critical part of rulemaking. At this stage, consensus must be reached in the professional community, after which any regulatory restriction should not contradict the agreed principles.

Unfortunately, in reality, “bad stereotypes” prevail, which in most cases have nothing to do not only with the science of organization and production management, but often simply with common sense.

Let us dwell on some, in our opinion, erroneous ideas, getting rid of which is a real reserve in the development of the design business:

1. The GUI is responsible for the quality of design (working) documentation, i.e. the GUI is responsible for everything.

That's impossible. The requirements for the position, or, as they say today, the “responsibility and authority” of the GUI, have historically correlated with the increasing complexity of the requirements for design objects, as well as with changes in customer expectations regarding design results. In the past, design and construction were managed by one person who made all decisions. Currently, the main task of the State Investment Project is to ensure the necessary dynamics of investments, as well as income to the customer from the implementation of the project, sufficient to compensate investors for the resources they have invested and the risk they have taken. Thus, the GUI makes all decisions when designing according to the criterion economic efficiency design, construction and operation of the facility. Hence the requirements for his qualifications. All other participants in the design process make decisions according to the criterion of technical optimality, and this condition is realized in the process of coordinating design decisions by the main specialists in the sections of the project.

2. The GIP’s “oath” relieves other design participants of responsibility for the quality of design (working) documentation.

In other words, the GIP is responsible for compliance in the project with norms and standards for the design, construction and operation of facilities, standards of self-regulatory organizations, individual requirements customer to technical level and quality, architectural expressiveness and social significance objects. We consider it necessary to return to the meanings: responsibility for what and in what cases.

Obviously, liability may arise if a negative result of the work that the specialist performed personally or personally checked is revealed; if there is an appropriate signature, supported by a date, and it is also documented for what and to whom one is responsible and when it ends. This prerequisites for personal liability. Otherwise, collective irresponsibility will prevail. Let's give an example. As you know, the drawings must have signatures: “developed”, “checked” and “standard control”. Let us pay attention to the fact that the signatures are given in terms of actions, i.e. they answer the question: what did you do? - developed; What did you do? - carried out standard control, etc. “Amateur activity” of design organizations and the appearance on the drawings of signatures of department heads, chief specialists, chief project engineers, etc. should not be allowed. The emphasis is shifting, and the signatures begin to determine not “what was done”, but “who” did".

As already mentioned, the signature represents responsibility. No signature - no responsibility. Since responsibility has boundaries, it is necessary to agree on where they lie, that is, make sure that everyone has the same understanding of the area of ​​responsibility. The meaning of the agreement is as follows: each drawing has content (“what” is depicted) and design (“how” is depicted). The Contractor is responsible for the content and design. For content - before the inspector, for design - before the normative inspector. The responsibility of the performer ceases at the moment when the inspector and the normative inspector put their signatures. Next, it is necessary to determine to whom the inspector and normative controller are responsible. Ideally, this should be a customer who is really interested in the consistency of the signature and the result. In the most design organization It is impossible to find those following the inspector and the normative controller. But could it be a GIP? In this case, the signature of the GIP will mean that he once again checked the content and design of the drawing and took responsibility, including for “compliance in the project with the norms and standards for the design, construction and operation of facilities...”, etc. and etc. But the GIP is physically unable to check all design solutions for compliance with all standards and all requirements. Therefore, holding the GIP responsible for everything in general is nothing more than a spell, formal due to the impossibility of fulfillment and dangerous if necessary to punish for someone else’s guilt. The project manager is only one of many authors of the play called “preparation of project documentation.”

3. If something serious happens at a construction site, the first to be jailed is the GUI.

If something really serious happens, then the investigator, having appointed a forensic technical examination or conducting several such examinations, will determine the designer who, for example, performed the calculation of the structure and applied the wrong coefficient, then determine the one who checked the calculation and present it to this person accusation, but the court under certain circumstances can punish the executor and the inspector.

4. The project manager must be the most qualified designer for all sections of the project.

It is clear that this simply cannot happen, because the project documentation contains at least ten specialized sections, work on which requires the presence of more than twenty specialties. This “bad stereotype” also extends to the idea of ​​appointing a specialist to the position of Chief Inspector. However, it is advisable to make the decision to appoint a chief executive officer on the basis of a competitive selection and be guided by completely different criteria.

An applicant for the position of chief engineer must justify to the applicant the possibility of achieving higher technical and economic indicators of the designed facility, reducing the initial design and construction timeframes, reducing the labor intensity (cost) of design work, more favorable terms for settlements with participants in the work for the design organization, as well as expanding the scope of additional requirements customer for the design object (7.2.1 “d” GOST R ISO 9001-2008), etc. The reputation of the GUI is of particular importance: character, communication skills, diligence, commitment, efficiency, punctuality, decency, ability to negotiate, attentiveness, politeness, responsiveness, performance, etc.

For civil objects, an advantage when appointed to the position of Chief Project Architect (CHAP) may be the presence of economic and architectural education. The second priority is economic education, the third is architectural and, finally, just engineering.

For industrial facilities (technological design), an advantage when appointed to the position of Chief Project Engineer (Chief Engineer) may be the presence of an economic education and a technological education corresponding to the specifics of the design object. The second priority is economic education, the third is technological and, finally, just engineering.

In both the first and second cases, the State Inspectorate (GAP) must have project management qualifications. Based on the results of the competitive selection, the chief executive officer is appointed to the position by the relevant order of the head of the software.

5. If disagreements arise between the main specialists on sections of the project, the GIP makes the final decision.

Let's imagine the following picture: The chief electrician for his section of the project decided that the switchboard would be between such and such axes and at such and such a level of the building. The chief specialist - a heating engineer - located a heating point in the same place. They come to the GIP so that he can “reconcile” them. Naturally, the qualifications of each of the Chief Specialists in the relevant specialty are higher than those of the Chief Inspectorate. If the ISU discusses this issue with them on the proposed technical level, then it is obviously at a disadvantage. He should turn the discussion into economics by saying that one option costs this much and the other costs this much, taking into account not only construction costs, but also operating costs, as well as possible risk associated with changes in equipment costs. When making and justifying its decision from an economic point of view, the PPI, which is responsible for this decision to the investor, must seek an appropriate technical solution from specialists. Today, few of the GUIs can act like this, but this is the purpose of the GUI, its part of responsibility for the quality of design solutions.

6. The State Inspectorate must first of all have a technical specialty.

We have already talked about what specialty the GIP should have and why. In the context of the accelerated pace of scientific and technological development, the quality of design documentation directly depends on the systematic improvement of the qualifications of GIs. Today, the chief executive officer must be competent in the field of organizing and managing the design process, methods for ensuring the economic efficiency of design, construction and operation of the facility in order to obtain his position on a competitive basis. But even successfully working GUIs feel that their knowledge on these issues is insufficient and they try to independently compensate for the gaps in their competencies.

To solve these problems, on the initiative of the Committee for Technological Design of Industrial Facilities NOPRIZ and the Institute of Construction and Architecture (ISA) of the National Research Moscow State University of Civil Engineering (MGSU), with the participation of the Consulting Center "CNIO-Project" and the Committee for Continuous vocational education V construction industry The Russian Union of Builders (RUC) organized the International School of Chief Engineers (Chief Architects) of projects. The School Council includes well-known experts in the Russian Federation and CIS countries in the field of design and quality assurance of design (working) documentation. Chairman of the Council of the International School of Chief Engineers (Chief Architects) of projects Igor Viktorovich Meshcherin has unique experience of working as both the State Aviation Administration and the State Inspectorate in the USSR, Russia, the USA and Italy.

Information about the International School of State Inspectors (GAP), including the conduct of specific courses, is posted on the websites of ISA MGSU, the National Association of Designers and Surveyors, the Central Scientific Research Institute of Projects, as well as on the websites of “Proektant” in the Russian Federation, Kazakhstan, Belarus and Ukraine.

The main goal of the International School of GIPs is to e m advanced training to ensure the training of highly professional personnel of State Inspector General. The programs that meet modern requirements and the practical orientation of the courses make it possible to meet the needs of technological and architectural and construction design, to maintain continuous professional growth and reproduction of GIPs, as well as prepare according to orders from design organizations personnel reserve to fill the positions of State Inspector General.

There are two main products in the “educational portfolio” of the GIP International School:

The proposed system for retraining GUIs is flexible, adequate to the needs of the time, responding to the real needs of extremely busy practical work designers. The content of the programs balances theoretical and practical knowledge, as well as experience in design management. It is very important that the program assumes a wide territorial coverage of students and ease of learning, including through the use of modern principles, forms and methods of training: modularity, training “to the result”, variability of training periods, distance learning, etc.

The main topics discussed at the courses at the International School of State Inspectors at Moscow State University of Civil Engineering:

1. The situation on construction market and its impact on the activities of the State Inspectorate.

2. Major changes in the content of the concept of “quality management system” in relation to the work of the State Inspectorate.

3. Distribution in the design organization (PO) of responsibility for the development of design solutions and their quality between the first manager, chief engineer, production director, GUI, technical department and production departments(workshops) in the process of preparation, release and implementation of design (technical) documentation in construction, including control, verification, analysis, coordination, validation and approval of design and estimate documentation.

4. Clarification of the role and place of GUIs in the “end-to-end process” of customer-oriented software: “interaction with software customers” – “formation and support of a portfolio of software orders” – “preparation and release/implementation of design (working) documentation” – “support of project implementation in construction” – “fulfillment of warranty obligations for software projects implemented in construction.”

5. Head of the production department: designer or leader (manager)? Interaction with GUIs. The main objects of management of the head of the production unit: labor resources, work, time, finances, material resources; subordination, powers, basic functional responsibilities(responsibility) of the head of the production unit, criteria for assessing his activities.

6. The procedure for “launching” work on the preparation of design documentation in accordance with the concluded general design agreement. Sample contract agreement with a subcontractor design organization (SPO); procedures for evaluation, selection (selection) and revaluation of open source software; concepts of subcontracting and outsourcing.

7. Interaction of the GUI with contract department, technical archive, project release department. Basic requirements for the State Inspectorate in the system of executive discipline.

8. Analysis of new responsibilities of the Chief Executive Officer; typical job description GIPa; requirements for the State Inspectorate when carrying out designer's supervision (including by sub-designers); GIP and issues of technical re-equipment, enterprise expansion, modernization, major repairs, etc.

9. Monitoring customer satisfaction with the processes and results of the design organization’s work.

10. The role of the GUI in expanding the types of products (services) of the design organization. Formation of the reputation of the self-propelled investment company among the participants of the investment project.

11. Management of subdesigners. Modern requirements for the selection of design participants.

12. Comments on the draft new organizational and methodological documents for GIPs: Standard professional activity GIP, Recommendations for organizing the activities of the GIP, Profile of the GIP, Requirements for training and appointment to the position of GIP, which are being developed in the Subcommittee on organizing the activities of the Chief Project Engineers of the Committee for the Technological Design of Industrial Facilities of the NOP this year.

13. Negotiating when concluding contracts and determining contract prices. Types of contracts.

14. Interaction with state and non-state expertise.

15. Legal and organizational basis for design, regulatory documents related to the work of GIPs, including GOST R 54869-2011, as well as the EUROCODE system.

16. Cost of design work. Basis-index and resource methods of cost calculation. Forms of estimate documentation. Assessing the economic efficiency of design solutions.

17. Project risk management. Definition and identification of risks (risk categories, known risks and unknown risks, risk magnitude, probability of occurrence and degree of risk impact); risk management budgeting; determining the probability of meeting the specified deadlines and project budget; risk response methods (avoidance, transfer, mitigation and acceptance); risk symptom control.

18. Participation in bidding for a contract for design and survey work.

19. Basic provisions of the quality management system in a design organization that meets the requirements of GOST ISO 9001-2015.

20. Functions and content of technical supervision of the customer. State construction supervision.

21. Competencies of the State Inspectorate in matters of self-education and advanced training.

22. GIP, GAP in functional, organizational and financial structures design organization.

23. GUI competencies related to marketing and sales.

24. The competence of the State Inspectorate in matters of determining its powers, rights and responsibilities.

25. Competencies of the Chief Executive Officer in assessing the effectiveness and efficiency of his professional activities and motivation.

Since May 2015, the Program of the International School of State Inspectors has included an additional module “Assessing the economic efficiency of design solutions” (30 academic hours). The total volume of the Program becomes 80 ac. hour. Classes on this module are taught by teachers of the State Academy of Investment Sector Specialists (GASIS) of the National Research University " graduate School Economics" Students also receive a GASIS certificate.

The topics of educational, consulting and research programs offered by the International School of GIPs are focused on solving the basic problems currently facing design organizations through real improvement of the qualifications of key figures in the design process - GIPs.

On the main topics, the Programs of the International School of GIPs have been developed by the Consulting Center “CNIO-Project”.

Now let’s turn to the mechanism for forming the quality of design solutions in order to clearly and unambiguously define the boundaries of the responsibility of the GIP.

Several general design provisions:

1. Any construction project is a combination of three models:

Models of the future facility (space planning and engineering solutions);

Models of its creation (Construction Organization Project);

Models of its operation (Organization and production management).

2. The formation of a design solution consists of the actual adoption of it, and then it is necessary to confirm its compliance, in other words, check it. Making a design decision itself is a choice from alternatives, and confirmation of compliance has many different options and, accordingly, many terms that correspond to these options. The options mainly depend on the time, venue and standards that are chosen for confirmation.

The quality of a design solution consists of four main properties. Each of these properties is formed by someone in the software and intended for someone. The one who forms the quality property bears personal responsibility for this. The first is “technical feasibility”, i.e. the design solution must be such that it can be implemented during construction. It is needed primarily by the construction contractor, and it is formed by technicians, engineers and chief specialists of production departments. The second is “information opportunity”, i.e. the design solution must contain all the information necessary to carry out construction and installation work, order equipment, obtain all necessary permits and approvals. The customer and the construction contractor need it. This property is formed by technicians, engineers and chief specialists of production departments. The third is the “economic feasibility” of the design solution, i.e. the design solution must be economically competitive during the construction and operation of the facility. This is needed by the main person in the market - the investor, it is formed, and the GIP is responsible for this. The fourth is “systematic”, i.e. all design decisions for the project must be agreed upon. This is necessary primarily for the designers themselves, and the main specialists in the project sections are responsible for this.

Design decisions are made at five levels. Let's look at these levels using the design section of the project as an example. The first level will be “assemblies, parts”. At this level of technology, decisions are made on reinforcing mesh, embedded parts, etc. The second level is “elements”. At this level, engineers design beams, columns, free-standing foundations, etc. The third is “components.” Senior and leading engineers design floors, coverings, enclosing structures, etc. The fourth level is the “project section.” At this level Chief Specialist makes decisions on the structural design of the building and the main strength parameters of the structure. The fifth level is “technical and economic indicators of the project.” The ISU is responsible for making decisions at this level.

Let's turn to “confirmation of compliance of the design solution.” This is control, assessment, verification, analysis, validation, coordination and approval of design solutions. Here it is important for us to determine the boundaries of the responsibility of the GIP.

Control involves correlating the adopted design decision with the current norms (rules), i.e. regulatory documents that currently operate in the construction complex (Town Planning Code of the Russian Federation, SNiP, SN, GOST, VSN, etc.). The result of the control is whether the design solution “complies” or “does not comply” with the specified regulatory documents.

Assessment is the same control procedure, only in addition to “complies” or “does not correspond” it is indicated how much “complies” or “does not correspond”. As a rule, the result of the assessment is given in quantitative indicators, for example, the fire gap between buildings is 10 meters less than the norm.

The so-called standard control is in the same row as control, with the only difference being that GOST SPDS standards are used to compare the adopted design decision with regulatory documents.

Verification involves comparing the adopted design solution with the input design data (design task, initial design data, technical specifications). GOST ISO 9001-2011 quite clearly establishes the requirements for testing design solutions, including planning the test and recording the results. In particular, 7.3.5 states that “In accordance with the planned activities, verification shall be carried out to ensure that the design and development outputs comply with the design and development input requirements. Records of the results of the inspection and all necessary actions must be maintained and retained.”. Since the “input data”, as a rule, contains technical and economic indicators (requirements) for the design documentation, the GUI checks their compliance with those actually received.

The analysis - a collective action under the leadership of the GIP - allows us to predict the consequences of the invariance of the existing design process in terms of the technical and economic characteristics of design solutions, design costs and its duration. Clause 7.3.4 of GOST ISO 9001-2011, as well as for verification, establishes requirements for analysis, namely: “Systematic design and development reviews shall be carried out at appropriate stages in accordance with planned activities to assess the ability of the design and development results to meet requirements, and to identify any [design and development] problems and propose necessary actions. Participants in such reviews should include representatives of functions relevant to the design and development phase being analyzed. Records of the results of the analysis and all necessary actions must be maintained and retained.” Please note that the analysis must be planned and its results documented. It is also obvious that analysis cannot be carried out at the beginning of design, since there is nothing to analyze yet, and at the end of design, since “the train has already left” and the process is completed. In design, the GUI is responsible for conducting the analysis. As a rule, during the design process, the GUI periodically gathers the heads of production departments and chief specialists in the sections of the project and discusses with them the progress of the design and the technical and economic characteristics of the design decisions made in order to be sure that at the end of the design the resulting design materials will correspond to the “input data” .

Coordination presupposes confidence that this design solution does not contradict design solutions for other sections of the project, i.e., for example, the design solution for the design section of the project is compared with the design solutions for the electrical, sanitary or heat engineering sections of the project.

Responsibility for ensuring that the approval is carried out lies with the Chief Executive Officer, and the corresponding chief specialists in the project sections are responsible for the correctness of the approval.

Let us remind you what “validation” is. In design, two confirmation situations are possible: in the first case, this can be done directly “on paper,” that is, the design solution is on the computer screen. For example, a design solution is a calculated and designed beam that must withstand the corresponding load. To confirm compliance, it is enough to use the same calculation method that was used when making this decision (or an alternative one), and if this method is proven and reliable, then a repeated calculation will give absolute confidence in the correctness of the design decision. Or another example, the design assignment indicates the composition of the premises on the corresponding floor of the building and the required areas are indicated. The design solution for this floor plan can be easily verified by comparing it with the original data. It should be emphasized that such design solutions in the total design volume are at least 80-90 percent. These include design decisions made using standard projects, standard units and parts, tested individual previously developed design solutions that are reused, catalogs of equipment that is duly certified, etc., etc. In other words, we are talking about reliable, tested, many times used, not questionable design decisions.

The second situation is when the design solution cannot be reliably verified using traditional verification techniques. They can only be checked during the construction or operation of a constructed facility, as well as by conducting special tests in conditions that are as close as possible to the construction or operation of the facility. This need arises when advanced technologies or materials that have already been recommended or advertised are used, new calculation methods, equipment that has never been used before, technological solutions that have no analogues, etc. For example, at the exhibition, designers became acquainted with a new roofing material , which is actively advertised, and the characteristics of this material are impressive.

It may be decided to use this material for a roof covering an area of ​​20 thousand square meters. square meters, however, it is specifically stipulated that during construction it is necessary to first complete a roof section of 10 square meters, create a dynamic load on it for a certain time, pour water on top and see how the lower surface of the roof behaves. If the test result is positive, the designers will give permission to manufacture the rest of the roof. Sometimes this need arises due to high uncertainty geological conditions in complex construction areas, when surveyors cannot (including for economic reasons) accurately model soil characteristics in specific foundation locations. In these cases, they indicate the need to drive test piles and only after that confirm the possibility of constructing a pile field under the entire object.

This is the validation of the design solution. The use of validation demonstrates the design organization’s commitment to everything new and advanced. This is a sign of the competitiveness of design solutions, this is the desire to take a leading position in design through the continuous increase in customer satisfaction. Responsibility for the very fact of conducting validation lies with the GIP, and for the content of validation - with the main specialists in the sections of the project.

Approval is permission to transfer the completed design documentation to the customer. This is the responsibility of the GUI, and he realizes it when he signs the invoice before sending the documentation to the customer.

Now let us turn to the responsibility of the State Industrial Inspectorate associated with reducing the cost of design work. As you know, there are many opportunities to reduce costs, and this is “ headache» management and all leading software specialists, since this is practically the only way to increase the profit of a design organization. The GUI makes a significant contribution to this, realizing responsibility for the management (outsourcing) of subdesigners.

Currently, it is possible to select sub-designers (SPO) based on the results of their assessment, comparison with competitors, regular re-evaluation, and the responsibility of the State Inspectorate for this choice has appeared. Between subjects in design began to work important principle, “he who pays calls the tune,” not only in the well-known traditional sense, but also as a requirement of the general designer (GP) to constantly think about increasing (ensuring) the quality and reducing the cost of design work. In addition, the Law establishes that only the SE is responsible to the Customer for the quality of the design and documentation developed by the open source software. Therefore, it is necessary to be guided by the requirements of GOST ISO 9001-2011 and the Guidelines for the use of outsourcing processes // ISO/TS 176/SC 2/N 630R2, November 24, 2003).

In general, three conventional types of open source software can be distinguished:

- “ordinary” – open source software with which the state enterprise has normal market relations;

- “proteges” – creatures of the customer, the relationship of the GP with whom is determined by the customer.

Using the example of relations with open source software, we will consider each of the subsystems sequentially, taking into account that the GIP in some cases makes decisions, and in others participates in their adoption.

Evaluating, selecting and re-evaluating subdesigners.

This subsystem consists of two blocks:

Formation and maintenance of a List (database, register, etc.) of approved open source software and its updating;

Selecting open source software from the specified List to perform work on a specific project.

Carrying out work within the first block is the function of the software technical department, while within the second block it is the responsibility of the GUI.

To create a List technical department The software searches, evaluates, selects and re-evaluates open source software in accordance with the needs of the software using criteria developed jointly with the GUIs.

It is clear that this approach does not guarantee full adequacy of the STR with the expectations of the GP due to the complexity of formalizing some issues. For example, the question regarding the availability of a valid QMS and its compliance with the requirements of GOST ISO 9001-2011. The SPO responds that the QMS is functioning and compliant, as evidenced by the certificate “N” of the certification body. Experience in assessing compliance with certain requirements of GOST ISO 9001-2011 self-regulatory organizations designers shows that more than 90% of certificates were obtained formally, simply “bought” and often have nothing to do with a specific open source software. It turns out that the GP bears real responsibility for the quality of the design (working) documentation prepared by the open source software, but the choice of the open source software is based on the “assurances” of the open source software itself in the form of answers to questionnaire questions. When designing a specific object, the GIP, as a rule, selects a suitable software from the List, guided by additional criteria, including the territorial location of the open source, the awareness of the open source about the properties of a specific construction site, previous contacts with a specific Customer, the readiness of the open source to fulfill the order, and others.

Before making a decision to involve open source software in the design, the GUI must visit the organization directly. This new duty GIPa. This technology is provided ISO standards 9000 series and is called a “second party” audit. The duration of the audit by the second party is no more than one working day (optimally 3-4 hours).

Such a short duration is explained by the fact that not the entire free software quality management system is considered, but only individual key points. Practice shows that if everything is normal at these points, then high degree the probability of the SPO corresponds to the expectations of the GP.

It must be emphasized that the Customer deals only with the GP with whom he has entered into an agreement. He may not know the rest of the project participants. Therefore, the relationship with the SPO is exclusively a problem for the SOE. SPO actually acts as an additional structural unit of the state enterprise, which it must manage during the implementation of the project in the same way as “its own” structural divisions, bearing in mind the timing and quality of the design (working) documentation developed by the open source software, for which the GP is responsible to the customer. This determines the responsibilities of the State Enterprise for managing open source software.

The type and scope of STR management can vary over a significant range: from the minimum, when a STR is issued technical task and the work performed is accepted practically without verification, to the maximum, when it is required that the SPO be guided when executing the order by management and other documents approved by the GP. At the same time, a complete check of the completed SPO design documentation is carried out, including with the involvement of independent experts.

The required amount of management is determined by the GIP depending on the results of the assessment (re-evaluation) of the STR, including taking into account the information obtained during the audit by the second party, as well as depending on the costs planned by the GP for conducting incoming inspection of STR materials, keeping in mind that these costs increase the cost of the project.

The specifics of SPO management must be formalized by the GIP in the “special conditions” of the subcontract agreement. The GP technical department is developing a template for such “ special conditions", which provides almost all possible and/or necessary aspects of open source management, and the GIP, when analyzing a specific contract with open source software, includes those management methods that meet the conditions of a specific project. The deeper the degree of open source control, the smaller the volume of input control of open source design materials, and therefore the cost of the software.

Such management methods may include the need to:

Coordination with the State Enterprise of the applied open source software technological process of design or ensuring the implementation of design work using technological process design used by the GP;

Coordination of the design work schedule, which the SPO should develop based on calendar plan works attached to the contract;

Appointment (by agreement with the GP) of a specific PI (project manager) for the order transferred for execution (section of the project), etc.

Depending on the degree of open source management, the amount of input control at the state enterprise can vary from 100% to virtually none, i.e., a formal recalculation of project documents received from the open source.

After handing over the completed design and estimate documentation to the Customer or after putting the facility into operation (if designer supervision was carried out), the PUI needs to complete the outsourcing project.

To do this you need:

Check the availability of documents confirming the acceptance of the design and estimate documentation from the SPO, including checking the quality of the specified documentation;

Conduct an assessment of cooperation with open source software and report the results to the technical department to adjust the List;

Receive from the open source software and transfer to the GP archive information about developed individual effective design solutions, including in the open source software documentation, which can be recommended for reuse;

Prepare an official review for the STR;

Resolve the issue (if necessary and possible) about economic stimulation of open source software.

Now about the responsibilities of the GUI, which is associated with participation in the formation of the “order portfolio” and reducing the cost of software for finding new customers.

The point is that, according to clause 7.2.1 “Processes related to consumers” GOST ISO 9001-2011, the software must define the requirements:

1. As specified by the customer, including requirements for delivery and post-delivery activities.

2. Not specified by the customer, but necessary for the specific or intended use of the design documentation, when known.

3. Legislative and other mandatory requirements related to design and estimate documentation.

4. Any additional, specific software.

What is meant by the first three groups of requirements (1-3) is more or less clear. Let us further explain that “requirements not stated by the customer, but necessary for the specific or intended use of design documentation, if known,” may include all the requirements of the software itself, the fulfillment of which determines the quality, price and delivery time of project documentation.

For example, if a customer receives design and estimate documentation, which, in accordance with existing design technology, is stored for a certain time before being transferred to the customer in a technical archive, then the requirements of the software itself regarding the conditions for storing the specified documentation in the archive will relate to clause 7.2.1 (2) of the standard . While fulfilling the requirements specified in clause 7.2.1 (1-3) of the standard, the software cannot receive competitive advantages, since these requirements are necessarily implemented by all competitors. In market conditions, only the software that can determine and fulfill the requirements of clause 7.2.1 (4) “survives”. We called these requirements “assumed” and clarified their meaning: firstly, they are “guessed” and formulated by the software itself, secondly, they are not approved or agreed upon with the customer and, thirdly, their implementation is carried out at the expense of own funds BY. As a result, the customer receives design documentation (services) with parameters that were unexpected for him or with parameters that are better than expected, which guarantees not only the customer’s satisfaction, but makes him admire the design and estimate documentation provided (the service provided). In the latter case, the software can be sure that the customer will return to it repeatedly. And, as you know, retaining a customer is 5-7 times cheaper than looking for a new one. This is the essence of a fundamentally new provision contained in GOST ISO 9001-2011.

In order for the fulfillment of the requirement specified in clause 7.2.1 (4) of the standard to influence the formation of competitive advantages of the software, it is necessary to determine the owner of the process for the formation of expected customer requirements, i.e. one of the managers who will establish rules for carrying out this activity. For software, the process owner should most likely be the chief engineer of the institute. The “master” of the process, i.e. the specialist who forms the customer’s expected requirements for a specific project, should be the GUI. Let us clarify that the GUI is responsible for ensuring that the customer’s expected requirements are determined, and the main specialists of the production departments are responsible for the content of these requirements.

Another responsibility of the GUI arises when analyzing the contract (agreement) with the customer. The customer's request to the software can be in different forms: information about the won tender (competition); official letter with a proposal to develop project documentation; phone call to the software manager; informal contact through colleagues, etc. When one of the above signals is received, it is recommended to appoint a GUI who will manage the analysis of the contract before it is signed by the customer.

This responsibility of the GIP involves:

Determining the circle of persons who will participate in the approval of the draft agreement and the distribution of responsibilities between them;

Involvement of the specified managers and specialists to conduct negotiations (working meetings) with the customer to discuss certain provisions of the draft agreement, including negotiations to determine the contract price;

Selecting from a database of templates a suitable option for a specific customer and design object;

Determining the need and possibility of involving subdesigners and conducting preliminary negotiations with them;

Assessing the risks that may accompany the software's fulfillment of its obligations under the contract.

Each of these actions in today's conditions differs significantly from the practice we know. For example, approval of a draft agreement, as a rule, is drawn up on the “Approval Sheet”, which indicates the full name and position of the relevant manager, who, if the decision is positive, signs, and if the decision is negative, he gives reasons for his opinion in writing. In our opinion, it is necessary to establish the responsibility of the manager for the relevant points of the draft agreement. The sum of the points in the “Approval Sheet” must be equal to the sum of the points in the draft agreement. This ensures the personal responsibility of each manager for the feasibility of the terms of the contract by the project organization and the same understanding of the relevant terms of the draft contract by the project organization and the customer, etc.

The material in this article may raise objections among some designers. We are ready for constructive discussions with colleagues in a form convenient for them.

How can one treat designers who apply a norm that was repealed thirty years ago? The litmus test for lack of design knowledge is the inclusion of the "GUI oath" in the general data.

The history goes back at least to GOST 21.102-79 "SPDS General data on working drawings":

"12. In the lower left corner of the first sheet of general data of each main set of working drawings, in a rectangular frame, a record of the chief engineer of the project is placed, certifying the project’s compliance with current standards and regulations, and for buildings or structures with a fire hazardous and explosive nature of production, in addition, a safe their operation in compliance with the measures provided for by the project."

GOST 21.101-93 “SPDS Basic requirements for working documentation”, which replaced it, abolished this norm:

" 2.5.4. General guidelines include:

4) a record that the technical solutions adopted in the working drawings comply with the requirements of environmental, sanitary-hygienic, fire safety, and other standards in force in the territory of the Russian Federation and ensure safe operation of the facility for the life and health of people, subject to compliance with the measures provided for in the working drawings ;"

GOST 21.101-97, which replaced it, “SPDS Basic requirements for design and working documentation” further simplified the necessary phrase:

"4.2.9 The general instructions provide:

d) a record that the working drawings were developed in accordance with applicable norms, rules and standards."

GOST R 21.1101-2013 currently in force in Russia "System of design documents for construction. Basic requirements for design and working documentation" contains the following phrase:

"4.3.5 The general instructions include:

- a record of the compliance of the working documentation with the design assignment issued technical specifications, the requirements of current technical regulations, standards, codes of practice, and other documents containing established requirements."

It is easy to see that in none of the above regulatory documents, except for the first one, there is not a word about the GUI. Now take the first basic set you come across. Look for the phrase “about compliance” there. Depending on the wording, you can roughly estimate the age of the designer who issued the documentation :) If you see the “GUI Oath in a frame,” you’re probably a pensioner, and not far-fetched: he was once taught this way, and in 25 years he never thought to look at the standards.

For those who doubt, I will give one more argument. There is still SNiP 1.06.04-85, which has not been canceled by anyone, “Regulations on the chief engineer (chief architect) of the project. It contains the following provisions:

"2.2. In accordance with the main tasks, the chief engineer (chief architect) of the project is assigned the following responsibilities:

2.2.15. Confirmation in materials project corresponding entry that design and estimate documentation for the construction of enterprises, buildings and structures is developed in accordance with norms, rules, instructions and state standards." Not a word more that would require a separate entry in the working documentation.

Now, for the sake of the collection, I will quote my question, included in the Collection of Explanations, issue 2 “Collection of explanations of the requirements of the standards of the design documentation system for construction (questions and answers). Issue 2. - JSC "CNS", Moscow, 2012":

" 4. Clarify the need to include the “GUI Oath” on the general data sheets. This requirement was not contained even in GOST 21.101-97, but a significant number of design organizations continue, by inertia, to fulfill the requirement of the canceled GOST of 1979.

Answer: Yes, by continuing to carry out the “record of compliance with working documentation”, as was the case in GOST 21.102-79, which was canceled in 1993, these design organizations are now violating the current standard. According to clause 4.3.5 of GOST R 21.1101-2009, a record of compliance of the RD with the design assignment issued by the technical specifications, the requirements of the current TR, GOST, SP, etc., is given in the general instructions on the general data sheets."

The question continues to haunt minds, and in the Collection of Explanations, Issue 4 “Collection of explanations of the requirements of the standards of the design documentation system for construction (SPDS) (questions and answers). Issue 4. - JSC "CNS", Moscow, 2015" read again:

"Question 5: Is it necessary to make the requirement of clause 4.5.6 of GOST R 21.1101-2013 regarding the compliance of working documentation with all norms and rules separately, in a frame, and sign the GUI?

Answer: In GOST R 21.1101-2013 there are no requirements for any allocation within the frame of the paragraph of general instructions containing a “record of compliance with working documentation” and its separate signing by the State Inspector General.

The signature of the person preparing the working documentation (GIP) is mandatory in the main inscriptions on sheets of general data on working drawings and additional signatures the same person under any information on the same sheets is not required.

Having two GUI signatures on the same document (and most often on the same sheet) will not make the documentation twice as good.

Do not confuse the point in the “general instructions” in the working documentation with the “certification of the design organization” in the project documentation"

The GIP visa on the title page is enough
We are audited annually by the territorial standardization organization
and there were no comments on this matter
I and not only I have already reported that complete your set of documentation as you think is correct
It seems that only your organization from the army of design institutes carries out design work
Right
There will be no more comments from me
I repeat that this question has already set the teeth on edge and isn’t it time for us to devote useful time to developing working documentation?

I don't understand your displeasure. If you are not interested or you have decided everything for yourself and it is really not worth wasting time on discussion, I do not force you to do this. Moreover, your opinion on this topic was known even before its creation. And I wrote to you about this, saying that I am interested not only in my and your opinions on this issue, but also in other experts. Also, I did not in any way claim any superiority of my company, not myself as a designer, in any way different from you. We are simply having a dispute about the design rules and only based on your comments on my project. Of course, I try to defend my project, just as you would do in my place. But I’m ready to understand everything and make the appropriate changes in further design; I think that every self-respecting designer wants to produce correctly formatted documentation.

8.7 Title pages volumes of project documentation are drawn up with signatures:

- head or chief engineer of the organization;

Chief engineer (architect) of the project.

The signatures of the chief engineer (architect) of the project are mandatory on sheets of general data on working drawings, the most significant sheets of working drawings, the graphic part of the design and reporting survey documentation;

I have already posted links about the mandatory presence of the GIP oath and the list of regulatory documents in the OD.

From this we draw a conclusion. Despite the lack of comments territorial organization standardization (I don’t think there are Great Specialists there) and your vast experience, which I respect very much, from the point of view of GOST 21.1101-2009, which you repeatedly mentioned, you are not drawing up OA correctly, however, like most (if not all) present here (yes and not only here), not excluding me.
Some violate to a greater extent, some to a lesser extent, but no one could boast of absolutely literate ODs (we hope that there are some, especially since they promised) and this is really regrettable. All that remains is to bashfully admit this fact, despite your credentials and merits, correct your mistakes and continue to fulfill the requirements. In principle, this is why I created this topic.

The composition of sections of project documentation according to the norms of the Russian Federation and specific requirements for registration is stated in Resolution 87. Many are interested in current legislature and its explanations for this resolution, so you should find out what’s new in this law for this year, and what the list of its requirements looks like.

on the composition of project documentation

In writing this provision, the government referred to urban planning and its Russian code. According to Art. 48 of this code established the content of the documentation. The Ministry, which is responsible for construction, as well as the Federation security service began to submit the main requirements. The Federation can also receive recommendations on the preparation of documents through the state transport authority. An additional requirement may be included at the request of many other services. The first edition and clarifications were to come into force in February 2008. Then, at the end of February, designations were given to each aspect of the requirements.

Changes to the Federal Law on the composition of project documentation

Decree of the Government of the Russian Federation on the composition of project documentation dated February 16, 2008 87 with amendments needed to be approved in January 2016. Prior to this, more than one section, by government decision, was changed in April and at the end of April, in December, March, August, July, May and June of previous years. Latest edition By decision of the plenum, it received a small addition, and some paragraph will be introduced in a new wording. Today you can read the edit for free. from 2016 via your computer or download the position plan.

The regulations of the Russian Federation on the composition of project documentation, as amended, contain the following sections:

• Basic provisions;
• Composition of the project for the linear construction process;
• Composition of sections on capital production and non-production construction processes.

Comments to Resolution 87

Recent comments for planning documents under this law make it clear the relevance of the new provisions. For example, the federal law has a list of requirements for the working stage of design. In connection with the comments, you can more accurately understand what to do if a condition from a specific post in the law is fulfilled, how the force of this resolution works and how the system carries out technological supervision.

Oath of the GIP according to Resolution 87

This provision of the Russian Federation does not regulate the oath of the GIP, although there must be his note or entry for the project. There must always be certification, seal and signature of the GUI. This allows you to provide information that the project scheme is written in accordance with the requirements, and the development is officially certified.

List of sections of project documentation under 87 Federal Law

Depending on what kind of construction this provision needs to be applied to, the sample and stages of compilation change. In total, the amendment to the law contains two types of construction - linear objects and capital construction. It is worth classifying an object and applying rules for text and graphic design to it. Help on this issue is condemned by many legal portals, for example, technical expert, consultant or consultantplus. This suggests that today the order of writing projects is of interest to more than one organization. It is worth studying the status of the land, buildings and structures under this law, and then following it in writing.

General explanatory note on Resolution 87

The text of the provision is used to justify the general explanatory note and its development. The project must contain such volumes and sections as described in the resolution. For example, the estimate, power supply, important codes, network availability, environmental aspect of the project, safety and expertise, energy efficiency, etc. must be indicated. Also, the project itself should act as a guarantor of the correctness of the development; for example, preserving the environment is important if this is a document for a nuclear plant or a car wash in Moscow. If an important public node is blocked, or part of the infrastructure needs to be removed, permissions must be attached. The finished document may be bound or folded and given an acceptance date.