За състава на секциите проектна документацияспоред нормите на Руската федерация и специфични изисквания за регистрация, вижте Резолюция 87. Мнозина се интересуват от действащото законодателство и неговите обяснения за тази резолюция, така че трябва да разберете какво ново в този закон се появи за тази година и какво списъкът с неговите изисквания изглежда така.
относно състава на проектната документация
При писането на тази разпоредба правителството се позовава на градоустройственото планиране и неговото руски код. Съгласно чл. 48 от този кодекс е установено съдържанието на документацията. Основните изисквания започнаха да се подават от министерството, в чиято компетентност е строежът, както и службата за сигурност на федерацията. Също така Федерацията може да получи препоръки относно подготовката на документи чрез държавния транспортен орган. Допълнително изискване може да бъде направено при поискване от много други услуги. Първото издание и разясненията трябваше да влязат в сила през февруари 2008 г. След това, в края на февруари, беше дадено обозначение на всеки аспект от изискванията.
Изменения във Федералния закон за състава на проектната документация
Постановление на правителството на Руската федерация относно състава на проектната документация от 16 февруари 2008 г. 87 с промени трябваше да бъде одобрено през януари 2016 г. Преди това повече от един участък с решение на правителството беше променен през април и в края на април, през декември, март, август, юли, май и юни от миналите години. Последна редакцияс решение на пленума, получи малко допълнение и някои параграфи ще бъдат въведени в нова редакция. Днес можете да прочетете редакцията безплатно. от 2016 г. през вашия компютър или изтеглете плана на позицията.
Позиция Руска федерацияотносно състава на проектната документация с промени съдържа следните раздели:
- Основни положения;
- Съставът на проекта за линеен строителен процес;
- Съставът на разделите на капиталния производствен и непроизводствен строителен процес.
Коментари по Резолюция 87
Последните коментари по плановата документация за този закон ясно показват уместността на новите разпоредби. Например, федералният законима списък с изисквания за работния етап на проектиране. Във връзка с коментарите може по-точно да се разбере какво да се прави, ако е изпълнено условието от конкретен пост в закона, как действа силата на това постановление и как системата извършва технологичен надзор.
Клетва на GIP по 87-ма резолюция
Тази разпоредба на Руската федерация не регулира клетвата на GIP, въпреки че трябва да има негова бележка или запис към проекта. Винаги трябва да има заверка, печат и подпис на ISU. Това ви позволява да предоставите информация, че проектната схема е написана в съответствие с изискванията и разработката е официално сертифицирана.
Списък на разделите на проектната документация съгласно 87 Федерален закон
В зависимост от конструкцията, за която се изисква да се приложи тази разпоредба, извадката и етапът на компилацията се променят. Общо допълнението към закона съдържа два вида строителство - линейни обекти и капитално строителство. Струва си да класифицирате даден обект и да приложите към него правила за текст и графичен дизайн. Помощта по тази тема се отхвърля от мнозина правни портали, като технически експерт, консултант или консултант плюс. Това предполага, че днес редът на писане на проекти е интересен за повече от една организация. Струва си да проверите състоянието поземлен имот, сгради и постройки съгласно този закон, след което го следва писмено.
Обща обяснителна бележка към Указ 87
Съгласно текста на разпоредбата е мотивирана общата обяснителна записка и нейното развитие. Проектът трябва да съдържа такива томове и раздели, които са описани в резолюцията. Например трябва да се посочи оценка, доставка на електроенергия, важни кодове, наличност на мрежата, екологичен аспект на проекта, безопасност и експертни познания, енергийна ефективност и т.н. Също така самият проект трябва да действа като гарант за правилното развитие, например, важно е да се запази околната среда, ако това е документ за атомна централа или автомивка в Москва. Ако важен обществен възел е блокиран или ако част от инфраструктурата трябва да бъде премахната, трябва да се приложат разрешителни. ДА СЕ готов документможе да се използва подвързване или сгъване, като се поставя и датата на приемане.
Публикувано на 01.04.2015 г
М. С. Подолски, председател на подкомисията по организацията на дейностите на главните инженери на проекта на комисията за технологично проектиране на промишлени съоръжения на Националната асоциация на дизайнерите и геодезистите, научен съветник Международно училищеГлавни инженери (главни архитекти) на проекти в MGSU
А. В. Литвинов, зам генерален директорКонсултантски център "ЦНИО-проект", член на Съвета на Международната школа на главните инженери (главни архитекти) по проекти към Московския държавен университет по строителство
IN съвременни условияуправление, клиентът има възможност да избере проектантска организация (софтуер) според оптималното съотношение на срокове, цени и качество на предлаганите услуги. При привидното равенство на горните критерии именно качеството на проектната документация може да се превърне в решаващо условие за успеха на софтуера в състезание. Качеството на проектната документация се оценява както по обективни параметри - съответствие с изискванията на съществуващите норми и правила, така и по субективни - максимално задоволяване на изискванията на клиента. И тези, и други параметри непрекъснато се променят: клиентите преминават от стандартен дизайн към индивидуални, месечни промени и допълнения към регулаторните и техническите и законодателна рамка, нов Строителни материали, ново оборудване, технологии и т.н. Обичайният „доволен“ или „недоволен“ клиент от проектната документация се допълва от необходимостта от постоянно подобряване на удовлетвореността на клиентите и това е заложено в идеологията на международните стандарти от серия ISO 9000.
Да предоставя необходимо качествопродукти, софтуерът трябва, ако не, да бъде в крак с научно-техническия прогрес, тогава поне поддържайте, предлагайки на клиента нови, оригинални и надеждни дизайнерски решения.
Какво пречи на реалното подобряване на работата на главните инженери (главни архитекти) на проекти (изпълнителни директори)? Според нас, първо, преобладаващите погрешни стереотипи относно мястото и ролята на GUI в процеса на проектиране, които се предават от поколение на поколение дизайнери, и второ, недостатъчната квалификация на софтуерните мениджъри по въпроси, свързани с дейността на GUI, което не им позволява да вземат адекватни решения, трето, липсата на ясна представа от какво се състои качеството на дизайнерското решение и за каква част от него отговаря GUI, четвърто, опростено разбиране на механизъм за формиране на качество, включително когато се прилага от поддизайнери, и накрая, пето, защото повечето дизайнери все още не осъзнават важността на ролята на GUI за намаляване на разходите проектантска работа.
Би било погрешно да се мисли, че самите софтуерни мениджъри и GUI не искат да се справят с горните причини, но техните опити не водят до забележими резултати, защото вместо да разчитат на факти, които ясно диктуват правилните решения, те се ръководят от минал опит и субективни мнения, които не отговарят на изискванията на времето.
В процеса на обсъждане на тези въпроси често се оказвахме от двете страни на барикадата с много наши колеги – с един вид „колективен опонент“, чиито възгледи са формирани исторически и който все още живее в отминалата икономическа реалност. Тази статия е допълнително възражение срещу "колективния опонент".
Както е известно, модерен мениджмънтпрепоръчва документираневажни разпоредби, но появата на всяка регулация трябва да бъде предшествана от формирането на принципи, които установяват, например „покрай или през реката“ ще бъде построен мост. Това е най-важната част от създаването на правила. На този етап трябва да се постигне консенсус в професионалната общност, след което всяко нормативно ограничение не трябва да противоречи на договорените принципи.
За съжаление, в действителност триумфират „лошите стереотипи“, които в повечето случаи нямат нищо общо не само с науката за организиране и управление на производството, но често просто със здравия разум.
Нека се спрем на някои, според нас, погрешни идеи, отърваването от които е истински резерв в развитието на дизайнерския бизнес:
1. GUI отговаря за качеството на проектната (работната) документация, т.е. GUI отговаря за всичко.
Това е невъзможно. Изискванията към длъжността или, както се казва днес, „отговорността и правомощията“ на GUI исторически са свързани със сложността на изискванията към дизайнерските обекти, както и промените в очакванията на клиентите по отношение на резултатите от дизайна. В миналото проектирането и строителството се ръководеше от един специалист, който вземаше всички решения. Понастоящем основната задача на GUI е да осигури необходимата динамика на инвестициите, както и приходи за клиента от изпълнението на проекта, достатъчни да компенсират инвеститорите за вложените от тях ресурси и поетия риск. По този начин всички решения при проектирането на GUI се вземат според критерия икономическа ефективностпроектиране, изграждане и експлоатация на съоръжението. Оттук и изискванията към неговата квалификация. Всички останали участници в процеса на проектиране вземат решения според критерия за техническа оптималност и това условие се реализира в процеса на координиране на проектните решения от главните специалисти по разделите на проекта.
2. "Клетвата" на GUI освобождава останалите участници в проектирането от отговорност за качеството на проектната (работната) документация.
С други думи, GIP отговаря за спазването на нормите и стандартите за проектиране, изграждане и експлоатация на съоръженията, стандартите на саморегулиращите се организации, индивидуалните изисквания на клиента за техническо ниво и качество, архитектурна изразителност и социална значимост на съоръженията. в проекта. Считаме за необходимо да се върнем към значенията: отговорност за какво и в какви случаи.
Разбира се, отговорност може да възникне, ако се разкрие отрицателен резултат от работата, която специалистът е извършил лично или лично го е проверил; ако има подходящ подпис, подкрепен с дата, а също и документиран, за какво и пред кого се носи отговорност и кога приключва. Това задължителни условияза лична отговорност. В противен случай тържествува колективната безотговорност. Да вземем пример. Както знаете, чертежите трябва да бъдат подписани: „разработен“, „проверен“ и „стандартен контрол“. Нека обърнем внимание на факта, че подписите са дадени по отношение на действията, тоест отговарят на въпроса: какво направихте? - развити; Какво направи? - извършен нормативен контрол и др. Не трябва да допускаме "аматьорски дейности" на проектантските организации и появата на чертежите на подписи на ръководители на отдели, главни специалисти, главни инженери и др. Акцентите се изместват и подписите започват да определят не " какво направи", но "кой направи".
Както вече споменахме, подписът представлява отговорност. Без подпис - без отговорност. Тъй като отговорността има граници, е необходимо да се споразумеят къде отиват, тоест да се уверите, че всеки разбира зоната на отговорност по един и същи начин. Значението на споразумението е следното: всеки чертеж има съдържание (показва се „какво“) и дизайн (показва се „как“). Изпълнителят носи отговорност за съдържанието и дизайна. За съдържанието - пред инспектора, за дизайна - пред нормоконтролора. Отговорността на изпълнителя отпада в момента, в който инспекторът и нормативният контрольор положат своите подписи. След това е необходимо да се определи пред кого са отговорни инспекторът и нормативният контрольор. В идеалния случай това трябва да е клиент, който наистина се интересува от съпоставяне на подписа и резултата. В проектантска организацияневъзможно е да се намерят тези, които следват инспектора и нормативния контрольор. Но може ли да е GUI? В този случай подписът на GUI ще означава, че той отново е проверил съдържанието и дизайна на чертежа и е поел отговорност, включително за „спазване в проекта на норми и стандарти за проектиране, изграждане и експлоатация на съоръжения ... ”, и т.н. и т.н. Но е физически невъзможно GUI да провери всички дизайнерски решения за съответствие с всички стандарти и всички изисквания. Следователно, налагането на GUI отговорен за всичко като цяло не е нищо повече от заклинание, формално поради невъзможността за изпълнение и опасно, ако е необходимо, за наказване за вина на някой друг. ISU е само един от многото автори на пиеса, наречена „Документация на проекта“.
3. Ако нещо сериозно се случи на строителната площадка, тогава GUI ще бъде първият, който ще бъде „затворен“.
Ако се случи нещо наистина сериозно, тогава следователят, след като е назначил съдебно-техническа експертиза или след извършване на няколко такива експертизи, ще определи проектанта, който например е извършил изчислението на конструкцията и е приложил грешен коефициент, след което ще определи този, който е проверил изчисляването и именно това лице ще повдигне обвинение, но съдът при определени обстоятелства може да накаже изпълнителя и инспектора.
4. GUI трябва да е най-квалифицираният дизайнер във всички области на проекта.
Ясно е, че това просто не може да бъде, тъй като проектната документация съдържа най-малко десет специализирани раздела, работата по които предполага наличието на повече от двадесет специалности. Този „лош стереотип“ се простира и до идеята за назначаване на специалист на поста главен изпълнителен директор. Въпреки това е препоръчително да вземете решение за назначаване на главен изпълнителен директор въз основа на конкурсен подбор и да се ръководите от съвсем различни критерии.
Кандидатът за длъжността главен инженер трябва да обоснове от кандидата възможността за постигане на по-високи технически и икономически показатели на проектираното съоръжение, намаляване на първоначалното време за проектиране и строителство, намаляване на трудоемкостта (цената) на проектантската работа, по-благоприятно за условията за организация на проектиране за селища с участници в работата, както и разширяване на състава допълнителни изискванияклиент за обекта на проектиране (7.2.1 "d" GOST R ISO 9001-2008) и др. Репутацията на GUI е от особено значение: характер, общителност, старание, ангажираност, ефективност, точност, почтеност, способност за преговори, внимание, учтивост, отзивчивост, изпълнителност и др.
За граждански обекти предимство при назначаването на длъжността Главен архитект на проекта (ГАП) може да бъде наличието на икономическо и архитектурно образование. Вторият приоритет е икономическото образование, третият е архитектурното и накрая само инженерното.
За индустриални съоръжения(технологично проектиране) предимство при назначаването на длъжността главен инженер по проекта (ГИП) може да бъде наличието на икономическо образование и технологично, съответстващо на спецификата на обекта на проектиране. Вторият приоритет е икономическото образование, третият е технологичното и накрая само инженерството.
И в първия, и във втория случай PIU (GAP) трябва да има квалификация по управление на проекти. Въз основа на резултатите от конкурсния подбор изпълнителният директор се назначава на длъжността със съответната заповед на ръководителя на софтуера.
5. При разногласия между главните специалисти по участъците на проекта окончателното решение се взема от ISU.
Представете си следната картина: Главният специалист - електротехник в своя участък от проекта решава таблото да бъде между едни и същи оси и на еди-коя си маркировка на сградата. Главният специалист – топлоинженер на същото място разположи отоплителен пункт. Те идват в GUI, за да ги "помирят". Естествено, квалификацията на всеки един от главните специалисти по съответната специалност е по-висока от тази на главния изпълнителен директор. Ако ISU обсъди този въпрос с тях в предложената техническа област, тогава очевидно е в неизгодно положение. Той трябва да преведе дискусията в икономическа равнина, като каже, че единият вариант струва толкова, а другият струва толкова, като се вземат предвид не само строителните разходи, но и оперативните разходи, както и възможен рисксвързани с промени в цената на оборудването. При вземане и обосновка на решението си от икономическа гледна точка, GUI, който отговаря за това решение пред инвеститора, трябва да потърси подходящо техническо решение от специалисти. Днес малко от GUI могат да действат по този начин, но това е мисията на GUI, неговата част от отговорността за качеството на дизайнерските решения.
6. GUI трябва да има преди всичко техническа специалност.
Вече говорихме за това каква специалност и защо трябва да има GIP. В условията на ускорен темп на научно и технологично развитие качеството на проектната документация пряко зависи от систематичното подобряване на уменията на главните изпълнителни директори. Днес изпълнителният директор трябва да е компетентен в организацията и управлението на процеса на проектиране, методите за осигуряване на икономическата ефективност на проектирането, изграждането и експлоатацията на съоръжението, за да получи позицията си на конкурентна основа. Но дори успешните изпълнителни директори усещат липсата на знания по тези въпроси, опитвайки се самостоятелно да компенсират пропуските в своите компетенции.
За решаването на тези проблеми, по инициатива на Комитета за технологично проектиране на промишлени съоръжения на NOPRIZ и Института по строителство и архитектура (ISA) на Националния изследователски Московски държавен строителен университет (MGSU), с участието на TsNIO- проект Консултативен център и Комитета за непрекъснато професионално образованиев строителната индустрия Руският съюз на строителите (RCC) организира Международното училище за главни инженери (главни архитекти) на проекти. Училищният съвет включва известни специалисти в Руската федерация и страните от ОНД в областта на проектирането и осигуряването на качеството на проектната (работна) документация. Председател на Управителния съвет на Международното училище за главни инженери (главни архитекти) на проекти Мещерин Игор Викторович има уникален опит в работата като главен архитект и главен архитект в СССР, Русия, САЩ и Италия.
Информация за Международното училище по GUI (GAS), включително провеждането на конкретни курсове, е публикувана на уебсайтовете на ISA MGSU, Националната асоциация на дизайнерите и геодезистите, проекта TsNIO, както и на уебсайтовете на Projectant в Руската федерация, Казахстан, Беларус и Украйна.
Основната цел на Международното училище за GUI е да постави Йо m повишаване на квалификацията, за да се осигури обучението на високо професионален персонал на главните изпълнителни директори. Програми, които отговарят на съвременните изисквания, практическата ориентация на курсовете ви позволяват да отговорите на нуждите на технологичния и архитектурния дизайн, да поддържате непрекъснато професионално развитиеи възпроизвеждане на GUI, както и да се изготвят по поръчка на проектантски организации кадрови резервза заемане на позиции на изпълнителни директори.
Има два основни продукта в "образователното портфолио" на International School of GUI:
Предложената система за преквалификация на GUI е гъвкава, адекватна на нуждите на времето, отговаряща на реалните нужди на изключително заетите практическа работадизайнери. Съдържанието на програмите балансира теоретични и практически знания, както и опит в управлението на дизайна. Много е важно програмата да предполага широко териториално покритие на студентите и удобството на обучение, включително чрез използване на съвременни принципи, форми и методи на обучение: модулност, обучение „до резултата“, вариативност по отношение на обучението, дистанционно обучение и др.
Основните теми, които се обсъждат в курсовете на Международното училище по GIP в MGSU:
1. Ситуацията на строителния пазар и нейното въздействие върху дейността на GIP.
2. Основните промени в съдържанието на понятието "система за управление на качеството" във връзка с работата на ISU.
3. Разпределение в проектантската организация (PO) на отговорността за разработването на дизайнерски решения и тяхното качество между първия мениджър, главен инженер, производствен директор, GUI, технически отдел и производствени отдели(работилници) в процеса на изготвяне, издаване и внедряване на проектна (техническа) документация в строителството, включително контрол, проверка, анализ, одобряване, валидиране и одобрение на проекти и бюджетна документация.
4. Изясняване на ролята и мястото на GUI в „процеса от край до край“ на ориентирания към клиента софтуер: „взаимодействие с клиентите на софтуера“ – „формиране и поддръжка на портфолио от софтуерни поръчки“ – „подготовка и издаване/изпълнение на проектна (работна) документация" - "подкрепа за изпълнение на проекта в строителството" - "изпълнение на гаранционни задължения за софтуерни проекти, изпълнявани в строителството".
5. Ръководителят на производствената единица: дизайнер или ръководител (мениджър)? Взаимодействие с GUI. Основните обекти на управление на ръководителя на производствената единица: трудови ресурси, работа, време, финанси, материални ресурси; подчинение, власт функционални отговорности(отговорност) на ръководителя на производственото звено, критерии за оценка на дейността му.
6. Процедурата за "стартиране" на работа по изготвяне на проектна документация в съответствие със сключеното общо споразумение за проектиране. Примерен договордоговор с проектантска организация подизпълнител (SPO); процедури за оценка, селекция (подбор) и преоценка на STR; концепции за подизпълнение и аутсорсинг.
7. Взаимодействие на GUI с договорен отдел, технически архив, отдел за освобождаване на проекти. Основни изисквания към GUI в системата на изпълнителската дисциплина.
8. Анализ на новите отговорности на ISU; типичен описание на работата GUI; изисквания към GUI при авторски надзор (включително от подпроектанти); GUI и въпроси на техническото преоборудване, разширяване на предприятието, модернизация, основен ремонти т.н.
9. Мониторинг на удовлетвореността на клиентите от процесите и резултатите на проектантската организация.
10. Ролята на GUI в разширяването на видовете продукти (услуги) на проектантската организация. Формиране на репутацията на ISU сред участниците в инвестиционния проект.
11. Управление на поддизайнера. Съвременни изискваниякъм подбора на участниците в проектирането.
12. Коментари по проекти на нови организационни и методически документи за ISU: Стандарт професионална дейностГлавен инженер, Препоръки относно организацията на дейността на главния изпълнителен директор, Профил на главния изпълнителен директор, Изисквания за подготовка и назначаване на длъжността главен изпълнителен директор, които са разработени от Подкомитета по организацията на дейностите на главните инженери на проекта на Комитета за технологично проектиране на производствени мощности на NOP през текущата година.
13. Договаряне на договори и определяне на договорни цени. Видове договори.
14. Взаимодействие с държавна и недържавна експертиза.
15. Правни и организационни основи за проектиране, нормативни документи, свързани с работата на GUI, включително GOST R 54869-2011, както и системата EUROCODE.
16. Цената на проектантската работа. Базово-индексни и ресурсни методи за изчисляване на себестойността. Форми на бюджетна документация. Оценка на икономическата ефективност на проектните решения.
17. Управление на риска по проекта. Дефиниране и идентифициране на рискове (категории рискове, известни рискове и неизвестни рискове, величина на риска, вероятност за възникване и степен на въздействие на риска); Бюджетиране за управление на риска; определяне на вероятността за изпълнение на определените срокове и бюджет на проекта; методи за реагиране на риска (избягване, прехвърляне, смекчаване и приемане); контрол на рисковите симптоми.
18. Участие в търгове за сключване на договор за проектиране и проучване.
19. Основните разпоредби на системата за управление на качеството в проектантска организация, която отговаря на изискванията на GOST ISO 9001-2015.
20. Функции и съдържание на техническия надзор на клиента. Държавен строителен надзор.
21. Компетенциите на GIP по въпросите на самообразованието и повишаването на квалификацията.
22. CIP, CAP във функционални, организационни и финансови структурипроектантска организация.
23. CEO компетенции, свързани с маркетинга и продажбите.
24. Компетентността на ISU по въпросите на определяне на неговите правомощия, права и отговорности.
25. Компетентността на главния изпълнителен директор за оценка на ефективността и ефикасността на неговата професионална дейност и мотивация.
От май 2015 г. Програмата на Международното училище по GUI включва допълнителен модул „Оценка на икономическата ефективност на дизайнерските решения” (30 академични часа). Общата сума на Програмата става 80 ак. час. Занятията по този модул се водят от преподаватели от Държавната академия на инвестиционните специалисти (ГАСИС) на Националния изследователски университет " висше училищеикономика” Студентите получават и сертификат GASIS.
Темите на образователните, консултантските и изследователските програми, предлагани от Международното училище по GUI, са фокусирани върху решаването на основните проблеми, пред които са изправени проектантските организации в момента, чрез реално подобряване на уменията на ключови фигури в процеса на проектиране - GUI.
По основните теми на Програмата на Международното училище за графични потребителски интерфейси, Консултантският център на проекта TsNIO е разработен.
А сега нека се обърнем към механизма за формиране на качеството на дизайнерските решения, за да определим ясно и недвусмислено границите на отговорността на GUI.
Няколко общи съображения за дизайн:
1. Всеки проект за строителство е комбинация от три модела:
Макети на бъдещия обект (пространствено-планировъчни и инженерни решения);
Модели на неговото създаване (Проект за организация на строителството);
Модели на неговото функциониране (Организация и управление на производството).
2. Формирането на дизайнерско решение се състои в действителното му приемане и след това е необходимо да се потвърди неговото съответствие, с други думи, да се провери. Самото приемане на дизайнерско решение е избор на алтернативи, а потвърждаването на съответствието има много различни опции и съответно много условия, които съответстват на тези опции. По принцип опциите зависят от времето, мястото и стандартите, които са избрани за потвърждение.
Качеството на дизайнерското решение се състои от четири основни свойства. Всяко от тези свойства се формира от някого в софтуера и е предназначено за някого. Този, който формира свойството на качеството, го носи лична отговорност. Първата е „техническа осъществимост“, т.е. проектното решение трябва да бъде такова, че да може да бъде реализирано по време на строителството. На първо място, той е необходим на строителния предприемач, а неговите техници, инженери и главни специалисти на производствените звена го формират. Втората е „информационна способност“, т.е. проектното решение трябва да съдържа всичко необходимо за извършване на строително-монтажни работи, поръчка на оборудване, получаване на всички необходими разрешителнии информация за одобрение. Необходим е на клиента и строителния предприемач. Тази собственост се формира от техници, инженери и главни специалисти на производствени звена. Трето - " икономическа целесъобразност» проектно решение, т.е. проектното решение трябва да бъде икономически конкурентноспособно в процеса на изграждане и експлоатация на съоръжението. Това е необходимо за основното лице на пазара - инвеститорът, той се формира и ISU отговаря за това. Четвъртият е „систематичен“, т.е. всички дизайнерски решения за проекта трябва да бъдат съгласувани. Това е необходимо преди всичко за самите дизайнери, а главните специалисти в разделите на проектите са отговорни за това.
Дизайнерските решения се вземат на пет нива. Нека разгледаме тези нива на примера на проектната част на проекта. Първото ниво ще бъде "възли, части". На това ниво техниците вземат решения за армировъчни мрежи, вградени части и т.н. Второто ниво са „елементи“. На това ниво инженерите проектират греди, колони, свободно стоящи основи и т.н. Третото е „компоненти“. Старши и водещи инженери проектират тавани, покрития, ограждащи конструкции и др. Четвъртото ниво е „проектна секция“. На това ниво Главен специалиствзема решение за конструктивната схема на сградата и основните якостни параметри на конструкцията. Петото ниво е „технико-икономически показатели на проекта“. Вземането на решения на това ниво е отговорност на ISU.
Нека се обърнем към "потвърждаване на съответствието на проектното решение". Това са контрол, оценка, проверка, анализ, валидиране, съгласуване и одобрение на проектни решения. Тук за нас е важно да определим границите на отговорността на GUI.
Контролът включва съответствието на приетото проектно решение с действащите норми (правила), т.е. нормативни документи, които в момента действат в сградния комплекс ( Градоустройствен кодексРуската федерация, SNiP, SN, GOST, VSN и др.). Резултатът от контрола - "съответства" или "не отговаря" на проектното решение на посочените нормативни документи.
Оценяване - същата процедура за контрол, само че освен "отговаря" или "не отговаря" се посочва колко "отговаря" или "не отговаря". По правило резултатът от оценката се дава в количествени показатели, например, пожарната разлика между сградите е по-малка от стандартната с 10 метра.
Така нареченият нормативен контрол е в същия ред като контрола, с единствената разлика, че SPDS GOST се използват за сравняване на приетото проектно решение с нормативните документи.
Проверката включва сравняване на приетото проектно решение с входните проектни данни (проектно задание, проектни входни данни, спецификации). GOST ISO 9001-2011 доста ясно определя изискванията за проверка на проектните решения, включително планиране на проверката и записването на резултатите. По-специално, 7.3.5 казва това „Съгласно планираните договорености трябва да се извърши проверка, за да се гарантира, че изходните данни за проектиране и разработка отговарят на входните изисквания за проектиране и разработка. Записите на резултатите от проверката и всички необходими действия трябва да се поддържат и съхраняват.. Тъй като "входните данни", като правило, съдържат технико-икономически показатели (изисквания) към проектната документация, GUI проверява тяхното съответствие с действително получените.
Анализът - колективно действие, ръководено от GUI - ви позволява да предвидите последствията от неизменността на съществуващия процес на проектиране по отношение на техническите и икономическите характеристики на дизайнерските решения, разходите за проектиране и неговата продължителност. В точка 7.3.4 от GOST ISO 9001-2011, както и за проверка, са установени изисквания за анализ, а именно: „Системичните прегледи на дизайна и разработката трябва да се извършват на подходящи етапи в съответствие с планираните дейности, за да се оцени способността на резултатите от дизайна и разработката да отговарят на изискванията и да се идентифицират всички проблеми при [проектиране и разработка] и да се предложат необходими действия. Участниците в такива прегледи трябва да включват представители на функции, имащи отношение към разглеждания етап на проектиране и разработка. Записите на резултатите от анализа и всички необходими действия трябва да се поддържат и съхраняват.Обърнете внимание, че анализът трябва да бъде планиран и резултатите от него документирани. Също така е очевидно, че анализът не може да се извърши в началото на дизайна, тъй като все още няма какво да се анализира, и в края на дизайна, защото „влакът вече е тръгнал“ и процесът е завършен. При проектирането GUI е отговорен за провеждането на анализа. Като правило GUI по време на процеса на проектиране периодично събира ръководителите на производствени отдели и главните специалисти по участъците на проекта и обсъжда с тях напредъка на проектирането и технико-икономическите характеристики на взетите дизайнерски решения, за да бъде сигурни, че в края на проектирането получените дизайнерски материали ще съответстват на "входните данни".
Координацията предполага увереност, че това проектно решение не противоречи на проектните решения за други раздели на проекта, т.е. например проектното решение на проектния раздел на проекта се сравнява с проектните решения на електрическите, санитарните или топлотехническите секции на проекта.
Осъществяването на съгласуването е задължение на ПГУ, а за коректността на съгласуването са отговорни съответните главни специалисти по раздели на проекта.
Спомнете си какво е "валидиране". При проектирането са възможни две ситуации на потвърждение: в първия случай това може да стане директно "на хартия", т.е. проектното решение е на екрана на компютъра. Например проектното решение е изчислена и проектирана греда, която трябва да издържи съответното натоварване. За да потвърдите съответствието, достатъчно е да използвате същия метод за изчисление, който е бил използван при вземането на това решение (или алтернативен) и ако този метод е доказан и надежден, тогава повторното изчисление ще даде абсолютна увереност в правилността на дизайна решение. Или друг пример, в заданието за проектиране е посочен съставът на помещенията на съответния етаж от сградата и са посочени необходимите площи. Проектното решение за този етажен план е лесно да се провери, като се сравни с оригиналните данни. Трябва да се подчертае, че такива дизайнерски решения в общия обем на проектиране са най-малко 80-90 процента. Те включват дизайнерски решения, взети с помощта на стандартни проекти, стандартни възли и части, одобрени индивидуални ранно разработени дизайнерски решения, които се използват повторно, каталози на оборудване, които са надлежно сертифицирани и т.н. и т.н. С други думи, говорим за надеждни, тествани, много пъти прилагани, несъмнени дизайнерски решения.
Втората ситуация е, когато проектното решение не може да бъде надеждно проверено с помощта на традиционни техники за проверка. Те могат да бъдат проверени само по време на строителството или експлоатацията на изграденото съоръжение, както и чрез провеждане на специални изпитвания при условия, които са възможно най-близки до конструкцията или експлоатацията на съоръжението. Такава необходимост възниква, когато се използват напреднали технологии или материали, които вече са препоръчани или обявени в реклами, нови методи за изчисление, оборудване, което не е използвано досега, технологични решения, които нямат аналози и т.н. Например на изложението дизайнерите се запознаха с нов покривен материал, който се рекламира активно и характеристиките на този материал са впечатляващи.
Може да бъде решено да се използва този материал за покрив с площ от 20 хиляди квадратни метра, но е изрично посочено, че по време на строителството първо трябва да завършите покривна секция от 10 квадратни метра, да създадете динамично натоварване върху него за определено време, налейте вода отгоре и вижте как се държи долната повърхност на покрива в този случай. Ако резултатът от теста е положителен, проектантите ще дадат разрешение за изработка на останалата част от покрива. Понякога такава необходимост възниква поради високата несигурност на геоложките условия в сложни строителни зони, когато изследователите не могат (включително по икономически причини) да моделират характеристиките на почвата с достатъчна точност в конкретни места на основата. В тези случаи те посочват необходимостта от забиване на пробни пилоти и едва след това потвърждават възможността за подреждане на пилотно поле под целия обект.
Това е валидирането на проектното решение. Използването на валидиране показва ангажираността на проектантската организация към всичко ново, усъвършенствано. Това е знак за конкурентоспособност в дизайнерските решения, това е желанието да се заеме водеща позиция в дизайна чрез непрекъснато подобряване на удовлетвореността на клиентите. Отговорност за самия факт на валидирането носи GUI, за съдържанието на валидирането - основните специалисти по разделите на проекта.
Одобрението е разрешение за прехвърляне на готовата проектна документация на клиента. Това е отговорност на GUI и той го изпълнява, когато подписва фактурата, преди да изпрати документацията на клиента.
Сега нека се обърнем към отговорността на GUI, свързана с намаляване на разходите за проектиране. Както знаете, има много възможности за намаляване на разходите и това е „главоболие“ за ръководството и всички водещи софтуерни специалисти, тъй като това е практически единственият начин да се увеличи печалбата на дизайнерска организация. Съществен принос за това има GUI, осъзнавайки отговорността за управлението (аутсорсването) на поддизайнери.
Понастоящем стана възможно да се избират поддизайнери (SPO) въз основа на резултатите от тяхната оценка, сравнение с конкуренти, редовна преоценка и се появи отговорността на GUI за този избор. Между субектите в дизайна започна работа важен принцип, „който плаща, вика музиката“, не само в известен традиционен смисъл, но и като изискване на генералния проектант (ОП) постоянно да мисли за подобряване (осигуряване) на качеството и намаляване на разходите за проектантска работа. Освен това законът установява, че само ОПЛ носи отговорност пред Клиента за качеството на проектно-оценъчната документация, разработена от софтуера с отворен код. Следователно е необходимо да се ръководите от изискванията на GOST ISO 9001-2011 и Указанията за използване на процеси на аутсорсинг // ISO/TS 176/SC 2/N 630R2, 24 ноември 2003 г.).
Като цяло има три условни типа софтуер с отворен код:
- "обикновени" - СПО, с които ДП имат нормални пазарни отношения;
- "протежета" - креатура на клиента, отношенията на личния лекар с които се определят от клиента.
Използвайки примера за връзки със софтуер с отворен код, ще разгледаме всяка от подсистемите на свой ред, като вземем предвид, че GUI в някои случаи взема решения, а в други участва в тяхното приемане.
Оценка, подбор и преоценка на подпроектанти.
Тази подсистема се състои от два блока:
Формиране и поддържане на Списък (база данни, регистър и др.) на одобрен софтуер с отворен код и неговото актуализиране;
Избор на софтуер с отворен код от посочения списък за извършване на работа по конкретен проект.
Изпълнението на работата в рамките на първия блок е функция на софтуерния технически отдел, във втория блок е отговорност на GUI.
За формиране на Списъка технически отдел PO търси, оценява, избира и преоценява STR в съответствие с нуждите на PO, като използва критерии, разработени съвместно с ISU.
Ясно е, че подобен подход не гарантира пълната адекватност на STR спрямо очакванията на личния лекар поради трудното формализиране на някои въпроси. Например въпросът относно наличието на валидна СУК и нейното съответствие с изискванията на GOST ISO 9001-2011. Софтуерът с отворен код отговаря, че СУК функционира и отговаря на изискванията, както се вижда от сертификата на сертифициращия орган „N“. Опит в оценката на изпълнението на определени изисквания на GOST ISO 9001-2011 саморегулиращи се организациина дизайнерите показва, че повече от 90% от сертификатите са получени формално, просто „купени“ и често нямат нищо общо с определен софтуер с отворен код. Оказва се, че ОПЛ носи реална отговорност за качеството на проектната (работната) документация, изготвена от СПО, но изборът на СПО се основава на "заверките" на самия СПО под формата на отговори на въпросите на въпросника. При проектирането на конкретен обект GUI по правило избира подходящия SPO от списъка, ръководен от допълнителни критерии, включително териториалното местоположение на SPO, информираността на SPO за свойствата на определен строителен обект, предишни контакти с конкретен Клиент, готовността на СПО да изпълни поръчката и др.
GUI трябва да посети организацията директно, преди да вземе решение да включи софтуер с отворен код в дизайна. Това ново мито GUI. Тази технология е предоставена ISO стандартисерия 9000 и се нарича одит на „втора страна“. Продължителността на одита от втората страна е не повече от един работен ден (оптимално 3-4 часа).
Такава кратка продължителност се обяснява с факта, че не се разглежда цялата система за управление на качеството на софтуера с отворен код, а само някои ключови точки. Практиката показва, че ако в тези точки всичко е нормално, то с голяма степен на вероятност STR отговаря на очакванията на личния лекар.
Трябва да се подчертае, че Клиентът работи само с личния лекар, с който има договор. Той може да не познава останалите участници в проекта. Следователно връзката със софтуера с отворен код е проблем изключително за държавните предприятия. SPO всъщност действа като допълнително структурно подразделение на GP, което той трябва да управлява в процеса на изпълнение на проекта по същия начин като своя „собствен“ структурни подразделения, като се имат предвид сроковете и качеството на проектната (работната) документация, разработена чрез софтуера с отворен код, за което ОПЛ носи отговорност пред клиента. Това определя и отговорностите на ДП за управление на СПО.
Типът и обхватът на управление на софтуера с отворен код може да варира в значителни граници: от минимума, когато техническото задание се издава и извършената работа се приема с малка или никаква проверка, до максимума, когато се изисква софтуер с отворен код да се ръководи от управленски и други документи, одобрени от ОПЛ при изпълнение на поръчката. В същото време се извършва пълна проверка на завършения SPO на проектно-сметната документация, включително с участието на независими експерти.
Необходимият обхват на управление се определя от GUI в зависимост от резултатите от оценката (преоценката) на STR, включително като се вземе предвид информацията, получена по време на одита от втората страна, както и в зависимост от разходите, планирани от GPU за провеждане входен контрол STR материали, като се има предвид, че тези разходи оскъпяват работата по проекта.
Характеристики на управлението на SPO ISU трябва да издаде договор за подизпълнение при „специални условия“. Техническият отдел на SE разработва шаблон за такива „специални условия“, който изброява почти всички възможни и/или необходими аспекти на управлението на софтуер с отворен код, а GUI, когато анализира конкретен договор със софтуер с отворен код, включва тези методи на управление, които отговарят на условията на конкретен проект. Колкото по-дълбока е степента на контрол на софтуера с отворен код, толкова по-малък е обемът на входящия контрол на дизайнерските материали на софтуера с отворен код, а оттам и цената на GP.
Такива методи на управление могат да включват необходимостта от:
Координиране с GP на технологичния процес на проектиране, използван от софтуера с отворен код или осигуряване на изпълнението на проектантската работа, използваща технологичен процесдизайн, който се използва от ОПЛ;
Одобряване на работния график за проектиране, въз основа на който трябва да се разработи SPO календарен планработи към договора;
Назначаване (съгласувано с ОПЛ) на конкретен GUI (ръководител на проекта) за предадената за изпълнение поръчка (част от проекта) и др.
В зависимост от степента на управление на софтуера с отворен код, обхватът на входния контрол в SOE може да варира от 100% до почти никакъв, т.е. формално преизчисляване на проектните документи, получени от софтуера с отворен код.
След прехвърлянето на завършената проектна и разчетна документация на Клиента или след пускането в експлоатация на съоръжението (ако е извършен архитектурен надзор), GUI трябва да завърши проекта за аутсорсинг.
За целта са ви необходими:
Проверете наличието на документи, потвърждаващи приемането на проектната и разчетната документация от SPO, включително проверка на качеството на посочената документация;
Извършете оценка на сътрудничеството със софтуер с отворен код и докладвайте резултатите на техническия отдел за коригиране на списъка;
Получаване от SPO и прехвърляне в архива на GP информация за разработените индивидуални ефективни проектни решения, включително в документацията на SPO, които могат да бъдат препоръчани за повторно използване;
Подгответе официално ревю за софтуер с отворен код;
Разрешаване на въпроса (ако е необходимо и възможно) с икономическите стимули за софтуер с отворен код.
Сега относно задължението на GUI, което е свързано с участие във формирането на "портфолио от поръчки" и намаляване на разходите за софтуер за търсене на нови клиенти.
Говорим за факта, че съгласно клауза 7.2.1 „Процеси, свързани с потребителите“ от GOST ISO 9001-2011, софтуерът трябва да определи изискванията:
1. Установява се от клиента, включително изисквания за доставка и дейности след доставка.
2. Не е посочено от клиента, но е необходимо за конкретната или предвидена употреба на DCE, когато е известно.
3. Законодателни и други задължителни, свързани с проектно-сметната документация.
4. Всеки дефиниран допълнителен софтуер.
Какво се разбира под първите три групи изисквания (1-3) е повече или по-малко ясно. Нека обясним допълнително, че „изисквания, които не са декларирани от клиента, но са необходими за конкретното или предвиденото използване на проектно-сметната документация, ако са известни“, могат да включват всички изисквания на самия софтуер, изпълнението на които определя качеството, цена и срок на доставка на проектната документация.
Например, ако клиентът получи проектни оценки, които в съответствие със съществуващата технология за проектиране се съхраняват определено времепреди да бъде прехвърлен на клиента в техническия архив, тогава изискванията на самия софтуер относно условията за съхраняване на определената документация в архива ще се отнасят до точка 7.2.1 (2) от стандарта. Изпълнявайки изискванията, посочени в точка 7.2.1 (1-3) от стандарта, софтуерът не може да получи конкурентно предимство, тъй като тези изисквания задължително се изпълняват от всички състезатели. При пазарни условия „оцелява“ само софтуер, който може да определи и изпълни изискванията на точка 7.2.1 (4). Нарекохме тези изисквания „преднамерени“ и изяснихме значението им: първо, те са „угадани“, формулирани от самия софтуер, второ, не са одобрени или съгласувани с клиента, и трето, изпълнението им се извършва за сметка на собствени средстваОТ. В резултат на това клиентът получава проектна документация (услуги) с неочаквани за него параметри или с параметри, по-добри от очакваните, което гарантира не само удовлетвореността на клиента, но и го кара да се възхищава на предоставената проектно-сметна документация (извършена услуга). В последния случай софтуерът може да бъде сигурен, че клиентът ще се връща към него многократно. А задържането на клиент, както знаете, е 5-7 пъти по-евтино от търсенето на нов. Това е същността на принципно нова разпоредба, заложена в GOST ISO 9001-2011.
За да може изпълнението на изискването, посочено в точка 7.2.1 (4) от стандарта, да окаже влияние върху формирането на конкурентни предимства на софтуера, е необходимо да се определи собственикът на процеса за формиране на очакваните изискванията на клиентите, т.е. един от ръководителите, които установяват правила за изпълнение на тази дейност. За софтуера собственикът на процеса вероятно ще бъде главният инженер на института. „Собственикът“ на процеса, т.е. специалистът, който формира очакваните изисквания на клиента за конкретен проект, трябва да бъде GUI. За да поясним, GUI е отговорен за гарантирането, че предвидените изисквания на клиента са дефинирани и за съдържанието определени изискванияотговарят главните специалисти на производствените отдели.
Друго задължение на GUI се формира при анализа на договора (споразумението) с клиента. Призивът на клиента към софтуера може да бъде по различни начини: информация за спечеления търг (конкуренция); официално писмо с предложение за разработване на проектна документация; телефонно обажданесофтуерен мениджър; неформален контакт чрез колеги и т.н. В момента на получаване на един от горните сигнали се препоръчва да се назначи GUI, който да управлява анализа на договора до подписването му от клиента.
Това задължение на GIP включва:
Определяне на кръга от лица, които ще участват в съгласуването на проектодоговора и разпределение на отговорностите между тях;
Ангажиране на горепосочените мениджъри и специалисти за провеждане на преговори (работни срещи) с клиента за обсъждане на определени клаузи на проекта на договор, включително преговори за определяне на цената на договора;
Избор от базата данни с шаблони на подходящ вариант за конкретен клиент и обект на проектиране;
Определяне на необходимостта и възможността за привличане на подпроектанти и водене на предварителни преговори с тях;
Оценка на рисковете, които могат да съпътстват изпълнението от софтуера на неговите задължения по договора.
Всяко едно от тези действия в днешните условия се различава значително от познатата ни практика. Например, одобрението на проект на споразумение, като правило, се съставя на „Лист за споразумение“, в който се посочват пълното име и длъжност на съответния ръководител, който, ако решението е положително, поставя подписа си и ако решението е отрицателно, аргументира становището си писмено. Според нас е необходимо да се установи отговорността на ръководителя за съответните клаузи от проектодоговора. Сборът от точките в „Списък с одобрения” трябва да е равен на сбора от точките в проекта на договор. Това гарантира личната отговорност на всеки ръководител за осъществимостта на условията на договора от проектантската организация и еднаквото разбиране на съответните условия на проектодоговора от проектантската организация и клиента и др.
Материалът на тази статия може да предизвика възражения за някои дизайнери. Готови сме за конструктивна дискусия с колегите в удобна за тях форма.
| Обсъдете във форума |
|
| |
|
От февруари 2008 г. започна работният етап по отношение на документите, които определят процеса на проектиране. Това беше актът от февруари 2008 г., който въведе свои собствени правила за строителство на територията на Руската федерация. Който и месец да се извършва строителството - през декември, април, май или август - трябва да одобрите документите от съответните органи. Това важи дори за основен ремонт на обекта.
Правителствен указ 87 относно състава на проектната документация,
Например в първия параграф се посочва, че всички обяснения относно използването на Регламента, който е одобрен в Резолюцията, се дават директно от Министерството на строителството на Руската федерация. Всички останали въпроси се решават в съответствие с компетентността на конкретни органи. Изпълнителна властучаства в разработването на публична политика.
Промени 2016г
с промени съдържа няколко модификации в сравнение с Стара версия. Например, разработването на прогнозни стандарти за изграждането на конкретно съоръжение се извършва в съответствие с решението на правителството на Руската федерация.
Достатъчно виза на GUI на заглавната страница
Ежегодно сме одитирани от териториалната организация по стандартизация
и нямаше коментари
Аз и не само аз вече съобщих, че следвайте вашия набор от документация, както смятате за правилно
Изглежда само вашата организация от армията проектантски институти изпълнява проектната документация
вярно
Няма да има повече коментари от моя страна.
Повтарям, че този въпрос вече създаде „захапка от зъби“ и не е ли време да отделим полезно време за разработване на работна документация
Не разбирам недоволството ти. Ако не се интересувате или сте решили всичко за себе си и наистина не трябва да губите време да го обсъждате, аз не ви принуждавам да правите това. Още повече, че вашето мнение по тази тема беше известно още преди нейното създаване. И аз ви писах за това, като казах, че се интересувам не само от моето и вашето мнение за този проблемкакто и други професионалисти. Освен това по никакъв начин не съм твърдял, че моята фирма ме превъзхожда лично, като дизайнер, за разлика от вас. Просто имаме спор относно правилата за регистрация и само въз основа на вашите коментари по моя проект. Разбира се, опитвам се да защитя проекта си, както бихте направили вие на мое място. Но аз съм готов да разбера всичко и да направя подходящи промени в по-нататъшния дизайн, мисля, че всеки уважаващ себе си дизайнер иска да пусне документация правилно форматирана.
8.7 Заглавни страницитомове проектна документация са подписани от:
- ръководителят или главният инженер на организацията;
Главен инженер (архитект) на проекта.
Подписите на главния инженер (архитект) на проекта са задължителни върху листовете с общи данни на работните чертежи, най-важните листове с работни чертежи, графичната част на документацията за проектиране и отчетно проучване;
относно задължителното присъствие на клетвата на GIP и списъка нормативни документиВече публикувах връзки в OD.
Оттук вадим извод. Въпреки липсата на коментари териториална организациястандартизацията (не мисля, че има големи специалисти) и вашият голям опит, който наистина уважавам, от гледна точка на ГОСТ 21.1101-2009, който многократно споменавате, вие съставяте OD неправилно, но както повечето ( ако не всички) от присъстващите тук (да и не само тук), без да изключвам мен.
Кой нарушава в по-голяма степен, кой в по-малка степен, но никой не може да се похвали с абсолютно компетентен поне ОД (надяваме се, че някой е, особено след като обещаха) и това е наистина жалко. Остава само срамежливо да признаят този факт, въпреки техните регалии и заслуги, да работят върху грешките и да продължат да изпълняват изискванията. По принцип затова създадох тази тема.
Как може да се отнасяме към дизайнери, които прилагат отменена преди тридесет години норма? Лакмус, показващ липса на познания в областта на дизайна, е включването на "Клетвата GIP" в общите данни.
Историята се връща поне към GOST 21.102-79 „Общи данни на SPDS за работни чертежи“:
"12. В долния ляв ъгъл на първия лист с общи данни на всеки основен набор от работни чертежи в правоъгълна рамка се поставя запис на главния инженер на проекта, удостоверяващ съответствието на проекта с действащите норми и правила, както и за сгради или конструкции с пожароопасен и експлозивен характер на производство, в допълнение, безопасна тяхната експлоатация при спазване на мерките, предвидени в проекта.
GOST 21.101-93 „Основни изисквания на SPDS за работна документация“, който го замени, отмени тази норма:
" 2.5.4. Общите инструкции са:
4) запис, че техническите решения, приети в работните чертежи, отговарят на изискванията на екологичните, санитарно-хигиенните, противопожарните и други стандарти, действащи на територията на Руската федерация, и осигуряват безопасна експлоатация на съоръжението за живота на хората. и здраве при спазване на мерките, предвидени в работните чертежи;“
GOST 21.101-97, който го замени, "SPDS Основни изисквания за проектиране и работна документация" опрости необходимата фраза още повече:
„4.2.9 Общите инструкции дават:
г) запис, че работните чертежи са разработени в съответствие с приложимите кодекси, правила и стандарти.
GOST R 21.1101-2013 в сила в момента в Русия „Система от проектни документи за строителство. Основни изисквания към проектната и работната документация”съдържа следната фраза:
„4.3.5 Общите инструкции дават:
- протокол за съответствието на работната документация със заданието за проектиране, издадено от спецификации, изискванията на тока технически регламенти, стандарти, правилници, други документи, съдържащи установени изисквания“.
Лесно се вижда, че нито един от горните нормативни документи, с изключение на първия, не съдържа дума за GUI. Сега вземете първия основен комплект, който ви попадне под ръка. Намерете там фразата „относно съответствието“. В зависимост от формулировката можете грубо да прецените възрастта на дизайнера, който е издал документацията :) Ако видите „Клетвата на GUI в рамката“, вероятно сте пенсионер и недалеч: някога са го научили на това начин, а за 25 години изобщо не се сети да погледне норматива.
За тези, които се съмняват, ще дам още един аргумент. Все още няма отменен SNiP 1.06.04-85 "Наредби за главния инженер (главен архитект) на проекта. Той съдържа следните разпоредби:
"2.2. В съответствие с основните задачи главният инженер (главен архитект) на проекта отговаря за:
2.2.15. Потвърждение в материали проектсъответен записче проектната и разчетна документация за изграждането на предприятия, сгради и съоръжения е разработена в съответствие с нормите, правилата, инструкциите и държавните стандарти.Нито дума повече, изисквайки отделно записване в работната документация.
Сега за целите на сборника ще цитирам моя въпрос, който беше включен в Сборника с разяснения, бр.2 „Сборник от обяснения на изискванията на стандартите на системата за проектна документация за строителство (въпроси и отговори). Брой 2. - OJSC "CNS", Москва, 2012 г. ":
" 4. Посочете необходимостта от полагане на "клетвата на GIP" върху листовете с общи данни. Това изискванедори не се съдържаше в GOST 21.101-97, но значителен брой проектантски организации продължават по инерция да изпълняват изискването на отменения GOST 1979.
Отговор: Да, като продължават да извършват "запис за съответствие на работната документация", както беше в GOST 21.102-79, който беше отменен през 1993 г., сега тези проектантски организации нарушават действащия стандарт. Съгласно клауза 4.3.5 от GOST R 21.1101-2009 в общи инструкции в общите информационни листове.
Въпросът продължава да вълнува умовете и в Книгата на обясненията, бр.4 „Сборник от обяснения на изискванията на стандартите на системата за проектна документация за строителство (SPDS) (въпроси и отговори). Брой 4. - OJSC "CNS", Москва, 2015 г. "Прочети отново:
"Въпрос 5: Необходимо ли е да се издаде изискването на клауза 4.5.6 от GOST R 21.1101-2013 относно съответствието на работната документация с всички норми и правила отделно, в рамка и да се постави подпис на GUI?
Отговор: В GOST R 21.1101-2013 няма изисквания за разпределение в рамката на параграф от общи инструкции, съдържащ "запис за съответствие на работната документация" и отделното му подписване от GUI.
Подписът на лицето, което изготвя работната документация (GIP), е задължително в основните надписи на листовете с общи данни на работни чертежи и допълнителни подписи едно и също лицепод никаква информация на същите листове не се изисква.
Наличието на два GUI подписа на един и същи документ (и най-често на един и същи лист) няма да направи документацията два пъти по-добра.
Не бъркайте елемента в "общите инструкции" в работната документация с "сертифицирането на проектантската организация" в проектната документация"
