SNiP 1.06.04-85 Правилник за главния инженер (главен архитект) на проекта

1.1 Настоящият регламент определя задълженията, правата и отговорностите на главния инженер (главен архитект) на проекта за изграждане на нови, разширение, реконструкция и техническо преоборудване на съществуващи предприятия, сгради и структури на националната икономика и индустрии, планиране и развитие на градове, селища от градски тип и селски селища (оттук нататък - изграждане на съоръжения).

1.2 Министерствата и ведомствата имат право, ръководени от действащото законодателство, да възлагат допълнителни задължения към настоящия регламент на главния инженер (главен архитект) на проекта, като вземат предвид спецификата на проектирането и изграждането на съоръжения в различни сектори на националната икономика и индустрии.

1.3 Главният инженер (главен архитект) на проекта е назначен да организира разработването на проектни разчети и техническото управление на проектантските и проучвателни работи през целия период на проектиране, изграждане, въвеждане в експлоатация на съоръжението и развитие на проектните мощности.

При проектиране на обекти от промишлеността, транспорта, енергетиката, комуникациите, селското стопанство и управлението на водите се назначава главният инженер на проекта, а на гражданското строителство, планирането и развитието на градовете, градските селища и селските селища - главният архитект на проекта.

При проектирането на големи и сложни обекти или обекти, които са от голямо значение за архитектурния облик на града, предприятията и структурите, е позволено да се назначи главен инженер по проекти и главен архитект на проекта. В този случай водещата роля се възлага на един от тях.

Главният инженер (главен архитект) на проекта се назначава измежду най-квалифицираните специалисти за големи и сложни обекти - от министерства и ведомства, за други обекти - от ръководителите на проектантски организации.

Изпратено
Главоргпроект Главстройпроект Госстрой на СССР и Госгражданстрой

Одобрен с резолюцията на Държавния комитет на СССР по строителните работи от 28 юни 1985 г. N 103

Дата на влизане в сила
15 юли 1985 г..

Генералната проектантска организация назначава главен инженер (главен архитект) на проекта за целия комплекс на предприятието, сгради и съоръжения, планиране и развитие на градове, селища от градски тип и селски населени места, проектантска организация на подизпълнителя - за обхвата на извършените от тази организация работи.

Ръководителите на организации - генерални дизайнери имат право да влизат в персонала, ако е необходимо, при проектирането на най-важните обекти, позицията на заместник главен инженер на проекта.

1.4. Главният инженер (главен архитект) на проекта се ръководи в своите дейности от:

схеми за развитие и разположение на отрасли на националната икономика и индустрии;

схеми за развитие и разпределение на производителните сили в икономическите региони и съюзните републики;

схеми и проекти за районно планиране;

проекти за планиране и развитие на градове, селища от градски тип и селски селища;

схеми на генерални планове на промишлени единици;

документи за основните насоки при проектирането на съоръжения в съответните отрасли;

каталози на стандартна проектна документация;

строителни норми и правила;

нормативни документи на органите за държавен надзор и общосъюзни нормативни документи на отделни министерства и ведомства на СССР и обществени организации, свързани с проектирането, инженерните проучвания и строителството и други инструкции на министерства, ведомства и съвети на министрите на съюзните републики.

2. ОСНОВНИ ЗАДАЧИ И ЗАДЪЛЖЕНИЯ НА ГЛАВНИЯ ИНЖЕНЕР (ГЛАВЕН АРХИТЕКТ) НА ПРОЕКТА

2.1. Основните задачи на главния инженер (главен архитект) на проекта са да осигури високо техническо и икономическо ниво на проектираните съоръжения и качеството на проектните разчети в съответствие с "Правилника за оценка на качеството на проектните разчети за строителство", повишаване на производителността на труда и намаляване на потреблението на материални ресурси по време на тяхното строителство и експлоатация, намаляване на дела на строително-монтажните работи и цената на обектите, подобряване на качеството на градоустройствените и архитектурно-планировъчните решения.

2.2. В съответствие с основните задачи на главния инженер (главен архитект) на проекта се възлагат отговорности:

2.2.1. Участие в работата на комисията за избор на обект (маршрут) за строителство, при изготвяне на проектно задание и в организиране на инженерни проучвания за разработване на проектни разчети за реконструкция и техническо преоборудване на съществуващи предприятия, сгради и съоръжения.

2.2.2. Участие в изготвянето на интегрирани планове и графици за изпълнение на проучвания, проектиране и проектиране на съоръжения, които ще използват нови технологични процеси и оборудване с дълъг цикъл на разработка, проектиране и производство.

2.2.3. Подготовка на данни за сключване на споразумение с клиента за извършване на проектни и проучвателни работи, включително за разходите за проектиране и проучване и неговото разпределение между организации и отдели - участници в разработването на проекта, и изготвяне на график за разработване на проектно-сметна документация.

2.2.4. Осигуряване на формирането на състава на разработчиците на проекта, разпределението на задачите между тях по раздели и части на проекта и обхвата на работата с подходяща ведомост.

2.2.5. Контрол на техническото и икономическото ниво на приетите проектни решения и времето за разработване на проектни разчети.

2.2.6. Изготвяне на задания на подизпълнители на проектантски и проучвателни организации за изпълнението на поверената им работа и предоставяне на тези организации на необходимите изходни данни за проектиране; своевременно решаване на всички въпроси, възникващи от подизпълнителите в процеса на разработване на проектно-сметна документация.

2.2.7. Избор на стандартни и многократно използваеми икономични индивидуални проекти, единни пространствено-планировъчни, структурни и технологични решения, възли, конструкции и продукти с цел широкото им използване в проектирането, предотвратяващи неоправданото разработване на отделни проекти и дизайнерски решения.

2.2.8. Координация на проектни и проучвателни работи в целия комплекс на проекта, осигуряване на издаване на пълна проектна и сметна документация на клиента в рамките на сроковете, предвидени в графика за договора за изпълнение на тези работи, и систематичен контрол върху правилното изразходване на средства за проектни и проучвателни работи.

2.2.9. Навременно решаване на въпроси, свързани с проектирането и възникващи в процеса на строителство, въвеждане в експлоатация на съоръжението и развитие на проектни мощности.

2.2.10. Осигуряване на разработването на необходимите опции за идентифициране на най-подходящите и рентабилни дизайнерски решения.

2.2.11. Осигуряване на съответствие на проектите с проектното задание и работната документация - одобреният проект.

2.2.12. Организация на работата по проверка за патентна чистота на технологични процеси, оборудване, устройства, конструкции, материали и продукти, приложени за първи път или разработени в проекта.

2.2.13. Намаляване на обема на проектните разчети и друга документация.

2.2.14. Съгласуване на документацията, изпълнена с обосновани отклонения от действащите норми, правила и инструкции, по отношение на тези отклонения, с органите за държавен надзор и заинтересованите организации, които са ги одобрили.

2.2.15. Потвърждение в материалите по проекта чрез подходящо вписване, че проектната и сметна документация за изграждане на предприятия, сгради и съоръжения е разработена в съответствие с нормите, правилата, инструкциите и държавните стандарти.

2.2.16. Участие в разглеждането и одобрението на организацията на изпълнителя на проектно-сметна документация в съответствие с процедурата, установена от Държавния комитет по строителството на СССР.

2.2.17. Защита на проекта във висши организации и експертни органи.

2.2.18. Строителен надзор.

2.2.19. Изготвяне на предложения за ръководството на проектантската организация и клиента на проектно-сметна документация за извършване на промени в работната документация, свързани с въвеждането на нови нормативни документи, като се вземе предвид действителното състояние на строителството.

3. ПРАВА НА ГЛАВНИЯ ИНЖЕНЕР
(ГЛАВЕН АРХИТЕКТ) НА ПРОЕКТА

3.1. Главният инженер (главен архитект) на проекта има право:

3.1.1. Представляват проектантската организация в институции, организации и предприятия по разработването, одобряването и разглеждането на проектно-сметна документация, изпълнението на строителството съгласно одобрения проект и кореспондират по тези въпроси по начина, установен от проектантската организация.

3.1.2. Вземете решения по технически въпроси по време на проектирането, изграждането, въвеждането в експлоатация на съоръжението и развитието на проектните възможности.

3.1.3. Спиране на производството на определени видове строително-монтажни работи, когато те се извършват с отклонения от проекта, в случай на нарушаване на технически условия и правила за производството на тези работи, както и тяхното незадоволително качество.

3.1.4. Създайте, в съгласие с договарящите се строителни и монтажни организации, намален обем на работна документация.

3.1.5. Проверете състоянието на разработването на проекта, правилното изразходване на средства за проектиране и проучване, спазване на установените срокове за проектиране и качеството на проектните решения в процеса на разработване на проектно-сметна документация.

3.1.6. Подаване на предложения до ръководството на проектантската организация за разработване на нови и изменение на съществуващи нормативни документи за проектиране, изграждане и експлоатация на съоръжения.

3.1.7. Вземете решения за използването на резерва от годишния обем работа за конкретни проекти.

3.1.8. Внасяйте предложения в ръководството на проектантската организация, за да насърчите служителите, които са се отличили при разработването на проекта, да участват в разпределението на бонуси между организации и подразделения - изпълнители, както и да правят предложения за налагане на наказания на виновните за ненавременното и некачествено разработване на проектни разчети.

4. ОТГОВОРНОСТ НА ГЛАВНИЯ ИНЖЕНЕР
(ГЛАВЕН АРХИТЕКТ) НА ПРОЕКТА

4.1 Главният инженер (главен архитект) на проекта носи установената от закона отговорност за техническото и икономическо ниво и архитектурните решения на строящите се обекти, за качеството, навременното разработване и пълнота на проектно-сметната документация, правилното определяне на прогнозните разходи и последователността на строителството, за постигане на проектните показатели от предприятията в установената условия, както и за изпълнение на всички задължения, възложени му с настоящия регламент.

SNiP 1.06.04-85 Правилник за главния инженер (главен архитект) на проекта

Обхват и условия на употребаНастоящият регламент определя задълженията, правата и отговорностите на главния инженер (главен архитект) на проекта за изграждане на нови, разширение, реконструкция и техническо преоборудване на съществуващи предприятия, сгради и структури на националната икономика и индустрии, планиране и развитие на градове, селища от градски тип и селски селища.
Съдържание1. Общи разпоредби
2 Основни задачи и отговорности на главния инженер (главен архитект) на проекта
3 Права на главния инженер (главен архитект) на проекта
4 Отговорност на главния инженер (главен архитект) на проекта
Проектирана отЦНИИпроект Госстрой на СССР (кандидат на икономическите науки М. С. Подолски; А. В. Литвинов, С. А. Барченков)
Изпратено и подготвено за одобрениеGlavorgproekt (В. Г. Коршунов, А. Д. Мирошников, В. М. Луценко), Главстройпроект на Държавния комитет по строителството на СССР (С. Е. Потехин) и Госгражданстрой (В. В. Милашевски).
ОдобренаРезолюция на Държавния комитет по строителството на СССР от 28 юни 1985 г. N 103
ПубликуваноЦИТП Госстрой СССР 1989г
Дата на влизане в сила1985-07-15
СъстояниеSNiP 1.06.04-85 Правилник за главния инженер (главен архитект) на проекта
Актуализирано текущо издание

С влизането в сила на SNiP 1.06.04-85, "Правилникът за главния инженер (главен архитект) на проекта", одобрен с постановлението на Държавния комитет по строителството на СССР от 31 декември 1969 г., № 150.

Когато се използва нормативен документ, трябва да се вземат предвид одобрените промени в строителните норми и разпоредби и държавните стандарти, публикувани в списание "Бюлетин на строителната техника" и информационния индекс "Държавни стандарти".

1. Общи разпоредби

1.1 Настоящият регламент определя задълженията, правата и отговорностите на главния инженер (главен архитект) на проекта за изграждане на нови, разширение, реконструкция и техническо преоборудване на съществуващи предприятия, сгради и структури на националната икономика и индустрии, планиране и развитие на градове, селища от градски тип и селски селища (оттук нататък - изграждане на съоръжения).

1.2 Министерствата и ведомствата имат право, ръководени от действащото законодателство, да възлагат допълнителни задължения към настоящия регламент на главния инженер (главен архитект) на проекта, като вземат предвид спецификата на проектирането и изграждането на съоръжения в различни сектори на националната икономика и индустрии.

1.3 Главният инженер (главен архитект) на проекта е назначен да организира разработването на проектни разчети и техническото управление на проектантските и проучвателни работи през целия период на проектиране, изграждане, въвеждане в експлоатация на съоръжението и развитие на проектните мощности.

При проектиране на обекти от промишлеността, транспорта, енергетиката, комуникациите, селското стопанство и управлението на водите се назначава главният инженер на проекта, а на гражданското строителство, планирането и развитието на градовете, градските селища и селските селища - главният архитект на проекта.

При проектирането на големи и сложни обекти или обекти, които са от голямо значение за архитектурния облик на града, предприятията и структурите, е позволено да се назначи главен инженер по проекти и главен архитект на проекта. В този случай водещата роля се възлага на един от тях.

Главният инженер (главен архитект) на проекта се назначава измежду най-квалифицираните специалисти за големи и сложни обекти - от министерства и ведомства, за други обекти - от ръководителите на проектантски организации.

Генералната проектантска организация назначава главен инженер (главен архитект) на проекта за целия комплекс на предприятието, сгради и съоръжения, планиране и развитие на градове, селища от градски тип и селски населени места, проектантска организация на подизпълнителя - за обхвата на извършените от тази организация работи.

Ръководителите на организации - генерални дизайнери имат право да влизат в персонала, ако е необходимо, при проектирането на най-важните обекти, позицията на заместник главен инженер на проекта.

1.4 Главният инженер (главен архитект) на проекта се ръководи в своите дейности от:

  • действащо законодателство;
  • схеми за развитие и разположение на отрасли на националната икономика и индустрии;
  • схеми за развитие и разпределение на производителните сили в икономическите региони и съюзните републики;
  • схеми и проекти за районно планиране;
  • проекти за планиране и развитие на градове, селища от градски тип и селски селища;
  • схеми на генерални планове на промишлени единици;
  • стандарти;
  • документи за основните насоки при проектирането на съоръжения в съответните отрасли;
  • каталози на стандартна проектна документация;
  • строителни норми и правила;
  • нормативни документи на органите за държавен надзор и общосъюзни нормативни документи на отделни министерства и ведомства на СССР и обществени организации, свързани с проектирането, инженерните проучвания и строителството и други инструкции на министерства, ведомства и съвети на министрите на съюзните републики.

2 Основни задачи и отговорности на главния инженер (главен архитект) на проекта

2.1 Основните задачи на главния инженер (главен архитект) на проекта са да осигури високо техническо и икономическо ниво на проектираните съоръжения и качеството на проектните разчети в съответствие с "Наредбата за оценка на качеството на проектните разчети за строителство", повишаване на производителността на труда и намаляване на потреблението на материални ресурси, когато тяхното изграждане и експлоатация, намаляване на дела на строително-монтажните работи и себестойността на обектите, подобряване на качеството на градоустройствените и архитектурно-планировъчните решения.

2.2 В съответствие с основните задачи на главния инженер (главен архитект) на проекта се възлагат отговорности:

2.2.1 Участие в работата на комисията за избор на обект (маршрут) за строителство, при изготвяне на проектно задание и в организиране на инженерни проучвания за разработване на проектни разчети за реконструкция и техническо преоборудване на съществуващи предприятия, сгради и съоръжения.

2.2.2 Участие в изготвянето на интегрирани планове и графици за изпълнение на проучвания, проектиране и проектиране на съоръжения, които ще използват нови технологични процеси и оборудване с дълъг цикъл на разработка, проектиране и производство.

2.2.3 Подготовка на данни за сключване на споразумение с клиента за извършване на проектни и проучвателни работи, включително за разходите за проектиране и проучване и разпределението им между организации и отдели - участници в разработването на проекта, и изготвяне на график за разработване на проектно-сметна документация.

2.2.4 Осигуряване на формирането на състава на разработчиците на проекта, разпределението на задачите помежду им по раздели и части на проекта и обхвата на работата с подходяща ведомост.

2.2.5 Контрол на техническото и икономическото ниво на приетите проектни решения и времето за разработване на проектните разчети.

2.2.6 Подготовка на задания за подизпълнители на проектантски и проучвателни организации за изпълнение на поверената им работа и предоставяне на тези организации на необходимите изходни данни за проектиране; своевременно решаване на всички въпроси, възникващи от подизпълнителите в процеса на разработване на проектно-сметна документация.

2.2.7 Избор на стандартни и многократно използваеми икономически индивидуални проекти, единно пространствено планиране, структурни и технологични решения, възли, конструкции и продукти с цел широкото им използване в проектирането, предотвратяване на неоправданото разработване на отделни проекти и дизайнерски решения.

2.2.8 Координация на проектни и проучвателни работи в целия комплекс на проекта, осигуряване на издаване на пълна проектно-сметна документация на клиента в рамките на сроковете, предвидени в графика за договора за изпълнение на тези работи, и систематичен контрол върху правилното изразходване на средства за проектни и проучвателни работи.

2.2.9 Навременно решаване на въпроси, свързани с проектирането и възникващи в процеса на строителство, въвеждане в експлоатация на съоръжението и развитие на проектния капацитет.

2.2.10 Гарантиране на разработването на необходимите опции за идентифициране на най-подходящите и рентабилни дизайнерски решения.

2.2.11 Осигуряване на съответствие на проектите с проектното задание и работната документация - одобреният проект.

2.2.12 Организация на работата по проверка за патентна чистота на технологични процеси, оборудване, устройства, конструкции, материали и продукти, приложени за първи път или разработени в проекта.

2.2.13 Намаляване на обема на проектните разчети и друга документация.

2.2.14 Съгласуване на документацията, изпълнена с обосновани отклонения от действащите норми, правила и инструкции, по отношение на тези отклонения с органите за държавен надзор и заинтересованите организации, които са ги одобрили.

2.2.15 Потвърждение в материалите по проекта чрез подходящо вписване, че проектната и сметна документация за изграждане на предприятия, сгради и съоръжения е разработена в съответствие с нормите, правилата, инструкциите и държавните стандарти.

2.2.16 Участие в разглеждането и одобрението от генералния изпълнител на проектно-сметна документация в съответствие с процедурата, установена от Държавния комитет по строителството на СССР.

2.2.17 Защита на проекти във висши организации и изпитни органи.

2.2.18 Полеви надзор на строителството.

2.2.19 Изготвяне на предложения към ръководството на проектантската организация и клиента на проектно-сметна документация за извършване на промени в работната документация, свързани с въвеждането на нови нормативни документи, отчитайки действителното състояние на строителството.

3 Права на главния инженер (главен архитект) на проекта

3.1 Главният инженер (главен архитект) на проекта има право:

3.1.1 Представлява проектантската организация в институции, организации и предприятия по разработването, одобряването и прегледа на проектните разчети, строителството по одобрения проект и кореспондира по тези въпроси по начина, установен от проектантската организация.

3.1.2 Вземане на решения по технически въпроси по време на проектирането, изграждането, въвеждането в експлоатация на съоръжението и развитието на проектния капацитет.

3.1.3 Спиране на производството на определени видове СМР, когато те се извършват с отклонения от проекта, в случай на нарушение на техническите условия и правила за производството на тези работи, както и на тяхното незадоволително качество.

3.1.4 Да се ​​създаде, в съгласие с строителните и монтажните организации на изпълнителя, намалено количество работна документация.

3.1.5 Проверка на състоянието на разработването на проекта, правилно изразходване на средства за проектиране и проучване, спазване на установените срокове за проектиране и качеството на проектните решения в процеса на разработване на проектно-сметна документация.

3.1.6 Подаване на предложения до ръководството на проектантската организация за разработване на нови и изменение на съществуващи нормативни документи за проектиране, изграждане и експлоатация на съоръжения.

3.1.7 Вземане на решения относно използването на резерва от годишния обем работа за конкретни проекти.

3.1.8 Внасяйте предложения в ръководството на проектантската организация, за да насърчите служителите, които са се отличили при разработването на проекта, да участват в разпределението на бонуси между организации и подразделения - изпълнители, както и да правят предложения за налагане на наказания на отговорните за ненавременното и некачествено разработване на проектно-сметна документация.

4 Отговорност на главния инженер (главен архитект) на проекта

4.1 Главният инженер (главен архитект) на проекта носи установената от закона отговорност за техническото и икономическо ниво и архитектурните решения на строящите се обекти, за качеството, навременното разработване и пълнота на проектно-сметната документация, правилното определяне на прогнозните разходи и последователността на строителството, за постигане на проектните показатели от предприятията в установената условия, както и за изпълнение на всички задължения, възложени му с настоящия регламент.

Ключови думи: SNiP 1.06.04-85, Правилник за главния инженер (главен архитект) на проекта, текущ, статус, 2019

Главният инженер по проекти е ключова фигура в процеса на проектиране

М. С. Подолски, председател на Подкомисията за организация на дейностите на главните инженери по проекти на Комитета за технологично проектиране на промишлени съоръжения към Националната асоциация на дизайнерите и геодезистите, научен директор на Международната школа на главните инженери (главни архитекти) на проекти в MGSU

А. В. Литвинов, заместник генерален директор на Консултантския център "ЦНИО-проект", член на Съвета на Международното училище за главни инженери (главни архитекти) на проекти към MGSU

В съвременните икономически условия клиентът има възможност да избере проектна организация (софтуер) според оптималното съотношение на срокове, цена и качество на предлаганите услуги. С привидното равенство на изброените критерии, качеството на проектната документация може да се превърне в решаващо условие за успеха на софтуера в конкурса. Качеството на проектната документация се оценява както по обективни параметри - съответствие с изискванията на действащите норми и правила, така и по субективни - чрез максимизиране на удовлетвореността на клиентите. И тези, и други параметри непрекъснато се променят: клиентите преминават от стандартен дизайн към индивидуален дизайн, появяват се месечни промени и допълнения към нормативната, техническа и законодателна рамка, появяват се нови строителни материали, ново оборудване, технологии и др. Обичайният клиент е „доволен“ или „Не съм доволен“ от проектната документация се допълва от необходимостта от постоянно подобряване на удовлетвореността на клиентите и това е заложено в идеологията на международните стандарти ISO 9000 серия.

За да се осигури необходимото качество на продукта, софтуерът, ако не е в крак с научно-техническия прогрес, то поне е в крак, предлагайки на клиента нови, оригинални и надеждни дизайнерски решения.

Какво пречи на реалното подобряване на работата на главните инженери (главни архитекти) на проекти (GUI)? Според нас, първо, преобладаващите неправилни стереотипи по отношение на мястото и ролята на GUI в процеса на проектиране, които се предават от поколение на поколение дизайнери, и второ, недостатъчна квалификация на софтуерните мениджъри по въпроси, свързани с дейностите на GUI, което не им позволява да приемат адекватно решения, на трето място, липсата на ясна представа от какво се състои качеството на дадено дизайнерско решение и за каква част от него е отговорен графичният интерфейс, четвърто, опростено разбиране на механизма за формиране на качеството, включително кога то се прилага от подизайнерите, и накрая, пето, защото повечето дизайнери все още не осъзнават значението на ролята на графичния интерфейс за намаляване на разходите за проектиране.

Би било погрешно да се мисли, че софтуерните мениджъри и ISU не искат да премахнат горните причини, но опитите им не носят забележими резултати, защото вместо да разчитат на факти, които очевидно диктуват правилни решения, те се ръководят от миналия опит и субективни мнения, които не отговарят на изискванията на времето.

В процеса на обсъждане на тези въпроси често се озовавахме от противоположните страни на барикадата с много наши колеги - с един вид „колективен противник“, чиито възгледи се формираха исторически и който все още живее в миналата икономическа реалност. Тази статия е допълнително възражение срещу "колективния опонент".

Както знаете, съвременното ръководство препоръчва да се документират важни разпоредби, но появата на която и да е наредба трябва да бъде предшествана от формирането на принципи, които установяват, например, „по протежение на реката или отвъд нея“ ще бъде изграден мост. Това е съществена част от вземането на правила. На този етап трябва да се постигне консенсус в професионалната общност, след което всяко регулаторно ограничение не трябва да противоречи на договорените принципи.

За съжаление в действителност преобладават „лошите стереотипи“, които в повечето случаи нямат нищо общо не само с науката за организацията и управлението на производството, но често само със здравия разум..

Нека се спрем на някои, според нас, погрешни идеи, избавянето от които е истински резерв в развитието на дизайнерския бизнес:

1. GUI е отговорен за качеството на проектната (работна) документация, т.е. GUI е отговорен за всичко.

Това е невъзможно. Изискванията за позицията или, както се казва днес, „отговорност и авторитет“ на графичния интерфейс, исторически корелират с нарастващата сложност на изискванията към обектите за проектиране, както и с промените в очакванията на клиентите по отношение на резултатите от дизайна. В миналото проектирането и строителството се ръководеше от един експерт, който вземаше всички решения. Понастоящем основната задача на ISU е да осигури необходимата динамика на инвестициите, както и доход за клиента от изпълнението на проекта, достатъчен да компенсира инвеститорите за инвестираните от тях ресурси и поетия риск. По този начин всички решения при проектирането на GUI се взимат според критерия за икономическа ефективност при проектиране, изграждане и експлоатация на съоръжението. Оттук и изискванията за неговата квалификация. И все пак останалите участници в процеса на проектиране взимат решения по критерия техническа оптималност и това условие се прилага в процеса на съгласуване на проектните решения от главните специалисти в проектните раздели.

2. „Клетвата“ на GUI премахва отговорността за качеството на проектната (работната) документация от останалите участници в проектирането.

С други думи, ISU отговаря за спазването в проекта на норми и стандарти за проектиране, изграждане и експлоатация на съоръжения, стандарти на саморегулиращи се организации, индивидуални изисквания на клиентите за техническо ниво и качество, архитектурна изразителност и социална значимост на съоръженията. Считаме за необходимо да се върнем към значенията: отговорност за какво и в какви случаи.

Очевидно отговорността може да възникне, ако се разкрие отрицателен резултат от работата, който специалистът е извършил лично или лично го е проверил; ако има съответен подпис, подкрепен с дата, и също документиран за какво и на кого се носи отговорността и кога тя приключва. Това са предпоставки за лична отговорност. В противен случай колективната безотговорност надделява. Нека дадем пример. Както знаете, чертежите трябва да съдържат подписи: „разработен“, „проверен“ и „нормативен контрол“. Нека обърнем внимание на факта, че подписите се дават по отношение на действия, тоест те отговарят на въпроса: какво направихте? - развита; Какво направи? - изпълнен стандартният контрол и др. Невъзможно е да се допусне „инициативата“ на проектантските организации и появата на чертежите на подписи на ръководители на отдели, главни специалисти, главни инженери по проекти и др. Акцентът се измества и подписите започват да определят не „какво направи“, а „кой Направих".

Както бе споменато по-рано, подписът представлява отговорност. Без подпис - без отговорност. Тъй като отговорността има граници, е необходимо да се договорим къде отиват, тоест да се уверим, че всички еднакво разбират зоната на отговорност. Смисълът на споразумението е следният: всеки чертеж има съдържание ("какво" е показано) и дизайн ("как" е показано). Изпълнителят носи отговорност за съдържанието и дизайна. За съдържанието - пред инспектора, за дизайна - пред нормативния контролер. Отговорността на изпълнителя се прекратява в момента, в който инспекторът и регулаторният инспектор поставят своите подписи. След това е необходимо да се определи на кого са отговорни инспекторът и нормативният контролер. В идеалния случай това трябва да е клиент, който наистина се интересува от последователността на подписа и резултата. В самата дизайнерска организация е невъзможно да се намерят тези, които следват инспектора и стандартния контролер. Но може ли да е GUI? В този случай подписът на GUI ще означава, че той за пореден път е проверил съдържанието и дизайна на чертежа и е поел отговорност за себе си, включително „за съответствие в проекта с норми и стандарти за проектиране, изграждане и експлоатация на съоръжения...“ и т.н. и и т.н. Но GUI не може физически да провери всички дизайнерски решения за съответствие с всички стандарти и всички изисквания. Следователно налагането на отговорност на ISU за всичко като цяло не е нищо повече от заклинание, формално поради невъзможността за екзекуция и опасно, ако е необходимо, да бъде наказано за чужда вина. ISU е само един от многото автори на пиеса, наречена "изготвяне на проектна документация".

3. Ако на строителната площадка се случи нещо сериозно, тогава първият, който „затвори“ GIP.

Ако се случи нещо наистина сериозно, тогава следователят, като назначи съдебно-техническа експертиза или проведе няколко такива експертизи, ще определи проектанта, който например е извършил изчислението на конструкцията и е приложил грешен коефициент, тогава той ще определи този, който е проверил изчислението и това лице ще представи обвинение, но съдът при определени обстоятелства може да накаже изпълнителя и инспектора.

4. GUI трябва да бъде най-квалифицираният дизайнер във всички раздели на проекта.

Ясно е, че това просто не може да бъде, тъй като проектната документация съдържа поне десет специализирани раздела, работата по които включва присъствието на повече от двадесет специалности. Този „лош стереотип“ се разпростира и върху идеята за назначаването на специалист на длъжността главен инспектор. Препоръчително е обаче да се вземе решение за назначаването на GUI въз основа на състезателен подбор и да се ръководи от напълно различни критерии..

Кандидатът за длъжността главен инженер трябва да обоснове от кандидата възможността за постигане на по-високи технически и икономически показатели на проектираното съоръжение, намаляване на първоначалното проектиране и време за строителство, намаляване на трудоемкостта (разходите) на проектните работи, по-благоприятни условия за уреждане на проектантската организация с участниците в работата, както и разширяване на списъка с допълнителни изисквания клиент за обекта на проектиране (7.2.1 "d" GOST R ISO 9001-2008) и др. Репутацията на GUI е от особено значение: характер, общителност, усърдие, ангажираност, ефективност, точност, благоприличие, способност за договаряне, внимателност, учтивост, отзивчивост, ефективност и др..

За гражданските имоти икономическото и архитектурно образование може да бъде предимство, когато бъде назначен на длъжността главен архитект на проекта (GAP). Вторият приоритет е икономическото образование, третият е архитектурата и накрая просто инженерството.

За индустриални съоръжения (технологичен дизайн) предимство при назначаването на длъжността главен инженер по проекти (GIP) може да бъде наличието на икономическо образование и технологично образование, съответстващо на спецификата на обекта на проектиране. Вторият приоритет е икономическото образование, третият е технологичен и накрая просто инженерство.

И в първия, и във втория случай главният инженер (GAP) трябва да има квалификация по управление на проекти. Въз основа на резултатите от състезателния подбор ISU се назначава на длъжността със съответната заповед на ръководителя на софтуера.

5. Ако възникнат разногласия между основните специалисти по секциите на проекта, тогава ISU взема окончателното решение.

Нека си представим следната картина: Главният специалист - електротехник в неговия раздел на проекта е взел решение разпределителното табло да бъде между такива и такива оси и при такава и такава кота на сградата. Главният специалист, инженер по отопление, е разположил точка за отопление на същото място. Те идват в GIP, за да ги „помирят“. Естествено, квалификацията на всеки от главните специалисти по съответната специалност е по-висока от тази на главния инженер. Ако ISU обсъди този въпрос с тях в предложената техническа равнина, тогава той очевидно е в неравностойно положение. Той трябва да преведе дискусията в икономическа равнина, като заяви, че едната опция струва толкова много, а другата струва толкова много, като се вземат предвид не само строителните разходи, но и оперативните разходи, както и възможният риск, свързан с промени в цената на оборудването. Вземайки и обосновавайки своето решение от икономическа гледна точка, ISU, което носи отговорност за това решение пред инвеститора, трябва да потърси от специалистите подходящо техническо решение. Днес малко от GUI могат да действат по този начин, но това е целта на GUI, неговата част от отговорността за качеството на дизайнерските решения.

6. Главният инженер преди всичко трябва да има техническа специалност.

Вече говорихме каква специалност и защо трябва да има главният инженер. В условията на ускорените темпове на научно-техническо развитие качеството на проектната документация пряко зависи от системното подобряване на квалификацията на главните инженери. Днес ISU трябва да бъде компетентен в организацията и управлението на процеса на проектиране, методите за осигуряване на икономическата ефективност на проектирането, изграждането и експлоатацията на съоръжението, за да получи позицията си на конкурентна основа. Но дори и успешно работещите графични интерфейси се чувстват недостатъчно в знанията си по тези въпроси, те се опитват да компенсират независимо пропуските в своите компетенции.

За решаването на тези проблеми, по инициатива на Комитета за технологично проектиране на промишлени съоръжения NOPRIZ и Института по строителство и архитектура (ISA) на Националния изследователски Московски държавен строителен университет (MGSU), с участието на Консултантския център "ЦНИО-проект" и Комитета за продължаващо професионално образование в строителната индустрия Руският съюз на строителите (RCC) организира Международното училище за главни инженери (главни архитекти) на проекти. Училищният съвет включва известни специалисти в Руската федерация и страните от ОНД в областта на проектирането и осигуряването на качеството на проектната (работна) документация. Председател на Съвета на Международната школа за главни инженери (главни архитекти) на проекти Игор В. Мещерин има уникален опит в работата като главен изпълнителен директор и главен инженер в СССР, Русия, САЩ и Италия.

Информация за Международната школа на GIP (GAP), включително провеждането на специфични курсове, се публикува на уебсайтовете на ISA MGSU, Националната асоциация на дизайнерите и геодезистите, проект TsNIO, както и на уебсайтовете на проектори в Руската федерация, Казахстан, Беларус и Украйна.

Основната цел на Международната школа по GIPs е да осигури обучение на високопрофесионален персонал на GIPs чрез напреднало обучение. Програмите, които отговарят на съвременните изисквания, практическата ориентация на курсовете ни позволяват да отговорим на нуждите на технологичния и архитектурен и строителен дизайн, да поддържаме непрекъснат професионален растеж и възпроизвеждане на графични интерфейси, както и да подготвяме талант за запълване на позициите на графични интерфейси по поръчки на проектантски организации.

В „образователното портфолио“ на Международната школа на доставчиците на интернет услуги има два основни продукта:

Предложената система за преквалификация на GUI е гъвкава, адекватна на нуждите на времето, отговаряща на реалните нужди на дизайнерите, които са изключително заети с практическа работа. Съдържанието на програмите балансира теоретични и практически знания, както и опит в управлението на дизайна. Много е важно програмата да поеме широко териториално покритие на слушателите и удобството на обучението, включително чрез използване на съвременни принципи, форми и методи на преподаване: модулност, обучение „до точката“, вариабилност на продължителността на обучението, дистанционно обучение и т.н..

Основните теми, които се обсъждат в курсовете на Международната школа по GIPs в MGSU:

1. Ситуацията на строителния пазар и нейното въздействие върху дейността на главния изпълнителен директор.

2. Основните промени в съдържанието на понятието "система за управление на качеството" във връзка с работата на графичния интерфейс.

3. Разпределение в проектантската организация (ПО) на отговорността за разработването на дизайнерски решения и тяхното качество между първия ръководител, главен инженер, директор на производството, GUI, техническия отдел и производствените отдели (цехове) в процеса на подготовка, пускане и внедряване в конструкцията на проекта ) документация, включително контрол, проверка, анализ, съгласуване, валидиране и одобряване на документация за проектиране и оценка.

4. Изясняване на ролята и мястото на графичните интерфейси в „процеса от край до край” на софтуер, ориентиран към клиента: „взаимодействие със софтуерни клиенти” - „формиране и поддръжка на портфолио от софтуерни поръчки” - „подготовка и пускане / внедряване на проектна (работна) документация” - „подкрепа за внедряване проект в строителството "-" изпълнение на гаранционни задължения за софтуерни проекти, изпълнени в строителството ".

5. Ръководител на производствен отдел: дизайнер или ръководител (мениджър)? Взаимодействие с GUI. Основните обекти на управление на ръководителя на производствената единица: трудови ресурси, труд, време, финанси, материални ресурси; субординация, правомощия, основни функционални задължения (отговорност) на ръководителя на производствената единица, критерии за оценка на неговите дейности.

6. Процедурата за „стартиране” на работи по изготвяне на проектна документация в съответствие със сключения общ договор за проектиране. Образец на договор с подизпълнителна проектантска организация (STR); процедури за оценка, подбор (подбор) и преоценка на софтуер с отворен код; концепциите за подизпълнение и възлагане на външни изпълнители.

7. Взаимодействие на графичния интерфейс с договорния отдел, технически архив, отдел за издаване на проекти. Основни изисквания към главния изпълнителен директор в системата на изпълнителната дисциплина.

8. Анализ на новите отговорности на ISU; стандартна длъжностна характеристика на GUI; изисквания за графичния интерфейс по време на полевия надзор (включително от подизайнери); GUI и въпроси за техническо преоборудване, разширяване на предприятието, модернизация, основен ремонт и др..

9. Мониторинг на удовлетвореността на клиентите от процесите и резултатите от проектантската организация.

10. Ролята на GUI в разширяването на видовете продукти (услуги) на проектантската организация. Формиране на репутацията на GUI сред участниците в инвестиционния проект.

11. Управление на поддизайнери. Съвременни изисквания за подбор на участниците в дизайна.

12. Коментари по проектите на нови организационни и методологични документи за ISU: Стандарт за професионалните дейности на ISU, Препоръки за организиране на дейностите на ISU, Профил на ISU, Изисквания за подготовката и назначаването на ISU, които са разработени в Подкомитета за организиране на дейностите на главните инженери по проекти на Комитета за технологично проектиране на съоръжения за промишлени цели NOP тази година.

13. Преговори при сключване на договори и определяне на договорни цени. Видове договори.

14. Взаимодействие с държавна и недържавна експертиза.

15. Правни и организационни основи за проектиране, нормативни документи, свързани с работата на GUI, включително GOST R 54869-2011, както и системата EUROCODES.

16. Цената на проектантската работа. Основни индексни и ресурсни методи за изчисляване на разходите. Форми на сметна документация. Оценка на икономическата ефективност на проектните решения.

17. Управление на проектния риск. Определяне и идентифициране на рисковете (категории рискове, известни рискове и неизвестни рискове, големината на риска, вероятността за възникване и степента на влияние на риска) бюджетиране за управление на риска; определяне на вероятността от спазване на посочените срокове и бюджета на проекта; методи за реагиране на риска (избягване, прехвърляне, смекчаване и приемане); контрол на симптомите на риска.

18. Участие в търгове за получаване на договор за проектиране и проучване.

19. Основни разпоредби на системата за управление на качеството в проектантската организация, която отговаря на изискванията на ГОСТ ISO 9001-2015.

20. Функции и съдържание на техническия надзор на клиента. Държавен строителен надзор.

21. Компетентност на ISU по въпросите на самообразованието и професионалното развитие.

22. GUI, GAP във функционалните, организационни и финансови структури на проектантската организация.

23. Компетентност на ISU, свързана с маркетинг и продажби.

24. Компетентност на ISU по въпросите за определяне на неговите правомощия, права и отговорности.

25. Компетентност на ISU по въпроси за оценка на ефективността и ефикасността на неговите професионални дейности и мотивация.

От май 2015 г. допълнителен модул „Оценка на икономическата ефективност на дизайнерските решения“ (30 академични часа) е включен в програмата на Международната школа на доставчиците на интернет услуги. Общият обем на Програмата става 80 ак. час. Курсовете по този модул се провеждат от преподаватели от Държавната академия на инвестиционните специалисти (GASIS) на Националния изследователски университет "Висше училище по икономика". Студентите получават и GASIS сертификат.

Темите на образователните, консултантските и изследователските програми, предлагани от Международното училище на доставчици на интернет услуги, са фокусирани върху решаването на основните проблеми, с които се сблъскват в момента дизайнерските организации чрез реално напреднало обучение на ключови фигури в процеса на проектиране - доставчици на интернет услуги.

По основните теми от Програмата на Международната школа на GIPs Консултантският център "ЦНИО-проект" разработи конкретни препоръки.

А сега нека се обърнем към механизма за формиране на качеството на дизайнерските решения, за да се определят ясно и недвусмислено границите на отговорността на GUI.

Няколко общи разпоредби за дизайна:

1. Всеки проект за строителство е комбинация от три модела:

- модели на бъдещия обект (пространствено планиране и инженерни решения);

- модели на неговото създаване (проект за строителна организация);

- модели на неговото функциониране (Организация и управление на производството).

2. Формирането на дизайнерско решение се състои от действителното му приемане и след това е необходимо да се потвърди съответствието му, с други думи, да се провери. Самото приемане на решение за дизайн е избор от алтернативи, а потвърждаването на съответствието има много различни възможности и съответно много термини, които съответстват на тези опции. Повечето от опциите зависят от времето, местоположението и стандартите, които са избрани за потвърждение.

Качеството на дизайнерското решение се състои от четири основни свойства. Всяко от тези свойства се формира от някой в ​​софтуера и е предназначено за някого. Този, който формира качественото имущество, носи лична отговорност за това. Първият е „техническа осъществимост“, т.е. проектното решение трябва да бъде такова, че да може да бъде приложено по време на строителството. Необходим е преди всичко на строителен предприемач и се формира от техници, инженери и главни специалисти на производствените отдели. Второто е "информационна способност", т.е. проектното решение трябва да съдържа цялата информация, необходима за извършване на строително-монтажни работи, поръчка на оборудване, получаване на всички необходими разрешения и одобрения. Клиентът и строителният предприемач се нуждаят от него. Това свойство се формира от техници, инженери и главни специалисти на производствените отдели. Трето, „икономическата осъществимост“ на проектното решение, тоест дизайнерското решение трябва да бъде икономически конкурентноспособно в процеса на изграждане и експлоатация на съоръжението. Това е необходимо за основния човек на пазара - инвеститора, той се формира и ISU отговаря за това. Четвърто - „последователност“, тоест всички дизайнерски решения за проекта трябва да бъдат съгласувани. Това е необходимо преди всичко за самите дизайнери и за това отговарят основните специалисти в проектните раздели..

Дизайнерските решения се вземат на пет нива. Нека разгледаме тези нива, като използваме примера на секцията за проектиране на проекта. Първото ниво ще бъде "възли, подробности". На това технологично ниво се вземат решения за армировъчни мрежи, вградени части и др. Второто ниво са „елементи“. На това ниво инженерите проектират греди, колони, свободно стоящи основи и т. Н. Трето, „компоненти“. Старши и водещи инженери проектират плочи, покрития, ограждащи конструкции и др. Четвърто ниво "проектна част". На това ниво главният специалист взема решение за конструктивната схема на сградата и основните якостни параметри на конструкцията. Петото ниво е „технически и икономически показатели на проекта“. ISU отговаря за вземането на решения на това ниво..

Нека се позовем на "потвърждение за съответствие на проектното решение." Това са контрол, оценка, проверка, анализ, валидиране, съгласуване и одобряване на проектни решения. Тук е важно за нас да определим границите на отговорността на главния инженер.

Контролът включва корелация на приетото дизайнерско решение с настоящите норми (правила), т.е.регулаторните документи, които в момента действат в строителния сектор (Кодекс за градско развитие на Руската федерация, SNiP, SN, GOST, VSN и др.). Резултатът от контрола - „съответства“ или „не съответства“ проектното решение на посочените нормативни документи.

Оценка - същата процедура за контрол, само в допълнение към „съответства“ или „не съответства“ се посочва колко „съответства“ или „не отговаря“. Като правило резултатът от оценката се дава в количествено изражение, например, пожарната разлика между сградите е по-малка от стандартната с 10 метра.

Така нареченият стандартен контрол е в същия ред като контрола, с единствената разлика, че GOST SPDS се използва за сравняване на възприетото проектно решение с нормативни документи.

Проверката включва сравняване на възприетото проектно решение с входните проектни данни (проектно задание, първоначални проектни данни, технически условия). ГОСТ ISO 9001-2011 съвсем ясно установява изискванията за проверка на проектните решения, включително проверка на планирането и записване на резултатите. По-специално 7.3.5 гласи, че „в съответствие с планираните договорености трябва да се извърши проверка, за да се гарантира, че резултатите от проектирането и разработването отговарят на изискванията за проектиране и разработка. Записите за резултатите от теста и всички необходими действия трябва да се поддържат и поддържат. " Тъй като във „входните данни“ като правило се дават технически и икономически показатели (изисквания) за проектна документация, GUI проверява съответствието им с действителните.

Анализът - колективно действие под ръководството на GUI - позволява да се предскажат последиците от постоянството на съществуващия процес на проектиране по отношение на техническите и икономическите характеристики на проектните решения, цената на проектирането и неговата продължителност. Клауза 7.3.4 от ГОСТ ISO 9001-2011, както и за проверка, установява изисквания за анализа, а именно: „На подходящи етапи в съответствие с планираните дейности трябва да се извършват систематични прегледи на проектиране и разработка за оценка на способността на резултатите от проектирането и разработването отговарят на изискванията, както и идентифицират всички проблеми [проектиране и разработване] и предлагат необходимите действия. Участниците в такива прегледи трябва да включват представители на функции, свързани с етапа на проектиране и разработване, който се анализира. Записите за резултатите от анализа и всички необходими действия се поддържат и поддържат. " Имайте предвид, че анализът трябва да бъде планиран и документиран. Очевидно е също така, че анализът не може да се извърши в началото на проектирането, тъй като все още няма какво да се анализира и в края на проектирането, тъй като влакът вече е тръгнал и процесът е завършен. При проектирането ISU отговаря за анализа. Като правило, по време на процеса на проектиране, GUI периодично събира ръководителите на производствени отдели и главните специалисти в секциите на проекта и обсъжда с тях напредъка на проектирането и техническите и икономическите характеристики на взетите решения за проектиране, за да бъде сигурен, че в края на проекта получените дизайнерски материали ще съответстват на "входните данни".

Координацията предполага увереност, че това дизайнерско решение не противоречи на дизайнерските решения за други раздели на проекта, т.е., например, проектното решение на проектната част на проекта се сравнява с проектните решения на електрическите, санитарно-техническите или топлотехническите секции на проекта.

Отговорността за осигуряване на изпълнението на одобрението се носи от ISU, а съответните главни специалисти за секциите на проектите носят отговорност за правилността на одобрението..

Нека си припомним какво е „валидиране“. При проектирането са възможни две ситуации на потвърждение: в първия случай това може да се направи директно „на хартия“, тоест дизайнерското решение е на екрана на компютъра. Например, дизайнерско решение е изчислена и структурирана греда, която трябва да издържа на съответното натоварване. За да се потвърди съответствието, достатъчно е да се използва същия метод на изчисление, който е бил използван при вземането на това решение (или алтернативен) и ако този метод е доказан и надежден, тогава повторното изчисление ще даде абсолютна увереност в правилността на проектното решение. Или друг пример, в заданието за проектиране се посочва съставът на помещенията на съответния етаж на сградата и се посочват необходимите площи. Дизайнерското решение за този етажен план може лесно да бъде проверено чрез сравняването му с първоначалните данни. Трябва да се подчертае, че подобни дизайнерски решения в общия обем на проектиране са най-малко 80-90 процента. Те включват решения за проектиране, взети със стандартни проекти, стандартни възли и части, одобрени индивидуални предварително разработени дизайнерски решения, които се използват повторно, каталози на оборудването, които са сертифицирани по предписания начин и т.н., и др. С други думи, реч става въпрос за надеждни, тествани, многократно прилагани, несъмнени дизайнерски решения.

Втората ситуация е, когато проектното решение не може да бъде надеждно проверено с помощта на традиционни техники за проверка. Те могат да бъдат проверени само по време на строителството или експлоатацията на изграденото съоръжение, както и чрез провеждане на специални тестове в условия, които са възможно най-близки до изграждането или експлоатацията на съоръжението. Такава необходимост възниква, когато се използват усъвършенствани технологии или материали, вече препоръчани или обявени в реклами, нови методи за изчисление, оборудване, което никога досега не е използвано, технологични решения, които нямат аналози и др. Например, на изложението дизайнерите се запознаха с нов покривен материал която е силно рекламирана и характеристиките на този материал са впечатляващи.

Може да се вземе решение този материал да се приложи за покрив с площ от 20 хиляди квадратни метра, но е специално предвидено, че по време на строителството трябва първо да завършите участък от покрива от 10 квадратни метра, да създадете динамично натоварване върху него за определено време, да излеете вода отгоре и да видите как се държи долната повърхност на покрива в този случай. Ако резултатът от теста е положителен, тогава дизайнерите ще дадат разрешение за производството на останалата част от покрива. Понякога такава необходимост възниква поради голямата несигурност на геоложките условия в трудни строителни райони, когато златотърсачите не могат (включително, поради икономически причини) да моделират характеристиките на почвата с достатъчна точност на определени места на основите. В тези случаи те посочват необходимостта от забиване на тестови купчини и едва след това потвърждават възможността за подреждане на купчинно поле под целия обект..

Това е валидиране на дизайна. Използването на валидиране показва ангажираността на проектантската организация към всичко ново, авангардно. Това е знак за конкурентоспособността на дизайнерските решения, това е желанието да се заеме водеща позиция в дизайна чрез непрекъснатото подобряване на удовлетвореността на клиентите. GUI е отговорен за самия факт на валидирането, а основните специалисти за разделите на проекта са отговорни за съдържанието на валидирането..

Одобрението е разрешение за предаване на завършената проектна документация на клиента. Това е отговорност на GUI и той го прилага, когато подписва фактурата, преди да изпрати документацията на клиента..

Сега нека се обърнем към отговорността на GUI, свързана с намаляването на разходите за проектиране. Както знаете, има много възможности за намаляване на разходите и това е „главоболие“ за мениджмънта и всички водещи софтуерни специалисти, тъй като това е практически единственият начин за увеличаване на печалбите на проектантска организация. ISU допринася значително за това, като осъзнава отговорността за управлението (възлагането на външни изпълнители) на подизайнери.

Понастоящем е възможно да се изберат подизайнери (SSO) въз основа на резултатите от тяхната оценка, сравнение с конкурентите, редовно преоценяване и отговорността на GUI за този избор се появи. Между субектите в дизайна започна да работи важен принцип, „който плаща, той поръчва мелодията“, не само в определен традиционен смисъл, но и като изискване на генералния дизайнер (GP) постоянно да мисли за подобряване (осигуряване) на качеството и намаляване на разходите за проектни работи. В допълнение, законът установява, че само SE отговаря за качеството на проектната и прогнозна документация, разработена от софтуера с отворен код. Следователно е необходимо да се ръководим от изискванията на ГОСТ ISO 9001-2011 и Насоките за прилагане на аутсорсинг процеси // ISO / TS 176 / SC 2 / N 630R2, 24 ноември 2003 г.).

Като цяло могат да се разграничат три конвенционални типа софтуер с отворен код:

- „Обикновени“ - STR, с които ДП има нормални пазарни отношения;

- „Обикновени“ - НТ, с които ДП има нормални пазарни отношения;

- “Протежета” - създанието на клиента, връзката на SOE, с която клиентът определя.

Използвайки примера за връзки със софтуер с отворен код, ще разгледаме последователно всяка от подсистемите, като вземем предвид, че GUI в някои случаи взема решения, а в други участва в тяхното приемане..

Оценка, подбор и преоценка на подизайнерите.

Тази подсистема се състои от два блока:

- формиране и поддържане на Списъка (база данни, регистър и др.) на одобрен софтуер с отворен код и неговото актуализиране;

- избор на софтуер с отворен код от посочения списък за извършване на работа по конкретен проект.

Изпълнението на работа в рамките на първия блок е функция на техническия отдел на софтуера, в рамките на втория - отговорността на GUI.

За да формира Списъка, техническият отдел на софтуера търси, оценява, избира и преоценява софтуера с отворен код в съответствие с нуждите на софтуера, използвайки критериите, разработени заедно с GUI.

Ясно е, че подобен подход не гарантира пълната адекватност на STR за очакванията на SOE поради сложността на формализирането на някои въпроси. Например въпрос относно съществуването на валидна СУК и нейното съответствие с изискванията на ГОСТ ISO 9001-2011. Отвореният код отговаря, че СУК функционира и отговаря на изискванията, както е видно от сертификата на "N" -я сертифициращ орган. Опитът от оценката на изпълнението на определени изисквания на ГОСТ ISO 9001-2011 от саморегулиращи се организации на дизайнерите показва, че повече от 90% от сертификатите са получени официално, просто „закупени“ и често нямат нищо общо със специфичен софтуер с отворен код. Оказва се, че SE носи реална отговорност за качеството на проектната (работна) документация, изготвена от софтуера с отворен код, но изборът на софтуер с отворен код се основава на „уверенията“ на самия софтуер с отворен код под формата на отговори на въпросника. Когато проектира конкретен обект, GUI по правило избира подходящ софтуер с отворен код от Списъка, като се ръководи от допълнителни критерии, включително териториалното местоположение на софтуера с отворен код, осведомеността на софтуера с отворен код за свойствата на конкретна строителна площадка, предишни контакти с конкретен клиент, готовността на софтуера с отворен код за изпълнение на поръчки и други..

Преди да реши да включи софтуер с отворен код в дизайна, GUI трябва да посети директно организацията. Това е новата отговорност на ISU. Тази технология е осигурена от серията ISO 9000 и се нарича „одит на втора страна“. Продължителността на одита от втората страна е не повече от един работен ден (оптимално 3-4 часа).

Подобна кратка продължителност се обяснява с факта, че не се разглежда цялата система за управление на качеството на софтуера с отворен код, а само отделни ключови моменти. Практиката показва, че ако всичко е нормално в тези точки, тогава с висока степен на вероятност STR ще отговори на очакванията на SO.

Трябва да се подчертае, че Клиентът се занимава само със SOE, с което има сключен договор. Той може да не познава останалите участници в проекта. Следователно връзката с STR е единствен проблем за държавните предприятия. SPO всъщност действа като допълнителна структурна единица на SE, която в процеса на изпълнение на проекта трябва да се управлява от него по същия начин като "неговите" структурни подразделения, като се има предвид времето и качеството на проектната (работна) документация, разработена от SE, за която SE отговаря клиентът. Това също така определя отговорностите на SOE за управление на софтуер с отворен код..

Видът и обхватът на управлението с отворен код могат да варират в значителен диапазон: от минимума, когато на отворения код е издадено техническо задание и извършената работа се приема практически без проверка, до максимума, когато се изисква отвореният код да се ръководи при изпълнение на поръчката от ръководството и други документи, одобрени от държавното предприятие. В същото време се извършва пълна проверка на завършената документация за проектиране и оценка на отворения код, включително с участието на независими експерти.

Необходимият обхват на управление се определя от ISU в зависимост от резултатите от оценката (преоценката) на STR, включително като се вземе предвид информацията, получена по време на одита от втората страна, както и в зависимост от планираните разходи на SP за провеждане на входящия контрол на материалите на STR, като се има предвид, че тези разходи увеличават разходите за работа по проекта.

Характеристики на управлението на софтуер с отворен код GUI трябва да се формализира в „специалните условия“ на споразумението за подизпълнение. Техническият отдел на SOE разработва шаблон за такива „специални условия“, който описва почти всички възможни и / или необходими аспекти на управлението на софтуер с отворен код, а GUI, когато анализира конкретен договор със софтуер с отворен код, включва тези методи за управление, които отговарят на условията на конкретен проект. Колкото по-дълбока е степента на управление на отворения код, толкова по-малък е обемът на входящия контрол на дизайнерските материали на отворения код и, следователно, цената на SE.

Такива методи за управление могат да включват необходимостта от:

- одобрение на процеса на проектиране, използван от SPO, или осигуряване на изпълнението на проектни работи, използвайки процеса на проектиране, използван от SP;

- съгласуване на работния график за дизайна, който софтуерът с отворен код трябва да разработи въз основа на работния график, приложен към договора;

- назначаване (в съгласие с личния лекар) на конкретен GUI (мениджър на проекта) за поръчката, прехвърлена за изпълнение (раздел на проекта) и др..

В зависимост от степента на управление на софтуера с отворен код, обхватът на входящия контрол в SOE може да варира от 100% до почти никакъв, т.е. формално преизчисляване на проектните документи, получени от софтуера с отворен код.

След прехвърлянето на завършената проектна и сметна документация на клиента или след пускането в експлоатация на съоръжението (ако е бил извършен полевият надзор), GUI трябва да завърши проекта за възлагане.

Това изисква:

- проверява наличността на документи, потвърждаващи приемането на проектна и прогнозна документация от софтуер с отворен код, включително проверка на качеството на посочената документация;

- оценява сътрудничеството с STR и докладва резултатите на техническия отдел за актуализиране на Списъка;

- получаване от софтуера с отворен код и прехвърляне в архива на GP информация за разработените индивидуални ефективни дизайнерски решения, включително в документацията за софтуер с отворен код, която може да бъде препоръчана за повторна употреба;

- подгответе официален преглед за софтуер с отворен код;

- разрешаване на въпроса (ако е необходимо и възможно) относно икономическите стимули за софтуера с отворен код.

Сега за отговорността на графичния интерфейс, който е свързан с участие във формирането на „портфолио от поръчки“ и намаляване на софтуерните разходи за намиране на нови клиенти.

Въпросът е, че в съответствие с точка 7.2.1 "Процеси, свързани с потребителите" GOST ISO 9001-2011, софтуерът трябва да дефинира изискванията:

1. Посочено от клиента, включително изискванията за дейности по доставка и след доставка.

2. Не е посочено от клиента, но е необходимо за конкретното или предвиденото използване на проектната и сметна документация, когато е известно.

3. Законодателни и други задължителни, свързани с проектно-сметна документация.

4. Всеки допълнителен, специфичен софтуер.

Какво се разбира под първите три групи изисквания (1-3) е повече или по-малко ясно. Нека допълнително изясним, че „изискванията, които не са декларирани от клиента, но са необходими за конкретна или предвидена употреба на проектната и сметна документация, ако са известни“, могат да включват всички изисквания на самия софтуер, от изпълнението на които зависи качеството, цената и времето за доставка на проектната документация.

Например, ако клиентът получи документация за проектиране и оценка, която в съответствие със съществуващата технология за проектиране се съхранява за определено време, преди да бъде прехвърлена на клиента в техническия архив, тогава изискванията на самия софтуер относно условията за съхранение на посочената документация в архива ще се отнасят до точка 7.2.1 (2) от стандарта... Изпълнявайки изискванията, посочени в точка 7.2.1 (1-3) от стандарта, софтуерът не може да спечели конкурентни предимства, тъй като тези изисквания задължително се прилагат от всички конкуренти. При пазарни условия оцелява само софтуер, който може да определи и изпълни изискванията на точка 7.2.1 (4). Ние нарекохме тези изисквания „приети“ и изяснихме значението им: първо, те са „познати“, формулирани от самия софтуер, второ, те не са одобрени или съгласувани с клиента и, трето, изпълнението им се извършва за наша сметка BY. В резултат на това клиентът получава проектна документация (услуги) с неочаквани за него параметри или с параметри, по-добри от очакваното, което гарантира не само удовлетвореност на клиента, но го радва с предоставената проектна и разчетна документация (предоставена услуга). В последния случай софтуерът може да бъде сигурен, че клиентът ще се връща към него многократно. Както знаете, задържането на клиент е 5-7 пъти по-евтино от търсенето на нов. Това е същността на принципно нова разпоредба, заложена в ГОСТ ISO 9001-2011.

За да може изпълнението на изискването, посочено в точка 7.2.1 (4) на стандарта, да окаже влияние върху формирането на конкурентните предимства на софтуера, е необходимо да се определи собственикът на процеса за формиране на очакваните изисквания на клиентите, т.е. един от лидерите, които ще установи правилата за изпълнение на тази дейност. Що се отнася до софтуера, собственикът на процеса най-вероятно ще бъде главният инженер на института. „Собственикът“ на процеса, т.е. специалистът, който формира очакваните изисквания на клиента за конкретен проект, трябва да бъде GUI. За да се изясни, GUI е отговорен за това, че са определени бъдещите изисквания на клиента, а главните специалисти на производствените отдели са отговорни за съдържанието на тези изисквания..

Друга отговорност на GUI се формира при анализ на договора (споразумението) с клиента. Апелацията на клиента към софтуера може да бъде по различни начини: информация за спечелената оферта (конкурс); официално писмо с предложение за разработване на проектна документация; телефонно обаждане до софтуерния мениджър; неформално обжалване чрез колеги и др. По време на получаване на един от горните сигнали се препоръчва да се назначи GUI, който ще управлява анализа на договора, преди той да бъде подписан от клиента.

Тази отговорност на ISU включва:

- определяне на кръга от лица, които ще участват в одобряването на проекта на споразумение и разпределението на отговорността между тях;

- ангажиране на гореспоменатите мениджъри и специалисти за провеждане на преговори (работни срещи) с клиента за обсъждане на отделни разпоредби от проекта на споразумение, включително преговори за определяне на договорната цена;

- избор от основата на шаблон на подходяща опция за конкретен клиент и обект на дизайн;

- определяне на необходимостта и възможността за привличане на подизайнери и провеждане на предварителни преговори с тях;

- оценка на рисковете, които могат да съпътстват изпълнението на софтуера от неговите задължения по договора.

Всяко от тези действия в днешните условия се различава значително от познатата ни практика. Например одобрението на проект на договор по правило се изготвя на „Лист за одобрение“, където се посочват пълното име и длъжността на съответния ръководител, който, ако е взето положително решение, се подписва или ако отрицателно мотивира своето мнение. Според нас е необходимо да се установи отговорността на управителя за съответните клаузи на проекта на споразумение. Сборът от точки в "Листа за одобрение" трябва да бъде равен на сумата от точките в проектоспоразумението. Това гарантира личната отговорност на всеки ръководител за изпълнението на условията на договора от проектантската организация и същото разбиране на съответните условия на проекта на договор от проектантската организация и клиента и т.н..

Някои дизайнери могат да възразят срещу материала в тази статия. Готови сме за конструктивна дискусия с колеги във форма, удобна за тях..