Hlavný projektový inžinier je kľúčovou postavou v procese návrhu

Aký je vzťah k dizajnérom, ktorí pred tridsiatimi rokmi uplatňovali zrušenú normu? Lakmusovým papierikom preukazujúcim nedostatok vedomostí v oblasti dizajnu je zahrnutie „prísahy GIP“ do všeobecných údajov.

História siaha prinajmenšom k GOST 21.102-79 „SPDS Všeobecné údaje o pracovných výkresoch“:

"12. V ľavom dolnom rohu prvého listu všeobecných údajov každej hlavnej sady pracovných výkresov je v pravouhlom ráme umiestnený záznam hlavného inžiniera projektu, ktorý potvrdzuje súlad projektu s platnými normami a pravidlá a pre budovy alebo stavby s požiarne nebezpečným a výbušným charakterom výroby navyše bezpečnú ich prevádzku v súlade s opatreniami predpokladanými v projekte.

GOST 21.101-93 „SPDS Základné požiadavky na pracovnú dokumentáciu“, ktorá ju nahradila, zrušila túto normu:

" 2.5.4. Všeobecné pokyny sú:

4) záznam, že technické riešenia prijaté na pracovných výkresoch sú v súlade s požiadavkami environmentálnych, hygienických a hygienických, požiarnych a iných noriem platných na území Ruskej federácie a zabezpečujú bezpečnú prevádzku zariadenia pre ľudský život a zdravie, s výhradou opatrení stanovených v pracovných výkresoch;“

GOST 21.101-97, ktorý ho nahradil, „Základné požiadavky SPDS na projektovú a pracovnú dokumentáciu“ ešte viac zjednodušil potrebnú frázu:

"4.2.9 Vo všeobecných pokynoch sa uvádza:

d) záznam, že pracovné výkresy boli vypracované v súlade s platnými predpismi, pravidlami a normami.

GOST R 21.1101-2013 v súčasnosti platný v Rusku „Systém projektových podkladov pre výstavbu. Základné požiadavky na projektovú a pracovnú dokumentáciu“ obsahuje nasledujúcu frázu:

"4.3.5 Vo všeobecných pokynoch sa uvádza:

- záznam o súlade pracovnej dokumentácie s konštrukčným zadaním, vydanými technickými špecifikáciami, požiadavkami aktuálnych technických predpisov, noriem, kódexov a iných dokumentov obsahujúcich ustanovené požiadavky.

Je ľahké vidieť, že žiadny z vyššie uvedených normatívnych dokumentov, okrem prvého, neobsahuje ani slovo o GUI. Teraz vezmite prvú základnú súpravu, ktorá vám príde pod ruku. Nájdite tam frázu „o súlade“. Podľa formulácie viete zhruba odhadnúť vek projektanta, ktorý dokumentáciu vystavil :) Ak vidíte "Prísahu GUI v ráme", ste pravdepodobne dôchodca a nie je ďaleko: kedysi ho to učili spôsobom a 25 rokov ho nikdy nenapadlo pozrieť sa na normatív.

Pre tých, ktorí pochybujú, uvediem ešte jeden argument. Stále nie je zrušený SNiP 1.06.04-85 "Predpisy o hlavnom inžinierovi (hlavnom architektovi) projektu. Obsahuje tieto ustanovenia:

"2.2. V súlade s hlavnými úlohami je hlavný inžinier (hlavný architekt) projektu zodpovedný za:

2.2.15. Potvrdenie v materiálov projektu zodpovedajúci záznamže projektová a odhadová dokumentácia pre výstavbu podnikov, budov a stavieb bola vypracovaná v súlade s normami, pravidlami, pokynmi a štátnymi normami. Ani slovo viac, náročné na samostatné zaznamenanie v pracovnej dokumentácii.

Teraz pre zbierku uvediem svoju otázku, ktorá bola zaradená do Zborníka vysvetliviek, číslo 2 „Zbierka vysvetliviek k požiadavkám noriem systému projektovej dokumentácie stavby (otázky a odpovede). Vydanie 2. - OJSC "CNS", Moskva, 2012 ":

"4. Uveďte potrebu uvedenia" prísahy GIP "na listoch všeobecných údajov. Táto požiadavka nebola obsiahnutá ani v GOST 21.101-97, ale značný počet projekčných organizácií zotrvačnosťou naďalej spĺňa požiadavku zrušený GOST z roku 1979.

Odpoveď: Áno, pokračovaním vo vykonávaní „záznamu o súlade pracovnej dokumentácie“, ako to bolo v prípade GOST 21.102-79, ktorý bol zrušený v roku 1993, teraz tieto dizajnérske organizácie porušujú súčasnú normu. Podľa článku 4.3.5 GOST R 21.1101-2009 je záznam o súlade projektovej dokumentácie s konštrukčným zadaním vydaným technickými špecifikáciami, požiadavkami súčasných TR, GOST, SP atď. všeobecné pokyny na kartách všeobecných údajov.

Táto otázka neprestáva miešať mysle a v Knihe vysvetlení, číslo 4 „Zbierka vysvetliviek k požiadavkám noriem systému projektovej dokumentácie výstavby (SPDS) (otázky a odpovede). Vydanie 4. - OJSC "CNS", Moskva, 2015 "Čítaj ešte raz:

"Otázka 5: Je potrebné vydať požiadavku ustanovenia 4.5.6 GOST R 21.1101-2013 o súlade pracovnej dokumentácie so všetkými normami a pravidlami samostatne, v rámci a vložiť podpis GUI?

Odpoveď: V GOST R 21.1101-2013 neexistujú žiadne požiadavky na akékoľvek priradenie k rámcu odseku všeobecných pokynov obsahujúcich „záznam o zhode pracovnej dokumentácie“ a jeho samostatné podpísanie GUI.

Podpis osoby pripravujúcej pracovnú dokumentáciu (GIP) je povinný v hlavných nápisoch na listoch všeobecných údajov o pracovných výkresoch a dodatočných podpisoch. tá istá osoba za žiadnych informácií na tých istých hárkoch sa nevyžaduje.

Mať dva podpisy GUI na tom istom dokumente (a najčastejšie na rovnakom hárku) nebude dokumentácia dvakrát lepšia.

Nezamieňajte si položku vo „všeobecných pokynoch“ v pracovnej dokumentácii s „osvedčením projekčnej organizácie“ v projektovej dokumentácii."

Zloženie častí projektovej dokumentácie v súlade s normami Ruskej federácie a špecifické požiadavky na vykonanie sú uvedené v rezolúcii 87. Mnohých zaujíma súčasná legislatíva a jej vysvetlenia k tomuto uzneseniu, preto by ste si mali zistiť, čo sa v tomto zákone objavila novinka pre tento rok a ako vyzerá zoznam jeho požiadaviek.

o skladbe projektovej dokumentácie

Pri písaní tohto ustanovenia sa vláda odvolávala na mestské plánovanie a jeho ruský kódex. Podľa čl. 48 tohto zákonníka bol stanovený obsah dokumentácie. Hlavné požiadavky začalo predkladať ministerstvo, v kompetencii ktorého sa stavba nachádza, ako aj bezpečnostná služba federácie. Federácia môže tiež dostávať odporúčania na prípravu dokumentov prostredníctvom štátneho dopravného úradu. Dodatočná požiadavka môže byť vykonaná na žiadosť mnohých ďalších služieb. Prvé vydanie a objasnenia mali vstúpiť do platnosti vo februári 2008. Potom, na konci februára, bolo pridelené označenie každému aspektu požiadaviek.

Zmeny a doplnenia federálneho zákona o zostavení projektovej dokumentácie

Nariadenie vlády Ruskej federácie o zostavení projektovej dokumentácie zo 16. februára 2008 87 so zmenami muselo byť schválené v januári 2016. Predtým sa rozhodnutím vlády menil viac ako jeden paragraf v apríli a koncom apríla v decembri, marci, auguste, júli, máji a júni minulých rokov. Do posledného znenia bolo rozhodnutím pléna vložené malé doplnenie a niektoré odseky budú uvedené v novom znení. Dnes si úvodník môžete prečítať zadarmo. z roku 2016 cez váš počítač alebo si stiahnite pozičný plán.

Nariadenie Ruskej federácie o zostavovaní projektovej dokumentácie v znení neskorších predpisov obsahuje tieto oddiely:

• Základné ustanovenia;
• Zloženie projektu pre proces lineárnej výstavby;
• Zloženie sekcií o procese investičnej a nevýrobnej výstavby.

Pripomienky k uzneseniu 87

Nedávne pripomienky k územnoplánovacej dokumentácii k tomuto zákonu objasňujú relevantnosť nových ustanovení. Napríklad federálny zákon obsahuje zoznam požiadaviek na fázu pracovného návrhu. V súvislosti s komentármi možno presnejšie pochopiť, čo robiť, ak je splnená podmienka z konkrétneho postu v zákone, ako funguje sila tejto vyhlášky a ako systém vykonáva technologický dozor.

Prísaha GIP podľa 87. rezolúcie

Toto ustanovenie Ruskej federácie neupravuje prísahu GIP, hoci by mala existovať jeho poznámka alebo vstup do projektu. Vždy musí existovať osvedčenie, pečiatka a podpis ISU. To vám umožňuje poskytnúť informácie, že projektová schéma je napísaná v súlade s požiadavkami a vývoj je úradne certifikovaný.

Zoznam častí projektovej dokumentácie podľa 87 federálneho zákona

V závislosti od konštrukcie, pre ktorú sa toto ustanovenie vyžaduje, sa mení vzorka a etapa kompilácie. Celkovo dodatok k zákonu obsahuje dva druhy stavieb – líniové objekty a investičnú výstavbu. Stojí za to klasifikovať objekt a aplikovať naň pravidlá textového a grafického dizajnu. Pomoc na túto tému zavrhujú mnohé právne portály, napríklad technický expert, konzultant alebo konzultantplus. To naznačuje, že dnes je poradie písania projektov zaujímavé pre viac ako jednu organizáciu. Oplatí sa preštudovať si stav pozemku, budov a stavieb podľa tohto zákona a následne sa ním písomne ​​riadiť.

Všeobecná vysvetlivka k vyhláške 87

Všeobecná vysvetlivka a jej vývoj sú podľa textu ustanovenia opodstatnené. Projekt musí obsahovať také zväzky a časti, ktoré sú popísané v uznesení. Napríklad by sa mal uviesť odhad, dodávka elektriny, dôležité kódy, dostupnosť siete, environmentálny aspekt projektu, bezpečnosť a odbornosť, energetická účinnosť atď. Aj samotný projekt by mal pôsobiť ako garant správneho vývoja, napríklad je dôležité zachovať životné prostredie, ak ide o dokument pre jadrovú elektráreň alebo umývačku áut v Moskve. Ak je zablokovaný dôležitý verejný uzol alebo ak je potrebné odstrániť časť infraštruktúry, musia byť pripojené povolenia. Hotový dokument môže byť zviazaný alebo zložený a je tiež uvedený dátum prijatia.

Dostatok víz GUI na titulnej strane
Každoročne sme auditovaní územnou organizáciou normalizácie
a neboli žiadne komentáre
Ja a nielen ja som už uviedol, že postupujeme podľa vášho súboru dokumentácie tak, ako si myslíte, že je správne
Zdá sa, že len vaša organizácia z armády projektových ústavov vykonáva projektovú dokumentáciu
správny
Už odo mňa nebudú žiadne komentáre.
Opakujem, že táto otázka už vytvorila „zahryznutie do zubov“ a nie je čas, aby sme venovali užitočný čas vypracovaniu pracovnej dokumentácie

Nerozumiem tvojej nespokojnosti. Ak vás to nezaujíma alebo ste o všetkom rozhodli sami a naozaj by ste nemali strácať čas diskusiou, nenútim vás do toho. Navyše, váš názor na túto tému bol známy ešte pred jej vznikom. A napísal som vám o tom, že ma zaujímajú nielen moje a vaše názory na túto problematiku, ale aj iných odborníkov. Taktiež som v žiadnom prípade netvrdil, že moja firma je mne osobne ako dizajnérovi na rozdiel od Vás nadradená. Máme len spor o pravidlách registrácie a to len na základe vašich pripomienok k môjmu projektu. Samozrejme, snažím sa chrániť svoj projekt, ako by ste to urobili na mojom mieste. Ale som pripravený pochopiť všetko a urobiť vhodné zmeny v ďalšom dizajne, myslím si, že každý sebaúctyhodný dizajnér chce vydať dokumentáciu správne naformátovanú.

8.7 Titulné strany zväzkov projektovej dokumentácie podpisujú:

- vedúci alebo hlavný inžinier organizácie;

Hlavný inžinier (architekt) projektu.

Podpisy hlavného inžiniera (architekta) projektu sú povinné na listoch všeobecných údajov o pracovných výkresoch, najvýznamnejších listoch pracovných výkresov, grafickej časti projektovej a ohlasovacej dokumentácie geodézie;

o povinnej prítomnosti prísahy GUI a zozname regulačných dokumentov v OD som už zverejnil odkazy.

Odtiaľto vyvodíme záver. Napriek absencii pripomienok zo strany územnej organizácie normalizácie (nemyslím si, že existujú veľkí špecialisti) a vašim bohatým skúsenostiam, ktoré si veľmi vážim, z pohľadu GOST 21.1101-2009 opakovane spomínate, nesprávne vypracovať OD však ako väčšina (ak nie povedzme všetci) tu prítomných (a nielen tu), mňa nevynímajúc.
Kto porušuje vo väčšej miere, kto v menšej miere, no nikto sa nemohol pochváliť absolútne kompetentným aspoň OD (dúfame, že niekto áno, hlavne keď sľúbili) a to je vlastne poľutovaniahodné. Zostáva len hanblivo priznať túto skutočnosť, napriek ich regalom a zásluhám, pracovať na chybách a pokračovať v plnení požiadaviek. V podstate preto som založil toto vlákno.

Zverejnené dňa 04.01.2015

MS Podolsky, predseda podvýboru pre organizáciu činnosti hlavných inžinierov projektov komisie pre technologický návrh priemyselných zariadení Národnej asociácie projektantov a geodetov, vedecký dozorca Medzinárodnej školy hlavných inžinierov (hlavných architektov) projektov na MGSU

A. V. Litvinov, zástupca generálneho riaditeľa konzultačného centra projektov TsNIO, člen predstavenstva Medzinárodnej školy hlavných inžinierov (hlavných architektov) projektov Moskovskej štátnej univerzity stavebných inžinierov.

V moderných obchodných podmienkach má zákazník možnosť vybrať si projekčnú organizáciu (PO) podľa optimálneho pomeru termínov, ceny a kvality ponúkaných služieb. Pri zdanlivej rovnosti vyššie uvedených kritérií sa práve kvalita projektovej dokumentácie môže stať rozhodujúcou podmienkou úspechu softvéru v súťaži. Kvalita projektovej dokumentácie sa posudzuje jednak objektívnymi parametrami – súlad s požiadavkami existujúcich noriem a pravidiel, ako aj subjektívnymi – maximálnym uspokojením požiadaviek zákazníka. Tieto aj ďalšie parametre sa neustále menia: zákazníci prechádzajú od štandardného prevedenia k individuálnemu, zmeny a doplnky regulačnej, technickej a legislatívnej základne sú vydávané mesačne, nové stavebné materiály, nové zariadenia, technológie a pod. Bežný zákazník je „spokojný “ alebo „Nespokojný“ s projektovou dokumentáciou je doplnený potrebou neustáleho zlepšovania spokojnosti zákazníkov, a to je zakotvené v ideológii medzinárodných noriem radu ISO 9000.

Na zabezpečenie požadovanej kvality produktov musí softvér, ak už nie držať krok s vedeckým a technologickým pokrokom, tak aspoň držať krok a ponúkať zákazníkovi nové, originálne a spoľahlivé konštrukčné riešenia.

Čo bráni skutočnému zlepšeniu práce hlavných inžinierov (hlavných architektov) projektov (CEO)? Podľa nášho názoru po prvé, prevládajúce nesprávne stereotypy o mieste a úlohe GUI v procese navrhovania, ktoré sa dedia z generácie na generáciu dizajnérov, a po druhé, nedostatočná kvalifikácia softvérových manažérov vo veciach súvisiacich s činnosťou GUI, čo im neumožňuje prijímať adekvátne rozhodnutia, po tretie, nedostatok jasnej predstavy o tom, z čoho pozostáva kvalita dizajnového riešenia a za akú časť je GUI zodpovedné, po štvrté, zjednodušené chápanie mechanizmus tvorby kvality, vrátane prípadu, keď ho implementujú subdizajnéri, a napokon po piate, pretože väčšina dizajnérov si ešte neuvedomuje dôležitosť úlohy GUI pri znižovaní nákladov na dizajnérske práce.

Bolo by nesprávne domnievať sa, že samotní softvéroví manažéri a GUI nechcú riešiť vyššie uvedené príčiny, no ich pokusy neprinášajú badateľné výsledky, pretože namiesto toho, aby sa spoliehali na fakty, ktoré jasne diktujú správne rozhodnutia, sa riadia skúsenosťami z minulosti a subjektívne názory, ktoré nezodpovedajú požiadavkám doby.

V procese diskusie o týchto otázkach sme sa s mnohými našimi kolegami často ocitli na opačných stranách barikády – s akýmsi „kolektívnym protivníkom“, ktorého názory sa formovali historicky a stále žije v minulej ekonomickej realite. Tento článok je dodatočnou námietkou voči „kolektívnemu oponentovi“.

Ako viete, moderný manažment odporúča zdokumentovať dôležité predpisy, ale vzniku akéhokoľvek predpisu by malo predchádzať vytvorenie zásad, ktoré stanovujú napríklad „popri rieke alebo cez ňu sa postaví most“. Toto je najdôležitejšia časť tvorby pravidiel. V tejto fáze by mal dôjsť ku konsenzu v odbornej verejnosti, po ktorom by prípadné regulačné obmedzenie nemalo odporovať dohodnutým princípom.

Bohužiaľ, v skutočnosti víťazia „zlé stereotypy“, ktoré vo väčšine prípadov nesúvisia nielen s vedou o organizácii a riadení výroby, ale často jednoducho so zdravým rozumom.

Zastavme sa pri niektorých, podľa nášho názoru, chybných nápadoch, ktorých zbavenie sa je skutočnou rezervou vo vývoji dizajnérskeho biznisu:

1. Za kvalitu projektovej (pracovnej) dokumentácie zodpovedá GUI, teda za všetko zodpovedá GUI.

To je nemožné. Požiadavky na prácu alebo, ako sa dnes hovorí, „zodpovednosť a autorita“ GUI historicky koreluje so zložitosťou požiadaviek na dizajnové objekty, ako aj so zmenami v očakávaniach zákazníkov ohľadom výsledkov dizajnu. V minulosti projektovanie a výstavbu viedol jeden špecialista, ktorý robil všetky rozhodnutia. V súčasnosti je hlavnou úlohou GUI poskytnúť potrebnú dynamiku investícií, ako aj príjem zákazníkovi z realizácie projektu, dostatočný na kompenzáciu investorov za investované zdroje a podstupované riziko. Všetky rozhodnutia pri návrhu GUI sa teda robia podľa kritéria ekonomickej efektívnosti návrhu, výstavby a prevádzky zariadenia. Z toho vyplývajú požiadavky na jeho kvalifikáciu. Všetci ostatní účastníci procesu návrhu sa rozhodujú podľa kritéria technickej optimality a táto podmienka je realizovaná v procese koordinácie rozhodnutí o návrhu hlavnými špecialistami v sekciách projektu.

2. „Prísaha“ GUI zbavuje ostatných účastníkov dizajnu zodpovednosti za kvalitu projektovej (pracovnej) dokumentácie.

Inými slovami, GUI zodpovedá za dodržiavanie noriem a štandardov pre projektovanie, výstavbu a prevádzku zariadení, štandardov samoregulačných organizácií, individuálnych požiadaviek zákazníkov na technickú úroveň a kvalitu, architektonickú výraznosť a spoločenský význam zariadení v r. projekt. Považujeme za potrebné vrátiť sa k významom: zodpovednosť za čo a v akých prípadoch.

Zodpovednosť samozrejme môže vzniknúť, ak sa odhalí negatívny výsledok práce, ktorú odborník osobne vykonal alebo ju osobne skontroloval; ak existuje náležitý podpis, podložený dátumom a tiež zdokumentovaný, za čo a komu je zodpovedný a kedy to skončí. Toto sú predpoklady osobnej zodpovednosti. V opačnom prípade víťazí kolektívna nezodpovednosť. Vezmime si príklad. Ako viete, výkresy musia byť podpísané: „vyvinuté“, „skontrolované“ a „štandardná kontrola“. Venujme pozornosť skutočnosti, že podpisy sú uvedené v rámci akcií, to znamená, že odpovedajú na otázku: čo ste urobili? - rozvinutý; Čo si robil? - vykonaná normatívna kontrola atď. Nesmieme dovoliť "amatérske aktivity" projekčných organizácií a objavenie sa podpisov na výkresoch vedúcich oddelení, hlavných špecialistov, hlavných projektantov atď. Akcenty sa posúvajú a podpisy začínajú určovať, že nie " čo urobil“, ale „kto urobil“.

Ako už bolo spomenuté, podpis predstavuje zodpovednosť. Bez podpisu - bez zodpovednosti. Keďže zodpovednosť má hranice, je potrebné sa dohodnúť, kam smerujú, teda zabezpečiť, aby každý chápal oblasť zodpovednosti rovnako. Význam dohody je nasledovný: každý výkres má obsah („čo je zobrazené“) a dizajn („ako“ je zobrazené). Za obsah a prevedenie zodpovedá zhotoviteľ. Za obsah - pred inšpektorom, za dizajn - pred normatívnym kontrolórom. Zodpovednosť zhotoviteľa zaniká v okamihu podpisu inšpektora a normatívneho kontrolóra. Ďalej je potrebné určiť, komu je zodpovedný inšpektor a normatívny kontrolór. V ideálnom prípade by to mal byť zákazník, ktorý má skutočný záujem o zhodu podpisu a výsledku. V samotnej projekčnej organizácii nie je možné nájsť tých, ktorí sledujú inšpektora a normatívneho kontrolóra. Ale mohlo by to byť GUI? V tomto prípade bude podpis GUI znamenať, že ešte raz skontroloval obsah a dizajn výkresu a prevzal zodpovednosť, a to aj za „dodržiavanie noriem a štandardov v projekte pre návrh, výstavbu a prevádzku zariadení ... ”, atď. atď. Ale pre GUI je fyzicky nemožné kontrolovať všetky konštrukčné riešenia, či sú v súlade so všetkými normami a všetkými požiadavkami. Preto robiť GUI zodpovedným za všetko vo všeobecnosti nie je nič iné ako kúzlo, formálne kvôli nemožnosti splnenia a nebezpečné, ak je to potrebné, potrestať za cudzie zavinenie. ISU je len jedným z mnohých autorov hry s názvom „Projektová dokumentácia“.

3. Ak sa na stavenisku stane niečo vážne, GUI bude prvý, kto bude „uväznený“.

Ak sa stane niečo naozaj vážne, potom vyšetrovateľ po vymenovaní forenznej technickej skúšky alebo po vykonaní niekoľkých takýchto skúšok určí projektanta, ktorý napríklad vykonal výpočet konštrukcie a použil nesprávny koeficient, potom určí toho, kto kontroloval výpočet a je to práve táto osoba, ktorá vznesie obvinenie, ale súd môže za určitých okolností potrestať výkonného umelca a inšpektora.

4. GUI musí byť najkvalifikovanejší dizajnér vo všetkých oblastiach projektu.

Je jasné, že to jednoducho nemôže byť, pretože projektová dokumentácia obsahuje minimálne desať špecializovaných častí, z ktorých práce vyplýva prítomnosť viac ako dvadsiatich odborností. Tento „zlý stereotyp“ sa rozširuje aj na myšlienku vymenovania špecialistu na post generálneho riaditeľa. Je však vhodné rozhodnúť o vymenovaní generálneho riaditeľa na základe výberového konania a riadiť sa úplne inými kritériami.

Uchádzač o funkciu hlavného inžiniera musí zo strany uchádzača zdôvodniť možnosť dosiahnutia vyšších technicko-ekonomických ukazovateľov projektovaného zariadenia, skrátenie počiatočného projektovania a času výstavby, zníženie prácnosti (nákladov) projekčných prác, výhodnejšie podmienky pre dohody s účastníkmi projektu pre organizáciu dizajnu, ako aj rozšírenie rozsahu dodatočných požiadaviek zákazníka na dizajnový objekt (7.2.1 "d" GOST R ISO 9001-2008) atď. Povesť GUI je obzvlášť dôležitá : charakter, spoločenskosť, pracovitosť, nasadenie, výkonnosť, dochvíľnosť, slušnosť, schopnosť vyjednávať, všímavosť, zdvorilosť, ústretovosť, výkonnosť atď.

Pri občianskych objektoch môže byť výhodou pri menovaní do funkcie hlavného projektového architekta (GAP) prítomnosť ekonomického a architektonického vzdelania. Druhou prioritou je ekonomické vzdelanie, treťou architektonické a napokon len inžinierske.

Pre priemyselné objekty (technologický dizajn) môže byť výhodou pri vymenovaní do funkcie hlavného projektového inžiniera (CIP) prítomnosť ekonomického vzdelania a technologického vzdelania zodpovedajúceho špecifikám projektovaného objektu. Druhou prioritou je ekonomické vzdelanie, treťou technologické a napokon práve strojárske.

V prvom aj druhom prípade musí mať PIU (GAP) kvalifikáciu v projektovom manažmente. Na základe výsledkov konkurenčného výberu je do funkcie príslušným príkazom vedúceho software menovaný generálny riaditeľ.

5. Ak dôjde k nezhodám medzi hlavnými odborníkmi na úsekoch projektu, konečné rozhodnutie prijme ISU.

Predstavte si nasledujúci obrázok: Hlavný odborník - elektrikár na svojom úseku projektu rozhodol, že rozvádzač bude medzi takou a takou osou a na takej a takej značke budovy. Hlavný odborník - kúrenár umiestnil na tom istom mieste vykurovacie miesto. Prichádzajú do GUI, aby ich „zladili“. Prirodzene, kvalifikácia každého z hlavných špecialistov v príslušnej špecializácii je vyššia ako kvalifikácia generálneho riaditeľa. Ak s nimi bude ISU o tejto problematike diskutovať v navrhovanej technickej oblasti, tak je zjavne v nevýhode. Mal by posunúť diskusiu do ekonomickej roviny s tým, že jedna možnosť stojí toľko a druhá toľko, berúc do úvahy nielen stavebné, ale aj prevádzkové náklady, ako aj možné riziko spojené so zmenami nákladov. zariadení. Pri prijímaní a zdôvodňovaní svojho rozhodnutia z ekonomického hľadiska musí GUI, ktoré je za toto rozhodnutie zodpovedné investorovi, hľadať vhodné technické riešenie u špecialistov. Dnes už len máloktoré z GUI dokáže pôsobiť takto, ale toto je poslaním GUI, jeho súčasťou zodpovednosti za kvalitu dizajnových riešení.

6. GUI by malo mať predovšetkým technickú špecializáciu.

Už sme hovorili o tom, akú špecialitu a prečo by mal mať GIP. V podmienkach zrýchleného tempa vedecko-technického rozvoja kvalita projektovej dokumentácie priamo závisí od systematického zdokonaľovania schopností vedúcich pracovníkov. Dnes musí byť generálny riaditeľ kompetentný v organizácii a riadení procesu projektovania, metód na zabezpečenie ekonomickej efektívnosti projektovania, výstavby a prevádzky zariadenia, aby získal svoju pozíciu na konkurenčnom základe. Ale aj úspešní generálni riaditelia pociťujú nedostatok vedomostí o týchto otázkach a snažia sa nezávisle kompenzovať medzery vo svojich kompetenciách.

Na vyriešenie týchto problémov z iniciatívy Výboru pre technologický dizajn priemyselných zariadení NOPRIZ a Inštitútu výstavby a architektúry (ISA) Národného výskumu Moskovskej štátnej univerzity stavebníctva (MGSU) za účasti TsNIO -Projektové konzultačné centrum a Výbor pre ďalšie odborné vzdelávanie v stavebníctve Ruský zväz staviteľov (RCC) zorganizoval Medzinárodnú školu hlavných inžinierov (hlavných architektov) projektov. Školská rada zahŕňala známych odborníkov v Ruskej federácii a krajinách SNŠ v oblasti dizajnu a zabezpečenia kvality projektovej (pracovnej) dokumentácie. Predseda predstavenstva Medzinárodnej školy hlavných inžinierov (hlavných architektov) projektov Meshcherin Igor Viktorovič má jedinečnú skúsenosť s prácou hlavného architekta a hlavného architekta v ZSSR, Rusku, USA a Taliansku.

Informácie o International School of GUIs (GAS), vrátane vedenia špecifických kurzov, sú zverejnené na webových stránkach ISA MGSU, Národnej asociácie dizajnérov a geodetov, projektu TsNIO, ako aj na webových stránkach Projektanta v Ruská federácia, Kazachstan, Bielorusko a Ukrajina.

Hlavným cieľom International School of GUIs je dať joj m nadstavbové vzdelávanie na zabezpečenie prípravy vysoko odborných zamestnancov generálnych riaditeľov. Programy, ktoré zodpovedajú moderným požiadavkám, praktickému zameraniu kurzov, umožňujú uspokojiť potreby technologického a architektonického a konštrukčného riešenia, udržiavať neustály odborný rast a reprodukciu generálnych riaditeľov a zároveň pripravujú personálnu rezervu pre obsadzovanie pozícií. generálnych riaditeľov na príkaz projekčných organizácií.

Vo „vzdelávacom portfóliu“ International School of GUIs sú dva hlavné produkty:

Navrhovaný systém preškolenia GUI je flexibilný, adekvátny potrebám doby, reagujúci na reálne potreby dizajnérov, ktorí sú mimoriadne vyťažení praktickou prácou. Obsah programov vyvažuje teoretické a praktické znalosti, ako aj skúsenosti s manažmentom dizajnu. Je veľmi dôležité, aby program predpokladal široké územné pokrytie študentov a pohodlnosť učenia sa, a to aj s využitím moderných princípov, foriem a metód vzdelávania: modularita, učenie sa „k výsledku“, variabilita z hľadiska odbornej prípravy, vzdialenosť. učenie atď.

Hlavné témy, o ktorých sa diskutuje na kurzoch International School of GIPs na MGSU:

1. Situácia na stavebnom trhu a jej vplyv na činnosť GIP.

2. Hlavné zmeny v obsahu pojmu „systém manažérstva kvality“ vo vzťahu k práci ISU.

3. Rozdelenie v projekčnej organizácii (PO) zodpovednosti za vývoj konštrukčných riešení a ich kvalitu medzi prvého manažéra, hlavného inžiniera, výrobného riaditeľa, GUI, technické oddelenie a výrobné oddelenia (dielne) v procese prípravy, vydávania a realizácie dizajnu. (technická) dokumentácia vo výstavbe vrátane kontroly, overovania, analýzy, schvaľovania, validácie a schvaľovania projektových odhadov.

4. Objasnenie úlohy a miesta GUI v "end-to-end procese" zákaznícky orientovaného softvéru: "interakcia so zákazníkmi softvéru" - "tvorba a podpora portfólia softvérových objednávok" - "príprava a vydávanie / implementácia projektová (pracovná) dokumentácia“ - „podpora realizácie projektu vo výstavbe“ – „plnenie záručných povinností na softvérové ​​projekty realizované vo výstavbe“.

5. Vedúci výrobnej jednotky: dizajnér alebo vedúci (manažér)? Interakcia s GUI. Hlavné predmety riadenia vedúceho výrobnej jednotky: pracovné zdroje, práca, čas, financie, materiálne zdroje; podriadenosť, právomoci, hlavné funkčné povinnosti (zodpovednosť) vedúceho výrobnej jednotky, kritériá hodnotenia jeho činnosti.

6. Postup pri „spustení“ prác na vypracovaní projektovej dokumentácie v zmysle uzatvorenej rámcovej zmluvy o projekte. Vzorová zmluva so subdodávateľskou projekčnou organizáciou (SPO); postupy hodnotenia, výberu (výberu) a prehodnocovania STR; koncepcie subdodávok a outsourcingu.

7. Interakcia GUI so zmluvným oddelením, technickým archívom, oddelením uvoľňovania projektov. Základné požiadavky na GUI v systéme výkonnej disciplíny.

8. Analýza nových zodpovedností ISU; typický popis práce GIP; požiadavky na GUI počas architektonického dozoru (vrátane subdizajnérov); GUI a problematika technického prevybavenia, rozšírenia podniku, modernizácie, generálnej opravy atď.

9. Sledovanie spokojnosti zákazníkov s procesmi a výsledkami projekčnej organizácie.

10. Úloha GUI pri rozširovaní typov produktov (služieb) projekčnej organizácie. Vytvorenie dobrého mena ISU medzi účastníkmi investičného projektu.

11. Vedenie subdizajnérov. Moderné požiadavky na výber účastníkov dizajnu.

12. Pripomienky k návrhu nových organizačných a metodických dokumentov pre generálnych riaditeľov: Štandard pre odbornú činnosť generálneho riaditeľa, Odporúčania na organizáciu činnosti generálneho riaditeľa, Profil generálneho riaditeľa, Požiadavky na prípravu a menovanie generálneho riaditeľa, ktoré sú vypracovaný Podvýborom pre organizáciu činnosti hlavných projektantov komisie pre technologické projektovanie výrobných zariadení NOP v aktuálnom roku.

13. Vyjednávanie zmlúv a stanovovanie zmluvných cien. Typy zmlúv.

14. Interakcia so štátnou a neštátnou expertízou.

15. Právne a organizačné základy pre dizajn, regulačné dokumenty súvisiace s prácou GUI, vrátane GOST R 54869-2011, ako aj systém EUROCODE.

16. Náklady na dizajnérske práce. Základno-indexové a zdrojové metódy kalkulácie nákladov. Formy rozpočtovej dokumentácie. Hodnotenie ekonomickej efektívnosti konštrukčných riešení.

17. Riadenie rizík projektu. Definícia a identifikácia rizík (kategórie rizík, známe riziká a neznáme riziká, veľkosť rizika, pravdepodobnosť výskytu a miera dopadu rizika); rozpočtovanie riadenia rizík; stanovenie pravdepodobnosti splnenia stanovených termínov a rozpočtu projektu; metódy reakcie na riziko (vyhýbanie sa, prenos, zmierňovanie a akceptovanie); kontrola rizikových symptómov.

18. Účasť na výberových konaniach na získanie zákazky na projektové a prieskumné práce.

19. Hlavné ustanovenia systému manažérstva kvality v projekčnej organizácii, ktorá spĺňa požiadavky GOST ISO 9001-2015.

20. Funkcie a obsah technického dozoru objednávateľa. Štátny stavebný dozor.

21. Kompetencie GIP v otázkach sebavzdelávania a ďalšieho vzdelávania.

22. CEO, hlavný architekt vo funkčných, organizačných a finančných štruktúrach projekčnej organizácie.

23. Kompetencie CEO súvisiace s marketingom a predajom.

24. Pôsobnosť ISU vo veciach určovania jej právomocí, práv a povinností.

25. Kompetencia generálneho riaditeľa pri posudzovaní účinnosti a efektívnosti jeho odborných činností a motivácie.

Od mája 2015 je súčasťou Programu International School of GUIs doplnkový modul „Hodnotenie ekonomickej efektívnosti konštrukčných riešení“ (30 akademických hodín). Celková suma programu sa stáva 80 ac. hodina. Kurzy v tomto module vedú učitelia Štátnej akadémie investičných špecialistov (GASIS) Vysokej ekonomickej školy Národnej výskumnej univerzity a študenti získavajú aj certifikát GASIS.

Témy vzdelávacích, konzultačných a výskumných programov, ktoré ponúka International School of GUIs, sú zamerané na riešenie základných problémov, ktorým v súčasnosti čelia dizajnérske organizácie, a to skutočným zdokonaľovaním zručností kľúčových postáv v procese navrhovania – GUI.

K hlavným témam programu Medzinárodnej školy GUI sa rozvinulo Konzultačné centrum projektu TsNIO.

A teraz sa obráťme na mechanizmus tvorby kvality návrhových rozhodnutí, aby sme jasne a jednoznačne určili hranice zodpovednosti GUI.

Niekoľko všeobecných návrhov:

1. Akýkoľvek projekt na výstavbu je kombináciou troch modelov:

Modely budúceho objektu (priestorové plánovanie a inžinierske riešenia);

Modely jeho tvorby (Projekt organizácie výstavby);

Modely jej fungovania (Organizácia a riadenie výroby).

2. Vytvorenie rozhodnutia o dizajne pozostáva z jeho skutočného prijatia a potom je potrebné potvrdiť jeho súlad, inými slovami, skontrolovať. Samotné prijatie rozhodnutia o dizajne je výberom alternatív a potvrdenie zhody má veľa rôznych možností, a teda aj veľa podmienok, ktoré týmto možnostiam zodpovedajú. Možnosti v podstate závisia od času, miesta konania a noriem, ktoré sa vyberú na potvrdenie.

Kvalita konštrukčného riešenia pozostáva zo štyroch hlavných vlastností. Každá z týchto vlastností je niekým tvorená v softvéri a je pre niekoho určená. Ten, kto tvorí vlastnosť kvality, nesie za ňu osobnú zodpovednosť. Prvou je „technická realizovateľnosť“, t. j. konštrukčné riešenie musí byť také, aby sa dalo realizovať počas výstavby. V prvom rade je to potrebné, aby dodávateľ stavby a jeho technici, inžinieri a hlavní špecialisti výrobných jednotiek ju tvoria. Druhou je „informačná schopnosť“, t. j. projektové riešenie musí obsahovať všetky informácie potrebné na vykonanie stavebných a inštalačných prác, objednanie zariadenia, získanie všetkých potrebných povolení a súhlasov. Potrebuje ho zákazník a dodávateľ stavby. Túto vlastnosť tvoria technici, inžinieri a hlavní špecialisti výrobných jednotiek. Treťou je „ekonomická realizovateľnosť“ konštrukčného riešenia, t.j. konštrukčné riešenie musí byť ekonomicky konkurencieschopné v procese výstavby a prevádzky zariadenia. To je potrebné pre hlavnú osobu na trhu - investora, tvorí sa a je za to zodpovedná ISU. Štvrtý je „systematický“, t. j. všetky rozhodnutia o dizajne projektu musia byť odsúhlasené. Je to potrebné predovšetkým pre samotných dizajnérov a za to zodpovedajú hlavní špecialisti v sekciách projektov.

Rozhodnutia o dizajne sa robia na piatich úrovniach. Zoberme si tieto úrovne na príklade projektovej časti projektu. Prvou úrovňou budú „zostavy, diely“. Na tejto úrovni technici rozhodujú o výstužných sieťach, zabudovaných častiach atď. Druhou úrovňou sú „prvky“. Na tejto úrovni inžinieri navrhujú nosníky, stĺpy, voľne stojace základy atď. Treťou sú „komponenty“. Starší a poprední inžinieri navrhujú stropy, nátery, obvodové konštrukcie atď. Štvrtou úrovňou je „projektová časť“. Na tejto úrovni rozhoduje hlavný špecialista o konštrukčnom riešení budovy a hlavných pevnostných parametroch konštrukcie. Piatou úrovňou sú „technické a ekonomické ukazovatele projektu“. Rozhodovanie na tejto úrovni je v kompetencii ISU.

Prejdime k "potvrdeniu zhody konštrukčného riešenia." Ide o kontrolu, hodnotenie, overovanie, analýzu, validáciu, koordináciu a schvaľovanie rozhodnutí o návrhu. Tu je pre nás dôležité definovať hranice zodpovednosti GUI.

Kontrola zahŕňa koreláciu prijatého rozhodnutia o projekte so súčasnými normami (pravidlami), t.j. regulačnými dokumentmi, ktoré v súčasnosti fungujú v stavebnom komplexe (Kód mestského plánovania Ruskej federácie, SNiP, SN, GOST, VSN atď.). Výsledok kontroly - "zodpovedá" alebo "nezodpovedá" konštrukčnému riešeniu špecifikovaným regulačným dokumentom.

Hodnotenie – rovnaký postup kontroly, len sa okrem „zodpovedá“ alebo „nezodpovedá“ uvádza, nakoľko „zodpovedá“ alebo „nezodpovedá“. Výsledok hodnotenia sa spravidla udáva kvantitatívne, napríklad požiarna medzera medzi budovami je menšia ako norma o 10 metrov.

Takzvaná normatívna kontrola je v rovnakom rade ako kontrola, s jediným rozdielom, že SPDS GOST sa používajú na porovnanie prijatého rozhodnutia o dizajne s regulačnými dokumentmi.

Overenie zahŕňa porovnanie prijatého rozhodnutia o návrhu so vstupnými údajmi o návrhu (zadanie návrhu, vstupné údaje návrhu, špecifikácie). GOST ISO 9001-2011 pomerne jasne stanovuje požiadavky na kontrolu konštrukčných riešení, vrátane plánovania kontroly a zaznamenávania výsledkov. Hovorí to najmä 7.3.5 „Podľa plánovaných opatrení sa vykoná overenie, aby sa zabezpečilo, že výstupy návrhu a vývoja zodpovedajú vstupným požiadavkám na dizajn a vývoj. Záznamy o výsledkoch kontroly a všetkých potrebných úkonoch sa musia viesť a uchovávať.. Keďže „vstupné údaje“ spravidla obsahujú technicko-ekonomické ukazovatele (požiadavky) na projektovú dokumentáciu, GUI kontroluje ich súlad so skutočne prijatými.

Analýza – kolektívna akcia vedená GUI – umožňuje predpovedať dôsledky nemennosti existujúceho procesu navrhovania z hľadiska technických a ekonomických charakteristík návrhových riešení, nákladov na návrh a jeho trvania. V ustanovení 7.3.4 GOST ISO 9001-2011, ako aj na overenie, sú stanovené požiadavky na analýzu, a to: „Vo vhodných fázach, v súlade s plánovanými činnosťami, by sa mali vykonávať systematické preskúmania návrhu a vývoja, aby sa zhodnotila schopnosť výsledkov návrhu a vývoja spĺňať požiadavky, ako aj identifikovať akékoľvek [návrhové a vývojové] problémy a navrhnúť potrebné opatrenia. Medzi účastníkmi takýchto preskúmaní by mali byť zástupcovia funkcií relevantných pre posudzovanú fázu návrhu a vývoja. Záznamy o výsledkoch analýzy a všetkých potrebných úkonoch sa musia uchovávať a uchovávať. Upozorňujeme, že analýza musí byť naplánovaná a jej výsledky zdokumentované. Je tiež zrejmé, že analýzu nemožno vykonať na začiatku návrhu, keďže ešte nie je čo analyzovať, a na konci návrhu, pretože „vlak už odišiel“ a proces je ukončený. V dizajne je GUI zodpovedné za vykonávanie analýzy. GUI spravidla počas procesu navrhovania pravidelne zhromažďuje vedúcich výrobných oddelení a hlavných špecialistov v sekciách projektu a diskutuje s nimi o postupe návrhu a technických a ekonomických charakteristikách prijatých návrhových rozhodnutí, aby bolo možné uistite sa, že na konci návrhu budú prijaté návrhové materiály zodpovedať „vstupným údajom“ .

Z koordinácie vyplýva dôvera, že toto konštrukčné riešenie nie je v rozpore s konštrukčnými riešeniami iných častí projektu, teda napríklad konštrukčné riešenie konštrukčnej časti projektu sa porovnáva s konštrukčnými riešeniami časti elektro, zdravotechniky alebo tepelnej techniky. projektu.

Za zabezpečenie koordinácie zodpovedá PSU a za správnosť koordinácie zodpovedajú príslušní hlavní špecialisti pre úseky projektu.

Pripomeňme si, čo je „validácia“. V dizajne sú možné dve situácie potvrdenia: v prvom prípade to možno urobiť priamo "na papieri", t. j. rozhodnutie o dizajne je na obrazovke počítača. Napríklad návrhové rozhodnutie je vypočítaný a navrhnutý nosník, ktorý musí vydržať zodpovedajúce zaťaženie. Na potvrdenie súladu stačí použiť rovnakú metódu výpočtu, ktorá bola použitá pri tomto rozhodnutí (alebo alternatívnu), a ak je táto metóda overená a spoľahlivá, potom opakovaný výpočet poskytne absolútnu dôveru v správnosť návrhu. rozhodnutie. Alebo iný príklad, v projektovej úlohe je uvedené zloženie priestorov na príslušnom poschodí budovy a sú uvedené požadované plochy. Konštrukčné riešenie tohto pôdorysu je ľahko overiteľné porovnaním s pôvodnými údajmi. Treba zdôrazniť, že takéto konštrukčné riešenia v celkovom rozsahu dizajnu sú minimálne 80-90 percent. Patria sem konštrukčné rozhodnutia uskutočnené pomocou štandardných návrhov, štandardných zostáv a dielov, schválené individuálne skoršie vyvinuté konštrukčné riešenia, ktoré sa opätovne používajú, katalógy zariadení, ktoré sú riadne certifikované atď., atď. Inými slovami, reč hovoríme o spoľahlivých, testovaných, mnohých časy aplikované, nepochybné dizajnové riešenia.

Druhou situáciou je situácia, keď konštrukčné riešenie nemožno spoľahlivo overiť pomocou tradičných overovacích techník. Kontrolovať ich možno len počas výstavby alebo prevádzky vybudovaného zariadenia, ako aj vykonaním špeciálnych skúšok za podmienok, ktoré sú čo najbližšie k výstavbe alebo prevádzke zariadenia. Takáto potreba vzniká, keď sa používajú pokročilé technológie alebo materiály už odporúčané alebo avizované v reklamách, nové výpočtové metódy, doteraz nepoužívané zariadenia, technologické riešenia, ktoré nemajú obdobu a pod.. Napríklad na výstave sa dizajnéri zoznámili s novým strešným materiálom , ktorý je aktívne inzerovaný a vlastnosti tohto materiálu sú pôsobivé.

Môže sa rozhodnúť použiť tento materiál na strechu s rozlohou 20 000 metrov štvorcových, je však konkrétne stanovené, že počas výstavby musíte najskôr dokončiť strešnú časť s rozlohou 10 metrov štvorcových, vytvoriť na nej dynamické zaťaženie. po určitú dobu nalejte vodu na vrch a uvidíte, ako sa v tomto prípade správa spodný povrch strechy. Ak je výsledok testu pozitívny, dizajnéri dajú povolenie na výrobu zvyšku strechy. Niekedy takáto potreba vzniká z dôvodu vysokej neistoty geologických pomerov v zložitých stavebných oblastiach, keď geodeti nedokážu (aj z ekonomických dôvodov) dostatočne presne modelovať charakteristiky pôdy v konkrétnych miestach zakladania. V týchto prípadoch poukazujú na potrebu zaraziť skúšobné pilóty a až potom potvrdzujú možnosť usporiadania pilótového poľa pod celým objektom.

Ide o overenie konštrukčného riešenia. Použitie validácie naznačuje odhodlanie projekčnej organizácie ku všetkému novému, pokročilému. To je znakom konkurencieschopnosti v dizajnových riešeniach, je to túžba zaujať vedúcu pozíciu v dizajne prostredníctvom neustáleho zlepšovania spokojnosti zákazníkov. Zodpovednosť za samotný fakt validácie nesie GUI, za obsah validácie - hlavní špecialisti v sekciách projektu.

Schválenie je povolenie na odovzdanie dokončenej projektovej dokumentácie zákazníkovi. Je to zodpovednosť GUI a implementuje to, keď podpíše faktúru pred odoslaním dokumentácie zákazníkovi.

Teraz prejdime k zodpovednosti GUI, spojenej so znižovaním nákladov na dizajnérske práce. Ako viete, existuje veľa príležitostí na zníženie nákladov a to je „bolesť hlavy“ pre manažment a všetkých popredných softvérových špecialistov, pretože je to prakticky jediný spôsob, ako zvýšiť zisk dizajnérskej organizácie. Významne k tomu prispieva GUI, uvedomujúce si zodpovednosť za riadenie (outsourcing) subdizajnérov.

V súčasnosti je možné vyberať poddizajnérov (SPO) na základe výsledkov ich hodnotenia, porovnávania s konkurenciou, pravidelného prehodnocovania a objavila sa zodpovednosť GUI za tento výber. V dizajne začal medzi subjektmi fungovať dôležitý princíp „kto platí, volá muziku“ nielen v určitom tradičnom zmysle, ale aj ako požiadavka generálneho dizajnéra (GP) neustále myslieť na zlepšovanie (zabezpečenie) kvalitu a zníženie nákladov na projekčné práce. Okrem toho zákon stanovuje, že za kvalitu projektovej a odhadovacej dokumentácie vyvinutej softvérom s otvoreným zdrojovým kódom zodpovedá zákazníkovi iba praktický lekár. Preto je potrebné riadiť sa požiadavkami GOST ISO 9001-2011 a Smernicami pre používanie procesov outsourcingu // ISO/TS 176/SC 2/N 630R2, 24. novembra 2003).

Vo všeobecnosti existujú tri podmienené typy softvéru s otvoreným zdrojovým kódom:

- "obyčajné" - STR, s ktorými majú štátne podniky normálne trhové vzťahy;

- "proteges" - tvor zákazníka, s ktorým vzťah GP určuje zákazník.

Na príklade vzťahov so softvérom s otvoreným zdrojovým kódom zvážime postupne každý z podsystémov, pričom vezmeme do úvahy, že GUI v niektorých prípadoch rozhoduje a v iných sa podieľa na ich prijatí.

Hodnotenie, výber a prehodnotenie subdizajnérov.

Tento subsystém pozostáva z dvoch blokov:

Vytváranie a udržiavanie Zoznamu (databáza, register atď.) schváleného softvéru s otvoreným zdrojovým kódom a jeho aktualizácia;

Výber softvéru s otvoreným zdrojovým kódom zo zadaného zoznamu na vykonanie práce na konkrétnom projekte.

Výkon prác v rámci prvého bloku je funkciou softvérového technického oddelenia, v rámci druhého bloku zaň zodpovedá GUI.

Pri zostavovaní zoznamu softvérové ​​technické oddelenie vyhľadáva, hodnotí, vyberá a prehodnocuje softvér v súlade s potrebami softvéru pomocou kritérií vyvinutých spoločne s GUI.

Je zrejmé, že takýto prístup nezaručuje úplnú primeranosť STR k očakávaniam GP vzhľadom na náročnosť formalizácie niektorých otázok. Napríklad otázka týkajúca sa dostupnosti platného QMS a jeho súladu s požiadavkami GOST ISO 9001-2011. Softvér s otvoreným zdrojovým kódom odpovedá, že QMS funguje a vyhovuje, o čom svedčí certifikát certifikačného orgánu „N“. Skúsenosti s hodnotením plnenia určitých požiadaviek GOST ISO 9001-2011 samoregulačnými organizáciami dizajnérov naznačujú, že viac ako 90% certifikátov je získaných formálne, jednoducho „kúpených“ a často nemajú nič spoločné s konkrétnym softvérom s otvoreným zdrojovým kódom. . Ukazuje sa, že GP nesie skutočnú zodpovednosť za kvalitu projektovej (pracovnej) dokumentácie vypracovanej ŠPÚ, no výber ŠPÚ je založený na „certifikáciách“ samotnej ŠPÚ v podobe odpovedí na otázky č. dotazník. Pri navrhovaní konkrétneho zariadenia GUI spravidla vyberá príslušný SS zo zoznamu, pričom sa riadi ďalšími kritériami, vrátane územného umiestnenia SS, informovanosti SS o vlastnostiach konkrétneho staveniska, predchádzajúcich kontaktov s konkrétnym Zákazníkom, pripravenosť SS splniť objednávku a iné.

GUI musí navštíviť organizáciu priamo predtým, ako sa rozhodne zapojiť open source softvér do návrhu. Toto je nová povinnosť GUI. Táto technológia je poskytovaná normami série ISO 9000 a nazýva sa audit „druhej strany“. Trvanie auditu druhou stranou nie je dlhšie ako jeden pracovný deň (optimálne 3-4 hodiny).

Takéto krátke trvanie sa vysvetľuje skutočnosťou, že sa neberie do úvahy celý systém riadenia kvality softvéru s otvoreným zdrojovým kódom, ale iba určité kľúčové body. Prax ukazuje, že ak je v týchto bodoch všetko normálne, potom STR s vysokou mierou pravdepodobnosti spĺňa očakávania praktického lekára.

Je potrebné zdôrazniť, že Zákazník jedná len s GP, s ktorým má uzatvorenú zmluvu. Zvyšných účastníkov projektu možno nepozná. Vzťah k softvéru s otvoreným zdrojovým kódom je preto výlučne problémom pre štátne podniky. SPO vlastne vystupuje ako doplnková štrukturálna divízia SE, ktorú musí v procese realizácie projektu riadiť rovnako ako „svoje“ štrukturálne divízie, pričom má na zreteli načasovanie a kvalitu projektovej (pracovnej) dokumentácie vypracovanej spol. SPO, za ktorú sú voči zákazníkovi zodpovedné SE. Toto tiež určuje zodpovednosti ŠÚ za riadenie STR.

Typ a rozsah správy softvéru s otvoreným zdrojovým kódom sa môže líšiť v značnom rozsahu: od minima, keď je zadaná technická úloha a vykonaná práca je akceptovaná s malým alebo žiadnym overením, až po maximum, keď sa vyžaduje, aby softvér s otvoreným zdrojovým kódom sa riadi správou a inými dokumentmi schválenými všeobecným lekárom pri plnení objednávky. Zároveň sa vykonáva kompletná kontrola dokončeného SPO projektovej a odhadovej dokumentácie, a to aj so zapojením nezávislých odborníkov.

Požadovaný rozsah riadenia určuje GUI v závislosti od výsledkov hodnotenia (prehodnotenia) STR, vrátane zohľadnenia informácií získaných počas auditu druhou stranou, a tiež v závislosti od nákladov plánovaných zo strany STR. GM pre vstupnú kontrolu materiálov STR, majúc na pamäti, že tieto náklady zvyšujú náklady projektu.

Vlastnosti riadenia SPO ISU musí vydať zmluvu o subdodávke za „osobitných podmienok“. Technické oddelenie SE vypracuje šablónu pre takéto „špeciálne podmienky“, v ktorej sú uvedené takmer všetky možné a/alebo nevyhnutné aspekty správy softvéru s otvoreným zdrojovým kódom a GUI pri analýze konkrétnej zmluvy s otvoreným softvérom, zahŕňa tie metódy riadenia, ktoré spĺňajú podmienky konkrétneho projektu. Čím hlbší je stupeň kontroly nad softvérom s otvoreným zdrojovým kódom, tým menší je objem vstupnej kontroly návrhových materiálov softvéru s otvoreným zdrojovým kódom, a teda aj náklady na GP.

Takéto metódy riadenia môžu zahŕňať potrebu:

Koordinácia s GP v procese navrhovania, ktorý používa SPO, alebo zabezpečenie vykonania projektových prác pomocou procesu navrhovania používaného GP;

Koordinácia harmonogramu projektových prác, ktorý by SPO mala vypracovať na základe harmonogramu prác priloženého k zmluve;

Vymenovanie (po dohode s GP) konkrétneho GUI (projektového manažéra) pre zákazku (projektovú sekciu) odovzdanú na realizáciu atď.

Rozsah vstupnej kontroly na GP sa môže v závislosti od stupňa hospodárenia ŠPÚ pohybovať od 100% až po takmer žiadne, t.j. formálne prepočítavanie projektových dokumentov prijatých od ŠPÚ.

Po odovzdaní dokončenej projektovej a odhadovej dokumentácie zákazníkovi alebo po uvedení zariadenia do prevádzky (ak bol vykonaný architektonický dozor), musí GUI dokončiť projekt outsourcingu.

Na to potrebujete:

Skontrolujte dostupnosť dokumentov potvrdzujúcich prijatie projektovej a odhadovej dokumentácie od SPO vrátane kontroly kvality špecifikovanej dokumentácie;

Vykonať hodnotenie spolupráce so softvérom s otvoreným zdrojovým kódom a oznámiť výsledky technickému oddeleniu na opravu zoznamu;

Získať od SPO a preniesť do archívu GP informácie o vypracovaných individuálnych efektívnych konštrukčných riešeniach vrátane dokumentácie SPO, ktoré možno odporučiť na opätovné použitie;

Pripravte oficiálnu recenziu pre softvér s otvoreným zdrojom;

Vyriešte otázku (ak je to potrebné a možné) ekonomických stimulov pre softvér s otvoreným zdrojovým kódom.

Teraz o povinnosti GUI, ktorá je spojená s účasťou na tvorbe „portfólia objednávok“ a znižovaním nákladov na softvér na vyhľadávanie nových zákazníkov.

Hovoríme o skutočnosti, že podľa bodu 7.2.1 „Procesy týkajúce sa spotrebiteľov“ GOST ISO 9001-2011 musí softvér určiť požiadavky:

1. Stanovené zákazníkom, vrátane požiadaviek na doručenie a pozáručné činnosti.

2. Nie je špecifikované zákazníkom, ale je potrebné pre konkrétne alebo zamýšľané použitie DCE, ak je známe.

3. Legislatívne a iné povinné, týkajúce sa projektovej a odhadovej dokumentácie.

4. Akýkoľvek dodatočný softvér je definovaný.

Čo sa myslí prvými tromi skupinami požiadaviek (1-3), je viac-menej jasné. Vysvetlime si ďalej, že „požiadavky nedeklarované zákazníkom, ale potrebné pre konkrétne alebo zamýšľané použitie dokumentácie návrhu a odhadu, ak sú známe“, môžu zahŕňať všetky požiadavky samotného softvéru, ktorých splnenie určuje kvalitu, cena a dodacia lehota projektovej dokumentácie.

Napríklad, ak zákazník dostane projektovú a odhadovú dokumentáciu, ktorá je v súlade s existujúcou konštrukčnou technológiou uložená na určitý čas pred odovzdaním zákazníkovi v technickom archíve, potom požiadavky samotného softvéru týkajúce sa podmienok pre uloženie špecifikovanej dokumentácie v archíve sa bude riadiť článkom 7.2.1 (2) normy. Splnením požiadaviek špecifikovaných v článku 7.2.1 (1-3) normy nemôže softvér získať konkurenčné výhody, pretože tieto požiadavky nevyhnutne implementujú všetci konkurenti. V trhových podmienkach „prežije“ iba softvér, ktorý dokáže určiť a splniť požiadavky článku 7.2.1 (4). Tieto požiadavky sme nazvali „zamýšľané“ a ujasnili si ich význam: po prvé sú „uhádnuté“, formulované samotným softvérom, po druhé, nie sú schválené ani dohodnuté so zákazníkom a po tretie, ich implementácia prebieha na vlastné náklady. ON. Zákazník tak dostane projektovú dokumentáciu (služby) s parametrami, ktoré sú pre neho neočakávané alebo s parametrami lepšími ako očakával, čo zaručuje nielen spokojnosť zákazníka, ale núti ho obdivovať poskytnutú projektovú a odhadovú dokumentáciu (poskytnutú službu). V druhom prípade má softvér istotu, že sa k nemu zákazník bude opakovane vracať. A udržať si zákazníka, ako viete, je 5-7 krát lacnejšie ako hľadanie nového. Toto je podstata zásadne nového ustanovenia stanoveného v GOST ISO 9001-2011.

Aby splnenie požiadavky uvedenej v článku 7.2.1 (4) normy malo vplyv na tvorbu konkurenčných výhod softvéru, je potrebné určiť vlastníka procesu tvorby očakávané požiadavky zákazníkov, teda jedného z manažérov, ktorí stanovujú pravidlá pre vykonávanie tejto činnosti. V prípade softvéru bude vlastníkom procesu pravdepodobne hlavný inžinier ústavu. „Vlastníkom“ procesu, teda špecialistom, ktorý formuje očakávané požiadavky zákazníka na konkrétny projekt, by malo byť GUI. Pre upresnenie, GUI zodpovedá za to, že sú definované očakávané požiadavky zákazníka a za obsah týchto požiadaviek zodpovedajú hlavní špecialisti výrobných jednotiek.

Ďalšia povinnosť GUI vzniká pri analýze zmluvy (dohody) so zákazníkom. Odvolanie zákazníka na softvér môže byť rôzne: informácie o vyhratom tendri (súťaži); úradný list s návrhom na vypracovanie projektovej dokumentácie; telefonický hovor vedúcemu softvéru; neformálny kontakt cez kolegov a pod. V čase prijatia jedného z vyššie uvedených signálov sa odporúča určiť GUI, ktoré bude riadiť analýzu zmluvy až do jej podpisu zákazníkom.

Táto povinnosť GIP zahŕňa:

Určenie okruhu osôb, ktoré sa budú podieľať na koordinácii návrhu dohody a rozdelenie zodpovednosti medzi ne;

Angažovanie vyššie uvedených manažérov a špecialistov na vedenie rokovaní (pracovných stretnutí) so zákazníkom za účelom prerokovania niektorých ustanovení návrhu zmluvy, vrátane rokovaní o určení zmluvnej ceny;

Výber z databázy šablón vhodnej možnosti pre konkrétneho zákazníka a dizajnový objekt;

Určenie potreby a možnosti prilákania poddizajnérov a vedenie predbežných rokovaní s nimi;

Posúdenie rizík, ktoré môžu sprevádzať plnenie záväzkov zo zmluvy softvérom.

Každý z týchto úkonov sa v dnešných podmienkach výrazne líši od nám známej praxe. Napríklad schválenie návrhu zmluvy sa spravidla vyhotovuje na „Zmluvnom hárku“, v ktorom je uvedené celé meno a funkcia príslušného manažéra, ktorý v prípade kladného rozhodnutia pripojí svoj podpis, resp. rozhodnutie je zamietavé, svoje stanovisko písomne ​​argumentuje. Podľa nášho názoru je potrebné stanoviť zodpovednosť prednostu za príslušné body návrhu zmluvy. Súčet bodov v „Zozname súhlasov“ sa musí rovnať súčtu bodov v návrhu zmluvy. Tým je zabezpečená osobná zodpovednosť každého manažéra za uskutočniteľnosť podmienok zmluvy zo strany projekčnej organizácie a rovnaké chápanie príslušných podmienok návrhu zmluvy zo strany projekčnej organizácie a zákazníka atď.

Materiál tohto článku môže u niektorých dizajnérov spôsobiť námietky. Sme pripravení na konštruktívnu diskusiu s kolegami formou, ktorá im vyhovuje.