Kuidas saab suhtuda disaineritesse, kes taotlevad kolmkümmend aastat tagasi tühistatud normi? Lakmuspaber, mis näitab teadmiste puudumist disaini vallas, on "GIP vande" lisamine üldandmete hulka.
Ajalugu ulatub tagasi vähemalt GOST 21.102-79 "SPDS Üldandmed tööjooniste kohta":
"12. Iga põhitööjooniste komplekti üldandmete esimese lehe vasakpoolsesse alumisse nurka asetatakse ristkülikukujulises raamis projekti peainseneri kanne, mis tõendab projekti vastavust kehtivatele normidele ja reeglid ning tule- ja plahvatusohtlikud ehitised või rajatised, lisaks - ohutu töö need kooskõlas projektiga ette nähtud meetmetega."
GOST 21.101-93, mis selle asendas, "SPDS-i põhinõuded töödokumentatsioon" tühistas selle reegli:
" 2.5.4. AT üldised juhised plii:
4) märge selle kohta, et tööjoonistel kasutatud tehnilised lahendused vastavad territooriumil kehtivatele keskkonna-, sanitaar-, tuletõrje- ja muudele normidele. Venemaa Föderatsioon ning tagama rajatise ohutu käitamise inimeste eluks ja terviseks, järgides tööjoonistel ettenähtud meetmeid;
GOST 21.101-97, mis selle asendas, "SPDS põhinõuded projekteerimis- ja töödokumentatsioonile" lihtsustas vajalikku fraasi veelgi:
"4.2.9 Üldised juhised annavad:
d) märge selle kohta, et tööjoonised on välja töötatud kooskõlas kehtivate koodide, reeglite ja standarditega.
Praegu Venemaal kehtiv GOST R 21.1101-2013 "Süsteem projekti dokumentatsioon ehitamiseks. Põhinõuded projekteerimisele ja töödokumentatsioonile” sisaldab järgmist fraasi:
"4.3.5 Üldised juhised annavad:
- töödokumentatsiooni vastavuse kohta projekteerimisülesandele, väljaantud tehnilistele kirjeldustele, kehtivate tehniliste eeskirjade, standardite, tegevusjuhiste ja muude kehtestatud nõudeid sisaldavate dokumentide nõuetele.
On lihtne mõista, et mitte ükski ülaltoodust normatiivdokumendid, välja arvatud esimene, ei sisalda GUI kohta sõnagi. Nüüd võtke esimene põhikomplekt, mis käepärast on. Leidke sealt fraas "vastavuse kohta". Olenevalt sõnastusest saad umbkaudselt hinnata dokumentatsiooni väljastanud disaineri vanust :) Kui näed "GUI vannet raamis", siis olete tõenäoliselt pensionär ja mitte kaugel: kunagi õpetati talle seda viisil ja 25 aasta jooksul ei mõelnud ta kordagi normatiive vaadata.
Neile, kes kahtlevad, annan veel ühe argumendi. Endiselt pole tühistatud SNiP 1.06.04-85 "Projekti peainseneri (peaarhitekti) eeskirjad. See sisaldab järgmisi sätteid:
"2.2. Projekti peainsener (peaarhitekt) vastutab vastavalt põhiülesannetele:
2.2.15. Kinnitus sisse materjalid projekt vastav kirje et ettevõtete, hoonete ja rajatiste ehitamise projekt- ja kalkulatsioonidokumentatsioon on välja töötatud vastavalt normidele, reeglitele, juhistele ja riiklikele standarditele. Ei sõnagi rohkem, nõudes töödokumentatsiooni eraldi fikseerimist.
Nüüd tsiteerin kogumiku huvides oma küsimust, mis sisaldus seletuste kogumikus, 2. number “Ehitamise projektdokumentatsiooni süsteemi standardite nõuete selgituste kogumine (küsimused-vastused). 2. väljaanne - OJSC "CNS", Moskva, 2012 ":
"4. Täpsustage vajadus tuua" GIP vande "üldandmete lehtedele. Seda nõuet ei sisaldunud isegi GOST 21.101-97, kuid märkimisväärne hulk projekteerimisorganisatsioone jätkab inertsist nõuete täitmist. tühistatud 1979. aasta GOST.
Vastus: Jah, jätkates "töödokumentatsiooni vastavuse arvestuse" läbiviimist, nagu see oli 1993. aastal tühistatud GOST 21.102-79 puhul, rikuvad need projekteerimisorganisatsioonid praegu kehtivat standardit. Vastavalt GOST R 21.1101-2009 punktile 4.3.5 on dokumendis esitatud dokumentatsioon projekteerimisdokumentatsiooni vastavuse kohta tehniliste kirjeldustega antud projekteerimisülesandele, kehtivate TR-i, GOST-ide, SP-de jne nõuetele. üldised juhised üldistel andmelehtedel.
Küsimus segab jätkuvalt mõtteid ja seletuste raamatu 4. number „Ehitamise projektdokumentatsiooni süsteemi (RAK) standardite nõuete selgituste kogumine (küsimused-vastused). 4. väljaanne - OJSC "CNS", Moskva, 2015 " Loe uuesti:
"5. küsimus: kas on vaja väljastada GOST R 21.1101-2013 punkti 4.5.6 nõue töödokumentatsiooni vastavuse kohta kõikidele normidele ja reeglitele eraldi, raami sisse ja panna GUI allkiri?
Vastus: GOST R 21.1101-2013 ei esita nõudeid üldiste juhiste lõigule, mis sisaldab dokumenti "töödokumentatsiooni vastavuse kohta" ja selle eraldi allkirjastamist GUI poolt.
Töödokumentatsiooni (GIP) koostaja allkiri on kohustuslik tööjooniste ja lisaallkirjade üldandmete lehtede peamistel pealdistel. sama isik samadel lehtedel olevat teavet ei nõuta.
Kui samal dokumendil (ja enamasti samal lehel) on kaks GUI allkirja, ei muuda dokumentatsiooni kaks korda paremaks.
Ärge ajage segi töödokumentatsiooni "üldises juhises" olevat elementi projekti dokumentatsioonis oleva "projekteerimisorganisatsiooni sertifikaadiga""
Piisavalt graafilise kasutajaliidese viisa tiitellehel
Meid auditeerib igal aastal standardimise territoriaalne organisatsioon
ja kommentaare ei olnud
Mina ja mitte ainult mina olen juba teatanud, et järgige teie dokumentatsiooni nii, nagu te õigeks peate
Näib, et projekteerimisdokumentatsiooni teostab ainult teie organisatsioon projekteerimisinstituutide armeest
õige
Rohkem minult kommentaare ei tule.
Kordan, et see küsimus on juba tekitanud "hambahammustuse" ja kas poleks aeg pühendada kasulikku aega töödokumentatsiooni väljatöötamisele
Ma ei mõista teie pahameelt. Kui te ei ole huvitatud või olete kõik ise otsustanud ja te ei tohiks selle üle arutlemisele aega raisata, siis ma ei sunni teid seda tegema. Pealegi oli teie arvamus sellel teemal teada juba enne selle loomist. Ja ma kirjutasin teile selle kohta, öeldes, et mind ei huvita mitte ainult minu ja teie arvamus see küsimus kui ka teised spetsialistid. Samuti ei väitnud ma kuidagi, et minu ettevõte on minust isiklikult, disainerina, erinevalt sinust üle. Meil on lihtsalt vaidlus registreerimisreeglite üle ja ainult teie kommentaaride põhjal minu projekti kohta. Muidugi püüan ma oma projekti kaitsta, nagu teeksite teie minu asemel. Aga olen valmis kõike mõistma ja edasises disainis vastavaid muudatusi tegema, arvan, et iga endast lugupidav disainer soovib välja anda korrektselt vormistatud dokumentatsiooni.
8.7 Projekti dokumentatsiooni köidete tiitellehtedele on alla kirjutanud:
- organisatsiooni juht või peainsener;
Projekti peainsener (arhitekt).
Projekti peainseneri (arhitekti) allkirjad on kohustuslikud tööjooniste üldandmete lehtedel, tööjooniste olulisematel lehtedel, projekti graafilisel osal ja aruandlusuuringu dokumentatsioonil;
GUI vande kohustusliku olemasolu ja OD-is olevate regulatiivdokumentide loendi kohta olen juba lingid postitanud.
Siit teeme järelduse. Vaatamata standardimise territoriaalse korralduse kommentaaride puudumisele (ma ei usu, et suuri spetsialiste on) ja teie tohutule kogemusele, mida ma väga austan, mainite GOST 21.1101-2009 seisukohalt korduvalt, koostage OD siiski valesti, nagu enamik (kui mitte öelda kõik) siin (ja mitte ainult siin), mitte välistades mind.
Kes rikub suuremal määral, kes vähemal määral, aga absoluutselt kompetentse vähemalt OD-ga ei saanud keegi kiidelda (loodame, et keegi on, seda enam, et lubas) ja see on tegelikult kahetsusväärne. Jääb vaid seda tõsiasja häbematult tunnistada, hoolimata nende regioonidest ja teeneid, teha vigade kallal tööd ja jätkata nõuete täitmist. Põhimõtteliselt sellepärast ma selle lõime lõin.
Postitatud 01.04.2015
M. S. Podolsky, Riikliku Projekteerijate ja Geodeetide Ühingu tööstusrajatiste tehnoloogilise projekteerimise komitee peaprojektide inseneride tegevuse korraldamise allkomisjoni esimees, teaduslik nõunik Rahvusvaheline kool MGSU projektide peainsenerid (peaarhitektid).
A. V. Litvinov, asetäitja Peadirektor Konsultatsioonikeskus "TsNIO-projekt", Moskva Riikliku Ehitusülikooli projektide rahvusvahelise peainseneride kooli (peaarhitektide) nõukogu liige
AT kaasaegsed tingimused haldamisel on kliendil võimalus valida projekteerimisorganisatsioon (tarkvara) vastavalt tingimuste, hindade ja pakutavate teenuste kvaliteedi optimaalsele suhtele. Eeltoodud kriteeriumide näilise võrdsuse juures võib just projekti dokumentatsiooni kvaliteet saada otsustavaks tingimuseks tarkvara edukuses konkursil. Projekti dokumentatsiooni kvaliteeti hinnatakse nii objektiivsete parameetrite järgi - vastavus olemasolevate normide ja reeglite nõuetele kui ka subjektiivne - kliendi nõuete maksimaalne rahuldamine. Nii need kui ka teised parameetrid muutuvad pidevalt: kliendid liiguvad standardprojektilt individuaalsele disainile, regulatiivses, tehnilises ja seadusandlikus aluses avaldatakse muudatusi ja täiendusi iga kuu, ilmub uusi. Ehitusmaterjalid, uued seadmed, tehnoloogiad jne. Tavalisele kliendile, kes on projekti dokumentatsiooniga "rahul" või "ei ole rahul", lisandub vajadus pidevalt parandada klientide rahulolu ning see on kinnistunud rahvusvaheliste standardite ISO 9000 seeria ideoloogiasse.
Varustama nõutav kvaliteet kui mitte, peab tarkvara nendega sammu pidama teaduse ja tehnoloogia areng, siis vähemalt kursis olla, pakkudes kliendile uusi, originaalseid ja töökindlaid disainilahendusi.
Mis takistab projektide peainseneride (peaarhitektide) (tegevjuhtide) töö reaalset täiustamist? Meie hinnangul on esiteks põlvest põlve disainerite põlvest põlve edasi kanduvad valitsevad valed stereotüübid GUI kohast ja rollist disainiprotsessis ning teiseks tarkvarahaldurite ebapiisav kvalifikatsioon disainerite tegevusega seotud küsimustes. GUI-d, mis ei võimalda neil teha adekvaatseid otsuseid, kolmandaks selge ettekujutuse puudumine sellest, millest disainilahenduse kvaliteet koosneb ja millise osa eest GUI vastutab, neljandaks lihtsustatud arusaamine kvaliteedi kujundamise mehhanism, sealhulgas siis, kui seda rakendavad alldisainerid, ja lõpuks, viiendaks, kuna enamik disainereid ei mõista veel GUI rolli tähtsust kulude vähendamisel. projekteerimistööd.
Oleks vale arvata, et tarkvarahaldurid ja GUI-d ise ei taha eelnimetatud põhjustega tegeleda, kuid nende katsed ei too märgatavaid tulemusi, sest selle asemel, et toetuda faktidele, mis selgelt õigeid otsuseid dikteerivad, juhinduvad varasemast kogemusest ning subjektiivsed arvamused, mis ei vasta aja nõuetele.
Nende teemade arutamise käigus sattusime sageli paljude kolleegidega barrikaadi vastaskülgedele – omamoodi “kollektiivsele vastasele”, kelle vaated kujunesid ajalooliselt ja kes elab endiselt minevikus majandusreaalsuses. See artikkel on täiendav vastuväide "kollektiivsele vastasele".
Nagu teada, kaasaegne juhtimine soovitab olulised määrused dokumenteerida, kuid igale määrusele peaks eelnema põhimõtete kujundamine, mis kehtestavad näiteks "mööda või üle jõe" ehitatakse sild. See on reeglite koostamise kõige olulisem osa. Selles etapis tuleks saavutada erialaringkondades konsensus, misjärel ei tohiks ükski regulatiivne piirang kokkulepitud põhimõtetega vastuolus olla.
Paraku võidutsevad tegelikkuses “halvad stereotüübid”, mis enamasti pole seotud mitte ainult tootmise korraldamise ja juhtimise teadusega, vaid sageli lihtsalt terve mõistusega.
Mõelgem mõnele meie arvates ekslikule ideele, millest vabanemine on disainiäri arendamisel tõeline reserv:
1. GUI vastutab projekteerimise (töö)dokumentatsiooni kvaliteedi eest, st GUI vastutab kõige eest.
See on võimatu. Töönõuded või, nagu tänapäeval öeldakse, GUI "vastutus ja volitused" on ajalooliselt korrelatsioonis nii disainiobjektidele esitatavate nõuete keerukusega kui ka klientide ootuste muutustega projekteerimistulemuste suhtes. Varem juhtis projekteerimist ja ehitamist üks spetsialist, kes tegi kõik otsused. Hetkel on GUI põhiülesanne tagada vajalik investeeringute dünaamika, aga ka kliendile projekti elluviimisest saadav tulu, mis on piisav, et kompenseerida investoritele nende investeeritud ressursse ja võetud riske. Seega tehakse kõik otsused GUI kujundamisel vastavalt kriteeriumile majanduslik efektiivsus rajatise projekteerimine, ehitamine ja käitamine. Sellest tulenevad nõuded tema kvalifikatsioonile. Kõik teised projekteerimisprotsessis osalejad langetavad otsuseid vastavalt tehnilise optimaalsuse kriteeriumile ja see tingimus realiseeritakse projekteerimisotsuste kooskõlastamise protsessis projekti sektsioonide peaspetsialistide poolt.
2. GUI "vanne" vabastab ülejäänud projekteerimisel osalejad vastutusest projekteerimis(töö)dokumentatsiooni kvaliteedi eest.
Teisisõnu vastutab GUI projektis vastavuse eest rajatiste projekteerimise, ehitamise ja käitamise normidele ja standarditele, isereguleeruvate organisatsioonide standarditele, kliendi individuaalsetele nõuetele tehnilisele tasemele ja kvaliteedile, arhitektuursele väljendusrikkusele ja sotsiaalne tähtsus objektid. Peame vajalikuks naasta tähenduste juurde: vastutus mille eest ja mis juhtudel.
Ilmselgelt võib vastutus tekkida, kui ilmneb spetsialist isiklikult tehtud või seda isiklikult kontrollinud töö negatiivne tulemus; kui on olemas vastav, kuupäevaga tagatud ja ka dokumenteeritud allkiri, mille ja kelle ees vastutate ning millal see lõpeb. seda kohustuslikud tingimused isikliku vastutuse eest. Vastasel juhul triumfeerib kollektiivne vastutustundetus. Võtame näite. Nagu teate, peavad joonised olema allkirjastatud: "arendatud", "kontrollitud" ja "standardkontroll". Pöörakem tähelepanu sellele, et allkirjad on antud tegude kaupa ehk vastavad küsimusele: mida sa tegid? - arenenud; Mida sa tegid? - teostas normatiivkontrolli jne. Me ei tohi lubada projekteerimisorganisatsioonide "amatöörtegevust" ja osakonnajuhatajate, peaspetsialistide, projekti peainseneride jne allkirjade ilmumist joonistele. Rõhumärgid nihkuvad ja allkirjad hakkavad määrama mitte " mida tegi", aga "kes tegi".
Nagu juba mainitud, tähistab allkiri vastutust. Pole allkirja - pole vastutust. Kuna vastutusel on piirid, tuleb kokku leppida, kuhu nad lähevad, ehk siis veenduda, et kõik mõistavad vastutusvaldkonda ühtemoodi. Lepingu tähendus on järgmine: igal joonisel on sisu (näidatud on „mida“) ja kujundus („kuidas“ on näidatud). Töövõtja vastutab sisu ja kujunduse eest. Sisu eest - enne inspektorit, disaini eest - enne normikontrolöri. Töövõtja vastutus lõpeb hetkel, mil inspektor ja normikontrolör oma allkirjad annavad. Järgmiseks on vaja kindlaks teha, kelle ees inspektor ja normikontrolör vastutavad. Ideaalis peaks see olema klient, kes on tõesti huvitatud allkirja ja tulemuse sobitamisest. Projekteerimisorganisatsioonis endas on võimatu leida neid, kes järgivad inspektorit ja normikontrolöri. Aga kas see võib olla GUI? Sel juhul tähendab GUI allkiri seda, et ta kontrollis veel kord joonise sisu ja kujundust ning võttis vastutuse, sealhulgas „rajatiste projekteerimise, ehitamise ja käitamise normide ja standardite projektis järgimise eest ... ” jne jne. Kuid GUI-l on füüsiliselt võimatu kontrollida, kas kõik disainilahendused vastavad kõigile standarditele ja nõuetele. Seetõttu pole GUI-le üldiselt kõige eest vastutavaks seadmine midagi muud kui loits, mis on täitmise võimatuse tõttu formaalne ja vajadusel ohtlik kellegi teise süü eest karistada. ISU on vaid üks näidendi "Projekti dokumentatsioon" paljudest autoritest.
3. Kui ehitusplatsil juhtub midagi tõsist, siis GUI on esimene, kes "vangistatakse".
Kui juhtub midagi tõesti tõsist, siis määrab uurija pärast kohtutehnilise ekspertiisi määramist või pärast mitme sellise ekspertiisi tegemist välja projekteerija, kes tegi näiteks ehitise arvutuse ja rakendas vale koefitsiendi, seejärel määrab kontrollija. arvutus ja see isik on see, kes süüdistuse esitab, kuid kohus võib teatud asjaoludel esinejat ja inspektorit karistada.
4. GUI peab olema projekti kõigis valdkondades kõige kvalifitseerituim disainer.
On selge, et see lihtsalt ei saa olla, sest projekti dokumentatsioon sisaldab vähemalt kümmet eriosa, mille töö eeldab enam kui kahekümne eriala olemasolu. See "halb stereotüüp" laieneb ka ideele nimetada tegevjuhi ametikohale spetsialist. Otsus tegevjuhi ametisse nimetamise kohta on aga otstarbekas langetada konkursipõhise valiku alusel ning juhinduda hoopis teistest kriteeriumidest.
Peainseneri ametikohale kandideerija peab taotleja poolt põhjendama projekteeritava objekti kõrgemate tehniliste ja majanduslike näitajate saavutamise võimalust, vähendades esialgset projekteerimis- ja ehitusaega, vähendades projekteerimistööde töömahukust (maksumust), soodsamaid tingimusi. arveldusteks projektis osalejatega projekteerimisorganisatsiooni jaoks, samuti projekteerimisobjekti kliendi lisanõuete ulatuse laiendamiseks (7.2.1 "d" GOST R ISO 9001-2008) jne. GUI maine on eriti oluline : iseloom, seltskondlikkus, töökus, pühendumus, tõhusus, täpsus, korralikkus, läbirääkimisvõime, tähelepanelikkus, viisakus, vastutulelikkus, sooritus jne.
Tsiviilobjektide puhul võib projekti peaarhitekti (GAP) ametikohale määramisel eeliseks olla majandus- ja arhitektuurihariduse olemasolu. Teine prioriteet on majandusharidus, kolmas arhitektuur ja lõpuks lihtsalt inseneriteadus.
Tööstusrajatiste (tehnoloogiline projekteerimine) puhul võib projekti peainseneri (CIP) ametikohale määramisel eeliseks olla majandushariduse ja projekteerimisobjekti spetsiifikale vastava tehnoloogilise hariduse olemasolu. Teine prioriteet on majandusharidus, kolmas tehnoloogiline ja lõpuks lihtsalt inseneriteadus.
Nii esimesel kui ka teisel juhul peab PIU-l (GAP) olema projektijuhtimise kvalifikatsioon. Võistlusliku valiku tulemuste põhjal määratakse tegevjuht tarkvarajuhi vastava korraldusega ametikohale.
5. Kui projekti osade osas on peaspetsialistide vahel lahkarvamusi, teeb lõpliku otsuse ISU.
Kujutage ette järgmist pilti: Peaspetsialist - elektrik oma projektijaos otsustas, et elektrikilp oleks selliste ja selliste telgede vahel ning hoone sellise ja sellise märgi juures. Peaspetsialist - samas kohas soojuspunkti asuv küttetehnik. Nad tulevad GUI-sse, et neid "leppida". Loomulikult on iga vastava eriala peaspetsialisti kvalifikatsioon kõrgem kui tegevjuhil. Kui ISU arutab seda küsimust nendega kavandatud tehnilises valdkonnas, on see ilmselgelt ebasoodsamas olukorras. Ta peaks tõlkima arutelu majandustasandile, öeldes, et üks variant maksab nii palju ja teine maksab nii palju, võttes arvesse mitte ainult ehituskulusid, vaid ka tegevuskulusid, samuti võimalik risk seotud seadmete maksumuse muutustega. Võttes ja põhjendades oma otsust majanduslikust aspektist, peab GUI, kes vastutab selle otsuse eest investori ees, otsima spetsialistidelt sobiva tehnilise lahenduse. Tänapäeval saavad vähesed GUI-d nii toimida, kuid see on GUI missioon, osa vastutusest disainilahenduste kvaliteedi eest.
6. GUI peaks olema ennekõike tehniline eriala.
Oleme juba rääkinud, milline eriala ja miks peaks GIP-l olema. Teaduse ja tehnoloogia kiirenenud arengu tingimustes sõltub projekti dokumentatsiooni kvaliteet otseselt tegevjuhtide oskuste süstemaatilisest täiendamisest. Tänasel päeval peab tegevjuht olema pädev projekteerimisprotsessi korraldamise ja juhtimise, projekteerimise majandusliku efektiivsuse tagamise meetodite, ehituse ja rajatise ekspluatatsiooni osas, et saada oma koht konkursil. Kuid isegi edukad tegevjuhid tunnevad nendes küsimustes oma teadmiste puudust, püüdes iseseisvalt kompenseerida puudujääke oma pädevustes.
Nende probleemide lahendamiseks komisjoni algatusel protsessi kujundamine NOPRIZi tööstusrajatiste ja Moskva Riikliku Ehitusülikooli (MGSU) Rahvusuuringute Instituudi Ehitus- ja Arhitektuuriinstituudi (ISA), kus osalevad projekti TsNIO konsultatsioonikeskus ja ehitustööstuse täiendõppe komitee Venemaa Ehitajate Liidu (RCC), projektide rahvusvahelise peainseneride (peaarhitektide) kooli. Koolinõukogusse kuulusid Vene Föderatsiooni ja SRÜ riikide tuntud spetsialistid projektide (töö)dokumentatsiooni projekteerimise ja kvaliteedi tagamise alal. Projektide Rahvusvahelise Peainseneride Kooli (peaarhitektide) nõukogu esimehel Meshcherin Igor Viktorovitšil on ainulaadne töökogemus peaarhitekti ja peaarhitektina NSV Liidus, Venemaal, USA-s ja Itaalias.
Teave Rahvusvahelise GUI-de kooli (GAS), sealhulgas konkreetsete kursuste läbiviimise kohta, on postitatud ISA MGSU, riikliku disainerite ja geodeetide liidu, projekti TsNIO veebisaitidele ning projektiprojektide veebisaitidele Venemaa Föderatsioon, Kasahstan, Valgevene ja Ukraina.
Rahvusvahelise GUI-de kooli peamine eesmärk on panna yo m täiendkoolitus, et tagada kõrgelt professionaalsete tegevjuhtide kaadri väljaõpe. Kaasaegsetele nõuetele vastavad programmid, kursuste praktiline suunitlus, võimaldavad täita tehnoloogilise ja arhitektuurse ja ehitusliku projekteerimise vajadusi, hoida tegevjuhtide pidevat erialast kasvu ja taastootmist ning koostada ka personalireservi ametikohtade täitmiseks. tegevjuhid disainiorganisatsioonide korraldusel.
Rahvusvahelise GUI-de kooli "haridusportfellis" on kaks peamist toodet:
Kavandatav GUI-de ümberõppe süsteem on paindlik, vastav aja vajadustele ja vastab väga hõivatud inimeste tegelikele vajadustele. praktiline töö disainerid. Programmide sisus on tasakaalus teoreetilised ja praktilised teadmised ning disainijuhtimise kogemus. On väga oluline, et programm eeldaks õpilaste laia territoriaalset katvust ja õppimise mugavust, sealhulgas kaasaegsete põhimõtete, õppevormide ja meetodite kasutamise kaudu: modulaarsus, õppimine "tulemuseni", koolituse varieeruvus, vahemaa. õppimine jne.
Peamised teemad, mida MGSU rahvusvahelise GIP-kooli kursustel arutatakse:
1. Olukord ehitusturul ja selle mõju GIP tegevusele.
2. Peamised muudatused mõiste "kvaliteedijuhtimissüsteem" sisus seoses ISU tööga.
3. Projekteerimisorganisatsioonis (PO) vastutus projekteerimislahenduste väljatöötamise ja nende kvaliteedi eest jaotus esimese juhi, peainseneri, tootmisdirektori, GUI, tehnilise osakonna ja tootmisosakondade (töökodade) vahel disaini ettevalmistamise, väljastamise ja rakendamise protsessis. ehitusalane (tehniline) dokumentatsioon, sealhulgas projekteerimishinnangute kontroll, kontrollimine, analüüs, kinnitamine, kinnitamine ja kinnitamine.
4. GUI-de rolli ja koha selgitamine kliendile suunatud tarkvara "otspunktiprotsessis": "suhtlus tarkvara klientidega" - "tarkvaratellimuste portfelli moodustamine ja toetamine" - "tarkvaratellimuste koostamine ja väljastamine / juurutamine". projekti (töö)dokumentatsioon" - "projekti elluviimise toetus ehituses" – "ehituses teostatavate tarkvaraprojektide garantiikohustuste täitmine".
5. Tootmisüksuse juht: disainer või juht (juht)? Koostoime GUI-dega. Tootmisüksuse juhi peamised juhtimisobjektid: tööjõuressursse, töö, aeg, rahandus, materiaalsed ressursid; alluvus, autoriteet funktsionaalsed kohustused tootmisüksuse juhi (vastutus), tema tegevuse hindamise kriteeriumid.
6. Projekti dokumentatsiooni koostamise töö "käivitamise" kord vastavalt sõlmitud projekteerimise üldlepingule. Eeskujulik leping alltöövõtja projekteerimisorganisatsiooniga (SPO); STR-de hindamise, valiku (valiku) ja ümberhindamise kord; allhanke ja allhanke mõisted.
7. GUI suhtlemine lepinguosakonna, tehnilise arhiivi, projekti väljastamise osakonnaga. Põhinõuded GUI-le täidesaatva distsipliini süsteemis.
8. ISU uute ülesannete analüüs; tüüpiline töö kirjeldus GUI; nõuded GUI-le arhitektuurse järelevalve käigus (sh allprojekteerijate poolt); GUI ja tehnilise ümbervarustuse, ettevõtte laiendamise, moderniseerimise, kapitaalremont jne.
9. Klientide rahulolu jälgimine projekteerimisorganisatsiooni protsesside ja tulemustega.
10. GUI roll disainiorganisatsiooni toodete (teenuste) tüüpide laiendamisel. ISU maine kujundamine investeerimisprojektis osalejate seas.
11. Allprojekteerija juhtimine. Kaasaegsed nõuded disainis osalejate valikule.
12. Märkused ISU-de uute organisatsiooniliste ja metoodiliste dokumentide kavandite kohta: Standard ametialane tegevus Peainsener, Soovitused tegevjuhi tegevuse korralduse kohta, Tegevjuhi profiil, Tegevjuhi ametikohale ettevalmistamise ja ametisse nimetamise nõuded, mille töötab välja tegevuskorralduse allkomisjon NOP tootmisrajatiste tehnoloogilise projekteerimise komisjoni peaprojektide inseneride kohta jooksval aastal.
13. Lepingute läbirääkimine ja lepinguhindade määramine. Lepingute liigid.
14. Suhtlemine riiklike ja mitteriiklike ekspertiisidega.
15. Juriidiline ja organisatsioonilised alused disain, GUI-de tööga seotud regulatiivsed dokumendid, sealhulgas GOST R 54869-2011, samuti EUROCODE süsteem.
16. Projekteerimistööde maksumus. Kulude arvutamise põhiindeks ja ressursimeetodid. Eelarvedokumentatsiooni vormid. Disainlahenduste majandusliku efektiivsuse hindamine.
17. Projekti riskijuhtimine. Riskide määratlemine ja tuvastamine (riskide kategooriad, teadaolevad riskid ja teadmata riskid, riski suurus, esinemise tõenäosus ja riski mõju määr); riskijuhtimise eelarvestamine; määratud tähtaegade ja projekti eelarve täitmise tõenäosuse määramine; riskidele reageerimise meetodid (vältimine, üleandmine, leevendamine ja aktsepteerimine); riskisümptomite kontrolli all hoidmine.
18. Osalemine projekteerimis- ja mõõdistustööde hankelepingu saamiseks.
19. Kvaliteedijuhtimissüsteemi põhisätted projekteerimisorganisatsioonis, mis vastab GOST ISO 9001-2015 nõuetele.
20. Kliendi tehnilise järelevalve funktsioonid ja sisu. Riiklik ehitusjärelevalve.
21. GIP pädevused enese- ja täiendõppe küsimustes.
22. CIP, CAP funktsionaalses, organisatsioonilises ja finants institutsioonid projekteerimisorganisatsioon.
23. Turunduse ja müügiga seotud tegevjuhi pädevused.
24. ISU pädevus tema volituste, õiguste ja kohustuste kindlaksmääramise küsimustes.
25. Tegevjuhi pädevus oma kutsetegevuse tulemuslikkuse ja tulemuslikkuse ning motivatsiooni hindamisel.
Alates 2015. aasta maist on International School of GUIs programmis lisamoodul "Disainlahenduste majandusliku efektiivsuse hindamine" (30 akadeemilist tundi). Programmi kogumaht on 80 ak. tund. Selle mooduli tunde viivad läbi Riikliku Investeerimisspetsialistide Akadeemia (GASIS) õpetajad. teadusülikool Majanduskõrgkooli üliõpilased saavad ka GASIS tunnistuse.
International School of GUIs pakutavad haridus-, nõustamis- ja uurimisprogrammide teemad on keskendunud praegu disainiorganisatsioonide ees seisvate põhiprobleemide lahendamisele, täiustades tegelikult disainiprotsessi võtmefiguuride – GUI-de – oskusi.
Rahvusvahelise GUI-de kooli programmi põhiteemadel on arenenud TsNIO-projekti konsultatsioonikeskus.
Ja nüüd pöördume disainiotsuste kvaliteedi kujundamise mehhanismi poole, et selgelt ja ühemõtteliselt määrata GUI vastutuse piirid.
Mõned üldised disainikaalutlused:
1. Iga ehitusprojekt koosneb kolmest mudelist:
Tulevase objekti mudelid (ruumiplaneering ja insenertehnilised lahendused);
Selle loomise mudelid (Ehituskorraldusprojekt);
Selle toimimise mudelid (Tootmise korraldamine ja juhtimine).
2. Projekteerimisotsuse vormistamine seisneb selle reaalses vastuvõtmises ja seejärel on vaja selle vastavust kinnitada ehk teisisõnu kontrollida. Disainiotsuse tegemine iseenesest on valik alternatiivide hulgast ja vastavuse kinnitust on palju erinevaid valikuid ja vastavalt ka palju termineid, mis neile valikutele vastavad. Põhimõtteliselt sõltuvad valikud kinnitamiseks valitud ajast, kohast ja standarditest.
Disainlahenduse kvaliteet koosneb neljast peamisest omadusest. Kõik need omadused on tarkvaras kellegi poolt loodud ja mõeldud kellelegi. See, kes moodustab kvaliteedi vara, kannab selle eest isiklikku vastutust. Esimene on “tehniline teostatavus”, st projektlahendus peab olema selline, et seda oleks võimalik ehituse käigus teostada. Eelkõige on see vajalik ehitustöövõtjale ning selle moodustavad tema tehnikud, insenerid ja tootmisüksuste peaspetsialistid. Teine on “infovõimekus” ehk projektlahendus peab sisaldama kogu infot, mis on vajalik ehitus- ja paigaldustööde tegemiseks, seadmete tellimiseks, kõigi vajalike lubade ja kooskõlastuste saamiseks. Seda vajavad tellija ja ehitustöövõtja. Selle kinnistu moodustavad tootmisüksuste tehnikud, insenerid ja peaspetsialistid. Kolmas on projektlahenduse "majanduslik teostatavus" ehk projektlahendus peab olema rajatise ehitus- ja ekspluatatsiooniprotsessis majanduslikult konkurentsivõimeline. See on vajalik turu põhiisikule - investorile, see moodustatakse ja selle eest vastutab ISU. Neljas on “süstemaatiline”, st kõik projekti projekteerimisotsused tuleb kokku leppida. See on vajalik eelkõige disaineritele endile ja selle eest vastutavad projektide sektsioonide põhispetsialistid.
Disainiotsuseid tehakse viiel tasandil. Vaatleme neid tasemeid projekti disainiosa näitel. Esimene tase on "koostud, osad". Sellel tasemel teevad tehnikud otsuseid võrkude, sisseehitatud osade jms tugevdamise kohta. Teine tasand on "elemendid". Sellel tasemel projekteerivad insenerid talasid, sambaid, eraldiseisvaid vundamente jne. Kolmas on “komponendid”. Vanem- ja juhtivinsenerid projekteerivad lagesid, katteid, piirdekonstruktsioone jne. Neljas tase on “projekti sektsioon”. Sellel tasemel teeb peaspetsialist otsuse hoone konstruktsiooniprojekti ja konstruktsiooni peamiste tugevusparameetrite kohta. Viies tase on "projekti tehnilised ja majanduslikud näitajad". Otsuste tegemine sellel tasandil on ISU vastutusel.
Pöördume "projektlahenduse vastavuse kinnitamise" juurde. Need on projekteerimisotsuste kontroll, hindamine, kontrollimine, analüüs, valideerimine, kooskõlastamine ja kinnitamine. Siin on meie jaoks oluline määratleda GUI vastutuse piirid.
Kontroll hõlmab vastuvõetud projekteerimisotsuse korrelatsiooni kehtivate normide (reeglitega), st regulatiivsete dokumentidega, mis praegu kehtivad. hoonete kompleks(Vene Föderatsiooni linnaplaneerimise kood, SNiP, SN, GOST, VSN jne). Kontrolli tulemus - "vastab" või "ei vasta" projektlahendusele määratud normatiivdokumentidele.
Hindamine - sama kontrolliprotseduur, ainult "vastab" või "ei vasta" kõrval näidatakse, kui palju "vastab" või "ei vasta". Üldjuhul antakse hindamise tulemus kvantitatiivselt, näiteks hoonete tulevahe on normist 10 meetri võrra väiksem.
Niinimetatud normatiivne kontroll on kontrolliga samas reas, ainsa erinevusega, et vastuvõetud projekteerimisotsuse võrdlemiseks normatiivdokumentidega kasutatakse GOST SPDS-i.
Kontrollimine hõlmab vastuvõetud projekteerimisotsuse võrdlemist sisendprojekti andmetega (projektiülesanne, projekteerimise sisendandmed, spetsifikatsioonid). GOST ISO 9001-2011 sätestab üsna selgelt nõuded projekteerimislahenduste kontrollimiseks, sealhulgas tulemuste kontrollimise ja salvestamise planeerimiseks. Eelkõige ütleb seda 7.3.5 „Vastavalt kavandatavale korrale kontrollitakse projekteerimis- ja arendusväljundite vastavust projekteerimis- ja arendussisendi nõuetele. Ülevaatuse tulemuste ja kõigi vajalike toimingute protokollid tuleb säilitada ja säilitada.. Kuna "sisendandmed" sisaldavad reeglina tehnilisi ja majanduslikke näitajaid (nõudeid) projekti dokumentatsioonile, kontrollib GUI nende vastavust tegelikult laekunud näitajatele.
Analüüs – GUI juhitav kollektiivne tegevus – võimaldab prognoosida olemasoleva projekteerimisprotsessi muutumatuse tagajärgi projekteerimislahenduste tehniliste ja majanduslike omaduste, projekteerimiskulude ja selle kestuse osas. GOST ISO 9001-2011 punktis 7.3.4, samuti kontrollimiseks, on kehtestatud analüüsinõuded, nimelt: „Sobivatel etappidel tuleks vastavalt kavandatud tegevustele läbi viia süstemaatilised projekteerimis- ja arendusülevaatused, et hinnata projekteerimis- ja arendustulemuste vastavust nõuetele, samuti tuvastada võimalikud [disaini- ja arendus] probleemid ning teha ettepanekuid vajalike tegevuste kohta. Sellistes läbivaatamistes osalejate hulgas peaksid olema läbivaatatava projekteerimis- ja arendusetapi jaoks oluliste funktsioonide esindajad. Analüüsi tulemuste ja kõigi vajalike toimingute protokollid tuleb säilitada ja säilitada. Pange tähele, et analüüs tuleb planeerida ja selle tulemused dokumenteerida. Samuti on ilmne, et analüüsi ei saa teha projekteerimise alguses, kuna pole veel midagi analüüsida, ja projekteerimise lõpus, kuna “rong on juba lahkunud” ja protsess on lõppenud. Disainis vastutab GUI analüüsi läbiviimise eest. Üldjuhul kogub GUI projekteerimisprotsessi käigus perioodiliselt kokku tootmisosakondade juhid ja projekti osade peaspetsialistid ning arutab nendega projekteerimise edenemist ning tehtud projekteerimisotsuste tehnilisi ja majanduslikke omadusi, et veenduge, et kavandi lõpus vastaksid saadud kujundusmaterjalid "sisendandmetele" .
Kooskõlastamine eeldab kindlustunnet, et antud projektlahendus ei ole vastuolus projekti teiste osade projektlahendustega, s.t näiteks võrreldakse projekti projekteerimisosa projektlahendust elektri-, sanitaar- või soojustehnilise sektsiooni projektlahendustega. projektist.
Kooskõlastamise eest vastutab ÜVK, kooskõlastamise õigsuse eest vastutavad projekti osade vastavad peaspetsialistid.
Tuletage meelde, mis on "valideerimine". Projekteerimisel on võimalik kaks kinnitusolukorda: esimesel juhul saab seda teha otse “paberil”, st disainiotsus on arvutiekraanil. Näiteks projekteerimisotsuseks on kalkuleeritud ja projekteeritud tala, mis peab vastu pidama vastavale koormusele. Nõuetele vastavuse kinnitamiseks piisab, kui kasutada sama arvutusmeetodit, mida kasutati selle otsuse tegemisel (või alternatiivset meetodit) ning kui see meetod on tõestatud ja usaldusväärne, annab korduv arvutus täieliku kindlustunde projekti õigsuses. otsus. Või teine näide, projekteerimisülesandes on märgitud hoone vastava korruse ruumide koosseis ja nõutavad pinnad. Selle korruseplaani kujunduslahendust on lihtne kontrollida, võrreldes seda algandmetega. Tuleb rõhutada, et sellised disainilahendused on projekteerimise kogumahus vähemalt 80-90 protsenti. Nende hulka kuuluvad standardprojektide, standardsete sõlmede ja osade abil tehtud projekteerimisotsused, heakskiidetud individuaalsed varakult välja töötatud disainilahendused, mida taaskasutatakse, nõuetekohaselt sertifitseeritud seadmete kataloogid jne jne. Teisisõnu räägime kõnest usaldusväärsest, testitud, paljudest korda rakendatud, kahtlemata disainilahendused.
Teine olukord on see, kui projektlahendust ei saa traditsiooniliste kontrollitehnikate abil usaldusväärselt kontrollida. Neid saab kontrollida ainult ehitatud rajatise ehitamise või käitamise ajal, samuti tehes spetsiaalseid katseid tingimustes, mis on võimalikult lähedased rajatise ehitamisele või käitamisele. Selline vajadus tekib siis, kui kasutatakse juba reklaamides soovitatud või välja kuulutatud arenenud tehnoloogiaid või materjale, uusi arvutusmeetodeid, seadmeid, mida pole varem kasutatud, tehnoloogilised lahendused, millel pole analooge jne Näiteks näitusel tutvusid disainerid uue katusematerjal, mida aktiivselt reklaamitakse, ja selle materjali omadused on muljetavaldavad.
Seda materjali võidakse otsustada kasutada katusel, mille pindala on 20 tuhat ruutmeetrit, kuid on konkreetselt ette nähtud, et ehitamise ajal peate esmalt lõpetama 10-ruutmeetrise katuseosa, looma sellele dünaamilise koormuse. teatud aja peale vala vett peale ja vaata kuidas käitub sel juhul katuse alumine pind. Kui testi tulemus on positiivne, annavad disainerid loa ülejäänud katuse valmistamiseks. Mõnikord tekib selline vajadus geoloogiliste tingimuste suure ebakindluse tõttu keerukates ehituspiirkondades, kui geodeedid ei suuda (sh majanduslikel põhjustel) pinnase omadusi piisava täpsusega modelleerida konkreetsetes vundamendi asukohtades. Nendel juhtudel viitavad need proovivaiade ajamise vajadusele ja alles pärast seda kinnitavad võimalust rajada kogu objekti alla vaiaväljak.
See on projektlahenduse valideerimine. Valideerimise kasutamine näitab projekteerimisorganisatsiooni pühendumust kõigele uuele, edasijõudnule. See on märk konkurentsivõimest disainilahendustes, see on soov võtta disainis juhtpositsioon läbi klientide rahulolu pideva parandamise. Valideerimise fakti eest vastutab GUI, valideerimise sisu eest - projekti sektsioonide peamised spetsialistid.
Kooskõlastamine on luba valminud projektdokumentatsiooni tellijale üleandmiseks. Selle eest vastutab GUI ja ta rakendab seda siis, kui allkirjastab arve enne dokumentatsiooni kliendile saatmist.
Nüüd pöördume GUI vastutuse poole, mis on seotud projekteerimistööde kulude vähendamisega. Nagu teate, on kulude vähendamiseks palju võimalusi ja seda peavalu» juhtkond ja kõik juhtivad tarkvaraspetsialistid, kuna see on praktiliselt ainus viis disainiorganisatsiooni kasumi suurendamiseks. Olulise panuse sellesse annab GUI, mõistes vastutust allprojekteerijate juhtimise (allhanke) eest.
Praeguseks on saanud võimalikuks alamdisainerite (SPO) valimine nende hindamise, konkurentidega võrdlemise, regulaarse ümberhindamise tulemuste põhjal ning on ilmnenud GUI vastutus selle valiku eest. Kujunduses hakkas subjektide vahel toimima oluline põhimõte, et "kes maksab, see kutsub muusikat" mitte ainult teatud traditsioonilises mõttes, vaid ka ülddisaineri (GP) nõudena mõelda pidevalt täiustamisele (tagamisele). ) projekteerimistööde kvaliteet ja kulude vähendamine. Lisaks sätestab seadus, et ainult perearst vastutab Kliendi ees avatud lähtekoodiga tarkvaraga välja töötatud projekteerimis- ja kalkulatsioonidokumentatsiooni kvaliteedi eest. Seetõttu tuleb juhinduda GOST ISO 9001-2011 nõuetest ja allhankeprotsesside kasutamise juhistest // ISO/TS 176/SC 2/N 630R2, 24. november 2003).
Üldiselt on avatud lähtekoodiga tarkvara kolme tingimuslikku tüüpi:
- "tavalised" – STR-d, millega riigiettevõtetel on normaalsed turusuhted;
- "kaitstud" - kliendi olend, kellega perearsti suhte määrab klient.
Kasutades näidet suhetest avatud lähtekoodiga tarkvaraga, käsitleme kõiki alamsüsteeme kordamööda, võttes arvesse, et GUI mõnel juhul teeb otsuseid, teistel aga osaleb nende vastuvõtmises.
Alamprojekteerijate hindamine, valik ja ümberhindamine.
See alamsüsteem koosneb kahest plokist:
Heakskiidetud avatud lähtekoodiga tarkvara nimekirja (andmebaas, register jne) moodustamine ja pidamine ning selle uuendamine;
Avatud lähtekoodiga tarkvara valik määratud loendist konkreetse projektiga töö tegemiseks.
Esimese ploki tööde teostamise eest vastutab tarkvara tehniline osakond, teise ploki piires vastutab GUI.
Nimekirja moodustamiseks otsib, hindab, valib ja ümber hindab tarkvara tehniline osakond tarkvara vastavalt tarkvara vajadustele, kasutades GUI-dega ühiselt välja töötatud kriteeriume.
On selge, et selline lähenemine ei taga STR täielikku vastavust perearsti ootustele mõne küsimuse vormistamise raskuse tõttu. Näiteks küsimus kehtiva QMS olemasolu ja selle vastavuse kohta GOST ISO 9001-2011 nõuetele. Avatud lähtekoodiga tarkvara vastab, et QMS töötab ja vastab nõuetele, mida tõendab “N” sertifitseerimisasutuse sertifikaat. Kogemus GOST ISO 9001-2011 teatud nõuete täitmise hindamisel isereguleeruvad organisatsioonid disaineritest näitab, et enam kui 90% sertifikaatidest saadakse ametlikult, lihtsalt "ostetakse" ja neil pole sageli mingit pistmist konkreetse avatud lähtekoodiga tarkvaraga. Selgub, et perearst kannab tegelikku vastutust SPO koostatud projekti (töö)dokumentatsiooni kvaliteedi eest, kuid SPO valiku aluseks on SPO enda “sertifikaadid” vastuste näol SPO poolt esitatud küsimustele. küsimustik. Konkreetse rajatise projekteerimisel valib GUI reeglina loendist sobiva SS-i, juhindudes täiendavatest kriteeriumidest, sealhulgas SS-i territoriaalne asukoht, SS-i teadlikkus konkreetse ehitusplatsi omadustest, varasemad kontaktid. konkreetse Kliendiga, SS-i valmisolekut tellimust täita ja muud.
GUI peab enne avatud lähtekoodiga tarkvara projekteerimisse kaasamise otsuse tegemist otse organisatsiooni külastama. See on GUI uus ülesanne. Seda tehnoloogiat pakutakse ISO standardid 9000 seeria ja seda nimetatakse "teise osapoole" auditiks. Teise osapoole auditi kestus on mitte rohkem kui üks tööpäev (optimaalselt 3-4 tundi).
Selline lühike kestus on seletatav asjaoluga, et arvesse ei võeta kogu avatud lähtekoodiga tarkvara kvaliteedijuhtimissüsteemi, vaid ainult teatud võtmepunkte. Praktika näitab, et kui nendes punktides on kõik normaalne, siis suure tõenäosusega vastab STR perearsti ootustele.
Tuleb rõhutada, et Klient suhtleb ainult perearstiga, kellega tal on leping. Ülejäänud projektis osalejaid ta ei pruugi tunda. Seetõttu on suhe avatud lähtekoodiga tarkvaraga eranditult riigiettevõtete probleem. SPO toimib tegelikult perearsti täiendava struktuurilise allüksusena, mida ta peab projekti elluviimise protsessis juhtima samamoodi nagu "enda oma" struktuurijaotused, pidades silmas avatud lähtekoodiga tarkvara poolt välja töötatud projekteerimis(töö)dokumentatsiooni ajastust ja kvaliteeti, mille eest vastutab kliendi ees perearst. See määrab ka riigiettevõtte kohustused STR-de haldamisel.
Avatud lähtekoodiga tarkvara haldamise tüüp ja ulatus võib varieeruda märkimisväärses vahemikus: alates minimaalsest, kui tehniline ülesanne on välja antud ja tehtud töö vastu võetakse vähese kontrolliga või ilma kontrollita, kuni maksimaalseni, kui nõutakse, et avatud lähtekoodiga tarkvara juhinduda tellimuse täitmisel juhtimis- ja muudest perearsti poolt kinnitatud dokumentidest. Samal ajal viiakse läbi projekteerimis- ja kalkulatsioonidokumentatsiooni SPO täielik kontroll, sealhulgas sõltumatute ekspertide kaasamisel.
Nõutava juhtimise ulatuse määrab GUI sõltuvalt STR-i hindamise (ümberhindamise) tulemustest, sealhulgas võttes arvesse teise osapoole poolt auditi käigus saadud teavet, samuti sõltuvalt ettevõtte kavandatud kuludest. GM STR-materjalide sisendkontrolli jaoks, pidades meeles, et Need kulud lisavad projekti maksumust.
SPO juhtimise tunnused ISU peab väljastama alltöövõtulepingu “eritingimustel”. GPU tehniline osakond töötab selliste jaoks välja malli eritingimused”, mis pakub peaaegu kõiki võimalikke ja/või vajalikke avatud lähtekoodiga tarkvara haldamise aspekte ning GUI sisaldab avatud lähtekoodiga tarkvaraga sõlmitud konkreetse lepingu analüüsimisel neid haldusmeetodeid, mis vastavad konkreetse projekti tingimustele. Mida sügavam on avatud lähtekoodiga tarkvara kontrolli aste, seda väiksem on avatud lähtekoodiga tarkvara kujundusmaterjalide sisendkontrolli maht ja sellest tulenevalt ka perearsti maksumus.
Sellised juhtimismeetodid võivad hõlmata vajadust:
Avatud lähtekoodiga tarkvara poolt kasutatava projekteerimise tehnoloogilise protsessi kooskõlastamine perearstiga või projekteerimistööde teostamise tagamine kasutades tehnoloogiline protsess disain, mida kasutab perearst;
Projekteerimistööde ajakava kinnitamine, millest lähtuvalt peaks SPO välja töötama kalenderplaan lepingule lisatud tööd;
Konkreetse GUI (projektijuhi) määramine (kokkuleppel perearstiga) täitmiseks üleantud tellimusele (projektiosale) jne.
Sõltuvalt avatud lähtekoodiga tarkvara haldamise astmest võib riigiettevõtte sisendikontrolli maht varieeruda 100% -st peaaegu olematuks, st formaalne ümberarvutamine projekti dokumendid saadud avatud lähtekoodiga tarkvarast.
Pärast valminud projekt- ja kalkulatsioonidokumentatsiooni üleandmist Tellijale või pärast rajatise kasutuselevõttu (kui teostati arhitektuurne järelevalve) on GUI-l vaja viia lõpule allhanke projekt.
Selleks vajate:
Kontrollige SPO-lt projekti- ja kalkulatsioonidokumentatsiooni vastuvõtmist kinnitavate dokumentide olemasolu, sealhulgas kontrollige kindlaksmääratud dokumentatsiooni kvaliteeti;
Viia läbi avatud lähtekoodiga tarkvaraga tehtava koostöö hindamine ja selle tulemustest teavitamine tehnikaosakonnale nimekirja parandamiseks;
Saada avatud lähtekoodiga tarkvarast ja edastada perearsti arhiivi infot väljatöötatud individuaalsete efektiivsete kujunduslahenduste kohta, sh tasuta tarkvaraprogrammi dokumentatsioonis, mida saab soovitada taaskasutamiseks;
Valmistage ette avatud lähtekoodiga tarkvara ametlik ülevaade;
Lahendage (vajadusel ja võimalusel) avatud lähtekoodiga tarkvara majanduslike stiimulite küsimus.
Nüüd GUI kohustusest, mis on seotud osalemisega "tellimuste portfelli" moodustamises ja tarkvara maksumuse vähendamisega uute klientide otsimiseks.
Me räägime sellest, et vastavalt GOST ISO 9001-2011 punktile 7.2.1 "Tarbijatega seotud protsessid" peab tarkvara määrama nõuded:
1. Kehtestatud kliendi poolt, sealhulgas nõuded tarne- ja tarnejärgsetele tegevustele.
2. Klient pole määranud, kuid vajalik DCE konkreetseks või kavandatud kasutamiseks, kui see on teada.
3. Seadusandlik ja muu kohustuslik, seotud projekteerimis- ja.
4. Määratletud mis tahes täiendav tarkvara.
Mida esimese kolme nõuetegrupi (1-3) all mõeldakse, on enam-vähem selge. Täiendavalt selgitame, et “tellija poolt deklareerimata, kuid projekti- ja kalkulatsioonidokumentatsiooni konkreetseks või kavandatud kasutamiseks vajalikud nõuded, kui need on teada”, võivad hõlmata kõiki tarkvara enda nõudeid, mille täitmine määrab kvaliteedi, projektdokumentatsiooni hind ja tarneaeg.
Näiteks kui tellija saab projekteerimis- ja kalkulatsioonidokumentatsiooni, mida vastavalt olemasolevale projekteerimistehnoloogiale säilitatakse teatud aja enne kliendile üleandmist tehnilises arhiivis, siis tarkvara enda nõuded tingimuste osas. nimetatud dokumentatsiooni säilitamine arhiivis viitab standardi punkti 7.2.1 lõikele 2 . Täites standardi punktis 7.2.1 (1-3) toodud nõudeid, ei saa tarkvara saavutada konkurentsieeliseid, kuna neid nõudeid rakendavad tingimata kõik konkurendid. Turutingimustes jääb „ellu“ ainult tarkvara, mis suudab kindlaks määrata ja täita punkti 7.2.1 lõike 4 nõudeid. Nimetasime need nõuded „ette nähtud“ ja selgitasime nende tähendust: esiteks on need „arvatud“, sõnastatud tarkvara enda poolt, teiseks ei ole need kinnitatud ega kliendiga kokku lepitud ning kolmandaks toimub nende rakendamine kliendi arvelt. omavahendid PEAL. Selle tulemusena saab klient tema jaoks ootamatute või oodatust paremate parameetritega projektdokumentatsiooni (teenused), mis ei garanteeri mitte ainult kliendi rahulolu, vaid paneb imetlema pakutavat projekt- ja kalkulatsioonidokumentatsiooni (teenuse osutamist). Viimasel juhul võib tarkvara olla kindel, et klient pöördub selle juurde korduvalt tagasi. Ja kliendi pidamine on teatavasti 5-7 korda odavam kui uue otsimine. See on GOST ISO 9001-2011 põhimõtteliselt uue sätte olemus.
Et standardi punkti 7.2.1 punktis 4 toodud nõude täitmine avaldaks mõju tarkvara konkurentsieeliste kujunemisele, on vaja kindlaks määrata tarkvara kujunemise protsessi omanik. klientide eeldatavad nõuded, st üks juhtidest, kes kehtestab reeglid selle tegevuse läbiviimiseks. Tarkvara puhul peaks suure tõenäosusega olema protsessi omanik Peainsener instituut. Protsessi "omanik" ehk spetsialist, kes kujundab kliendi eeldatavad nõudmised konkreetsele projektile, peaks olema GUI. Selgituseks, GUI vastutab selle eest, et kliendi eeldatavad nõuded on määratletud ning nende nõuete sisu eest vastutavad tootmisüksuste põhispetsialistid.
Teine GUI kohustus kujuneb kliendiga sõlmitud lepingu (lepingu) analüüsi käigus. Kliendi pöördumine tarkvara poole võib olla erineval viisil: teave võidetud hanke (konkursi) kohta; ametlik kiri projektidokumentatsiooni väljatöötamise ettepanekuga; telefonikõne tarkvarahaldur; mitteametlik kontakt kolleegide kaudu jne. Ühe ülaltoodud signaali saamise ajal on soovitatav määrata GUI, kes juhib lepingu analüüsi kuni selle allkirjastamiseni kliendi poolt.
See GIP-i kohustus hõlmab:
Lepingu projekti kooskõlastamisel osalevate isikute ringi määramine ja vastutuse jaotus nende vahel;
Eelnimetatud juhtide ja spetsialistide kaasamine läbirääkimiste (töökoosolekute) pidamiseks tellijaga lepinguprojekti teatud sätete arutamiseks, sh läbirääkimised lepinguhinna määramiseks;
Konkreetsele kliendile ja disainiobjektile sobiva variandi valik mallide andmebaasist;
Alaprojekteerijate kaasamise vajaduse ja võimaluse väljaselgitamine ning nendega eelläbirääkimiste pidamine;
Riskide hindamine, mis võivad kaasneda lepingust tulenevate kohustuste täitmisega tarkvara poolt.
Kõik need toimingud tänastes tingimustes erinevad oluliselt meile teadaolevast praktikast. Näiteks lepingu projekti kinnitamine vormistatakse reeglina “Lepingulehele”, kus on märgitud vastava juhi täisnimi ja ametikoht, kes positiivse otsuse korral annab oma allkirja ja kui otsus on eitav, argumenteerib ta oma arvamuse kirjalikult. Meie hinnangul on vajalik kehtestada juhi vastutus lepingu projekti vastavate punktide eest. "Kooskõlastuste loetelu" punktide summa peab võrduma lepingu projekti punktide summaga. See tagab iga juhi isikliku vastutuse lepingutingimuste teostatavuse eest projekteerimisorganisatsiooni poolt ning lepingu projekti vastavate tingimuste võrdväärse mõistmise projekteerimisorganisatsiooni ja tellija poolt jne.
Selle artikli materjal võib mõnele disainerile vastuväiteid tekitada. Oleme valmis kolleegidega konstruktiivseks aruteluks neile sobivas vormis.
| Arutage foorumis |
|
| |
|
Projekti dokumentatsiooni osade koosseis vastavalt Vene Föderatsiooni normidele ja täitmise erinõuded on sätestatud resolutsioonis 87. Paljud on huvitatud kehtivatest õigusaktidest ja nende selgitustest selle resolutsiooni kohta, nii et peaksite uurima, mis on uus selles seaduses ilmus selleks aastaks ja milline näeb välja selle nõuete loetelu.
projekti dokumentatsiooni koosseisu kohta
Selle sätte kirjutamisel viitas valitsus linnaplaneerimisele ja selle Vene seadustikule. Vastavalt Art. Käesoleva seadustiku artikli 48 kohaselt tehti kindlaks dokumentatsiooni sisu. Põhinõudeid hakkasid esitama ministeerium, kelle pädevuses ehitus asub, samuti Föderatsiooni turvateenistus. Samuti võib Föderatsioon saada soovitusi dokumentide koostamiseks riikliku transpordiameti kaudu. Paljude muude teenuste nõudmisel võidakse esitada lisanõue. Esimene trükk ja täpsustused pidid jõustuma 2008. aasta veebruaris. Seejärel määrati veebruari lõpus igale nõuete aspektile tähistus.
Projekti dokumentatsiooni koostamise föderaalseaduse muudatused
Vene Föderatsiooni valitsuse 16. veebruari 2008. aasta määrus projekti dokumentatsiooni koosseisu kohta 87 muudatustega tuli heaks kiita 2016. aasta jaanuaris. Enne seda muudeti valitsuse otsusega rohkem kui ühte paragrahvi aprillis ning möödunud aastatel aprilli lõpus, detsembris, märtsis, augustis, juulis, mais ja juunis. Viimane redaktsioon sai täiskogu otsusega väikese täienduse ja mõni lõik tuuakse sisse uues redaktsioonis. Täna saate juhtkirja lugeda tasuta. 2016. aastaga oma arvuti kaudu või laadige alla asendiplaan.
Vene Föderatsiooni määrus projekti dokumentatsiooni koostamise kohta koos muudatustega sisaldab järgmisi jaotisi:
- Põhisätted;
- Lineaarse ehitusprotsessi projekti koosseis;
- Kapitali tootmise ja tootmisega mitteseotud ehitusprotsessi osade koosseis.
Märkused resolutsiooni 87 kohta
Viimased kommentaarid selle seaduse planeerimisdokumentide kohta näitavad selgelt uute sätete asjakohasust. Näiteks, föderaalseadus omab projekteerimise tööetapi nõuete loetelu. Seoses kommentaaridega saab täpsemalt aru, mida teha, kui seaduse konkreetse postituse tingimus on täidetud, kuidas toimib selle dekreedi jõud ja kuidas süsteem teostab tehnoloogilist järelevalvet.
GIP-i vanne vastavalt 87. resolutsioonile
Selles Vene Föderatsiooni sättes ei ole GIP-i vannet reguleeritud, kuigi seal peaks olema tema märge või kanne projekti kohta. Alati peab olema ISU sertifikaat, pitser ja allkiri. See võimaldab anda teavet, et projekti skeem on koostatud vastavalt nõuetele ja arendus on ametlikult sertifitseeritud.
Projekti dokumentatsiooni jaotiste loend vastavalt föderaalseadusele 87
Olenevalt konstruktsioonist, mille puhul seda sätet on vaja kohaldada, muutub valim ja koostamise etapp. Kokku sisaldab seaduse täiendus kahte tüüpi ehitust - joonobjektid ja kapitaalehitus. Objekti tasub liigitada ja rakendada teksti- ja graafiline disain. Paljud juriidilised portaalid, näiteks tehniline ekspert, konsultant või konsultant pluss, on selleteemaline abi aegunud. See viitab sellele, et täna on projektide kirjutamise järjekord huvitav rohkem kui ühele organisatsioonile. Tasub kontrollida olekut maatükk, hooned ja rajatised vastavalt käesolevale seadusele ning seejärel järgige seda kirjalikult.
Üldine seletuskiri määruse nr 87 kohta
Vastavalt sätte tekstile on üld seletuskiri ja selle areng. Projekt peab sisaldama selliseid köiteid ja jaotisi, mis on resolutsioonis kirjeldatud. Näiteks tuleks märkida hinnang, toiteallikas, olulised koodid, võrgu kättesaadavus, projekti keskkonnaaspekt, ohutus ja asjatundlikkus, energiatõhusus jne. Samuti peaks projekt ise toimima õige arengu tagajana, näiteks on oluline hoida keskkonda, kui tegemist on Moskva tuumajaama või autopesula dokumendiga. Kui mõni oluline avalik sõlm on blokeeritud või kui mõni taristuosa tuleb eemaldada, tuleb lisada load. To valmis dokument saab kasutada köitmist või voltimist ning pannakse ka vastuvõtmise kuupäev.
