Gips hjelp i henhold til dekret 87-prøven. Generelle prosjektdata

Lagt ut 04/01/2015

MS Podolsky, styreleder for underkomiteen for organisering av aktivitetene til sjefsprosjektingeniører i komiteen for teknologisk design av industrielle anlegg ved National Association of Designers and Surveyors, vitenskapelig direktør for International School of Chief Engineers (sjefarkitekter) for prosjekter ved MGSU

A. V. Litvinov, stedfortreder Generaldirektør Konsulentsenter "TsNIO-project", medlem av Council of the International School of Chief Engineers (Chief Architects) prosjekter ved MGSU

I moderne forhold ledelse, har kunden muligheten til å velge en designorganisasjon (programvare) i henhold til det optimale forholdet mellom vilkår, pris og kvalitet på tjenestene som tilbys. Med tilsynelatende likhet mellom de listede kriteriene, er det kvaliteten prosjektdokumentasjon kan være kritisk for programvaresuksess i konkurransekamp... Kvaliteten på prosjektdokumentasjonen vurderes både av objektive parametere - samsvar med kravene i gjeldende regler og forskrifter, og av subjektive - ved å maksimere kundetilfredshet. Både disse og andre parametere endres kontinuerlig: kunder går fra standard design til individuell design, månedlige endringer og tillegg til det regulatoriske og tekniske og lovgivningsmessige rammer, nye byggematerialer, nytt utstyr, teknologier osv. dukker opp. Den vanlige kunden er "fornøyd" eller "ikke fornøyd" med prosjektdokumentasjon, suppleres med behovet for stadig å forbedre kundetilfredsheten, og dette er nedfelt i ideologien til internasjonale standarder ISO 9000-serien.

For å sikre den nødvendige kvaliteten på produktene, bør programvare, hvis ikke holde tritt med vitenskapelig og teknologisk fremgang, i det minste holde tritt med å tilby kunden nye, originale og pålitelige designløsninger.

Hva forhindrer den reelle forbedringen av sjefingeniørene (sjefarkitekter) for prosjekter (GUI)? Etter vår mening, for det første, de rådende uriktige stereotypene angående stedet og rollen til GUI-er i designprosessen, som overføres fra generasjon til generasjon av designere, og for det andre utilstrekkelige kvalifikasjoner for programvareledere i saker knyttet til GUI-aktivitetene, noe som ikke tillater dem å ta tilstrekkelig avgjørelser, for det tredje, mangelen på en klar ide om hva kvaliteten på en designløsning består av og for hvilken del av det GUI er ansvarlig, for det fjerde en forenklet forståelse av kvalitetsdannelsesmekanismen, inkludert når den implementeres av underdesignere, og til slutt , for det femte fordi de fleste designere ennå ikke er klar over viktigheten av GUIs rolle i å redusere kostnadene designarbeid.

Det ville være galt å tro at programvareledere og GUI-er selv ikke ønsker å eliminere de ovennevnte årsakene, men deres forsøk gir ikke merkbare resultater, for i stedet for å stole på fakta som åpenbart dikterer riktige beslutninger, blir de ledet av tidligere erfaring og subjektiv meninger som ikke oppfyller tidens krav.

I prosessen med å diskutere disse spørsmålene befant vi oss ofte på motsatte sider av barrikaden med mange av våre kolleger - med en slags "kollektiv motstander", hvis synspunkter ble dannet historisk og som fremdeles lever i den tidligere økonomiske virkeligheten. Denne artikkelen er en ekstra innvending mot den "kollektive motstanderen".

Som kjent, moderne ledelse anbefaler dokumentere viktige forskrifter, men fremveksten av en hvilken som helst regulering bør gå foran dannelsen av prinsipper som etablerer for eksempel "langs eller over elven" en bro vil bli bygget. Dette er en viktig del av regelverk. På dette stadiet må det oppnås enighet i fagmiljøet, hvoretter enhver reguleringsbegrensning ikke må være i strid med de avtalte prinsippene.

Dessverre hersker det i virkeligheten “dårlige stereotyper”, som i de fleste tilfeller ikke har noe å gjøre ikke bare med vitenskapen om organisasjon og produksjonsledelse, men ofte bare med sunn fornuft.

La oss dvele ved noen, etter vår mening, feilaktige ideer, og bli kvitt som er en reell reserve i utviklingen av designbransjen:

1. GUI er ansvarlig for kvaliteten på design (arbeids) dokumentasjonen, det vil si GUI er ansvarlig for alt.

Det er umulig. Krav til stillingen eller, som de sier i dag, "ansvar og autoritet" til GUI har historisk korrelert med den økende kompleksiteten i kravene til designobjekter, samt med endringer i kundens forventninger til designresultater. Tidligere ble design og konstruksjon ledet av en ekspert som tok alle beslutninger. For tiden er ISUs hovedoppgave å sikre den nødvendige dynamikken i investeringene, samt inntekt til kunden fra gjennomføringen av prosjektet, tilstrekkelig til å kompensere investorene for ressursene de har investert og risikoen. Dermed tas alle avgjørelser i utformingen av GUI i henhold til kriteriet økonomisk effektivitet design, konstruksjon og drift av anlegget. Derav kravene til hans kvalifikasjoner. Fortsatt tar resten av deltakerne i designprosessen avgjørelser om kriteriet teknisk optimalitet, og denne tilstanden implementeres i prosessen med å koordinere designbeslutninger av hovedspesialistene i prosjektseksjonene.

2. "Eeden" til GUI fjerner ansvaret for kvaliteten på design (arbeids) dokumentasjonen fra resten av designdeltakerne.

ISU er med andre ord ansvarlig for at prosjektet overholder normer og standarder for design, bygging og drift av anlegg, standarder for selvregulerende organisasjoner, individuelle kundekrav til teknisk nivå og objektenes kvalitet, arkitektoniske uttrykksevne og sosiale betydning. Vi anser det som nødvendig å gå tilbake til betydningene: ansvar for hva og i hvilke tilfeller.

Det er åpenbart at ansvar kan oppstå hvis et negativt resultat av arbeidet avsløres at spesialisten har utført personlig eller personlig sjekket det; hvis det er en tilsvarende signatur, støttet av en dato, og også dokumentert for hva og til hvem ansvaret holdes, og når den avsluttes. den obligatoriske vilkår for utbruddet av personlig ansvar. Ellers er det kollektivt uansvar. La oss gi et eksempel. Som du vet må tegningene inneholde signaturer: "utviklet", "kontrollert" og "normativ kontroll". La oss ta hensyn til det faktum at signaturene er gitt når det gjelder handlinger, det vil si at de svarer på spørsmålet: hva gjorde du? - utviklet; Hva gjorde du? - oppfylte standardkontrollen, etc. Det er umulig å tillate "initiativ" til designorganisasjoner og utseendet på tegningene av signaturer fra avdelingsledere, sjefspesialister, prosjektingeniører, etc. Vekten er forskjøvet, og signaturene begynner å bestemme ikke "hva som gjorde", men "hvem gjorde ".

Som allerede nevnt representerer signaturen ansvar. Ingen signatur - intet ansvar. Siden ansvar har grenser, er det nødvendig å bli enige om hvor de går, det vil si å sørge for at alle like forstår ansvarsområdet. Betydningen av avtalen er som følger: hver tegning har innhold ("hva" vises) og design ("hvordan" vises). Entreprenøren er ansvarlig for innhold og design. For innholdet - før inspektøren, for designet - før den normative kontrolleren. Ansvaret til utføreren opphører i det øyeblikket inspektøren og tilsynsinspektøren setter underskrifter. Deretter er det nødvendig å avgjøre hvem inspektøren og den normative kontrolløren er ansvarlig for. Ideelt sett bør dette være en kunde som virkelig er interessert i konsistensen av signaturen og resultatet. I det meste designorganisasjon det er umulig å finne de som følger inspektøren og standardkontrolleren. Men kan det være et GUI? I dette tilfellet vil GUIs signatur bety at han nok en gang sjekket innholdet og utformingen av tegningen og tok ansvar for seg selv, inkludert for "overholdelse i prosjektet av normer og standarder for design, konstruksjon og drift av anlegg ...", etc. og etc. Men GUI kan ikke fysisk sjekke alle designløsninger for å overholde alle standarder og alle krav. Derfor er ansvaret for ISU for alt generelt ikke noe annet enn en formel, formelt på grunn av umuligheten av henrettelse og farlig, om nødvendig, å straffe for andres skyld. ISU er bare en av mange forfattere av et teaterstykke som heter "utarbeidelse av prosjektdokumentasjon".

3. Hvis det skjer noe alvorlig på byggeplassen, vil brukergrensesnittet bli satt først.

Hvis noe virkelig alvorlig skjer, vil etterforskeren, ved å utpeke en rettsmedisinsk teknisk undersøkelse eller gjennomføre flere slike undersøkelser, bestemme designeren som for eksempel utførte designberegningen og brukte feil koeffisient, så vil han bestemme den som sjekket beregningen, og det er denne personen som vil presentere beskyldning, men retten kan under visse omstendigheter straffe eksekutøren og inspektøren.

4. GUI må være den mest kvalifiserte designeren i alle deler av prosjektet.

Det er klart at dette rett og slett ikke kan være, fordi prosjektdokumentasjonen inneholder minst ti spesialiserte seksjoner, hvor arbeidet forutsetter tilstedeværelse av mer enn tjue spesialiteter. Denne "dårlige stereotypen" strekker seg også til ideen om utnevnelse av en spesialist til stillingen som sjefinspektør. Det tilrådes imidlertid å ta en beslutning om utnevnelsen av en brukergrensesnitt basert på konkurransedyktig utvalg og bli styrt av helt andre kriterier.

Søkeren til stillingen som overingeniør må av søkeren underbygge muligheten for å oppnå høyere tekniske og økonomiske indikatorer for det projiserte anlegget, redusere den opprinnelige design- og konstruksjonstiden, redusere arbeidsintensiteten (kostnaden) for designarbeid, gunstigere bosettingsforhold for designorganisasjonen med deltakerne i arbeidet, samt utvide listen over tilleggskrav kunde for designobjektet (7.2.1 "d" GOST R ISO 9001-2008) osv. GUI-omdømmet er spesielt viktig: karakter, omgjengelighet, flid, engasjement, effektivitet, punktlighet, anstendighet, evne til å forhandle, oppmerksomhet, høflighet, respons, effektivitet, etc.

For sivile eiendommer kan en økonomisk og arkitektonisk utdanning være en fordel når den blir utnevnt til stillingen som sjefsprosjektarkitekt (GAP). Den andre prioriteten er økonomisk utdanning, den tredje er arkitektur og til slutt bare ingeniørfag.

For industrielle anlegg (teknologisk design) kan en fordel ved utnevnelse til stillingen som Chief Project Engineer (GIP) være tilgjengeligheten av økonomisk utdanning og teknologisk utdanning som tilsvarer detaljene til designobjektet. Den andre prioriteten er økonomisk utdanning, den tredje er teknologisk og til slutt bare engineering.

I både første og andre tilfeller må Chief Engineer (GAP) ha en kvalifikasjon i prosjektledelse. Basert på resultatene av det konkurransedyktige utvalget, blir ISU utnevnt til stillingen etter riktig rekkefølge av programvaresjefen.

5. Hvis det oppstår uenigheter mellom hovedspesialistene om delene av prosjektet, tar ISU den endelige avgjørelsen.

Tenk deg følgende bilde: Hovedspesialisten - en elektriker i sin seksjon av prosjektet tok en avgjørelse om at sentralbordet skulle være mellom slike akser og i en slik høyde av bygningen. Sjefsspesialisten, en varmetekniker, lokaliserte et varmepunkt på samme sted. De kommer til GIP for å "forene" dem. Naturligvis er kvalifikasjonene til hver av sjefspesialistene i den aktuelle spesialiteten høyere enn sjefingeniøren. Hvis ISU diskuterer dette problemet med dem i det foreslåtte tekniske planet, er han åpenbart i en ulempe. Han burde flytte diskusjonen til det økonomiske planet og si at det ene alternativet koster så mye, og det andre - så mye, idet han ikke bare tar hensyn til byggekostnadene, men også driftskostnadene, samt den mulige risikoen forbundet med endringer i utstyrskostnadene. Ved å ta og begrunne sin beslutning fra et økonomisk synspunkt, må ISU, som er ansvarlig for denne beslutningen overfor investoren, søke fra spesialistene den riktige tekniske løsningen. I dag er det få av GUIene som kan handle på denne måten, men dette er formålet med GUI, hans del av ansvaret for kvaliteten på designløsninger.

6. Overingeniøren må først og fremst ha en teknisk spesialitet.

Vi har allerede snakket om hvilken spesialitet og hvorfor sjefingeniøren skal ha. Under forholdene til den akselererte vitenskapelige og tekniske utviklingen, avhenger kvaliteten på prosjektdokumentasjonen direkte av den systematiske avanserte opplæringen til sjefsingeniører. I dag må ISU være kompetent i organisering og ledelse av designprosessen, metoder for å sikre den økonomiske effektiviteten til design, konstruksjon og drift av anlegget for å få sin posisjon på et konkurransedyktig grunnlag. Men selv vellykkede fungerende Internett-leverandører føler seg ikke tilstrekkelig med kunnskap om disse spørsmålene, prøv å kompensere uavhengig av hullene i deres kompetanse.

For å løse disse problemene, på initiativ fra NOPRIZ-komiteen for teknologisk design av industrielle anlegg og Institutt for konstruksjon og arkitektur (ISA) fra National Research Moscow State Construction University (MGSU), med deltakelse fra konsulentsenteret "TsNIO-prosjekt" og komiteen for kontinuerlig yrkesopplæring i byggebransjen Den russiske union byggere (RCC) organiserte International School of Chief Engineers (Chief Architects) prosjekter. Skolerådet inkluderer kjente Russland og CIS-landene er spesialister innen design og kvalitetssikring av design (arbeids) dokumentasjon. Styreleder for International School of Chief Engineers (Chief Architects) for prosjekter Igor V. Meshcherin har unik opplevelse arbeid og GAP og GIP i Sovjetunionen, Russland, USA og Italia.

Informasjon om International School of GIPs (GAPs), inkludert gjennomføring av spesifikke kurs, blir lagt ut på nettsidene til ISA MGSU, National Association of Designers and Surveyors, TsNIO-project, så vel som på Projector-nettstedene i Russland, Kasakhstan, Hviterussland og Ukraina.

Hovedmålet med International School of GIPs er satt em av videregående opplæring for å sikre opplæring av høyt profesjonelt personell i byggtekniske prosjekter. Programmene som oppfyller moderne krav, den praktiske orienteringen av kursene gjør at vi kan møte behovene til teknologisk og arkitektonisk og konstruksjonsdesign, for å opprettholde en kontinuerlig profesjonell vekst og reproduksjon av grafiske brukergrensesnitt, samt å forberede seg etter ordre fra designorganisasjoner personellreserve for å fylle innleggene til GUI.

Det er to hovedprodukter i "utdanningsporteføljen" til International School of ISPs:

Det foreslåtte omskolingssystemet for brukergrensesnitt er fleksibelt, tilstrekkelig for tidens behov og svarer til de virkelige kravene til ekstremt travle praktisk jobb designere. Innholdet i programmene balanserer teoretisk og praktisk kunnskapsamt erfaring med designledelse. Det er veldig viktig at programmet forutsetter en bred territoriell dekning av lyttere og bekvemmeligheten ved å lære, blant annet gjennom bruk av moderne prinsipper, former og metoder for undervisning: modularitet, læring "til poenget", variasjon i studieterminene, fjernundervisning osv.

Hovedtemaene som blir diskutert på kursene til International School of GIPs ved MGSU:

1. Situasjonen på byggemarked og dens innvirkning på ISUs aktiviteter.

2. De viktigste endringene i innholdet i begrepet "kvalitetsstyringssystem" i forhold til GUI-arbeidet.

3. Fordeling i designorganisasjonen (PO) av ansvar for utvikling av designløsninger og kvaliteten mellom den første lederen, sjefingeniøren, produksjonsdirektøren, GUI, teknisk avdeling og produksjonsavdelinger (workshops) i prosessen med klargjøring, frigjøring og implementering av design (teknisk) dokumentasjon i konstruksjon , inkludert kontroll, verifisering, analyse, avtale, validering og godkjenning av design og estimatdokumentasjon.

4. Avklaring av rolle og plassering av GUIer i den kundeorienterte programvaren “end-to-end prosess”: “interaksjon med programvarekunder” - “dannelse og støtte av programvareordreporteføljen” - “utarbeidelse og frigjøring / implementering av design (arbeids) dokumentasjon” - “støtte for prosjektgjennomføring i konstruksjon "-" oppfyllelse av garantiforpliktelser for programvareprosjekter implementert i konstruksjon. "

5. Leder for produksjonsavdelingen: designer eller leder (leder)? Interaksjon med GUIer. Hovedobjektene for ledelsen av lederen for produksjonsenheten: arbeidsressurser, arbeid, tid, økonomi, materielle ressurser; underordning, makter, hovedfunksjonelle plikter (ansvar) til leder av produksjonsenheten, kriterier for evaluering av hans aktiviteter.

6. Fremgangsmåten for "lansering" arbeider med utarbeidelse av prosjektdokumentasjon i samsvar med den inngåtte generelle designavtalen Modellkontrakt med en underorganisasjon design organisasjon (STR); prosedyrer for evaluering, valg (utvalg) og revaluering av programvare med åpen kildekode; begrepene underleveranse og outsourcing.

7. Interaksjon av GUI med kontraktsavdelingen, teknisk arkiv, prosjektfrigivelsesavdeling. Grunnleggende krav til ISU i systemet for utøvende disiplin.

8. Analyse av ISUs nye ansvar; typisk stillingsbeskrivelse GUI; krav til GUI ved feltovervåking (inkludert av underdesignere); GUI og spørsmål om teknisk re-utstyr, utvidelse av virksomheten, modernisering, overhaling etc.

9. Overvåke kundetilfredshet med prosessene og resultatene i designorganisasjonen.

10. GUIs rolle i å utvide typene produkter (tjenester) til designorganisasjonen. Dannelse av GUIs rykte blant deltakerne i investeringsprosjektet.

11. Ledelse av underdesignere. Moderne krav til utvalget av deltakere i designet.

12. Kommentarer til utkastet til nye organisasjons- og metodedokumenter for ISUer: Standard profesjonell aktivitet ISU, Anbefalinger for organisering av ISUs aktiviteter, ProfilyuGIP, Krav til forberedelse og utnevnelse av ISU, som er utviklet i underkomiteen for organisering av aktivitetene til sjefsprosjektingeniører i komiteen for teknologisk design av produksjonsanlegg for NOP i inneværende år.

13. Forhandle ved inngåelse av kontrakter og fastsettelse av kontraktspriser. Typer kontrakter.

14. Samhandling med statlig og ikke-statlig ekspertise.

15. Juridiske og organisatoriske designbaser, reguleringsdokumenter relatert til GUIs arbeid, inkludert GOST R 54869-2011, samt EUROCODES-systemet.

16. Kostnaden for designarbeid. Grunnleggende indeks og ressursmetoder for beregning av kostnadene. Skjemaer for estimeringsdokumentasjon. Vurdering av den økonomiske effektiviteten til designløsninger.

17. Prosjektrisikostyring. Definisjon og identifisering av risikoer (risikokategorier, kjente risikoer og ukjente risikoer, størrelsen på risikoen, sannsynligheten for forekomst og graden av innflytelse av risikoen); budsjettering for risikostyring; bestemme sannsynligheten for å oppfylle de angitte tidsfrister og prosjektbudsjett; metoder for risikosvar (unngåelse, overføring, avbøting og aksept); kontroll av risikosymptomer.

18. Deltakelse i anbud for å skaffe kontrakt for design og kartleggingsarbeid.

19. Hovedbestemmelsene i kvalitetsstyringssystemet i designorganisasjonen som oppfyller kravene i GOST ISO 9001-2015.

20. Funksjoner og innhold i kundens tekniske tilsyn. Statlig anleggstilsyn.

21. ISUs kompetanse innen egenopplæring og videregående opplæring.

22. GUI, GAP i funksjonelle, organisatoriske og økonomiske strukturer i designorganisasjonen.

23. ISUs markedsførings- og salgskompetanse.

24. ISUs kompetanse når det gjelder å bestemme hans fullmakter, rettigheter og ansvar.

25. ISUs kompetanse i å vurdere effektiviteten og effektiviteten av hans profesjonelle aktiviteter og motivasjon.

Siden mai 2015 har en tilleggsmodul "Evaluering av den økonomiske effektiviteten til designløsninger" (30 akademiske timer) blitt inkludert i programmet for International School of ISPs. Programmets totale volum blir 80 ac. time. Klassene i denne modulen gjennomføres av lærere fra State Academy of Investment Specialists (GASIS) ved National Research University "Higher School of Economics" Studentene får også et GASIS-sertifikat.

Temaene for utdanning, rådgivning og forskningsprogrammer som tilbys av International School of ISPs, er fokusert på å løse de grunnleggende problemene som designorganisasjoner står overfor for tiden gjennom reell avansert opplæring av nøkkeltall i designprosessen - ISPer.

På hovedtemaene i programmet for International School of GIPs har konsulentsenteret "TsNIO-project" utviklet seg.

Og la oss nå vende oss til mekanismen for å danne kvaliteten på designløsninger for tydelig og entydig å definere grensene for maskiningeniørens ansvar.

Noen få generelle bestemmelser for design:

1. Ethvert prosjekt for bygging er en kombinasjon av tre modeller:

Modeller av det fremtidige objektet (romplanlegging og tekniske løsninger);

Modeller av opprettelsen (Construction Organization Project);

Modeller for drift (organisering og styring av produksjonen).

2. Dannelsen av en designløsning består av dens faktiske aksept, og da er det nødvendig å bekrefte at det er samsvar, med andre ord å kontrollere. Selve vedtakelsen av en designbeslutning er et valg fra alternativer, og bekreftelse av samsvar har mange forskjellige alternativer og følgelig mange begreper som tilsvarer disse alternativene. I utgangspunktet avhenger alternativene av tid, sted og standarder som er valgt for bekreftelse.

Kvaliteten på en designløsning består av fire hovedegenskaper. Hver av disse egenskapene er dannet av noen i programvaren og er ment for noen. Den som danner kvalitetseiendommen bærer personlig ansvar for dette. Den første er "teknisk gjennomførbarhet", det vil si at designløsningen må være slik at den kan implementeres under bygging. Det trengs først og fremst av en entreprenør, og det er dannet av teknikere, ingeniører og sjefspesialister for produksjonsavdelinger. Det andre er "informasjonsevne", det vil si at designløsningen må inneholde all informasjon som er nødvendig for å utføre bygge- og installasjonsarbeid, bestille utstyr, få alle nødvendige tillatelser og godkjenninger. Kunden og entreprenøren trenger det. Denne eiendommen er dannet av teknikere, ingeniører og sjefspesialister for produksjonsenheter. Den tredje er "økonomisk gjennomførbarhet" av designløsningen, det vil si at designløsningen må være økonomisk konkurransedyktig under bygging og drift av anlegget. Dette er nødvendig for hovedpersonen i markedet - investoren, den er dannet, og ISU er ansvarlig for dette. Fjerde - "konsistens", det vil si at alle designløsninger for prosjektet må avtales. Dette er først og fremst nødvendig for designerne selv, og hovedspesialistene i prosjektseksjonene er ansvarlige for dette.

Designbeslutninger tas på fem nivåer. La oss vurdere disse nivåene ved hjelp av eksemplet i prosjektdelen. Det første nivået vil være "noder, detaljer". På dette teknologinivået tas det beslutninger om armeringsmasker, innebygde deler osv. Det andre nivået er "elementer". På dette nivået designer ingeniører bjelker, søyler, frittstående fundament, og så videre. For det tredje "komponenter". Senior og ledende ingeniører designer plater, belegg, omsluttende strukturer, etc. Fjerde nivå "prosjektdel". På dette nivået hovedspesialist tar en beslutning om bygningens strukturoppsett og strukturens viktigste styrkeparametere. Det femte nivået er “tekniske og økonomiske indikatorer for prosjektet”. ISU er ansvarlig for å ta beslutninger på dette nivået.

La oss referere til "bekreftelse på samsvar med designløsningen." Dette er kontroll, vurdering, verifisering, analyse, validering, avtale og godkjenning av designløsninger. Her er det viktig for oss å definere grensene for ISUs ansvar.

Kontroll innebærer å korrelere den adopterte designløsningen med gjeldende regelverk (regler), det vil si forskriftsdokumenter som for tiden fungerer i byggebransjen (Urban Planning Code of the Russian Federation, SNiP, SN, GOST, VSN, etc.). Resultatet av kontrollen - "tilsvarer" eller "samsvarer ikke" med designløsningen til de angitte reguleringsdokumentene.

Evaluering - den samme kontrollprosedyren, bare i tillegg til "tilsvarer" eller "samsvarer ikke" er det indikert hvor mye "tilsvarer" eller "ikke samsvarer". Resultatet av vurderingen er som regel gitt i kvantitative termer, for eksempel er branngapet mellom bygninger mindre enn standarden med 10 meter.

Den såkalte normative kontrollen er i samme rad som kontrollen, med den eneste forskjellen at GOST SPDS brukes til å sammenligne den adopterte designløsningen med reguleringsdokumenter.

Verifisering innebærer å sammenligne den adopterte designløsningen med input-designdataene (designoppgave, innledende designdata, tekniske forhold). GOST ISO 9001-2011 setter ganske klart kravene til verifisering av designløsninger, inkludert planleggingskontroll og registrering av resultatene. Spesielt i 7.3.5 sies det at “Som planlagt bør det utføres verifisering for å sikre at design- og utviklingsoutputen oppfyller kravene til design- og utviklingsinngang. Registreringer av testresultatene og alle nødvendige tiltak må opprettholdes og vedlikeholdes. "... Siden det i "input data" som regel er gitt tekniske og økonomiske indikatorer (krav) for designdokumentasjon, kontrollerer ISU at de er i samsvar med de som faktisk er mottatt.

Analyse - en kollektiv handling under ledelse av en GUI - gjør det mulig å forutsi konsekvensene av konstansen i den eksisterende designprosessen når det gjelder tekniske og økonomiske egenskaper ved designløsninger, designkostnader og varighet. I punkt 7.3.4 i GOST ISO 9001-2011, så vel som for verifisering, er kravene til analysen etablert, nemlig: “Systematiske design- og utviklingsgjennomganger bør utføres på passende stadier i samsvar med planlagte aktiviteter for å vurdere evnen til design- og utviklingsresultatene til å oppfylle kravene, samt identifisere eventuelle [design og utvikling] problemer og foreslå nødvendige tiltak. Deltakere i slike gjennomganger bør omfatte representanter for funksjonene som er relevante for design- og utviklingsfasen som analyseres. Registreringer av analyseresultater og alle nødvendige tiltak bør opprettholdes og vedlikeholdes. " Merk at analysen skal planlegges og dokumenteres. Det er også åpenbart at analysen ikke kan utføres i begynnelsen av designet, siden det ikke er noe å analysere ennå, og på slutten av designet, fordi toget allerede har gått og prosessen er fullført. I utformingen er ISU ansvarlig for analysen. Som regel samler GUI med jevne mellomrom lederne for produksjonsavdelinger og sjefspesialister i delene av prosjektet under designprosessen og diskuterer med dem designfremdriften og de tekniske og økonomiske egenskapene til designbeslutningene for å være sikker på at mottatte designmaterialer vil motsvare "input data" på slutten av designet. ...

Koordinering innebærer tillit til at denne designløsningen ikke er i strid med designløsninger for andre deler av prosjektet, dvs. for eksempel blir designløsningen til prosjektseksjonen av prosjektet sammenlignet med designløsningene til de elektriske, sanitære eller varmetekniske delene av prosjektet.

Ansvaret for å sikre at godkjenningen blir utført ligger hos ISU, og tilsvarende sjefspesialister for delene av prosjektene er ansvarlige for at godkjenningen er korrekt.

La oss huske hva "validering" er. I design er to situasjoner med bekreftelse mulig: i det første tilfellet kan det gjøres direkte "på papir", det vil si designløsningen er på dataskjermen. For eksempel er en designløsning en beregnet og strukturert bjelke som må tåle den tilsvarende belastningen. For å bekrefte samsvar er det nok å bruke den samme beregningsmetoden som ble brukt når du tok denne beslutningen (eller en alternativ), og hvis denne metoden er bevist og pålitelig, vil den gjentatte beregningen gi absolutt tillit til riktigheten av designbeslutningen. Eller et annet eksempel, i designoppgaven, er sammensetningen av lokalene i tilsvarende etasje i bygningen angitt og de nødvendige områdene er indikert. Designløsningen for denne planløsningen kan enkelt verifiseres ved å sammenligne den med de opprinnelige dataene. Det skal understrekes at slike designløsninger i det totale designvolumet er minst 80-90 prosent. Disse inkluderer designbeslutninger tatt med standarddesign, standardmonteringer og deler, godkjente individuelle tidligere utviklede designløsninger som blir gjenbrukt, utstyrskataloger som er sertifisert på foreskrevet måte, etc. osv. Med andre ord, tale det handler om pålitelige, testede, mange ganger anvendte, utvilsomme designløsninger.

Den andre situasjonen er når en designløsning ikke kan verifiseres pålitelig ved hjelp av tradisjonelle verifiseringsteknikker. De kan bare kontrolleres under bygging eller drift av det konstruerte anlegget, samt ved å utføre spesielle tester under forhold som er så nær konstruksjonen eller driften av anlegget som mulig. Et slikt behov oppstår når avanserte teknologier eller materialer som allerede er anbefalt eller kunngjort i reklame, nye beregningsmetoder, utstyr som aldri har vært brukt før, teknologiske løsninger som ikke har noen analoger osv. Blir brukt. For eksempel på utstillingen ble designere kjent med et nytt takmateriale. som er sterkt annonsert og egenskapene til dette materialet er imponerende.

Det kan tas en beslutning om å bruke dette materialet til et tak med et areal på 20 tusen kvm. kvadratmeterImidlertid er det spesifikt bestemt at du under konstruksjonen først må fullføre en takseksjon på 10 kvadratmeter, skape en dynamisk belastning på den i en viss tid, helle vann på toppen og se hvordan takets nedre overflate oppfører seg samtidig. Hvis testresultatet er positivt, vil designerne gi tillatelse til å produsere resten av taket. Noen ganger oppstår et slikt behov på grunn av den høye usikkerheten om geologiske forhold i vanskelige konstruksjonsområder, når etterforskere ikke (inkludert av økonomiske årsaker) kan modellere jordegenskapene med tilstrekkelig nøyaktighet på bestemte steder i fundamentene. I disse tilfellene indikerer de behovet for å kjøre testbunker, og først etter det bekrefter de muligheten for å arrangere et pælefelt under hele objektet.

Dette er designvalidering. Bruken av validering demonstrerer designorganisasjonens engasjement for alt nytt, banebrytende. Dette er et tegn på konkurransekraften til designløsninger, det er ønsket om å ta en ledende posisjon i designet gjennom kontinuerlig forbedring av kundetilfredshet. GUI er ansvarlig for selve valideringen, og hovedspesialistene i prosjektseksjonene er ansvarlige for valideringsinnholdet.

Godkjenning er tillatelse til å overføre den ferdige designdokumentasjonen til kunden. Dette er GUIs ansvar, og han innser det når han signerer fakturaen før han sender dokumentasjonen til kunden.

La oss nå vende oss til ansvaret til GUI assosiert med å redusere kostnadene ved designarbeid. Som du vet er det mange muligheter for å redusere kostnadene, og dette er en "hodepine" for ledelsen og alle ledende programvarespesialister, siden dette praktisk talt er den eneste måten å øke fortjenesten til en designorganisasjon. ISU yter et betydelig bidrag til dette ved å implementere ansvar for ledelsen (outsourcing) av underdesignerne.

For øyeblikket er det mulig å velge underdesignere (SSO) basert på resultatene av deres evaluering, sammenligning med konkurrenter, regelmessig revurdering og GUIs ansvar for dette valget har dukket opp. Et viktig prinsipp begynte å virke mellom fagene i designet, "hvem betaler, han bestiller melodien", ikke bare i en viss tradisjonell forstand, men også som et krav fra den generelle designeren (GP) til stadig å tenke på å forbedre (sikre) kvaliteten og redusere kostnadene ved designarbeidet. I tillegg fastslår loven at bare SE er ansvarlig overfor kunden for kvaliteten på design og estimatdokumentasjon utviklet av programvaren med åpen kildekode. Derfor er det nødvendig å bli styrt av kravene i GOST ISO 9001-2011 og retningslinjene for bruk av outsourcingprosesser // ISO / TS 176 / SC 2 / N 630R2, 24. november 2003).

Generelt kan man skille mellom tre konvensjonelle typer programvare med åpen kildekode:

- "vanlig" - programvare med åpen kildekode som SOE har normale markedsforhold med;

- “protégés” - skapningen til kunden, forholdet til SOE som kunden bestemmer med.

Ved å bruke eksemplet på relasjoner med programvare med åpen kildekode, vil vi sekvensielt vurdere hvert av delsystemene, og ta i betraktning at GUI i noen tilfeller tar beslutninger, og i andre deltar det i adopsjonen.

Evaluering, utvalg og omvurdering av underdesignere.

Dette delsystemet består av to blokker:

Dannelse og vedlikehold av listen (database, register osv.) Av godkjent programvare med åpen kildekode og oppdatering;

Valg av programvare med åpen kildekode fra den angitte listen for å utføre arbeid på et bestemt prosjekt.

Utførelsen av arbeidet i den første blokken er funksjonen til den tekniske avdelingen til programvaren, innenfor den andre blokken er GUIs ansvar

For å danne listen søker programvareingeniøravdelingen, evaluerer, velger og evaluerer programvare med åpen kildekode i samsvar med programvarebehovet ved å bruke kriteriene som er utviklet sammen med GUI.

Det er tydelig at en slik tilnærming ikke garanterer at STR er fullstendig tilstrekkelig til forventningene til SOE på grunn av kompleksiteten i å formalisere noen problemer. For eksempel et spørsmål angående eksistensen av et gyldig QMS og dets samsvar med kravene i GOST ISO 9001-2011. Åpen kildekode reagerer på at QMS fungerer og samsvarer, som det fremgår av sertifikatet fra "N" -te sertifiseringsorgan. Erfaringen med å vurdere oppfyllelsen av visse krav i GOST ISO 9001-2011 av selvregulerende organisasjoner av designere indikerer at mer enn 90% av sertifikatene ble innhentet formelt, ganske enkelt "kjøpt" og ofte ikke har noe å gjøre med en spesifikk programvare med åpen kildekode. Det viser seg at SE bærer reelt ansvar for kvaliteten på design (arbeids) dokumentasjonen utarbeidet av programvaren med åpen kildekode, men valget av programvare med åpen kildekode er basert på "forsikringene" om selve programvaren med åpen kildekode i form av svar på spørreskjemaet. Når du designer et spesifikt objekt, velger GUI som regel en egnet programvare med åpen kildekode fra listen, styrt av tilleggskriterier, inkludert programvaren for åpen kildekode, bevissthet om programvaren med åpen kildekode om egenskapene til et bestemt byggeplass, tidligere kontakter med en bestemt kunde, beredskapen til programvaren med åpen kildekode for å oppfylle bestillingen, og andre.

Før du bestemmer deg for å involvere programvare med åpen kildekode i designet, må GUI besøke organisasjonen direkte. Dette er ISUs nye ansvar. Denne teknologien er levert av ISO 9000-serien og kalles "second party" audit. Varigheten av den andre partens tilsyn er ikke mer enn en virkedag (optimalt 3-4 timer).

En så kort varighet forklares med det faktum at ikke hele kvalitetsstyringssystemet for åpen kildekode-programvare blir vurdert, men bare individuelle hovedpunkter. Praksis viser at hvis alt er normalt på disse punktene, vil STR med høy grad av sannsynlighet oppfylle forventningene til SOE.

Det skal understrekes at kunden kun handler med den SOE som han har kontrakt med. Han kjenner kanskje ikke til resten av prosjektdeltakerne. Derfor er forholdet til programvare med åpen kildekode bare et problem for SOE-er. Programvare med åpen kildekode fungerer faktisk som en ekstra strukturell enhet av SOE, som han i prosessen med prosjektgjennomføring må administrere på samme måte som "sin egen" strukturelle enheter, med tanke på tidspunktet og kvaliteten på design (arbeids) dokumentasjonen som er utviklet av programvaren med åpen kildekode, som SE er ansvarlig overfor kunden. Dette definerer også ansvaret til SOE for å administrere programvare med åpen kildekode.

Typen og omfanget av administrasjon av åpen kildekode kan variere i et betydelig område: fra minimum når åpen kildekode utstedes en teknisk oppgave og arbeidet som blir utført aksepteres praktisk talt uten verifisering, til det maksimale når programvaren for åpen kildekode må styres under utførelsen av bestillingen av ledelsen og andre dokumenter som er godkjent av SO. Samtidig utføres en fullstendig sjekk av den fullførte open source design- og estimeringsdokumentasjonen, inkludert involvering av uavhengige eksperter.

Det nødvendige omfanget av ledelsen bestemmes av ISU avhengig av resultatene av vurderingen (revurdering) av STR, inkludert å ta hensyn til informasjonen som er innhentet under den andre partens revisjon, samt avhengig av de planlagte kostnadene til SP for å utføre den innkommende kontrollen over STR-materialene, med tanke på at disse kostnadene øker kostnadene ved arbeidet med prosjektet.

Funksjoner ved administrasjon av programvare med åpen kildekode GUI må formaliseres i de "spesielle vilkårene" i underleverandøravtalen. Allmennlegeteknisk avdeling utvikler en mal for slike “ spesielle forhold", Som gir nesten alle mulige og / eller nødvendige aspekter ved open source management, og ISU, når man analyserer en spesifikk kontrakt med open source-programvare, inkluderer de administrasjonsmetodene som oppfyller vilkårene for et bestemt prosjekt. Jo dypere graden av åpen kildekontroll, jo mindre er volumet av innkommende kontroll av designmaterialer med åpen kildekode, og dermed kostnaden for SE.

Slike forvaltningsmetoder kan omfatte behovet for å:

Koordinering med SE anvendt ved åpen kildekode teknologisk designprosess eller å sikre implementering av designarbeid ved hjelp av teknologisk prosess design brukt av fastlegen;

Koordinering av arbeidsplanen, som programvaren med åpen kildekode skal utvikle på grunnlag av kalenderplan verk knyttet til kontrakten;

Avtaler (etter avtale med SE) av en spesifikk GUI (prosjektleder) for bestillingen overført for utførelse (prosjektseksjon), etc.

Avhengig av graden av styring av programvare med åpen kildekode, kan omfanget av innkommende kontroll ved en SOE variere fra 100% til nesten ingen, dvs. formell omberegning av prosjektdokumenter mottatt fra programvare med åpen kildekode.

Etter overføring av fullført design- og estimeringsdokumentasjon til kunden eller etter at gjenstanden er satt i drift (hvis feltoppsynet ble utført), trenger GUI å fullføre outsourcingprosjektet.

Dette krever:

Sjekk tilgjengeligheten av dokumenter som bekrefter aksept av design og estimatdokumentasjon fra programvare med åpen kildekode, inkludert kontroll av kvaliteten på den spesifiserte dokumentasjonen;

Vurdere samarbeid med STR og rapportere resultatene til teknisk avdeling for oppdatering av listen;

Motta fra åpen kildekode-programvare og overfør informasjon til GP-arkivet om utviklede individuelle effektive designløsninger, inkludert i dokumentasjonen for åpen kildekode, som kan anbefales for gjenbruk;

Forbered en offisiell gjennomgang for programvare med åpen kildekode;

Løs problemet (om nødvendig og mulig) om økonomiske insentiver for programvare med åpen kildekode.

Nå om ansvaret til GUI, som er forbundet med deltakelse i dannelsen av en "portefølje av ordrer" og redusering av programvarekostnader for å finne nye kunder.

Poenget er at i samsvar med punkt 7.2.1 "Prosesser tilknyttet forbrukere" GOST ISO 9001-2011, må programvare definere kravene:

1. Kundespesifisert, inkludert krav til leverings- og etterleveringsaktiviteter.

2. Ikke spesifisert av kunden, men nødvendig for en spesifikk eller tiltenkt bruk av design og estimatdokumentasjon, når kjent.

3. Lovgivningsmessig og annet obligatorisk relatert til dokumentasjon for utforming og estimering.

4. Eventuell ekstra, spesifikk programvare.

Hva som menes med de tre første kravenegruppene (1-3) er mer eller mindre tydelig. La oss i tillegg forklare at "krav som ikke er deklarert av kunden, men som er nødvendige for en spesifikk eller tiltenkt bruk av design- og estimeringsdokumentasjon, hvis kjent", kan omfatte alle kravene til selve programvaren, hvis oppfyllelse som kvalitet, pris og leveringstid for prosjektdokumentasjonen avhenger av.

For eksempel hvis en kunde mottar design- og estimeringsdokumentasjon, som i samsvar med eksisterende designteknologi lagres i en viss tid før den overføres til kunden i teknisk arkiv, vil kravene til selve programvaren angående lagringsforholdene i arkivet til den spesifiserte dokumentasjonen referere til punkt 7.2.1 (2) i standarden. Oppfyllelse av kravene spesifisert i punkt 7.2.1 (1-3) i standarden, kan ikke programvaren oppnå konkurransefortrinn, siden disse kravene nødvendigvis er implementert av alle konkurrenter. Under markedsforhold overlever bare programvare som kan bestemme og oppfylle kravene i punkt 7.2.1 (4). Vi kalte disse kravene "antatt" og klargjorde deres betydning: for det første er de "gjettet", formulert av selve programvaren, for det andre er de ikke godkjent eller koordinert med kunden, og for det tredje gjennomføres deres implementering for vår egen regning AV. Som et resultat mottar kunden designdokumentasjon (tjenester) med uventede parametere for ham eller med parametere som er bedre enn forventet, noe som ikke bare garanterer kundetilfredshet, men gleder ham med den medfølgende design- og estimatdokumentasjonen (levert av tjenesten). I sistnevnte tilfelle kan programvaren være sikker på at kunden kommer tilbake til den gjentatte ganger. Som du vet er det å holde en kunde 5-7 ganger billigere enn å lete etter en ny. Dette er essensen av en grunnleggende ny bestemmelse fastsatt i GOST ISO 9001-2011.

For at oppfyllelsen av kravet spesifisert i punkt 7.2.1 (4) i standarden skal ha en innvirkning på dannelsen av konkurransefortrinn med programvare, er det nødvendig å bestemme eieren av prosessen for dannelse av forventede krav fra kunder, dvs. vil etablere regler for gjennomføring av denne aktiviteten. For programvare burde prosesseeieren sannsynligvis være det overingeniør institutt. "Eieren" av prosessen, det vil si spesialisten som danner forventede kundekrav for et spesifikt prosjekt, skal være GUI. For å avklare er GUI ansvarlig for at kundens forventede krav er bestemt, og hovedspesialistene til produksjonsavdelingene er ansvarlige for innholdet i disse kravene.

Et annet ansvar for GUI dannes når man analyserer kontrakten (avtalen) med kunden. Kundens appel til programvaren kan være på forskjellige måter: informasjon om det vant anbudet (konkurranse); offisielt brev med et forslag om å utvikle prosjektdokumentasjon; telefonsamtale til programvarebehandleren; uformell kontakt gjennom kolleger osv. På tidspunktet for mottak av et av de ovennevnte signalene, anbefales det å utnevne en GUI som skal håndtere analysen av kontrakten før den blir signert av kunden.

Dette ansvaret til ISU innebærer:

Bestemmelse av kretsen av personer som vil delta i godkjenningen av utkastet til avtale og fordelingen av ansvaret mellom dem;

Involvering av de nevnte lederne og spesialistene for å føre forhandlinger (arbeidsmøter) med kunden for å diskutere visse bestemmelser i avtalen, inkludert forhandlinger for å bestemme kontraktsprisen;

Valg fra malbasen til et passende alternativ for en bestemt kunde og designobjekt;

Bestemmelse av behovet og muligheten for å tiltrekke underdesignere og føre foreløpige forhandlinger med dem;

En vurdering av risikoen som kan følge programvarens oppfyllelse av forpliktelsene i henhold til kontrakten.

Hver av disse handlingene i dagens forhold er vesentlig forskjellig fra den praksisen vi kjenner. For eksempel er godkjenningen av et utkast til kontrakt som regel utarbeidet på "Godkjenningsarket", som indikerer det fulle navnet og posisjonen til det tilsvarende lederen, som, hvis en positiv beslutning blir tatt, signerer, eller hvis en negativ gir skriftlige begrunnelser for sin mening. Etter vår mening er det nødvendig å fastslå lederens ansvar for de relevante paragrafene i avtalen. Summen av poengene i "Godkjenningsark" må være lik summen av poengene i avtalen. Dette sikrer det personlige ansvaret til hver leder for oppfyllelsen av kontraktsvilkårene fra designorganisasjonen og den samme forståelsen av de relevante vilkårene i kontraktutkastet av designorganisasjonen og kunden, etc.

Noen designere kan motsette seg materialet i denne artikkelen. Vi er klare for en konstruktiv diskusjon med kolleger i en form som er praktisk for dem.

Sammensetningen av seksjonene i prosjektdokumentasjonen i henhold til normene i Den russiske føderasjonen og de spesifikke kravene til registrering er oppgitt i resolusjon 87. Mange er interessert i gjeldende lovgivning og dens forklaringer til denne resolusjonen, så du bør finne ut hva som er nytt i denne loven i år og hvordan listen over kravene ser ut.

om sammensetningen av prosjektdokumentasjonen

I skrivingen av denne forskriften henviste regjeringen til byplanlegging og dens Russisk kode... I følge art. 48 i denne koden ble innholdet i dokumentasjonen etablert. De viktigste kravene begynte å bli introdusert av departementet, som er ansvarlig for bygging, samt Føderasjonens sikkerhetstjeneste. Også Føderasjonen kan motta anbefalinger om utarbeidelse av dokumenter gjennom statens transportmyndighet. Et tilleggskrav kan være gjenstand for innreise på forespørsel fra mange andre tjenester. Den første utgaven og presiseringene skulle tre i kraft i februar 2008. I slutten av februar ble hvert aspekt av kravene utpekt.

Endringer i føderal lov om sammensetning av prosjektdokumentasjon

Regjeringen i Den russiske føderasjonen om sammensetningen av prosjektdokumentasjonen datert 16. februar 2008 87 med endringer var pålagt å bli godkjent i januar 2016. Før dette ble mer enn en seksjon endret ved regjeringsbeslutning i april og i slutten av april, i desember, mars, august, juli, mai og juni tidligere år. Den siste utgaven, etter avgjørelse fra plenum, fikk et lite tillegg, og et visst punkt vil bli introdusert i en ny formulering. I dag kan du lese red. fra 2016 gjennom datamaskinen din eller last ned planen for situasjonen.

Forordningen til Den russiske føderasjon om sammensetningen av prosjektdokumentasjonen, som endret, inneholder følgende seksjoner:

• Grunnleggende bestemmelser;
• Sammensetning av prosjektet for den lineære byggeprosessen;
• Sammensetningen av seksjonene for kapitalproduksjon og ikke-produksjonsprosessen for bygging.

Kommentarer til dekret 87

Nylige kommentarer til planleggingsdokumentasjonen for denne loven gjør det klart relevansen av de nye bestemmelsene. For eksempel, føderal lov har en liste over krav til designfasen. I forbindelse med kommentarene er det mulig å forstå mer nøyaktig hva jeg skal gjøre hvis vilkåret fra et bestemt innlegg i loven er oppfylt, hvordan kraften i dette dekretet fungerer, og hvordan systemet driver teknologisk tilsyn.

Hovedinspektørens ed ved dekret 87

I denne bestemmelsen i Russland er ikke sjefingeniørens ed regulert, selv om det skal være hans notat eller oppføring til prosjektet. Det må alltid foreligge attest, forsegling og signatur fra brukergrensesnittet. Dette lar deg gi informasjon om at prosjektdiagrammet er skrevet i samsvar med kravene, og utviklingen er offisielt sertifisert.

Liste over deler av designdokumentasjon for 87 FZ

Avhengig av hvilken type konstruksjon det er nødvendig å bruke denne bestemmelsen, endres prøven og stadiene av kompilering. Totalt inneholder lovendringen to typer konstruksjoner - lineære objekter og dryppkonstruksjon. Det er verdt å klassifisere et objekt og bruke regler for tekst og grafisk design på det. Hjelp til dette problemet fordømmes av mange juridiske portaler, for eksempel en teknisk ekspert, konsulent eller consultantplus. Dette antyder at rekkefølgen på skriveprosjekter i dag er interessant for mer enn én organisasjon. Det er verdt å undersøke status for tomt, bygninger og strukturer under denne loven, og deretter følge den skriftlig.

Generell forklarende merknad til 87. oppløsning

I følge teksten til forskriften skal generalen forklarende merknad og dens utvikling. Prosjektet må inneholde slike volumer og seksjoner som beskrevet i resolusjonen. For eksempel bør estimat, strømforsyning, viktige koder, nettverkstilgjengelighet, prosjektets miljøaspekt, sikkerhet og kompetanse, energieffektivitet osv. Angis. Også selve prosjektet skal fungere som garant for riktig konstruksjon, for eksempel er det viktig å bevare miljøet hvis det er et dokument for et kjernefysisk anlegg eller en bilvask i Moskva. Hvis et viktig offentlig nettsted er blokkert, eller du må fjerne en del av infrastrukturen, må du legge ved tillatelser. Det ferdige dokumentet kan bindes eller brettes, og en akseptdato blir stemplet.

Hvordan kan du forholde deg til designere som bruker den avskaffede normen for tretti år siden? En lakmusprøve som viser mangel på designkunnskap er inkluderingen av "GUI ed" i de generelle dataene.

Historien går i det minste tilbake til GOST 21.102-79 "SPDS Generelle data om arbeidstegninger":

"12. I nedre venstre hjørne av det første arket med generelle data for hvert hovedsett av arbeidstegninger, i en rektangulær ramme, legg en oversikt over prosjektets overingeniør, som bekrefter at prosjektet er i samsvar med gjeldende normer og regler, og for bygninger eller konstruksjoner med en brannfarlig og eksplosiv produksjonstilstand, i tillegg sikker drift dem, underlagt tiltakene som er lagt opp til i prosjektet. "

Skifte den GOST 21.101-93 "SPDS Grunnleggende krav til arbeidsdokumentasjon"avlyste denne normen:

" 2.5.4. I generelle retningslinjer lede:

4) en oversikt over at de tekniske løsningene som er tatt i arbeidstegningene, oppfyller kravene til miljømessige, hygieniske, hygieniske, brannsikkerhetsmessige og andre standarder som er gjeldende på den russiske føderasjonens territorium og sikrer sikker drift av anlegget for menneskers liv og helse, underlagt tiltakene fastsatt i arbeidstegningene ; "

Å erstatte den GOST 21.101-97 "SPDS grunnleggende krav til design og arbeidsdokumentasjon" forenklet ytterligere den nødvendige setningen:

"4.2.9 De generelle instruksjonene gir:

d) en oversikt over at arbeidstegningene er utviklet i samsvar med gjeldende normer, regler og standarder. "

GOST R 21.1101-2013 for tiden i kraft i Russland "System med designdokumenter for konstruksjon. Grunnleggende krav til design og arbeidsdokumentasjon " inneholder følgende setning:

"4.3.5 De \u200b\u200bgenerelle instruksjonene gir:

- en oversikt over at arbeidsdokumentasjonen er i samsvar med utstedt designoppdrag tekniske spesifikasjoner, kravene til gjeldende tekniske forskrifter, standarder, retningslinjer, andre dokumenter som inneholder etablerte krav ".

Det er lett å se at ingen av de ovennevnte normative dokumentene, bortsett fra den første, ikke inneholder et ord om ISU. Ta tak i det første grunnleggende settet du kommer over. Finn uttrykket "om samsvar" der. Avhengig av ordlyden, kan du grovt estimere alderen til designeren som utstedte dokumentasjonen :) Hvis du ser "Eden til GUI i rammen", må du være pensjonist, og ikke langt borte: han ble en gang lært på den måten, og i 25 år tenkte han ikke engang å se på standarden.

For de som er i tvil, vil jeg gi et argument til. Det er fortsatt ikke kansellert SNiP 1.06.04-85 "Forskrift om sjefingeniør (sjefarkitekt) av prosjektet. Den inneholder følgende bestemmelser:

"2.2. I samsvar med hovedoppgavene tildeles overingeniøren (sjefarkitekten) for prosjektet følgende oppgaver:

2.2.15. Bekreftelse i materialer prosjektettilsvarende oppføringat utformings- og estimeringsdokumentasjonen for bygging av virksomheter, bygninger og strukturer er utviklet i samsvar med normer, regler, instruksjoner og statlige standarder. "Ikke et ord som er mer krevende å registrere separat i arbeidsdokumentasjonen.

Nå for samlingen vil jeg sitere spørsmålet mitt som er inkludert i samlingen av avklaringer, utgave 2 “Samling av avklaringer av kravene til standardene i designdokumentasjonssystemet for konstruksjon (spørsmål og svar). Utgave 2. - JSC "TsNS", Moskva, 2012 ":

"4. Spesifiser behovet for å sitere" GUI ed "på de generelle databladene. Dette kravet var ikke engang inneholdt i GOST 21.101-97, men et betydelig antall designorganisasjoner fortsetter å oppfylle kravet til den kansellerte GOST 1979 av treghet.

Svar: Ja, fortsetter å utføre "oversikten over samsvar med arbeidsdokumentasjonen", slik tilfellet var i GOST 21.102-79, kansellert i 1993, nå bryter disse designorganisasjonene den gjeldende standarden. I henhold til punkt 4.3.5 i GOST R 21.1101-2009, er en oversikt over RDs samsvar med designoppgaven utstedt av TU, kravene i gjeldende TR, GOST, SP, etc., generelle instruksjoner på de generelle databladene. "

Spørsmålet fortsetter å hjemsøke hjernen, og i Compendium of Explanations, utgave 4 “Samling av avklaringer av kravene til standardene i designdokumentasjonssystemet for konstruksjon (SPDS) (spørsmål og svar). Utgave 4. - JSC "TsNS", Moskva, 2015 " vi leser igjen:

"Spørsmål 5: Er det nødvendig å stille kravet til punkt 4.5.6 i GOST R 21.1101-2013 om samsvar med arbeidsdokumentasjonen med alle normer og regler hver for seg, i en ramme og signere GUI?

Svar: I GOST R 21.1101-2013 er det ingen krav for tildeling i rammen av avsnittet med generelle instruksjoner som inneholder "en oversikt over samsvar med arbeidsdokumentasjonen", og den separate signaturen fra ISU.

Signaturen til personen som utarbeider arbeidsdokumentasjonen (GUI) er obligatorisk i hovedinnskriftene på de generelle databladene for arbeidstegninger og tilleggssignaturer. den samme personen under noen informasjon på de samme arkene er ikke nødvendig.

Å ha to GUI-signaturer i samme dokument (og ofte på samme ark) vil ikke doble dokumentasjonen din.

Ikke forveksle varen i "generelle instruksjoner" i arbeidsdokumentasjonen med "sertifisering av designorganisasjonen" i prosjektdokumentasjonen."